Development of national eHealth system 1 Development of national eHealth system Development of national eHealth Infrastructure Gergely Héja National Healthcare Supply Center 16.02.2017.

Development of national eHealth system Main health IT projects 2 Development of national eHealth system Main health IT projects LIFERAY User interfaces - Portals Event catalogue ePrescription Access rules EHR etc. HISCOM TIOP2.3.1 Business modules TIOP2.3.2 Basic eHealth IT infrastructure TIOP2.3.2 business modules ORACLE Messaging, reporting, validation Registries Central IT infrastructure TIOP2.3.3 – Enhancing the IT infrastructure of healthcare providers

Development of national eHealth system 3 Development of national eHealth system EESZT acts as a “Karabiner” for the health sector It provides a basic IT infrastructure Central dependable and secure IT platform Centralised authentication and authorisation Centralised logging eHealth portal and central business services Centralised access to all relevant code systems and registries of the healthcare sector Centralised messaging and reporting system

Development of national eHealth system 4 Development of national eHealth system Professional registries Scope Centralised access to all relevant code systems and registries used in the health sector. No personal medical data is stored in this module. Architecture Data request served by: information stored/replicated within the module routed to service provided by external authority Data model Bespoke data model and operations but conforms to CTS2 on logical level

Development of national eHealth system 5 Development of national eHealth system Reporting system Scope Centralised reporting and messaging service Provides services to every healthcare professional and organisation Migrating all reports to this module is a long-term goal Optional validation of message and report content Architecture Central storage of objects and their states Users can poll their messages and reports Attached files (potentially containing personal medical data) are stored only for a limited time

Development of national eHealth system 6 Development of national eHealth system Authentication Scope Access to data of high security Two-factor authentication: user name and password possessed physical device: token or chip-card Authorisation Hierarchic operation Access of module's services based on user's role (e.g. physician, nurse) Different data access within a module based on user's role Data access rules specified by patient

Development of national eHealth system 7 Development of national eHealth system Business and access logging Scope Business log for each module Each and every data access is logged Architecture Separated from other services, logs cannot be altered

Development of national eHealth system 8 Development of national eHealth system General portal infrastructure Scope Access by healthcare professionals with some limitations Access by patients to their own data and specification of data access rules Architecture Liferay portal for professional use Liferay portal for patients, integrated into already existing governmental citizen's portal

Development of national eHealth system TIOP 2.3.1 creates medical modules in the framework of TIOP 2.3.2 Objectives Interoperability of healthcare providers Provisions to followi of patient's path in the sector Allowing the patient to specify access rights to his/her data Innovative data visualisation The following medical modules have been created: Centralised EHR service Patient Summary ePrescription Referral and resource publication Sharing of digital radiological images Disease registers

Development of national eHealth system Event catalogue Scope Following of patient's path in the sector Mandatory reporting of inpatient and outpatient encounters Other medical modules link the documents to the Event entry Data model Bespoke data structure

Development of national eHealth system Centralised EHR service Scope Discharge reports Outpatient records Laboratory and other diagnostic results Architecture Mandatory index database and optional EHR vault Healthcare providers can upload EHRs to the central vault or serve queries on-the-fly by their own health information system Data model Information model: national standard based on CEN/ISO 13606 standard Medical model: archetypes represented in ADL

Development of national eHealth system Patient summary – called eProfile Scope Most important and stable information about the patient – emergency dataset: chronic diseases allergies: drug and non-drug chronic medication important surgeries, implants etc. Data model Bespoke data structure Information content conforms to the European guideline on minimum patient summary dataset

Development of national eHealth system ePrescription Scope Transactional ePrescription and eDispensation database allowing electronic prescribing of magistral and manufactured medicinal products and medicinal appliances Data model Bespoke data structure Information content conforms to the European guideline on ePrescription dataset

Development of national eHealth system eReferral: electronic referral and resource publication Scope Central database of referrals: patient, referee, requested medical service and reason for referral provider's published resources and time slots and resource allocation making possible to select a time slot at the time of referral Using the referral database will be mandatory, resource publication and allocation is optional Data model Bespoke data model

Development of national eHealth system Sharing of radiological images Scope Provides access to patient's radiological images Architecture Central index database and image file cache Images are stored by the original radiological system since they are big and infrequently queried by other healthcare providers Data model Bespoke data structure

Development of national eHealth system Pseudonymisation and disease registers Scope Data protection through pseudonymisation Support of mandatory and voluntary disease registers Architecture Pseudonymisation module Independent disease registers Data model Bespoke internal data model, but disease registers may provide data in EN/ISO 13606 format

Development of national eHealth system Data access rights specified by patient Scope Implements patient's rights of self determination of data Possible scenarios: - default setting: data is accessible except for STD and mental disorders - specific authorisation/prohibition of health care professionals/organisations - partial opt-out data is stored but not accessible to anybody - full opt-out: data is not stored Patient sees each and every access to his/her data Architecture Each and every data access is routed through this module Data model Bespoke data model

Development of national eHealth system Thank you for your attention! Contact details: heja.gergely@aeek.hu