Transcript Overview of Technical Documents

HL7 and Electronic Health Records
The interplay between messages,
records and terminologies
David Markwell
The 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 paradigm
Order, 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
folder
EHCR
contains 1
1..*
Are types of
original
component
complex
composition
headed
section
cluster
1..*
record
component
Are types of
link item
data item
Various
specialised
types of
data item
HL7 RIM - a generic model of
heathcare information
Participation
type_cd : CS
tmr : IVL<TS>
note_text : ED
signature_cd : CV
function_cd : CD
awareness_cd : CV
signature_txt : ED
encounter_accommodation_cd : CV
status_cd : CS
has
for
1
0..n
Act
Act_relationship
id : SET<II>
type_cd : CS
has_source inversion_ind : BL
mood_cd : CS
is_source_for
type_cd : CC
sequence_nbr : INT
txt : ED
1
0..n priority_nbr : INT
status_cd : CS
pause_qty : PQ
activity_time : GTS
checkpoint_cd : CS
critical_time : GTS
is_target_for
has_target split_cd : CS
confidentiality_cd : SET<CV>
join_cd : CS
1
max_repeat_nmr : IVL<INT>
0..n negation_ind : BL
interruptible_ind : BL
conjunction_cd : CS
priority_cd : SET<CV>
orderable_ind : BL
availability_dttm : TS
originates_in_context_of
1..*
provides_context_for
Referral
Procedure
Observation
Medication
authorized_visits_qty : REAL
desc : ED
reason_txt : ED
entry_site_cd : SET<CD>
method_cd : SET<CV>
body_site_cd : SET<CD>
value : ANY
derivation_expr : ST
method_cd : SET<CV>
body_site_cd : SET<CD>
interpretation_cd : SET<CS>
form_cd : CD
route_cd : CD
dose_qty : PQ
strength_qty : PQ
rate_qty : PQ
dose_check_qty : PQ
method_cd : SET<CV>
body_site_cd : SET<CD>
substitution_cd : CV
Transportation
Supply
qty : PQ
Working_list
ownership_level_cd
Consent
Document_service
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
0..*
Act_context
level_cd
A first draft RMIM for EHR messages (1)
A first draft RMIM for EHR messages (2)
ENV13606 has a
terminology shaped gap
folder
EHCR
1..*
1..*
contains 1
Are types of
composition
A coded
descriptor,
title,
heading or
original
component
label that represents
the nature or focusheaded
complex
of the information contained by in thesection
cluster
record component.
record component
…
Component name
structure
Are types of
…
link item
data item
Various
specialised
types of
data item
HL7 RIM – also has
a terminology shaped gap
Participation
type_cd : CS
tmr : IVL<TS>
note_text : ED
signature_cd : CV
function_cd : CD
awareness_cd : CV
signature_txt : ED
encounter_accommodation_cd : CV
status_cd : CS
has
for
1
0..n
Act
Act_relationship
id : SET<II>
type_cd : CS
has_source inversion_ind : BL
mood_cd : CS
is_source_for
type_cd : CC
sequence_nbr : INT
txt : ED
1
0..n priority_nbr : INT
status_cd : CS
pause_qty : PQ
activity_time : GTS
checkpoint_cd : CS
critical_time : GTS
is_target_for
has_target split_cd : CS
confidentiality_cd : SET<CV>
join_cd : CS
1
max_repeat_nmr : IVL<INT>
0..n negation_ind : BL
interruptible_ind : BL
conjunction_cd : CS
priority_cd : SET<CV>
orderable_ind : BL
availability_dttm : TS
originates_in_context_of
1..*
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.
provides_context_for
Referral
Procedure
Observation
Medication
authorized_visits_qty : REAL
desc : ED
reason_txt : ED
entry_site_cd : SET<CD>
method_cd : SET<CV>
body_site_cd : SET<CD>
value : ANY
derivation_expr : ST
method_cd : SET<CV>
body_site_cd : SET<CD>
interpretation_cd : SET<CS>
form_cd : CD
route_cd : CD
dose_qty : PQ
strength_qty : PQ
rate_qty : PQ
dose_check_qty : PQ
method_cd : SET<CV>
body_site_cd : SET<CD>
substitution_cd : CV
Transportation
Supply
qty : PQ
Working_list
ownership_level_cd
Consent
Document_service
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
0..*
Act_context
level_cd
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
but …
• including CEN standards on categorial structures
• and the code-phrase expression of HL7
• 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