1. HL7 and Electronic Health Records The interplay between messages, records and terminologies David Markwell The Clinical Information Consultancy Chair of HL7UK Technical Subcommittee

2. 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

3. 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

4. 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

5. 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

6. 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

7. ENV13606 a practical generic EHCR Standard Are types of 1 contains 1..* Are types of 1..* EHCR original component complex record component link item data item folder composition headed section cluster Various specialised types of data item

8. HL7 RIM - a generic model of heathcare information

9. A first draft RMIM for EHR messages (1)

10. A first draft RMIM for EHR messages (2)

11. ENV13606 has a terminology shaped gap Are types of 1 contains 1..* Are types of 1..* EHCR original component complex record component … Component name structure … record component … Component name structure … link item data item folder composition headed section cluster Various specialised types of data item A coded descriptor, title, heading or label that represents the nature or focus of the information contained by in the record component.

12. HL7 RIM – also has a terminology shaped gap 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.

13. 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

14. 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)

15. 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

16. 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)

17. Representing a simple clinical statement in different ways Many specific structures + simple values – Type specific structures + multiple values – Generic structure + fully pre-composed names – Generic structure + partially pre-composed names – Generic structure + name + templates + values – Generic structure + post-composed name –

18. 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

19. 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

20. Remaining gaps in the record structure terminology interplay Contextual distinctions and “status terms” Single statement equivalence Multiple statement equivalence

21. 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”

22. 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

23. 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

24. 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