Overview of Healthcare Interoperability Standards HL7 IHE SNOMED DICOM Dr. Kai U. Heitmann Owner, Heitmann Consulting and Services (Germany)...and fellows Past Director International Affiliates HL7 Board International Chair HL7 Germany Co Chair Technical Committee HL7 Version 3
Agenda Introduc)on Terminologies and Iden)fica)on Schemes HL7 How are standards created? HL7 Products: v2, v2.xml, Version 3 and CDA DICOM Workflows and IHE Collabora)ons, Projects, Na)onal Infrastructures 2
Dr Kai U. Heitmann Owner Heitmann Consulting and Services Germany email: hl7@kheitmann.de Roles in HL7 and other standards developing organizations: Chair / Board member HL7 Germany Past Director International Affiliates - Board of Directors HL7 International Co-chair of the HL7 v3 Committee, HL7 Germany Member of the Technical Steering Committee, HL7 Netherlands Member of HL7 Germany, HL7 The Netherlands Representative at ISO and at DIN (German Normalization Institute), Berlin HL7 Volunteer of the Year 2004 Former co-chair of the HL7 International XML Special Interest Group 3
Introduction 4
Communica.on understanding Communica)on with direct contact Language, gestures I can ask, if something is unclear Electronic Communica)on Certain format and structure Asking back is not so easy Unambiguous Meaning (Semantics) Structure 5
That fits?! World s Electricity Wall Plugs Same Concept Different Plug (Structure) Different Characteris)cs Need for Adapters 6
Seman.cs Dog? 7
Seman.cs und Structure Pa)ent? What s part of Pa)ent s Data? Family name DOB Given name Address Next of kin Gender Insurance 8
Terminology Communication PCP MI Sodium Group I PCP MI Sodium Internist Group D MI PCP Dermatologist Gynecologist Group G PCP Sodium 9
Terminology Seman)c Interoperability, Concepts and Codes System A Male 1 Female 2 System B Male 2 Female 1 System NL mannelijk m vrouwelijk v 10
Concepts and Codes System IRL mna m fír f 11
V3 Enables Seman.c Interoperability interoperability: ability of two or more systems or components to exchange informa)on and to use the informa)on that has been exchanged. Semantic interoperability Functional interoperability 12
Interoperability Exchange of Informa)on Safe Networks, Security Iden)cal Ideas of Concepts e.g. What is an encounter? Defini)on of Structures (Content) e.g. What data belongs to a pa)ent? Terminologies Iden)fica)on Schemes 13
Terminologies and Identification Schemes
Iden.fica.on schemes Unfied iden)fica)on schemes: Iden)fica)on of real world objects Iden)fica)on of socware generated objects (e.g. prescrip)ons, encounters) 15
Iden.fica.on Mechanisms Iden)fica)on mechanism: iden)fiers which iden)fy an object instance (including vocabulary tables) UK: NHS Number NL: BSN, paspoortnr., UZI, AGB Z, URA DE: HPC Nummer, egk nummer NO: Folkeregister nummer, HPR nummer 16
Example: HL7 v3 17
Terminology The Medical Informa.cs dogma Fact: computers can only deal with a structured representa)on of reality: structured data: rela)onal databases, spread sheets structured informa)on: XML simulates context structured knowledge: rule based knowledge systems Conclusion: a need for structured data entry 18
Defini.ons Classifica)on (hierarchical) ordering into (disjunct) groups (classes), e.g. bacteria, lung infec)ons Ontology: rela)onships between concepts Rela)onship with Classifica)on Terminology = Vocabulary + Ontology (science of the) proper use of terms Vocabulary = required for human ontology interac)on Ontology = knowledge component, context, rela)onal informa)on to other vocabulary items 19
V3 Vocabulary iden.fica.on scheme Code + System! Fixed Vocabulary (pre defined in the HL7 standard) 20
Concepts, Codes, Value Sets Concept Domain Concept Coded Concept mnemonic that identifies a semantic concept Code System system of coded concepts used to represent semantic concepts Mostly authored by one source examples: ICD-10, SNOMED, LOINC Value Set 21
Code Systems ICD (Interna)onal Classifica)on of Diseases) ICPM (Interna)onal Classifica)on of Procedures) LOINC (Logical Observa)on Iden)fer Names and Codes) SNOMED / SNOMED CT HL7 (UCUM, Unified Code for Units of Measure)... 22
HL7 Code System Example 23
SNOMED Systema)zed NOmenclature of Human and Veterinary in MEDicine College of American Pathologist (CAP), 1965 SNOMED RT (Reference Terminology): CAP, 2000 SNOMED CT (Clinical Terms): 2002 CAP & NHS,UK SNOMED CT: 2007+ Interna)onal Health Terminology Standards Development Organisa)on, www.ihtsdo.org two revisions each year 24
SNOMED 7 axes: topography morphology e)ology func)on disease procedure occupa)on 25
SNOMED Clinical Terms Core Structure Descriptions ConceptID DescriptionID Term DescriptionType DescriptionStatus LanguageCode InitialCapitalStatus Concepts ConceptID ConceptStatus FullySpecifiedName CTV3ID SNOMEDID IsPrimitive Relationships RelationshipID ConceptID1 RelationshipType ConceptID2 CharacteristicType Refinability RelationshipGroup 2000 College of American Pathologists 26
Defini)on of Rela)onships Respiratory disease Infection is a is a finding site Pneumonia Lung causative agent is a Virus Viral pneumonia courtesy of Dr. David Markwell 27
Pre and Post coordina.on pre coordina)on single concept represents a concept example: 174041007: laparoscopic emergency appendicectomy post coordina)on combina)on of concepts represent a concept example: 80146002:260870009=25876001,260507000=129238008 Appendicectomy: priority=emergency, access=endocsopic => "laparoscopic emergency appendicectomy" courtesy of Dr. David Markwell 28
Terminologies/Iden.fica.on Schemes The choice of vocabulary/terminology is important Prerequisite for aggregated data sourced from mul)ple organiza)ons Choice of terminology: organiza)onal/poli)cal factors The choice of Iden)fica)on Schemes is important Prerequisite for aggregated data sourced from mul)ple organiza)ons Choice of Iden)fica)on Schemes: mostly determined by third par)es (e.g. government, insurance companies) 29
HL7
Where do HL7 standards help? HL7 standards assist in moving healthcare informa)on in a standardized way to the point of pa)ent care moving informa)on within and beyond the four walls of hospitals among all healthcare stakeholders the sharing of public health informa)on enabling the electronic healthcare record and the crea)on of na)onal healthcare informa)on networks 31
Basic principles of HL7 no assump)ons about the socware architecture few assump)ons about the technical communica)on infrastructure implementa)on guides, based on the underlying standards No agreed upon business process standardiza)on in healthcare > HL7 has to support variability in the models. 32
Variability.. Versus straight bananas Commission Regulation (EC) No. 2257/94: bananas must be "free from malformation or abnormal curvature. Commission Regulation (EEC) No. 1677/88:..are allowed a bend of 10mm per 10cm of length.. The latter regulation is actually about Class I and "Extra class" cucumbers. 33 CreativeCommons BY NC license - Eko
HL7 Standards Version 2.x Messaging Paradigm (1987..) V2.xml (2003..) Version 3 Messaging Paradigm (1995..) Services paradigm (work in progress) CDA: Clinical Document Architecture (1999..) Other: CCOW: Clinical Context Object Working Group (= Desktop Integra)on) Arden Syntax (Decision Support) 34
How is HL7 organized?
Health Level 7 Accredited Standards Developing Organisa)on (SDO) All volunteer open organisa)on Small permanent paid staff; Board Working groups with healthcare subject maver experts and informa)on scien)sts Working Group Mee)ngs, List Servers, TelCons, Wiki 36
Health Level Seven (HL7) Goal: Interoperability Global defini)ons for ehealth Structure and Seman)cs Exchange of Messages and Documents To create the best and most widely used standards in healthcare. 37
Mission Statement HL7 creates prac)cal standards for the exchange, management and integra)on of electronic healthcare informa)on. Standards for electronic data interchange in all healthcare environments. A way for inherently disparate [healthcare] applica)ons and data architectures to communicate 38
The Seven in HL7 HL7 supports the exchange, management and integra)on of electronic healthcare informa)on. ISO OSI Communication Architecture Model Image HL7, Inc reused by permission 39
HL7 Membership Worldwide 1800 organizations, 1000 individuals Other 8% North America 32% Europe 45% Asia/Oceania 15% 2007 figures. Based on the average 3 individuals per org rule
Stakeholder Loca.on 2007 figures. Based on the average 3 individuals per org rule
History of HL7 HL7 Version 3 Version 1.0 Published Implementa.on Support Guide published Version 2.2 Published Version 2.2 ANSI More Than Messages Version 2.3.1 Published and ANSI Version 2.5 CDA Rel.1 Published Version 2.6 Published 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 Version 2.0 Published First Mee.ng Hospital University of PA.. Charter member of ANSI HISPP 1993 : HL7 Version 2.1 Germany Published Version 2.3 Published and ANSI CCOW Arden Syntax 2.4 2.0 CDA Rel.2 Version 3.0 Norma.ve Edi.on 2005 42
Organiza.on 43
HL7 In Europe 44
HL7 In the rest of the world 45
HL7 Affiliates Argen)na Australia Austria Brazil Canada Chile China Columbia Croa)a Czech Republic Finland France Germany Greece Hong Kong India Ireland (lapsed) Italy Japan Korea New Zealand Norway Pakistan Romania Russia Singapore Spain Sweden Switzerland Taiwan The Netherlands Turkey United Kingdom Uruguay (USA) 46
IHIC Interna)onal HL7 Interoperability Conference a two day conference Started in 2000 in Dresden, different loca)ons Presenta)ons: interoperability in prac)ce, scien)fic aspects 47
How are standards created?
HL7 Working Groups
Working Groups 50
Working Group Mee.ng Synchronisa)on + Decisions (Regular) Conference Calls in between Meets three )me a year At different Loca)ons Two )me a year in the US, one )me somewhere else Canada: Toronto 1998; The Netherlands: Noordwijkerhout 2005; Germany: Cologne 2007; Canada: Vancouver 2008; Japan: Kyoto 2009; Brazil: Rio de Janeiro 2010 Australia: Sydney 2011 Canada: Vancouver 2012 51
Posi.ons Board Member Chair, Chair Elect, Past Chair Secretary, Treasurer Director at Large Affiliate Director Co Chair Facilitator Vocabulary, Methodology, Publishing Mentor Ambassador Speaker 52
Standards Developing Process Proposal (in database) Discussion in TC during WGM Preliminary vote Enhancement Process Ballot process Vote Reconcilia)on (Substan)al change? => reballot) Publica)on Connect a thon (IHE): test the standard 53
Ballo.ng Process Announcement 30 days in advance Signup Period, ends a week before ballot closes Ballot opens, material is available Cast a Vote Before ballot closes Vote: Affirma)ve, Abstain, Nega)ve (requires comments or reference to other nega)ve voters) 54
Ballot Home Page 55
Types of Ballot Documents Drac for Comments Informa)ve 60% affirm (of combined affirm+nega)ve) Drac Standard for Trial Use (DSTU) Valid for 2 years 60% affirm (of combined affirm+nega)ve) Norma)ve 90% affirm (of combined affirm+nega)ve) 56
Awards and Nomina.ons HL7 Fellowship (since 2010) Volunteer of the Year Award Ed Hammond Award Honors very ac)ve HL7 members in good standing New: IHIC presenta)ons Joachim Dudeck Award Honors newbees for their scien)fic work HL7 Ambassador 57
Other sources Website Document Server Wiki Gforge Listserver 58
Mee.ngs: Sharing Experiences Work Group Mee)ng, Conferences Developing the standard S)mula)ng Co Labora)ons Ins)tu)onalizing exchange Culture of ideas Remain concerned 59
HL7 Products: v2
Basic Principles of HL7 Messaging Trigger event send HL7 message receive HL7 ACK message System A network Receive HL7 message send HL7 ACK message System B 62
HL7 Version 2 Since mid 80ies Commonly used in hospitals Well suited for hospital workflows Focus on administra)ve/logis)cal aspects of the workflow Is able to convey medical data of low complexity (e.g. laboratory result, radiology report) Pragma)c Standard Widely used in most industrialized countries 63
HL7 Version 2 Well suited for hospital workflows Cannot be used for cross organiza)onal communica)on 64
HL7 Version 2 Chapter overview 65
Example v2 message MSH ^~\& PAS HBE RAD 2008040112149 ADT^A01 20080401112149 P 2.5 AL NE <cr> EVN A01 200804010800 20080401112149 <cr> PID "" 8005069^^^HBE^PI~24109642356^^^F-NUM^NPNO Haugen^^Terje^^^L 19961024 M Jonas Storm vei 23^^Bergen^^5022^^HP 70555366 "" "" "" "" <cr> Message Type Segment Segment Field Subfield Subfield 66
Example v2 Message ADT A01 Admission, Inpa)ent 67
Example v2 Message Message Type with 3 segments Message Header Event Type Pa)ent Iden)fica)on 68
Example v2 Message PID segment with fields 69
Example v2 Message Fields with components PID "" 8005069^^^HBE^PI~24109642356^^^F-NUM^NPNO Haugen^^Terje^^^L 19961024 M Jonas Storm vei 23^^Bergen^^5022^^HP Dr. K. Heitmann 70555366 "" "" "" "" Interoperability Standards HISI Conference, <cr> Dublin, November 2011 70
HL7 Products: v2.xml
Background v2.xml Ini)a)ve around the year 2000 of the HL7 XML SIG Version 2 with encoding rules Transi)on to XML Overcome shortcomings of the pipe encoding 72
Norma.ve HL7 Database Microsoc Access Database containing the official defini)ons for events, messages, segments, fields, data types, data type components, tables and table values. Developed by HL7 Germany (Frank Oemig) in response to issues with consistency in the wriven standard. XML Representa)on is algorithmically derived directly from the HL7 Database 73
Design Considera.ons XML DTD Op)miza)on Message length Structural complexity Localiza)on Looseness of the DTD Conformance with HL7 Version 3 XML Representa)on that was current at the )me of its development V3 XML Representa)on now is very different 74
Algorithms HL7 Database used as basis for XML DTD/ schema SQL queries used to extract tables containing defini)ons of messages, segments, fields and data types Perl scripts are applied to ASCII files to generate XML DTDs/schemas Issues with HL7 Database are reflected in the defini)ons 75
Schemas provided Single schema that contains all the HL7 V2.3.1 defini)ons Contains four separate DTD defini)ons: Messages.dtd segments.dtd fields.dtd datatypes.dtd Single schema for each message structure 76
HL7 2.xml Element Naming Conven.on message element names message name and trigger event ORM_O01, ADT_A01, etc. segment element names segment name MSH, PID, OBX, etc. field element names segment name and sequence number MSH.1, PID.11, OBX.5, etc Data type component element names datatype name and component number CE.2, HD.1, XAD.3, etc. <ORM_O01>...<OBX> <OBX.1> 1 </OBX.1> <OBX.2>ST</OBX.2> <OBX.3> <CE.1>9804-6</CE.1> <CE.2>Weight</CE.2> <CE.3>LN</CE.3> </OBX.3> <OBX.5>135</OBX.5> <OBX.6> <CE.1>lb</CE.1> </OBX.6> <OBX.11>F</OBX.11> </OBX>... </ORM_O01> 77
Single component is populated Where a field has a data type with mul)ple components but only a single component is populated, the data type element must s)ll be sent. OBX:6 = CE data type Valid: <OBX.6> <CE.1> lb </CE.1> </OBX.6> Invalid: <OBX.6> lb </OBX.6> 78
v2.3.1 naming conven.ons (cont) Field elements have the following fixed avributes Item, Table, LongName, Type Datatype component elements have the following fixed avributes Table, LongName, Type 79
An overview example ADT A01 message Three segments Message Header Event Pa)ent Iden)fica)on 80
Minimized XML Example <ORM_O01> <OBX> <OBX.1>1</OBX.1> <OBX.2>ST</OBX.2> <OBX.3> <CE.1>9804-6</CE.1> <CE.2>Weight</CE.2> <CE.3>LN</CE.3> </OBX.3> <OBX.5>135</OBX.5> <OBX.6> <CE.1>lb</CE.1> </OBX.6> <OBX.11>F</OBX.11> </OBX> </ORM_O01> 81
Expanded XML Example <ORM_O01> <OBX> <OBX.1 LongName='Set ID - OBX' Type='SI Item='569'>1</OBX.1> <OBX.2 Table='125' LongName='Value Type' Type='ID' Item='570'>ST</OBX.2> <OBX.3 LongName='Observation Identifier' Type='CE' Item='571'> <CE.1 LongName='identifier' Type='ST'> 9804-6</CE.1> <CE.2 LongName='text' Type='ST'>Weight</CE.2> <CE.3 LongName='name of coding system' Type='ST'>LN</CE.3> </OBX.3> <OBX.5 LongName='Observation Value' Type='WILDCARD' Item='573'>135</OBX.5> <OBX.6 LongName='Units' Type='CE' Item='574'> <CE.1 LongName='identifier' Type='ST'>lb</CE.1> </OBX.6> <OBX.11 LongName= Observation Result Status' Type= ID Item='578'>F</OBX.11> </OBX> </ORM_O01> 82
View on classics vs XML Event segment note: data type components are XML elements 83
Use of v2.xml Less used than expected Ireland messaging between GPs and hospitals and between GPs and GP Out of Hours Coops HL7 version 2.4 with XML encoding broker is Healthlink Project: electronic cancer referrals from GPs to the eight cancer centres of the Na)onal Cancer Control Programme HL7 version 2.4 with XML encoding 84
HL7 Products: Version 3 85
Drivers for v3 Enable inter organiza)onal workflows Process support, EHRs, na)onal healthcare informa)on networks Support the exchange of complex clinical models EHR, decision support Consistent seman)c modeling across the board 86
HL7 v3: Fragment 87
V3 is Model Based The central Healthcare informa4on model for HL7 Version 3 is called the Reference Informa4on Model (RIM) All V3 products are based on this model ANSI standard since 2003 ISO standard since 2006 88
How are V3 messages formed? 89
Reference Informa.on Model RIM Four (+two) Basic classes (the backbone) Role Relationship Act Relationship Entity Role Participation Act 90
RIM, Example Person A Pa.ent Subject Encounter Person B Prac..oner Perfomer 91
Refined Model Person classcode: <= PSN determinercode: <= INSTANCE id: II [0..1] name: EN [0..*] birthtime: TS [0..1] 1..1 pa2entperson Organiza.on scopedby Pa.ent classcode: <= PAT id: II [1..1] 1..1 pa2ent subject typecode*: <= SBJ Encounter classcode <= xy moodcode <= xy Person addr: AD [0..1] telecom: TEL [0..*] id: II [1..1] Organiza.on playedby scopedby Prac..oner classcode: <= PRT id: II [1..1] telecom: TEL [0..*] 1..1 prac22oner performer typecode*: <= PRF )me: IVL<TS>... 92
RIM (Reference Informa.on Model) Basic (Abstract) data model 93
HL7 V3 Uses Object Oriented Design Not ad hoc design V3 = Object Oriented socware methodology and informa)on architecture Object Oriented means that HL7 V3 can be extended incrementally whenever new healthcare informa)on domains need to be added doesn t require changing what already exists Scalable, flexible 94
Version 3 is a Family of standards ALL based on a shared informa)on model and terminology Version 3 RIM (ISO/HL7 21731:2006 RIM) V3 Messaging Documents Clinical Document Architecture (CDA Release 2) Service Oriented Architecture: En)ty Iden)fica)on Services (EIS) Common Terminology Services (CTS) Resource Loca)on and Update Services (RLUS) Decision Support Services (DSS) RIM Based Applica)on Architectures (RIMBAA) Java APIs 95
Version 3 Domains Accoun)ng and Billing Medical Records Blood, Tissue, and Organ Observa)ons Care Provision Orders Clinical Genomics Pa)ent Administra)on Claims and Reimbursement Personnel Management Clinical Document Architecture Pharmacy Clinical Decision Support Public Health Clinical Statement Registries Common Message Element Types Regulated Products Imaging Integra)on Regulated Studies (Clinical Trials) Immuniza)on Scheduling Laboratory Shared Messages Medica)on Specimen Domain Materials Management Therapeu)c Devices 96
HL7 V3: built to support inter organiza.onal care processes Other areas like: Research, clinical trials, administrative, utilization, financial, public health, drug certification, genomics Patient Aftercare Lab Surg. Hospital G. P. Information flow Specialist Rad 97
Three development phases Modeling process How are HL7 v3 models created? What has been created already? How do I find/interpret appropriate exis)ng models? Localiza)on process How do I adapt the exis)ng HL7 v3 models to fit my specific context? How to apply constraints? Implementa)on process How do I write socware to send/receive the localized v3 models? Any recommended architectural approaches? 98
Version 3 Enables the inter organiza2onal sharing of healthcare informa)on For example a lab result ordered in an outpa)ent clinic and obtained from the local laboratory could be: a part of a pa)ent summary (V3 CDA document) retrieved using a Resource Loca)on and Upda)ng Service (HL7 RLUS SOA) the reason to order a specific medicine using a computerized physician order entry system (CPOE) (V3 Rx Order message) an indica)on of a par)cular disease to a decision support system input to a RIM Based Applica)on Architecture (RIMBAA) decision support system 99
Addi.onal V3 features Formal vocabulary binding Extensive tools library Implementa)on Guides Iden)fiers Globally Unique Explicit Seman)cs (model based) makes automa)c conformance tes)ng possible Incorporates Web technology XML (Extended Markup Language) as primary implementa)on technology Use of Web Services protocols for transport 100
Class Snippets of V3 Class 101
Class Snippets of V3 Instance Activity! Kind? When? What? <observationevent classcode="obs" moodcode="evn"> <id root="1.9.99.999.99.10.3" extension="aph65597960" /> <code code="3141-9" codesystem="2.16.840.1.113883.6.1" displayname="body Weight"/> <statuscode code="completed" /> <effectivetime value="20100514" /> <value xsi:type="pq" value="81" unit="kg"/> </observationevent> 102
A short lijle Exercise Miles O Keefe, born 17.10.1975, lives in 27 Saint Stephen's Green, Dublin 2, Co. Dublin, Ireland He is registered as a pa)ent at the Good Health Hospital with iden)fica)on number 4321 His private phone number is +353 1 677 3243, he can also be reached at his office +353 1 407 0800 Pa)ent s primary language is English but he also understands Gaelic Good Health Hospital s address: 1 Harcourt Street, (off St. Stephens Green), Dublin 2 103
Guess where? 104
Solu.on! Good Health H 1 Harcourt Street, Dublin 2 27 Saint Stephen's Green, Dublin 2, Co. Dublin, Ireland 4532 +353 1 677 3243 (private) +353 1 407 0800 (business) Miles O Keefe 17.10.1975 2x en G ga P 105
HL7 Products: CDA 106
Tension of Documenta.on Extensible Markup Language (XML) Two extremes in today's data processing Narra)ve text vs. Fields in a database enrich text for various purposes Dr. K. Heitmann Interoperability Standards HISI Slide Conference, used Dublin, by permission November 2011 of Kai Heitmann 107
edocuments Documents are the most natural method to convey health status Prac))oners are trained in the crea)on of documents All electronic health records use documents Every EHR includes a document repository Data fragments useful within a known context; for exchange across )me, context, signed documents required 108
HL7 Mission Interoperability Paradigms HL7's mission is to provide standards for interoperability that: improve care delivery, op)mize workflow, reduce ambiguity and enhance knowledge transfer Three interoperability paradigms are used to achieve this: The exchange of electronic messages The use of (web )services The process of sharing documents 109
Clinical Document Architecture Interoperability Human The paper world with documents, forms... Applica)on Storage, management of clinical data Context driven analysis Reusability An approved standard way to exchange dictated, scanned, or electronic reports on a pa)ent between various health informa)on technology systems and pla orms. 110
Goals Persistence Stewardship (administra)on) Poten)al for Authen)fica)on Wholeness Human readability Context preserva)on Render arbitrary documents Addi)onal informa)on for computa)on Flexibility to support different document types Example Docs: Discharge letter Referrals Observations Medical Histories... Dr. K. Heitmann Interoperability Standards HISI Slide Conference, courtesy Dublin, November of François 2011 Macary 111
CDA Business Case CDA hits the sweet spot CDA encompasses all of clinical documents. A single standard for the en)re EHR is too broad. Mul)ple standards and/or messages for each EHR func)on are difficult to implement. CDA is just right. Implementa)on experience CDA has been a norma)ve standard since 2000, and has been balloted through HL7's consensus process. CDA is widely implemented. 112
CDA Business Case (cont d) Gentle on ramp to informa)on exchange CDA is straight forward to implement, and provides a mechanism for incremental seman)c interoperability. Improved pa)ent care CDA provides a mechanism for inser)ng evidencebased medicine directly into the process of care (via templates), making it easier to do the right thing. Lower costs CDA s top down strategy let s you implement once, and reuse many )mes for new scenarios. 113
Structure of a CDA Document Form A header providing the context: To facilitate the exchanges and the management of the documents, their compila)on in the pa)ent record A body clinical informa)on, ordered into sec)ons, paragraphs, lists, tables, Encoding in XML Comprehensive for the human and for the computers can be validated by a schema Header structured and coded Body structured content with coded sections Salutation Problem/Subjective History Family History Physical/Objective Diagnoses Epicrisis Plan... Past Medical History Admit diagnoses Intermediate diagnoses Discharge diagnoses coded (e.g. ICD 10) Slide used by permission of Kai Heitmann and Francois Macary 114
Structure of a CDA Document Based on HL7 v3 models, data types and development methodology Clinical Document Header Patient Provider Body Body Structures (textual section) Entries (Clinical Statements) Observation Procedure Encounter Medication... 115
Header + Body Text (e.g. when transformed to HTML) Human interoperability guaranteed 116
CDA Sec.ons: Textual Level Textual Level (mandatory) <component> <! History --> <section> <title>29.08.2005: History</title> <text> Onset of asthma in his teens. He was hospitalized twice last year, and already twice this year. </text> </section> </component> 117
Entry Level Entry (opt.) procedures Obs.... <component> <section> <code code="10164-2" codesystemname="loinc" codesystem="2.16.840.1.113883.6.1 /> <title>29.08.2005: History</title> <text> Onset of <content ID="a1">asthma</content> in his teens. He was hospitalized twice last year, and already twice this year. </text> <entry typecode="comp"> <observation> <code code="195967001" codesystem="2.16.840.1.113883.6.96" codesystemname="snomed CT" displayname="asthma"> <originaltext> <reference value="#a1"/> </originaltext> </code> </observation> </entry> </section> </component> 118
Deriva.on of text from a Level 3 entry Blood Pressure 120 80 Database...... systolicbp diastolicbp int int...... Slide used by permission of Ringholm GmbH <section> <text> Blood pressure 120/80 mmhg </text> <entry typecode="driv"> Observation Systolic BP: 120 mm[hg] </entry> <entry typecode="driv"> Observation Diastolic BP: 80 mm[hg] </entry> </section> 119
A CDA Implementa.on Guide.. Specifies document type Specifies mandatory and op)onal textual sec)ons Specifies mandatory and op)onal entries Specifies terminology codes, iden)fica)on schemes and other sta)c model constraints Most implementa4on guides are countryspecific: e.g. the CCD is U.S. only. 120
Summary: CDA Release 2 RIM R-MIM HMD W3C Schema Narrative blocks Structured Header human Sections (text/title) L2: section codes L3: coded entries Entries machine Header Body Text Observa)on Substance Administra)on Region of interest Procedure Pa)ent Encounter «Organizer» Observa)on (mul) media) courtesy of François Macary 121
HL7: Message or Document? Message Document Latest state of things Supports ongoing process Subset of data Finalized process Formal transfer of care However, what is a prescription, or a radiology report? 122
DICOM 123
DICOM Digital Imaging and Communications in Medicine A standard since 1983 stable since 1993 ini)ally developed by American College of Radiology (ACR) and Na)onal Electrical Manufacturers Associa)on (NEMA) ISO standard 12052:2006 "Health informa)cs Digital imaging and communica)on in medicine (DICOM) including workflow and data management 124
What is DICOM? Common Informa)on Model Service classes (What? ) e.g. Move, Print, Query Informa)on objects (With what?) e.g. CT Image, Pa)ent, Schedule SOP Service Object Pair e.g. Print CT Image, Move US Patient Study Series Image
DICOM Informa.on Model
127
CT Image IOD Module Table (M = mandatory, U = User opt) IE Module Reference Usage Patient Patient C.7.1.1 M Study General Study C.7.2.1 M Patient Study C.7.2.2 U Series General Series C.7.3.1 M Frame of Frame of Reference C.7.4.1 M Reference Equipment General Equipment C.7.5.1 M Image General Image C.7.6.1 M Image Plane C.7.6.2 M Image Pixel C.7.6.3 M Contrast/bolus C.7.6.4 C Required if contrast media was used in this image CT Image C.8.2.1 M Overlay Plane C.9.2 U VOI LUT C.11.2 U SOP Common C.12.1 M
Module Defini.on Avribute Name, Tag, Type, Descrip)on Table C.7.1.1 -- Patient Module Attributes Attribute Name Tag Type Attribute Description Patient's Name (0010,0010) 2 Patient's full legal name. Patient ID (0010,0020) 2 Primary hospital identification number or code for the patient. Patient's Birth Date (0010,0030) 2 Birth date of the patient. Patient's Sex (0010,0040) 2 Sex of the named patient. Enumerated Values are: M = male F = female O = other Referenced Patient Sequence (0008,1120) 3 A sequence which provides reference to a Patient SOP Class/Instance pair. Only a single reference is allowed. Encoded as sequence of items: (0008,1150) and (0008,1155)
Dicom header Study/serie/image Patient
Simple Service Example
DICOM: services Dicom Store Dicom Find Dicom Move Dicom Print Dicom Modality Worklist Dicom Performed Procedure Step Dicom Storage Commit Dicom Verifica)on Dicom Presenta)on Context others.. SCU = Service Class User A.k.a. client SCP = Service Class Provider A.k.a. server An applica)on may act both as a SCU as well as a SCP E.g. be a Dicom Store SCU as well as a SCP 133
How can DICOM services be used: Modality Worklist Informa2on System/ Broker Archive Verifica.on MR Store Query/ Printer Storage Commit Retrieve Print Performed Procedure Step Viewing
WADO Web Access To DICOM Objects Informa2on System Printer HTTP Request / Response Web browser Archive PACS Viewing
Conformance All vendors that use DICOM have to publish a DICOM conformance statement Lists all SOP classes supported Lists the op)onal/mandatory IEs, Modules, Avributes Lists the supported compression algorithms Textual expression 136
Dicom objecten 137
DICOM Used as a standard for transmission and storage of diagnos)c images (X Ray, CT, MRI, visible light, etc.) Used to support workflows within the imaging department Mandatory when purchasing PACS or modali)es; widely supported Mostly used in combina)on with the IHE Radiology Technical Framework 138
Workflow IHE 139
Workflow related challenges Major challenges in healthcare: applica)on interoperabililty Applica)ons contain data needed by other systems Applica)on interfacing quite ocen a challenge Consequences Subop)mal workflows, no workflow manegement redundant, inconsistent, or non available data 140
Trauma Workflow
Example: a Cath lab 1 2 6 7 Mul.ple re entry of Pa.ent ID 5 8 9 10 11 Error prone 3 4 Results fragmented across systems Results inconsistently.me tagged Custom solu.ons needed for data sharing Difficult to manage Uncoordinated with Hospital Informa.on System demographics, orders, billing Ad hoc scheduling of labs
Workflow Descrip)on
IHE IHE = Integra)ng the Healthcare Enterprise Based on exis2ng standards such as HL7 and DICOM IHE is not a standard; it is a constraint profile (a.k.a conformance profile). 144
Technical Framework Contents Introduc)on to IHE Volume 1: Actors and Transac)ons Volume 2: Messaging Details The IHE Technical Framework allows for a better, faster implementation of interfaces, leading to a higher level of management of orders and results. 145
Example: Laboratory 146
Actors and Transac.ons Actor (HL7: Applica)on Role, DICOM: Service Class) Func)onal grouping of the capability to exchange a specific set of Transac)ons in order to fulfill part of a workflow. Transac)on (Func)onal) Informa)on exchange Abstract concept, could be the equivalent of mul)ple message exchanges or service calls. 147
148
149
IHE Standardizes workflows, describes how standards such as HL7 can be used with a specific workflow context. Technical Frameworks exist for Radiology, Laboratory, Medical Summary Documents, document based EHRs, etc. 150
Related Profiles for Seman.c Interoperability Pre Surgery PPHP Consent BPPC Emergency EDER Scanned Doc XDS SD Imaging XDS I Laboratory XD* Lab Discharge & Referrals XDS MS PHR Exchange XPHR XDS Doc Sharing Dr. K. Heitmann Interoperability Standards HISI Conference, Dublin, xds November 2011 151
Proven Standards Adop.on Process IHE Connect-a-thon Results Product IHE Integration Statement IHE Technical Framework Product With IHE Easy to Integrate Products Standards IHE Integration IHE Integration Profiles B Profile A IHE Connect-a-thon IHE Demonstration User Site RFP 152
IHE Standardizes workflows, describes how standards such as HL7 can be used with a specific workflow context. Used by 99% of all PACS systems, imaging modali)es and RIS systems. Increasing interest in XDS (Cross enterprise Document Sharing) as the basis for EHR or virtual PACS solu)ons. 153
Collaborations, Projects, National Infrastructures 154
HL7 Version 3 Projects worldwide Methods V3 Messages Clinical Document Architecture (CDA) Canada Canada Health Infoway to create Pan Canadian Electronic Health Records Finland Na)onal Infrastructure with exchange based on CDA Great Britain Na)onal Infrastructure of the Na)onal Health Service with messages and documents 155
HL7 Version 3 Projects worldwide The Netherlands Electronic Medica)on Records (EMD) and exchange of health informa)on between Primary Care Providers (WHD) based on HL7 Version 3 and Web Services Europe Exchange of data about dialysis treatment in dialysis care, treatment centers to na)onal registries, na)onal registries to interna)onal ERA EDTA registry in Amsterdam 156
Version 3: other related work Diagnoses transmission of diagnoses defines informa)on exchange between prac))oners, and for reimbursement purposes, public health, and cancer treatment and research No)fiable Diseases Communica)on Physician/Lab to Public Health Department Robert Koch Ins)tute + AGFA HealthCare Based on Arztbrief CDA Assessment and Scores 157
Implementa.on Guidelines in Germany Base for Implementa)ons Guidelines in Germany: Data Types and CMETs Exchange of CDA Wrapper Insurance Data Diagnoses Care Record Summary Dialysis/Nephrology Order Communica)on Embedding Dig Sig Electronic Prescrip)on 158
SUMMARY 159
? What is the future of Version 2?!! Commonly used within hospitals Accepted by industry Never touch a running system will remain standard in hospitals for some more years! V2.xml allows transi)on to XML interfacing (V3) and other modern techniques! 160
? Where is V3 in use today? CDA is used in many countries, including Australia, Canada, UK, Germany, the US, the Netherlands, Greece, Japan...!! V3 messaging is used in Canada, UK, the Netherlands V3 SOA (service oriented architecture): in the US, the NCI and the VHA have significant projects!! V3 RIMBAA in Japan, Austria, Italy 161
V3 implementa.ons Registries (Pa)ent, Provider, Organiza)on) Transfer of care (Pa)ent Care domain) Clinical Documents (CDA) Medica)on (Pharmacy domain) Billing (Charges, insurance) Niche clinical areas (immuniza)on, clinical genomics, implantable therapu)c devices, blood and organ banks...) Research (clinical trials) 162
? Do I need to be a modelling / informa.cs expert to use V3? No, V3 implementa)on guides are usable without! a detailed theore)cal background. Many HL7 affiliates have also created detailed V3 implementa)on guides! HL7 offers a variety of tutorials to jump start implementa)on! If an IT staffer knows XML, and the system is using V3 messages or CDA documents or services, all you need is an implementa)on guide! Start small scale CDA Quick Start Guide 163
The V3 Family solving the BIGGER problems of healthcare interoperability Not just messaging! Easy to get started Messaging, documents, SOA, RIM based application development Free form CDA documents, implementation guides, extensive tooling, educational opportunities Employs Web technologies Model based: the RIM XML and Web Services, for universal application For a higher level of semantic interoperability 164
? How can I learn more about HL7?! Web sites hvp://www.hl7.org hvp://wiki.hl7.org Interna)onal Affiliates! hvp://www.hl7.org/special/commivees/interna)onal/intl.htm Educa)on and Tutorials! hvp://www.hl7.org/educa)on/index.cfm! How to request and HL7 Ambassador speaker mailto:hq@hl7.org Contact info for HL7 HQ! mailto:hq@hl7.org Product and Services Guide! hvp://productsandservices.hl7.org/report/report.aspx?varreport=product 165
? How can I learn more about V3?!!!!! Tutorials At Working Group Mee)ngs Affiliate mee)ngs Educa)onal Summits On site Distance learning class CDA Quick Start Guide and V3 Primer RIM and CDA Cer)fica)on HL7.tv with a lot of V3 related videos 166
? How can I learn more about...?!!! DICOM Standard medical.nema.org Integra)ng the Healthcare Enterprise ihe.net IHE Achievements: History and Expanding Role in Developing Interoperable Health Systems. Chris Carr, RSNA, download unter ihe.net SNOMED Interna)onal Health Terminology Standards Development Organisa)on, ihtsdo.org 167
Go raibh mile maith agaibh Later? mailto: hl7@kheitmann.de Thank you! Ques.ons? 168