METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 RIDE Overview Asuman Dogac Middle East Technical University Ankara, Turkey

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 RIDE Partners  METU-SRDC, Turkey  OFFIS, Germany  IFOMIS, Germany  EUROREC, EU  CNR, Italy  NTUA, Greece  DERI, Ireland  IHE-D, Germany  OLE, Belgium

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 RIDE Roadmap

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Goals and Challenges  Goal 1: Establishing a Europe-wide Secure Network to Exchange Medical Summaries (EHR) across Member States European Healthcare Network proposed is the sum of the intercommunicating Member State Networks Minimum necessary specification is provided to make the framework as widely adoptable as possible The technologies that can be used to implement such a network includes:  CEN prEN 13606, or  IHE Profiles, or  HL7 messaging, or,  … All will be detailed as possible alternatives in the RIDE Roadmap specification Version 1

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Authenticate Local System Local Data Repository A Local Data Repository A Member State A Locator Service MEMBER STATE A Mary Brown Local Physician Medical Summary+ Digital Signature Medical Summary Metadata

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 MEMBER STATE B Dr. Hans Schmidt Mary Brown Health Professional Registry Health Professional Registry Authenticate Local System Request Medical Summary Member State E Locator Service Member State D Locator Service Member State C Locator Service Member State A Locator Service Record Reference Choose Record Local Data Repository A Local Data Repository A Healthcare Provider Registry Member State B Locator Service

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Hospitals, Clinics,etc Individual Healthcar e Providers Regional Health Organization Healthcare Profession al Registry Healthcare Provider Registry Patient Identity Registry Locator Service Audit Services Professional Identity Service Provider Identity Service Member State Healthcare Network Interface Member State Healthcare Network European Healthcare Network Member State Healthcare Network European Healthcare Network

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Functionalities of the European Healthcare Network  Transmission of complete requested Medical Summary to a remote clinician at another Member State,  Providing authorization services to determine appropriate clinician access to Medical Summaries, respecting patient’s privacy and patient’s consent,  Providing a technical infrastructure which will support secure communication (authentication of systems, message integrity, message confidentiality) between two healthcare provider systems even when they are located at different Member States,  Providing patient identity matching between Member States,  Providing document (Medical Summary) integrity, attestation for possible legal cases about medical errors,  Providing auditing systems to monitor and audit the medical events and transactions  To provide this Member State Networks need to provide some functionalities

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Member State Data Repositories…  Each Member State network has: One or more Data Repositories which store and provide Medical Summary documents  A Data Repository is nothing but a location or a set of locations storing Medical Summaries  A Data Repository also stores Digital Signature documents of Medical Summaries and also has access control mechanisms based on patient consents A Health Professional Registry which stores and provides health professional’s identity information A Healthcare Provider Registry which maintains the identifiers of healthcare providers (clinics, doctor offices, hospitals, etc) and other related information like location of facility, speciality and public certificates

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Member State Network Services…  The Locator Service which indexes all submitted medical summaries and serves to provide locations of medical summaries in the Member State Healthcare Network  Medical summaries are indexed with the patient demographic information and other metadata attributes  Metadata format and terminologies used in the metadata needs to be standardised  The locator service, when receives a document request, after authentication, serves this request by checking its own indices as well as forwarding the request to the Locator Services of the other Member States  However, to improve efficiency and response time, the locator service may mandate the Member States to be checked to be stated in advance

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Member State Network Services…  The Locator Service uses a matching algorithm that determines which records are likely matches  This is a challenge for Europe because the work on matching is highly sensitive to local characteristics of the data set  The locator service may additionally provide a subscription based service where an authorized user can request info when a piece of content is updated  Health Professional Identity Service provides professional identity information as signed security assertions  Healthcare Provider Identity Service serves as an interface to the Healthcare Provider Registry to provide the provider identity information  Each Member State provides an Auditing service which records all the medical and administrative event logs passing through its Locator Service

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 A Scenario…  Mary Brown suffering from cardiovascular problems consults a healthcare institute in her home state A  After her treatment, her physician in Member State (MS) A, first authenticates himself to the local system and creates patient’s Medical Summary  Her local physician digitally signs the Medical Summary and the local system transfers these documents (Medical Summary and the Digital Signature) to the Data Repository and an audit record is sent to the local data repository  The Local Data repository informs the Member State Locator service so that the Locator service indexes the document with the demographics of the patient and the meta data if available  All of these interactions are audited and the participating entities are authenticated  The patient provides her consent on the use of her medical summaries and digitally signs the consent form and the consent form is sent to the local data repository

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 A Scenario…  Mary Brown goes to Member State B for further medical treatment and contacts Dr. Can Deniz  Dr. Can Deniz in Member State B wishing to access Mary Brown’s Medical Summaries authenticates himself to his local medical system and sends the request to Member State B Locator Service  Dr. Can Deniz’s and the hospital’s authentication information is obtained from MS B’s Health Professional Registry and Provider Registry and are sent to the Locator Service of MS B which passes it to Locator Service MS A for auditing purposes  Member State B Locator service tries to locate Mary Brown’s Medical Summaries both in Member State B and also in all the other Member State’s if no specific Member State is stated in the request  When the Locator Service of the Member State A receives the request from MS B, it checks its indices and provides the location of the record (if found) together with its metadata to the Locator Service of Member State B  Locator of Member State B passes this data to the requesting Healthcare Institute

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 A Scenario…  All these interactions are audited by the Auditing services of both of the Member State A and B  Dr. Can Deniz chooses the records he wishes to retrieve and send this request to the Locator Service of MS B  LS of MS A sends this information to the MS A Data Repository  Mary Brown’s consent form is retrieved and if satisfied, the record is sent to the LS MS A and eventually to LS MS B and the requesting physician Dr. Can Deniz  All of these interactions are audited  All the traffic within and between Member States are encrypted.  The Locator services of all the Member States must have a certificate and any two Locator Services planning to exchange data must have each other’s certificate  In each Member State, all the Healthcare Institute and all the healthcare professionals have unique identifiers and certificates which are stored in the Healthcare Provider Registry and Healthcare Professional Registry respectively as already discussed

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 The Architecture also provides the infrastructure for… Electronic Health Records Electronic Health Records – Images and Signals Documentation of Current Medication Episodic Medical Summary Collaborative Medical Summary Permanent Medical Summary Emergency Dataset Laboratory Results

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Challenges…  Standards for metadata and terminologies  How to match patient identifiers  Standards for Audit Records  Interoperability of Medical Summary content  Achieving chain of trust  Standards for identifying the clinicians and the roles of Clinicians  Authenticating the Healthcare Providers  Standards for patient consent forms  Digital signatures for patient consent  …

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Semantic Interoperability  Semantic interoperability aims to give the machines the ability to process semantics (Humans already have this ability !)  Semantic interoperability builds on top of the technical interoperability layer  Without technical interoperability, it does not make sense to talk about semantic interoperability layer  For sharing EHRs there are alternative proposals which can be used to achieve technical interoperability  Technical interoperability for the described scenario is not achieved yet!  There is not a single full scale deployed implementation to achieve the mentioned functionality!  And there are gaps in the standards to achieve this!

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Interoperability as Addressed in the RIDE Project  RIDE roadmap is intended to enumerate possible alternatives but will avoid recommending a particular technology direction  The proposed architectures will fully support privacy and security of healthcare data  RIDE will provide proof-of-concept public domain implementations of each possible alternative so that the interested parties can download and use it to get a first hand experience: An architecture based on CEN prEN proposals will be available soon A set of IHE Profiles to be demonstrated at WoHIT in session 15 HL7 Web services to be available soon …  Note further that to ensure interoperability there is a need for certifying interface conformance  EHR certification is being addressed in the QREC Project  Further interface certification is needed

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 A Proposal for implementing the Proposed Architecture through CEN prEN  EHR Content can be defined through EHRcom  Policy content can be defined through CEN prEN  EHR content can be made available from a local, regional or national repository  Member State networks can be designed as a (or a collection of) Communicating Communities  Communicating Community Identifier, Enterprise Identifier and Identification of message by Originator are provided by the Community Registries  Locator Service can be implemented through EHR Related Agent

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 A Web Service based Architecture  Local or regional or national repository will provide the following asynchronous two Web Services: EHR Info Message type Web service  Query EHR info message type  Provide EHR information message type EHR Message Type Web Service  Request EHR message type  Provide EHR message type

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 EHR Related Agent Functionality  Given Patient Identifier or Patient Demographics information it should return The end points of the EHR Info Message and the EHR Message Web services  To provide this functionality, either the EHR Agent dynamically searches to find such Web services, or, it searches them in the background and provides a registry of previously found Web services  “All message types defined in this standard shall use HL7 message wrapper “  HL7 Web Services Profile details how to implement HL7 Web services  This profile can be used which also handles the security and trust issues

METU-SRDCEUROREC Meeting, Geneva, October 10, 2006 Thank you very much for your Attention!