EHR Standards and Semantic Interoperability Setting the Frame of Reference Dr. Marco Eichelberg OFFIS - Institute for Information Technology E-Mail: eichelberg@offis.de Page 1
Introduction Semantic Interoperability: A Definition Data semantics is the relationship between data and what the data stand for. In order to obtain mutual understanding of interchanged data, the actors have to share a model of what the data represent. Semantic interoperability is about how to achieve such mutual understanding. This presentation addresses the issue of semantic interoperability in the context of the Electronic Health Record (EHR). EHR: A repository of information regarding the health of a subject of care in computer processable form [ISO TR 20514] Patient centred: stores information about the health status of individually identified patients Health related: stores health related information, i. e. not administrative, financial, etc. Longitudinal: contains information from cradle to grave Cross enterprise: The EHR contains information created from different health providers (i. e., more than a typical HIS system in a hospital) Page 2
Introduction: EHR Electronic Health Records (EHRs) have been discussed in scientific literature for about 25 years technology (computers, networks, etc.) perceived as adequate today currently a hot topic in many countries Integral part of many current ehealth initiatives, including: Austria, Australia, Belgium, Canada, Denmark, Estonia, France, Germany, Hungary, Ireland, Netherlands, Norway, Spain, UK, USA. Expected benefits: safer and more effective delivery of health care less medical error (better informed doctors, decision support systems) improvement of case management reduction of duplicate examinations complete & correct data source for public health and research Standards are absolutely needed for successful EHR implementation many systems, many players long-term stability of data Page 3
EHR Value Proposition The EHR is not a value on its own - it is valuable when combined with care processes and IT applications that utilise the EHR information! Electronic prescribing: Extract information about the patient s current medication, allergies and diagnoses from the EHR and create warnings if there is a contra-indication or high risk of adverse drug interaction. Laboratory: Make sure that new lab results and historical results from the EHR can be combined to show long-term trends. Telemedicine: Make sure the EHR can be used as a vehicle to offer high-quality diagnostic services to under-served (e. g. rural) areas. Research and public health: Make sure that anonymous data can be extracted automatically from the EHR to enable research. Integrated care: The EHR should serve as a means of synchronising the many health professionals involved in the treatment of patients with chronic diseases (diabetes, coronary heart disease, etc.) Home care: Integrate care provided at the patient s home with the EHR Page 4
EHR Information Models Page 5
EHR Information Models An Information Model is an abstract model of that part of the world about which the EHR stores information. This is important because The model determines, which types of information each compatible implementation has to manage (read, write, store), but not, how Message formats for the exchange of EHR content can be derived from the model. Due to the longitudinal nature of an EHR, an information model should be stable over a long time, so that past, current and future episodes of health can be recorded in the same EHR, be flexible, because medical knowledge, healthcare delivery processes, standards for best practice in clinical documentation etc. change over time, be powerful enough to cover all relevant information for past, current and future episodes of care in a single model, be simple enough to be manageable and implementable! Isn t this the proverbial squaring the circle??? Page 6
Two-Level Modelling: A Solution Two-Level Modelling is the solution to the basic problems of EHR information models, i. e. long-time stability vs. sufficient flexibility expressive power vs. sufficiently simple (implementable) models The idea is to distinguish two separate layers of information model: A simple reference model that is stable over time, plus A set of constraint rules that describe how certain clinical concepts such as a blood pressure measurement, a bed location or lab results can be expressed in the reference model. These constraint rules are called Archetypes (OpenEHR, EHRcom) or Templates (DICOM, HL7 CDA). Archetypes may change over time, but older EHR entries can still be stored in the same database because the reference model remains the same. A change of archetypes does not require structural changes in the database of EHR systems, because these only have to reflect the reference model. The following presentation (by Dr. Dipak Kalra) will address this issue in more detail Page 7
EHR Semantics Page 8
EHR Semantics - Introduction Domain specific terminology CAD = coronary artery disease LV = left ventricular Traditionally, medical reports consist of prose text, sometimes extended with graphical drawings, tables, images. The patient was admitted for elective invasive study and potential interventional treatment. The diagnostic cath procedure reveals CAD with significant lesions within the proximal circumflex artery and a mediumsized diagonal branch. LV function is normal in presence of arterial hypertension. As planned, interventional catheter treatment is performed in the same session, starting with the proximal circumflex lesion, that is passed with a standard guide wire and dilated with a 3.0 mm balloon with an acceptable result. The wire is then passed into the obstructed diagonal branch and dilatation is performed with a 3mm balloon, again with an acceptable initial result. About 5 min later, the patient develops chest pain and anterior ST elevations. [...] vague expressions numerical values and units Page 9
EHR Semantics Lots of structured information in this PDF file, but no way to ever get that out of the document again! Page 10
EHR Semantics - What do we want? Clinical statements in the EHR should be clear and unambiguous Compare new data with prior data (e. g. compute trends over time) Feed EHR content into a computer-based decision support system generate alarm when a new drug prescription is incompatible with prior drug prescriptions or diagnoses assign patient to certain risk category select most appropriate clinical guideline for patient treatment Extract statistical data for public health and epidemiology Enable data mining algorithms to search for statistically significant patterns and provide data for Evidence Based Medicine All of this requires EHR content to be structured and machine processable (at least to a certain degree)! One key ingredient : An explicit list of concepts for a certain domain along with machine readable codes assigned to each concept (Controlled Vocabulary, Taxonomy, Thesaurus, Ontology) Page 11
Example of a Coded Report (DICOM SR) Each node in the tree has a machine-readable code identifying the concept it represents TEXT Finding Malignant Mass Code=121071 Coding Scheme=DICOM Concept Name=Finding Human readable text (not machine processable) has properties has properties CODE Finding Mass CODE Finding Malignancy by-reference Code=M-020F9 Coding Scheme=SNOMED 3.0 Concept Name=Shape Code=C-C0E3 Coding Scheme=SNOMED-RT Concept Name=Finding Site has properties has properties has properties has properties inferred from Code=G-A428 Coding Scheme=SNOMED-RT Concept Name=Margin CODE CODE NUM CODE Shape Location Size Margin Round Central 15 mm Irregular Numeric Value Page 12 Code=112025 Coding Scheme=DICOM Concept Name=Size Descriptor
Example of a Coded Report (DICOM SR) Some nodes have a second machine-readable code identifying their content has properties TEXT Finding Malignant Mass Code=M-03000 Coding Scheme=SNOMED-RT Concept Name=Mass Code=G-A245 Coding Scheme=SNOMED-RT Concept Name=Malignant has properties CODE Finding Mass CODE Finding Malignancy by-reference Code=F-0178F Coding Scheme=SNOMED-RT Concept Name=Central region of breast has properties has properties has properties has properties inferred from Code=G-A402 Coding Scheme=SNOMED 3.0 Concept Name=Irregular CODE CODE NUM CODE Shape Location Size Margin Round Central 15 mm Irregular Code=M-02100 Coding Scheme=SNOMED 3.0 Concept Name=Round shape Page 13 Code=MM Coding Scheme=UCUM Concept Name=mm
The Coded Report, Revisited So, instead of storing the following block of text, A mass of round shape and irregular margin, 15 mm in diameter, was found in the central region of the breast. The mass is classified as malignant due to the irregular margin. we have now stored a graph with 7 nodes and 7 named links 1 block of free text malignant mass 1 numeric value (measurement) 13 machine-readable codes, taken from four different vocabularies The report is now fully machine-processable Translation to a different language could be performed automatically Enables use by decision support systems and for data mining However, the production of such coded reports in clinical routine, using current IT tools, is an open issue! Page 14
EHR Standards Page 15
EHR Standards In April 2006, the US National Alliance for Health Information Technology published a directory of e-health standards, which lists 2104 standards related to ICT in healthcare, produced by 436 separate organisations! Fortunately, the list of core EHR standards as such is much shorter. Here are the most promising candidates EHRcom: CEN EN 13606 Electronic Health Record Communication CDA: The HL7 Clinical Document Architecture IHE XDS: Cross-enterprise Clinical Document Sharing Page 16
EHRcom: EN 13606 A rigorous and durable information architecture for communicating the EHR, consisting of a reference model (information model) describing how EHR content can be represented and exchanged, a specification language for archetypes (constraint rules for clinical business objects built from the reference model), an initial (small) set of archetypes, a security concept, a set of exchange models (message/service interfaces) Representation of EHR content typically in XML Hierarchical structure where an EHR consists of folders, compositions (~ documents), sections, entries, clusters, elements and data values. Page 17
HL7 Clinical Document Architecture (CDA) CDA specifies a standard format for clinical documents for exchange. A CDA document can exist outside of a message, and can include text, images, sounds, and other multimedia content. CDA documents are encoded in XML Only a content format, no definition of services or messages CDA documents derive their meaning from the HL7 Reference Information Model (RIM) and use HL7 V3 data types A CDA document consists of a header and a body Header is consistent across all clinical documents - identifies and classifies the document, provides information on patient, provider, encounter etc. Body contains narrative text / multimedia content (level 1), optionally augmented by coded equivalents (levels 2 & 3) Page 18
Cross-enterprise Document Sharing (XDS) XDS is a specification that enables document sharing between EHR systems in different care settings and organisations XDS Properties Distributed: Each organisation publishes clinical information for others. Actual documents may remain in the source patient record system. Cross-Enterprise: A Registry provides an index for published information to authorised organisations belonging to the same clinical affinity domain. Document Centric: Published clinical data is organised into clinical documents using agreed standard document types. Document Content Neutral: Document content is processed only by source and consumer IT systems. Standardised Registry Attributes: Queries based on meaningful attributes ensure deterministic document searches. XDS can transmit and store any type of content, including EHRcom and HL7 CDA. Protocol based on ebxml Registry Services (SOAP, Web Services) Page 19
EHR Standards and Semantic Operability Where are we today? Information Models Both EHRcom and CDA use a two-level architecture with a simple reference model and constraint rules (templates/archetypes) EHRcom uses a formal specification for archetypes, CDA is informal IHE XDS only provides communication (plus simple meta-data for indexing) and relies on EHRcom, CDA, etc. for clinical content. Semantics Both EHRcom and CDA enable the creation of fully machine-readable structured content Both standards also still allow free text or semi-structured information, which is critical for migration purposes Both standards rely on external controlled vocabularies Interoperability EHRcom s communication architecture is still work in progress CDA does not address communication at all IHE XDS most advanced in this field with many implementations Page 20
Conclusion Is the issue of EHR Semantic Interoperability solved? No, but there has been much progress in the last 2-3 years Controlled vocabularies / ontologies are improving, but not yet there User interfaces / workflow integration for structured documentation Is there one obvious solution or way to go? No, all standards have their strengths and weaknesses Standardisation is still very much in progress The definition and maintenance process for templates / archetypes controlled vocabularies / ontologies will be one of the big issues to be addressed in the years to come Overall, however, my impression is that we re on a good way. Page 21
Acknowledgement This work is supported by the European Commission through the RIDE project: A Roadmap for Interoperability of ehealth Systems in Support of COM 356 with Special Emphasis on Semantic Interoperability Project Homepage: http://www.srdc.metu.edu.tr/webpage/projects/ride/ Page 22