More Related Content Similar to A European Patient Summary Infrastructure (20) More from Smruti Patanaik (20) A European Patient Summary Infrastructure1. A European Patient Summary
Infrastructure
A. Carenini (CEFRIEL) Reto Krummenacher (STI Innsbruck)
Elena Simperl (STI Innsbruck) Douglas Foxvog (DERI Galway)
2. The eHealth Scenario in TripCom
The European Patient Summary (EPS)
Hospitals,
p ,
An infrastructure for sharing patient clinics
Laboratories
summary at European level
• 5.000 health authorities
• More than 1 million users
(clinicians and administrative staff)
• 500 millions citizen summaries Home care
Specialists Citizens services
General
Practitioners Administration,
Assurance companies
Current national eHealth systems cannot be adopted as-is at an EU-wide level:
All of them force the adoption of a particular standard
All of them assume to operate with the same laws and privacy regulations
Regulations in a country prevents its eHealth system to operate as-is in another country
Sixth Framework Programme Priority 2
© TripCom 2 Information Society Technologies (IST)
Specific Targeted Research Project
3. The EPS Scenario
Requirements for the EPS Infrastructure
Scalability
500.000.000 patient summaries
5.000 Local health authorities
Multilateral Solution
M ltil t l S l ti
Virtual common infrastructure distributed among parties
Coordinate multidisciplinary actors in access data asynchronously and from
different locations
diff tl ti
Privacy and Data Ownership
National and Local policies to authorize caregivers to access citizen data
Each healthcare party owns the summaries of the cared citizens
Data heterogeneity
Intensive use of knowledge: structured data and terminologies
g g
Messages and vocabularies are expressed using different standards
Sixth Framework Programme Priority 2
© TripCom 3 Information Society Technologies (IST)
Specific Targeted Research Project
4. The EPS Scenario
Triple Space Capabilities
Decentralized, Distributed and Shared Space
Each healthcare party p
p y provides resources to the whole space
p
Persistent Publication
Actors persistently publish and update data in their own space,
enforcing d t ownership
f i data hi
Other actors can retrieve the published data
Security Mechanisms
Global and local policies to access data
Coordination Support
pp
Interactions decoupled in time, location and reference
Information are organized in a virtual tree-like structure of spaces
Spaces are managed by so-called TripCom kernels
Sixth Framework Programme Priority 2
© TripCom 4 Information Society Technologies (IST)
Specific Targeted Research Project
5. EPS Architecture
Data model(s)
Ontologies are used to model data inside the EPS
Message ontologies: based upon the most adopted standards for
exchanging patient data, such as HL7 CDA and ASTM CCR
Vocabulary ontologies: model of existing coding systems to re-
y g g g y
use clinical terminologies, such as: ICD10, ICD9, LOINC, MESH,
MTH, NCI, RXNORM, UMLS
PS ontology
t l
Head
Registry data (name, date of birth, residence)
Administrative data (IDs, insurance info)
Body
B d
Problems, alerts, medications, immunizations, encounters
Procedures,
Procedures Advance Directives Plan Of Care
Directives,
Sixth Framework Programme Priority 2
© TripCom 5 Information Society Technologies (IST)
Specific Targeted Research Project
6. EPS Architecture
Subspaces, Roles and Policies
The subspaces of a single PS space
Head: For administrative accesses
Body: For clinical accesses
Private: To restrict access to some data
Each space has a corresponding access
control policy
Security attributes provided by the user
allow mapping the user onto a role
Permissions are given to roles wrt
wrt.
operations on the space (read, write,
delete)
The
Th policy of a space also regulates
li f l l t
the evaluation order of the policies of
its subspaces
Sixth Framework Programme Priority 2
© TripCom 6 Information Society Technologies (IST)
Specific Targeted Research Project
7. eHealth national systems: state of the art
UK: NHS Spine
Demographics of all the patients are centrally stored in the Personal
Demographic Services repository
Medical data can be either stored in the National Care Record or in
local systems
Access with smart cards containing digital
certificates (PKI) and individual PINs.
Role based
Role-based access control
with SAML assertions
Message exchange through a
g g g
custom version of HL7 v.3
Sixth Framework Programme Priority 2
© TripCom 7 Information Society Technologies (IST)
Specific Targeted Research Project
8. eHealth national systems: state of the art
The Netherlands: AORTA
Distributed architecture with a central Hub
Clients ask the Hub for data
The Hub locates data, fetches and returns it to the client
No central repository of clinical data → data belongs to the source
organization
Data exchange through custom HL7 v.3 messages
Unique Healthcare Practitioner
ID (UZI) card and pincode
Identification and authentication
of healthcare practitioner
Role of health practitioner
Relies on PKI
Sixth Framework Programme Priority 2
© TripCom 8 Information Society Technologies (IST)
Specific Targeted Research Project
9. Integrating the EPS with NHS Spine
Data: HL7 v.3 messages can be automatically lifted to their RDF
representation
Security: SAML security assertions can be natively used when
interacting with the TS
User-restricted
User restricted data: Sealed envelopes correspond to the Private
subspace of a Patient Summary
PS spaces structures:
p
Demographics centrally stored → on a single kernel
Clinical data can be centralized or distributed
Centralized data in the main Body/Private PS subspace and
managed by a single kernel
Distributed data inside subspaces of Body/Private spaces and
managed by remote kernels
Sixth Framework Programme Priority 2
© TripCom 9 Information Society Technologies (IST)
Specific Targeted Research Project
10. Integrating the EPS with NHS Spine (2)
(2
Sixth Framework Programme Priority 2
© TripCom 10 Information Society Technologies (IST)
Specific Targeted Research Project
11. Integrating the EPS with AORTA
Data: HL7 v.3 messages can be automatically lifted to their RDF
representation
Data for building patient summaries MUST be held in a space owned
by the originating Health Authority
Sixth Framework Programme Priority 2
© TripCom 11 Information Society Technologies (IST)
Specific Targeted Research Project
12. Integrating AORTA and NHS Spine with the EPS
EPS spaces must be configured in order to be used as a
central repository by NHS Spine and as a registry by AORTA
Nation-wide spaces ensure uniqueness of the PS spaces
identifiers
Policies of the top-level spaces just specify very basic rules
Recursive read and policy evaluation is massively used
Inside a PS
PS policies must allow evaluated starting from the leaf
spaces
A PS is still divided into 3 main areas
Each “contributing nation” manages a subspace inside each
of the 3 areas
The spaces of the “contributing nation” are hosted on the
contributing nation
kernels managed by the “contributing nation”
Sixth Framework Programme Priority 2
© TripCom 12 Information Society Technologies (IST)
Specific Targeted Research Project
13. Integrating AORTA and NHS Spine with the EPS
(2)
Sixth Framework Programme Priority 2
© TripCom 13 Information Society Technologies (IST)
Specific Targeted Research Project
14. Thank you for your attention
http://www.tripcom.org
Sixth Framework Programme Priority 2
© TripCom Information Society Technologies (IST)
Specific Targeted Research Project