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

2. Development of national eHealth system Main health IT projects2
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

3. Development of national eHealth system3
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

4. Development of national eHealth system4
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

5. Development of national eHealth system5
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

6. Development of national eHealth system6
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

7. Development of national eHealth system7
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

8. Development of national eHealth system8
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

9. Development of national eHealth system
TIOP 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

10. 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

11. 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 standard
Medical model: archetypes represented in ADL

12. 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

13. 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

14. 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

15. 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

16. 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 format

17. 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

18. Development of national eHealth system Thank you for your attention!
Contact details: