HL7 IHE SNOMED DICOM

Transcription

1 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

2 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

3 Dr Kai U. Heitmann Owner Heitmann Consulting and Services Germany 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

4 Introduction 4

5 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

6 That fits?! World s Electricity Wall Plugs Same Concept Different Plug (Structure) Different Characteris)cs Need for Adapters 6

7 Seman.cs Dog? 7

8 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

9 Terminology Communication PCP MI Sodium Group I PCP MI Sodium Internist Group D MI PCP Dermatologist Gynecologist Group G PCP Sodium 9

10 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

11 Concepts and Codes System IRL mna m fír f 11

12 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

13 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

14 Terminologies and Identification Schemes

15 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

16 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

17 Example: HL7 v3 17

18 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

19 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

20 V3 Vocabulary iden.fica.on scheme Code + System! Fixed Vocabulary (pre defined in the HL7 standard) 20

21 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

22 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

23 HL7 Code System Example 23

24 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: Interna)onal Health Terminology Standards Development Organisa)on, two revisions each year 24

25 SNOMED 7 axes: topography morphology e)ology func)on disease procedure occupa)on 25

26 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

27 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

28 Pre and Post coordina.on pre coordina)on single concept represents a concept example: : laparoscopic emergency appendicectomy post coordina)on combina)on of concepts represent a concept example: : = , = Appendicectomy: priority=emergency, access=endocsopic => "laparoscopic emergency appendicectomy" courtesy of Dr. David Markwell 28

29 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

30 HL7

31 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

32 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

33 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

34 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

35 How is HL7 organized?

36 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

37 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

38 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

39 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

40 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

41 Stakeholder Loca.on 2007 figures. Based on the average 3 individuals per org rule

42 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 Published and ANSI Version 2.5 CDA Rel.1 Published Version 2.6 Published 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 CDA Rel.2 Version 3.0 Norma.ve Edi.on

43 Organiza.on 43

44 HL7 In Europe 44

45 HL7 In the rest of the world 45

46 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

47 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

48 How are standards created?

49 HL7 Working Groups

50 Working Groups 50

51 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

52 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

53 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

54 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

55 Ballot Home Page 55

56 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

57 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

58 Other sources Website Document Server Wiki Gforge Listserver 58

59 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

60

61 HL7 Products: v2

62 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

63 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

64 HL7 Version 2 Well suited for hospital workflows Cannot be used for cross organiza)onal communica)on 64

65 HL7 Version 2 Chapter overview 65

66 Example v2 message MSH ^~\& PAS HBE RAD ADT^A P 2.5 AL NE <cr> EVN A <cr> PID "" ^^^HBE^PI~ ^^^F-NUM^NPNO Haugen^^Terje^^^L M Jonas Storm vei 23^^Bergen^^5022^^HP "" "" "" "" <cr> Message Type Segment Segment Field Subfield Subfield 66

67 Example v2 Message ADT A01 Admission, Inpa)ent 67

68 Example v2 Message Message Type with 3 segments Message Header Event Type Pa)ent Iden)fica)on 68

69 Example v2 Message PID segment with fields 69

70 Example v2 Message Fields with components PID "" ^^^HBE^PI~ ^^^F-NUM^NPNO Haugen^^Terje^^^L M Jonas Storm vei 23^^Bergen^^5022^^HP Dr. K. Heitmann "" "" "" "" Interoperability Standards HISI Conference, <cr> Dublin, November

71 HL7 Products: v2.xml

72 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

73 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

74 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

75 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

76 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

77 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

78 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

79 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

80 An overview example ADT A01 message Three segments Message Header Event Pa)ent Iden)fica)on 80

81 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

82 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'> </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

83 View on classics vs XML Event segment note: data type components are XML elements 83

84 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

85 HL7 Products: Version 3 85

86 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

87 HL7 v3: Fragment 87

88 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

89 How are V3 messages formed? 89

90 Reference Informa.on Model RIM Four (+two) Basic classes (the backbone) Role Relationship Act Relationship Entity Role Participation Act 90

91 RIM, Example Person A Pa.ent Subject Encounter Person B Prac..oner Perfomer 91

92 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

93 RIM (Reference Informa.on Model) Basic (Abstract) data model 93

94 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

95 Version 3 is a Family of standards ALL based on a shared informa)on model and terminology Version 3 RIM (ISO/HL :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

96 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

97 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

98 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

99 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

100 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

101 Class Snippets of V3 Class 101

102 Class Snippets of V3 Instance Activity! Kind? When? What? <observationevent classcode="obs" moodcode="evn"> <id root=" " extension="aph " /> <code code="3141-9" codesystem=" " displayname="body Weight"/> <statuscode code="completed" /> <effectivetime value=" " /> <value xsi:type="pq" value="81" unit="kg"/> </observationevent> 102

103 A short lijle Exercise Miles O Keefe, born , 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 , he can also be reached at his office 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

104 Guess where? 104

105 Solu.on! Good Health H 1 Harcourt Street, Dublin 2 27 Saint Stephen's Green, Dublin 2, Co. Dublin, Ireland (private) (business) Miles O Keefe x en G ga P 105

106 HL7 Products: CDA 106

107 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

108 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

109 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

110 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

111 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

112 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

113 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

114 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

115 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

116 Header + Body Text (e.g. when transformed to HTML) Human interoperability guaranteed 116

117 CDA Sec.ons: Textual Level Textual Level (mandatory) <component> <! History --> <section> <title> : History</title> <text> Onset of asthma in his teens. He was hospitalized twice last year, and already twice this year. </text> </section> </component> 117

118 Entry Level Entry (opt.) procedures Obs.... <component> <section> <code code=" " codesystemname="loinc" codesystem=" /> <title> : 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=" " codesystem=" " codesystemname="snomed CT" displayname="asthma"> <originaltext> <reference value="#a1"/> </originaltext> </code> </observation> </entry> </section> </component> 118

119 Deriva.on of text from a Level 3 entry Blood Pressure 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

120 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

121 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

122 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

123 DICOM 123

124 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

125 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

126 DICOM Informa.on Model

127 127

128 CT Image IOD Module Table (M = mandatory, U = User opt) IE Module Reference Usage Patient Patient C M Study General Study C M Patient Study C U Series General Series C M Frame of Frame of Reference C M Reference Equipment General Equipment C M Image General Image C M Image Plane C M Image Pixel C M Contrast/bolus C C Required if contrast media was used in this image CT Image C M Overlay Plane C.9.2 U VOI LUT C.11.2 U SOP Common C.12.1 M

129 Module Defini.on Avribute Name, Tag, Type, Descrip)on Table C 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)

130

131 Dicom header Study/serie/image Patient

132 Simple Service Example

133 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

134 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

135 WADO Web Access To DICOM Objects Informa2on System Printer HTTP Request / Response Web browser Archive PACS Viewing

136 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

137 Dicom objecten 137

138 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

139 Workflow IHE 139

140 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

141 Trauma Workflow

142 Example: a Cath lab Mul.ple re entry of Pa.ent ID 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

143 Workflow Descrip)on

144 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

145 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

146 Example: Laboratory 146

147 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 148

149 149

150 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

151 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

152 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

153 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

154 Collaborations, Projects, National Infrastructures 154

155 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

156 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

157 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

158 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

159 SUMMARY 159

160 ? 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

161 ? 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

162 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

163 ? 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

164 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

165 ? How can I learn more about HL7?! Web sites hvp:// hvp://wiki.hl7.org Interna)onal Affiliates! hvp:// Educa)on and Tutorials! hvp:// How to request and HL7 Ambassador speaker mailto:[email protected] Contact info for HL7 HQ! mailto:[email protected] Product and Services Guide! hvp://productsandservices.hl7.org/report/report.aspx?varreport=product 165

166 ? 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

167 ? 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

168 Go raibh mile maith agaibh Later? mailto: Thank you! Ques.ons? 168