HL7 and Electronic Health Records

The interplay between messages, records and

terminologies

David MarkwellThe Clinical Information Consultancy

Chair of HL7UK Technical Subcommittee

Overview

• Background– Why health record communication interests me– Classic HL7 communication paradigm – Electronic health record communication requirements– Convergence of standard record and message models

• Terminology-shaped gaps in the models• Semantic challenges facing health record

communication• Alternative representations of clinical statements• The role of logically defined terminologies• Outstanding issues of context and equivalence• Conclusions and the intended role of the HL7 EHR SIG

Why health record communication is important

in the UK• UK GP computing

– 9,000 general practices– > 96% computerised– 100% use some version of Read Codes– > 70% use these for medical records– Many different systems (3 suppliers 80% of market)

• UK GP records– About 5 million patients change practices each year– Paper records moved with patient– Computerised record don’t

• Addressing the problem– XMLEPR – experiments based on CEN ENV13606– GP2GP Project – evaluating HL7v3 approach

The classic HL7 paradigmOrder, Report & Inform

• Features– Intent to communicate

• For a specific purpose• Often to a specific person or organisation

– Information content determined by intent• Information necessary for a request• Information from a requested service• Information about a distinct event

– Storage is secondary to communication• A record of a request• A report of a service

• Therefore …– Messages shaped by communication requirements– Variety of requirements variety of messages

Electronic Health Record Communication

• Features– Health records are kept for many purposes

• Aide-memoire• Analysis, research, audit• Decisions support• Medico-legal

– Information content determined by• Purposes of recording (perceived and actual)• Accuracy, completeness and method of recording• Collection of communications

– Communication is subservient to storage• Communication is limited by originating and target records• Communicated records should work like the native records

• Therefore …– Messages must be based a general architecture capable of

expressing different records with minimum loss of functionality

Messages and records converging standards

• In early 90’s the message-record gap seemed wide– Different groups championed divergent causes

• Europe– Records - GEHR and CEN TC251 WG1 – Messages - CEN TC251 WG3

• US– Messages – HL7– Records - CPRI

• Pragmatic modelling approaches have narrowed the gap– Europe

• An architecture for health record communication aligned with message development models (ENV 13606)

– US• HL7 Version 3 models pave the way for similar convergence

ENV13606 a practical generic EHCR Standard

Are types of1contains

1..*

Are types of

1..*

EHCREHCR

original component

complex

original component

complex

record component

record component

link itemlink item

data itemdata item

folderfolder

compositioncomposition

headed section

headed section

clustercluster

Variousspecialisedtypes ofdata item

HL7 RIM - a generic model of heathcare information

0..n1

has_target

0..n

is_target_for

1

0..n1

has_source

0..n

is_source_for

1

1..* originates_in_context_of1..*

provides_context_for

0..*

0..n

1for

0..n

has1

Act_context

level_cd

Medication

form_cd : CDroute_cd : CDdose_qty : PQstrength_qty : PQrate_qty : PQdose_check_qty : PQmethod_cd : SET<CV>body_site_cd : SET<CD>substitution_cd : CV

Document_service

completion_cd : CVset_id : IIstorage_cd : CVversion_nbr : INTcopy_dttm : TSorigination_dttm : TS

Observation

value : ANYderivation_expr : STmethod_cd : SET<CV>body_site_cd : SET<CD>interpretation_cd : SET<CS>

Procedure

entry_site_cd : SET<CD>method_cd : SET<CV>body_site_cd : SET<CD>

Supply

qty : PQ

Transportation

Referral

authorized_visits_qty : REALdesc : EDreason_txt : ED

Participation

type_cd : CStmr : IVL<TS>note_text : EDsignature_cd : CVfunction_cd : CDawareness_cd : CVsignature_txt : EDencounter_accommodation_cd : CVstatus_cd : CS

Act

id : SET<II>mood_cd : CStype_cd : CCtxt : EDstatus_cd : CSactivity_time : GTScritical_time : GTSconfidentiality_cd : SET<CV>max_repeat_nmr : IVL<INT>interruptible_ind : BLpriority_cd : SET<CV>orderable_ind : BLavailability_dttm : TS

Act_relationship

type_cd : CSinversion_ind : BLsequence_nbr : INTpriority_nbr : INTpause_qty : PQcheckpoint_cd : CSsplit_cd : CSjoin_cd : CSnegation_ind : BLconjunction_cd : CS

Working_list

ownership_level_cd

Consent

A first draft RMIM for EHR messages (1)

A first draft RMIM for EHR messages (2)

ENV13606 has aterminology shaped gap

Are types of1contains

1..*

Are types of

1..*

EHCREHCR

original component

complex

original component

complex

record component…

Component name structure

…

record component…

Component name structure

… link itemlink item

data itemdata item

folderfolder

compositioncomposition

headed section

headed section

clustercluster

Variousspecialisedtypes ofdata item

A coded descriptor, title, heading or label that represents the nature or

focus of the information contained by in the record component.

HL7 RIM – also hasa terminology shaped gap

0..n1

has_target

0..n

is_target_for

1

0..n1

has_source

0..n

is_source_for

1

1..* originates_in_context_of1..*

provides_context_for

0..*

0..n

1for

0..n

has1

Act_context

level_cd

Medication

form_cd : CDroute_cd : CDdose_qty : PQstrength_qty : PQrate_qty : PQdose_check_qty : PQmethod_cd : SET<CV>body_site_cd : SET<CD>substitution_cd : CV

Document_service

completion_cd : CVset_id : IIstorage_cd : CVversion_nbr : INTcopy_dttm : TSorigination_dttm : TS

Observation

value : ANYderivation_expr : STmethod_cd : SET<CV>body_site_cd : SET<CD>interpretation_cd : SET<CS>

Procedure

entry_site_cd : SET<CD>method_cd : SET<CV>body_site_cd : SET<CD>

Supply

qty : PQ

Transportation

Referral

authorized_visits_qty : REALdesc : EDreason_txt : ED

Participation

type_cd : CStmr : IVL<TS>note_text : EDsignature_cd : CVfunction_cd : CDawareness_cd : CVsignature_txt : EDencounter_accommodation_cd : CVstatus_cd : CS

Act

id : SET<II>mood_cd : CStype_cd : CCtxt : EDstatus_cd : CSactivity_time : GTScritical_time : GTSconfidentiality_cd : SET<CV>max_repeat_nmr : IVL<INT>interruptible_ind : BLpriority_cd : SET<CV>orderable_ind : BLavailability_dttm : TS

Act_relationship

type_cd : CSinversion_ind : BLsequence_nbr : INTpriority_nbr : INTpause_qty : PQcheckpoint_cd : CSsplit_cd : CSjoin_cd : CSnegation_ind : BLconjunction_cd : CS

Working_list

ownership_level_cd

Consent

Type_cd

A code specifying the kind of action.The Act.type_cd specifies the act conceptually.

The terminology that provides codes for this attribute is hierarchical.

Can HL7 fill the terminology gap?

• The RIM has specific links to vocabulary tables– These are fine for attributes with a few tens or hundreds of

possible values (So far about 5,000)– To meet wider needs HL7 vocabulary tables refer to external

terminology sources• Issues

– Clinical terminologies are large and growing– Concepts within terminologies are logically interrelated– Maintenance is non-trivial and HL7 is not resourced for such a

task• HL7 models need to work with established and emerging

terminologies– In UK Read Codes (now) and SNOMED Clinical Terms (by

2003)– In other countries the options may differ

Clinical terminologies scale and complexity

• Concepts– Read Codes in use in GP systems 40,000 concepts– NTS CTV3 (Read Codes version 3) 250,000 concepts– SNOMED RT 150,000 concepts– SNOMED Clinical Terms 350,000 concepts

• Of which 250,000 current

• Semantic relationships between concepts– Read Codes – 40,000 (precision limited by structure)– NHS CTV3 – 500,000 (human assigned manually

checked)– SNOMED RT – 500,000 (human+logical computation)– SNOMED Clinical Terms > 1,000,000 (human+logical

computation)

Structure-terminology interplay

• Effective use of clinical information – decision support, analysis, aggregation, research &

audit

• Requires recognition of – identical and semantically-related clinical

statements.

but …• The same clinical statements can be

represented– using different combinations of terminology

components and data structures

Why semantics matters

• Consistent retrieval is essential for– Analysis, aggregation and audit– Decision support

• Consistent retrieval means– Complete (no false negatives)

• E.g. Don’t miss “tuberculous meningitis” when looking for “TB” or “meningitis”

• Don’t miss the latest BP measurement because it is expressed or structured differently in a cardiologist’s record

– Correct (no false positives)• Don’t treat “aspiration of stomach contents” as a complication

when it is a procedure• Don’t confuse “cord compression (umbilical)” with “cord

compression (spinal)

Representing a simple clinical statement in

different ways• Many specific structures + simple values

– <Right_biceps_reflex Value=“normal”>

• Type specific structures + multiple values

– <Reflex_exam Location=“Biceps” Side=“R” Value=“normal”>

• Generic structure + fully pre-composed names

– <Item Name=“Right biceps reflex normal”>

• Generic structure + partially pre-composed names

– <Item Name=“Right biceps reflex” Value=“normal”>

• Generic structure + name + templates + values

– <Item Name=“Reflex_exam” Location=“Biceps”Side=“R” Value=“normal”>

• Generic structure + post-composed name

– <Item Name=“Reflex_exam(Loc:Biceps(Side:R ))” Value=“normal”>

Pros & cons of different structural representations

• Specific structures– Places for everything and everything needs a place

• Similar information may appear in different structures• Semantic relations and similarities lost in a structural maze

• Generic structure– Places for anything but everything needs a code

• Short code lists poverty of expression• Long code list needs logical semantics to identify similarities• Depends on logical semantics of the terminology

• Generic structure + Templates– Places for anything with a way to specify places for

everything• Enables more specific organisation without losing generic

structure• Still depends on logical semantics of the terminology

Meeting the terminology challenge

• SNOMED Clinical Terms will be– Scalable

• with 300,000 concepts and 500,000 descriptions– Semantically defined

• with about one million logical semantic relationships– Mapped to major classifications (such as ICD10)– Consistent with pre-existing standards

• including CEN standards on categorial structures• and the code-phrase expression of HL7

but …• It is only part of the answer

– Effective use depends on consistent use within Standard structures and architectures

Remaining gaps in the record structure terminology

interplay• Contextual distinctions and “status terms”• Single statement equivalence• Multiple statement equivalence

Contextual distinctions and “status terms”

• Certainty and negation– “Chest X-ray not done”– “Right dorsalis pedis pulse absent”– “Possible fracture of scaphoid bone”– “On examination no abdominal tenderness”

• Subject of information– “Family history diabetes”– “Carer has pneumonia”

• Planning and targets– “Waiting list for total hip replacement”– “Target body weight 70Kg”

Single statement equivalence

• The following are possible using one structure and one terminology – A single pre-coordinated concept identifier

• HL7 Act with– type_cd = [Appendectomy]

– A post-coordinated set of concept identifiers in a code phrase• HL7 Act with

– type_cd = [Surgical removal]+([Site]=[Appendix])

– Combination of values in specific fields• HL7 Act with

– type_cd = [Surgical removal]– body_site = [Appendix]

• Equivalence can be tested for analysis/decision support if– All codes are from one logically defined terminology– Specific fields have recognised equivalence to terminology

attributes

Multi-statement equivalence

• A single statement may be equivalent to several related statements– Two temporally related conditions

• Single statement– Observation =“AIDS with gastro-enteritis”

• Multiple statement with overlapping timeframe– Observation = “AIDS”– Observation = “Gastro-enteritis”

– Two explicitly related conditions• Single statement

– Observation = “Gangrene of toe due to peripheral vascular disease”• Multiple statement with explicit relationship

– Observation = “Gangrene of toe”– Act_relationship = “Caused by”– Observation = “Peripheral vascular disease”

• Testing these equivalences requires closer connection between record architecture and terminology semantics

Conclusions• Clinical users need EHR communication standards

– Inaccurate or incomplete communication prevents effective decision-support and accurate research and audit.

• Developers of EHR systems need communication standards– Communication standards and record systems must be

developed to enable effective products • HL7 standards for communication of health records require

– Consistent high-level architecture based on RIM elements– Recognition of the role of logically defined clinical terminologies

as part of the solution to effective communication semantically rich clinical information

• The nascent HL7 Electronic Health Record SIG– Brings together these strands to develop effective standards for

communication of electronic health records– Assisting with vHR development for Decision Support TC– Converging with CDA – probably at level 3