1 / 62

HL7 Version 3: Driving Interoperability & Transforming Healthcare Information Management

“The great thing about standards is that there are so many to choose from.” --- anonymous. HL7 Version 3: Driving Interoperability & Transforming Healthcare Information Management. Charles Mead, MD, MSc Director, Healthcare Information Architecture Oracle Healthcare

hinto
Download Presentation

HL7 Version 3: Driving Interoperability & Transforming Healthcare Information Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. “The great thing about standards is that there are so many to choose from.” --- anonymous HL7 Version 3:Driving Interoperability & Transforming Healthcare Information Management Charles Mead, MD, MSc Director, Healthcare Information Architecture Oracle Healthcare charlie.mead@oracle.com BCIG Seminar National Institutes of Health October 14, 2004

  2. A Framework for Change:Bits vs Atoms(“Being Digital,” Nicholas Negroponte) • Atoms • Occupy proportional physical space • Cost money to move or replicate • Take time to move or replicate • Atom processing today vs 2000BC is order-of-magnitude unchanged • Bits • Occupy disproportionately small physical space • Cost of replication not related to number of replications • Transport times virtually identical regardless of distance • Healthcare has traditionally used atoms (paper) to move bits (information) BCIG Seminar October 14, 2004

  3. A Second Framework:Process vs Implementation • Process Description:“An implementation-independent description of an activity or sequence of activities focused on accomplishing a specific goal.” • e.g. ‘Communicate a message from Party A to Party B’ • Implementation Solution:“An implementation-specific mechanism whereby a given process is realized and achieves its stated goal. Every implementation is a set of compromises on the original Problem statement” • e.g. Face-to-face conversation vs email vs voicemail vs US Mail • Healthcare personnel (clinical, administrative, and financial) often confuse the (historical) paper implementation as the essential care delivery / management process. BCIG Seminar October 14, 2004

  4. A Third Framework:Complex Systems • Complex System: A system composed of multiple vertical organizational levels engaged in horizontal processes that cross vertical organizational boundaries • Problems occur at the interchange boundaries/interfaces • Duplication/redundancy of effort • Inefficiency/variability of process BCIG Seminar October 14, 2004

  5. The Computer-Based Patient Record • Described by 1991 IOM report: “The Computer-Based Patient Record: An Essential Technology for Health Care” • 180 features in 12 categories. “The CPR should support…” • direct data entry by all persons caring for a patient • measurement of health status and function (outcomes of care) • support for co-managing cost and quality of care • documentation of clinical reasoning and rationale • clinical problem solving/decision support • Problem/Condition Lists • relevant and timely linkage with all relevant patient information • layered confidentiality and audit trails • continuous (ad hoc) (authorized) user access • simultaneous user views • local and remote information access to relevant resources • existing and evolving specialty needs BCIG Seminar October 14, 2004

  6. What Makes the CPR so Difficult? • Complexity of purpose • Requirement for (computable semantic) interoperability • Historic lack of standards facilitating (computable semantic) interoperability • ‘Best of Breed’ • E.g. Medication allergy • Initial text capture in an anesthetic setting • Need for machine processing and decision support in an ER setting BCIG Seminar October 14, 2004

  7. The National Health Information Infrastructure (NHII) • 2004 Announcement: “An initiative set forth to improve the effectiveness, efficiency, and overall quality of healthcare in the US through the development of a comprehensive knowledge-based network of interoperable systems of clinical, public health, and personal health information that will improve decision-making by making the information available when and where it is needed. The NHII includes the set of technologies, standards, applications, systems, values, and laws that currently or will be needed to support all facets of individual health, personal healthcare, and public health.” BCIG Seminar October 14, 2004

  8. The Continuity of Care Record (CCR) • 2003 initiative: “developed in response to the need to organize and make transportable a sete of basic information about a patient’s healthcare accessible to all clinicians and patients. The CCR is intended to foster and improve the continuity of care, reduce medical errors, and ensure a minimum standard of secure health information transportabiliity. Adoption of the CCR by the medical community and IT vendors will be the first step in achieving interoperability of medical records.” • CCR is being developed by the AAFP, the Massachusetts Medical Society, the AMA, the AAP, HIMSS, American Health Care Association, and ASTM Committee E31. BCIG Seminar October 14, 2004

  9. The Continuity of Care Record (CCR) • Contexts of application include • Referral • Transfer • Discharge • Proposed components of the CCR include • Dx, Problems, and Conditions • Adverse Reactions/Alerts • Current Medications and Immunizations • VS • Lab results • Procedures and Assessments • “Extensions” BCIG Seminar October 14, 2004

  10. The Cancer Bioinformatics Grid (caBIG) • 2003-04 initiative: “…An informatics infrastructure that will connect teams of cancer and biomedical researchers together to enable them to better develop and share tools and data. Standards for common vocabularies and data elements will be an integral part of the caBIG infrastructure.” BCIG Seminar October 14, 2004

  11. A caBIG Example(from Covitz et al, Bioinformatics, V19, N18, P2404) • Patient presents with headache, focal weakness, history of seizures • Workup reveals glioblastoma multiforma subtype astrocytoma • Is this tumor histology is associated with gene expression abnormalities? • Yes, in the p53 signaling pathway including BCL2, TIMP3, GADD45A, CCND1 • Is there documented evidence of aberrant expression of (e.g.) CCND1? • Yes, SAGE tags for cyclin D1 appear with 3x greater frequency in cancerous vs normal brain tissue • Are any gene products of the p53 signaling pathway known targets for therapeutic agents? • Yes, TP53, RB1, BCL2, CDK4, MDM2, CCNE1 • Are any of the agents known to target these genes being specifically tested in glioblastoma patients? • Yes, trials xxx and yyy are currently underway • Research data at the point of care, Clinical data at the point of research BCIG Seminar October 14, 2004

  12. “Interoperability” • Everyone in healthcare seems to want it (at least in some sense) • What does it mean? • Is it obtainable? • If so, at what cost ($$, effort, etc.)? BCIG Seminar October 14, 2004

  13. Clinical Data Interchange Standards Consortium (CDISC) • CDISC is an open, multidisciplinary, non-profit organization committed to the development of worldwide industry standards to support the electronic acquisition, exchange, submission and archiving of clinical trials data and metadata for medical and biopharmaceutical product development. • CDISC’s mission is to lead the development of global, vendor-neutral, platform-independent standards to improve data quality and accelerate product development in our industry. BCIG Seminar October 14, 2004

  14. The “World of Clinical Trial Standards” (circa 2004) International Conference on Harmonization (ICH) U.S. Dept. of Health and Human Services (HHS) EFPIA JPMA PhRMA EMEA MHLW KIKO U.S. FDA CDC NIH/NCI NLM TC: RCRIM DICOM Protocol Std ISO/ANSI CDISC Health Level 7 (HL7) ADaM SDS ODM Reference Information Model RIM LAB MedDRA LOINC SNOMED Clinical Document Architecture eCTD = Dictionary, Codelist = Document Standard, or Architecture = Organization = Standard = Model

  15. Health Level Seven (HL7) • “HL7 develops specifications that enable the semanticallyinteroperable exchange of healthcare data. ‘Data’ refers to any subject, patient, or population data required to facilitate the management or integration of any aspect healthcare including the management, delivery, evaluation of and reimbursement for healthcare services, as well as data necessary to conduct or support healthcare-related research. HL7 Specifications are created to enable the semanticallyinteroperable interchange of data between healthcare information systems across the entire healthcare continuum.” (C Mead paraphrase of HL7 Mission Statement) BCIG Seminar October 14, 2004

  16. Founded in 1987 Produced Version 1.0 and 2.0 in ‘87 and ‘88 Approved HL7 message standards - 2.1, 2.2, 2.3, 2.3.1 and 2.4 in ‘90, ‘94, ‘97, ‘99 and ‘00 Approved CCOW standards 1.0, 1.1, 1.2, 1.3 in ’99, ’00 and ‘01 Approved Arden Syntax standard in ’99 Approved XML-based Clinical Document Architecture standard in ‘00 Accredited as an SDO by ANSI in 1994 All HL7 approvals since ‘94 are “American National Standards” Published implementation recommendations for: Object broker interfacing ‘98 Secure messaging via e-mail ‘99 HIPAA Claims attachments ‘99 XML encoding of Version 2 ’00 HL7: A Brief History(www.hl7.org) BCIG Seminar October 14, 2004

  17. Syntax vs Semantics • The dog eats red meat. • The dog eats blue trees. • Give the patient pain medication. • Give the patient medication for pain. • Time flies like an arrow • Fruit flies like a banana. • Syntax  Structure • Semantics  Meaning • ….and then there’s Context • ‘he threw his hat into the ring….’ • ‘he’s got a chip on his shoulder…’ BCIG Seminar October 14, 2004

  18. (Concept) Symbol “Shark” Thing Concept 1 “Delicious with cabernet.” Concept 2 “A guy who hustled me.” Concept “A predator.” Thing 1 Symbol “Shark” Symbol “Shark” Thing Thing 2 The Semiotic Triangle:How Humans Communicate BCIG Seminar October 14, 2004

  19. Semanticinteroperability Syntacticinteroperability (interchange) Interchange vs Interoperability • Main Entry: in·ter·op·er·a·bil·i·ty: ability of a system ... to use the parts or equipment of another systemSource: Merriam-Webster web site • interoperability: ability of two or more systems or components toexchange information and to predictably use the information that has been exchanged. Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Syntax  Structure Semantics  Meaning BCIG Seminar October 14, 2004

  20. The Pillars of(Semantic) InteroperabilityNecessary but not Sufficient • Common model across all domains-of-interest • Information model vs Data model • Model grounded on robust data type specification • Methodology for binding terms from concept-based terminologies • A formally defined process for defining specific structures to be exchanged between machines, i.e. a “messaging standard” The Version 3 Tool Kit BCIG Seminar October 14, 2004

  21. Pillar #1: A Common Model • The HL7 Reference Information Model (RIM) (ANSI) • RIM203.pdf BCIG Seminar October 14, 2004

  22. Pillar #2: A Data Type Specification • The HL7 Version 3 Data Type Specification (ANSI) BCIG Seminar October 14, 2004

  23. Data Types • Design Goals for HL7 Data Type Specification • Coherence • Parsimony • Stability • Completeness • Simplicity • HL7 Data Type Specification as an interoperability standard • ANSI approved • Currently in ISO process • Endorsed by CEN BCIG Seminar October 14, 2004

  24. Pillar #3: A Methodology for Binding to Concept-Based Terminologies • The HL7 Version 3 Vocabulary Technical Committee • Concept-based terminologies are essential for capturing the complexity of healthcare delivery in the context of the CPR and its derivative products BCIG Seminar October 14, 2004

  25. Taxonomy of Terminologies(from Ingenerf, MEDINFO Proceedings, 1995) Dictionaries and Thesauri Collections of terms, definitions, associations, synonyms, etc. Classification Systems Exhaustive concept identification Hierarchical structure Disjunctive Derived from / serve a particular perspective ICD-9 CPT NANDA

  26. Taxonomy of Terminologies(from Ingenerf, MEDINFO Proceedings, 1995) Nomenclatures Multi-axial Combinations of atomic terms used to build complex terms No formal grammar C/C fx of L femur C/C/fx of R eye Formal Terminologies Nomenclature + associated formal grammar Requires tool support to enforce grammar rules during both construction and interpretation SNOMED-CT Grail (Galen Project, Rector et al)

  27. Pillar #4: A Messaging Model • The HL7 Version 3 Messaging Specifications (including Clinical Document Architecture, Release 2) • HL7 is an ANSI Standards Development Organization • HL7 v3 ‘Early Adopters’ Program BCIG Seminar October 14, 2004

  28. The HL7 V3 Messaging Standard • Focused on information exchange that enables semantic interoperability • All “message structures” are derived from the RIM • Message structures defined using HL7-defined process • Message content defined using HL7-supplied tools • Message implementation to multiple technologies • XML • Java BCIG Seminar October 14, 2004

  29. Pillar #1: A Common Model • The HL7 Reference Information Model (RIM) (ANSI) • RIM203.pdf BCIG Seminar October 14, 2004

  30. What’s the RIM ‘About?’ • The set of concepts, attributes, and relationships needed to describe any aspect of healthcare • Clinical • Patient Care • Aggregated Populations • Non-person domains-of-interest • Veterinary • Genomics BCIG Seminar October 14, 2004

  31. What’s the RIM ‘About?’ • The set of concepts, attributes, and relationships needed to describe any aspect of healthcare • Administrative • Scheduling • Materials Management • Personnel Management • Credentialing and Privileging BCIG Seminar October 14, 2004

  32. What’s the RIM ‘About?’ • The set of concepts, attributes, and relationships needed to describe any aspect of healthcare • Financial • Reimbursement model neutral • Supports ‘supply-chain’ approaches to patient care (‘inventory-to-bedside’) BCIG Seminar October 14, 2004

  33. How Can the RIM be All Things to All Parties? • Constructs • High-level abstract structures • Well-defined set of data types • Well-defined interfaces to terminologies • Healthcare Domains (clinical, administrative, financial) are defined by the combination of common structures and unique terminologies BCIG Seminar October 14, 2004

  34. The HL7 Reference Information Model • Motivated by need for standard to facilitate semantic interoperability • HL7 2.x is an interchange standard • “Too technical and abstract for domain experts (‘I can’t find the things I need to describe my domain’)” • “Too abstract and not detailed enough for the technology cognoscenti (‘No methods, no foreign keys…worthless as a data model.’)” BCIG Seminar October 14, 2004

  35. The RIM BackboneEssential Structures of Healthcare A Party (Person or Organization) is involved in zero-to-many Healthcare Actions Party Healthcare Action Is involved in 0.. * 1..* involves A Healthcare Action involves one-to-many Parties (Persons or Organizations) How do we represent a Person as both a Patient and a Clinician? BCIG Seminar October 14, 2004

  36. The RIM BackboneEssential Structures of Healthcare A Party (Person or Organization) in Role is involved in zero-to-many Healthcare Actions A Party (Person or Organization) plays zero-to-many Roles Party Role Healthcare Action 1 0..* 1..* 0..* plays involves How do we represent a Clinician who is a Consultant in one Healthcare Action and a Supervisor in another? BCIG Seminar October 14, 2004

  37. 0..* 1 0..* Role 1 The RIM BackboneEssential Structures of Healthcare A Party (Person or Organization) in Role assuming a Participation is involved in zero-or-one Healthcare Action A Party (Person or Organization) plays zero-to-many Roles Party Participation Healthcare Action 1 1..* A Party (Person or Organization) in a Role may assume zero-to-many Participations BCIG Seminar October 14, 2004

  38. ‘Collections’ using RIM Structures A Healthcare Action can be the source of zero-to-many Healthcare Relationships, each of which relate the source Healthcare Action to one-and-only one other Healthcare Action (the target action). NOTE: Each Observation is ‘Attributed’ AR: “is supported by” OBS: Temp 101F has target is source for OBS: Dx Pneumonia AR: “is supported by” OBS: Abnormal CXR has target is source for AR: “is supported by” is source for OBS: Elevated WBC has target BCIG Seminar October 14, 2004

  39. 0..* 0..* 0..* 0..* Role Link ActRelationship 1 1 1 1 0..* 1 0..* Role 1 The HL7 Reference Information Model Has component Is supported by Entity Participation Act 1 1..* • Organization • Place • Person • Living Subject • Material Patient Member Healthcare facility Practitioner Practitioner assignment Specimen Location Referral Transportation Supply Procedure Consent Observation Medication Administrative act Financial act Author Reviewer Verifier Subject Target Tracker ReducedShakespeare.ppt BCIG Seminar October 14, 2004

  40. State • Definition: “A named stage in the lifecycle of an instance of a concept” • Washing Machine • Stopped, Running (Filling, Spinning, Emptying) • Lab order • New, Active, Suspended • The lifecycle of a concept (i.e. valid states and transitions) is shown in a State Diagram (a visual representation of a State Machine) • A single instance of a concept may take on one-to-many states over its ‘lifetime’ • An instance does not have to pass through all possible states in its lifetime

  41. The State Diagram for the Act Class

  42. Mood • Definition: “A named description – from the perspective of a single concept – of one stage of a business cycle” • e.g. Order/Request vs Event • In order to completely describe a business cycle (from the perspective of a single concept), multiple instances of that concept – each with their own mood designation – must be instantiated • The term ‘mood’ is used based on its meaning in formal grammar, where it is used to describe certain characteristics of verbs relative to time • A concept instance can have many state (aka status) values in its life; it can have one and only one mood

  43. Mood in HL7 V3 • Specified by the value of the ‘moodCode’ attribute in the Act class • All instances of Act (or its subtypes) must have a value for moodCode attribute • Once assigned (at creation time), the value of moodCode never changes • moodCode value set is controlled by HL7 • Examples include… • Define • Order/Request • Event • Goal

  44. Mood: Example 1 • The Concept: Penicillin VK 500mg IV • In Master Service Catalogue (orderable)  DEFINE • Ordered or patients  ORDER/REQUEST • Mr. Brown TID x 10 days • Mrs. Smith QID x 7 days • Mr. Jones 2 doses STAT • Given to patients based on order  EVENT • Mr. Brown  3 x 10 = 30 events • Mrs. Smith  4 x 7 = 28 events • Mr. Jones  1 (or 2) events • State describes single instance; mood describes multiple instances in a business process

  45. Mood: Example 2 • The Concept: Observation (Ambulatory Assessment) • 03.06.03: “Pt will walk 20 ft without assistance in 3 weeks.” • 03.27.03: “Pt walked 15 ft with assistance.” • 03.27.03: “Pt did not meet ambulatory goal.” OBS: Date1: 03.06.03 Date2: 03.27.03 Amb. Asmt. moodCode: GOAL Value: 20 w/o AR: “has outcome” Is source for Is target for OBS: Date: 03.27.03 Goal Assmt. moodCode: EVT Value: DNM OBS: Date: 03.27.03 Amb Asmt. moodCode: EVT Value: 15 w AR: “has explanation” is source for has target

  46. Mood: A Final Implication • Because an instance in ORDER mood is different from an instance in EVENT mood, it follows that the ORDER mood instance will not have any ‘value’ associated with it, while the instance in the EVENT (or GOAL) mood will have a ‘value’ associated with it. • It follows (after a bit of thought) that Documents are collections of values which can be represented as instances of Acts in the EVENT mood • A document instance may have a complex structure which requires consider use of ActRelationship instances • Documents have additional semantics (discussed later)

  47. RMIM – Specifications vs Constraints

  48. Standardized Models (UML) Non-standard Graphics ad hoc Drawings Structured Documents Free-text Documents Discussions The Communication Pyramid ` ProblemSpace SolutionSpace Implementation-Independent Implementation-Specific Communication Source: Charlie Mead, MD, HL7 BCIG Seminar October 14, 2004

  49. Specification Development Requirements Implementation Domain Experts Vendors HL7 RCRIM FDA HL7 Documentation XML message spec SROs CDISC SEND ICH FDA other Other.. R. Levin, EuroInterchange, May 2004 (modified by Med, Oct 2004 Standards Development BCIG Seminar October 14, 2004

  50. Requirements Documentation:The Problem Space Model The “Problem Space” is defined using a combination of visual models and a rigorously-defined and linked Glossary Mission Statement And Goals Requirements Documentation Requirements Specification • Document Domain Process Flow: UML Activity Diagram • Capture Domain Structure: UML Class Diagram and Glossary • Capture Business Rules: Relationships, Triggers, and Constraints • Harmonize the resulting Problem Space Model with HL7 RIM etc. BCIG Seminar October 14, 2004

More Related