EHR Standards and Semantic Interoperability
Setting the Frame of Reference
Dr. Marco Eichelberg
OFFIS - Institute for Information Technology E-Mail: [email protected]
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”
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”
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.)
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”???
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
EHR Semantics - Introduction
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 medium-sized 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
Domain specific terminology
CAD = “coronary artery disease” LV = “left ventricular”
EHR Semantics
Lots of structured information in this PDF file, but no way to ever get that “out of the
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
has properties has properties
has properties has properties has properties has properties
inferred from NUM Size 15 mm CODE Shape Round CODE Location Central CODE Margin Irregular CODE Finding Malignancy CODE Finding Mass TEXT Finding Malignant Mass by-reference
Example of a Coded Report (DICOM SR)
Code=121071 Coding Scheme=DICOM Concept Name=Finding Code=M-020F9 Coding Scheme=SNOMED 3.0 Concept Name=Shape Code=C-C0E3 Coding Scheme=SNOMED-RT Concept Name=Finding Site
Code=G-A428
Coding Scheme=SNOMED-RT Concept Name=Margin Each node in the tree
has a machine-readable code
identifying the “concept” it represents
Human readable text
has properties has properties
has properties has properties has properties has properties
inferred from NUM Size 15 mm CODE Shape Round CODE Location Central CODE Margin Irregular CODE Finding Malignancy CODE Finding Mass TEXT Finding Malignant Mass by-reference
Example of a Coded Report (DICOM SR)
Some nodes have a second
machine-readable code identifying their content
Code=F-0178F
Coding Scheme=SNOMED-RT
Concept Name=Central region of breast
Code=G-A402 Coding Scheme=SNOMED 3.0 Concept Name=Irregular Code=M-03000 Coding Scheme=SNOMED-RT Concept Name=Mass Code=G-A245 Coding Scheme=SNOMED-RT Concept Name=Malignant
The Coded Report, Revisited
So, instead of storing the following block of text,
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!
A mass of round shape and irregular margin, 15 mm in diameter, was found in the central region of the breast.
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
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.
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
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.
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
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
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:
