Implementing a Document Standard: Perspectives on Adoption, Interoperability, and Utilization

Transcription

1 Implementing a Document Standard: Perspectives on Adoption, Interoperability, and Utilization Health Level 7 Clinical Document Architecture: What is it? Who is using it? Why in ehealth? Scottish Health Service Centre February, 23, 2007 Edinburgh, Scotland Charles N. Mead, MD, MSc Senior Technical Advisor National Cancer Institute (cabig Program) 1

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, clinical research and the life sciences have traditionally used atoms to move bits 2

3 Protocol a common term Concept 1 We need to sign off on the protocol by Friday Concept 2 Protocol XYZ has enrolled 73 patients Thing 1 (Document) Symbol Protocol Thing 2 (Study) Concept 3 Per the protocol, you must be at least 18 to be enrolled Thing 3 (Plan) Ogden/Richards Mead/Speakman 3 Source: John Speakman

4 The Four Pillars of Computable Semantic Interoperability (CSI): Necessary but not Sufficient Common model across all domains-of-interest Information model vs Data model The semantics of common (shared) data (dynamic and static) Common model grounded on robust data type specification Methodology for binding to concept-based terminologies Domain-specific semantics A formally defined process for defining specific structures to be exchanged between machines, i.e. a data exchange standard A single CSI statement is made by binding common, cross-domain structures to domain-specific terminologies (semantics). 4

5 Information vs Terminology Models Intersecting and interleaving semantic structures Information Model Common Structures for Shared Semantics Binding/Interface Terminology Model Domain-Specific Terms specifying Domain-Specific Semantics 5

6 CDA in the US (Exemplar list of CDA adoption) Driven by interoperability requirements Large Providers Mayo Kaiser Permanente Department of Defense/Military Health Service Large Payors CMM Claims Attachments (HL7) Large Regulators Federal Drug Administration Structured Product Label (HL7 SPL) Large Clinical Communities ASTM International/Massachusetts Medical Society/HIMSS, American Academy of Family Physicians, American Academy of Pediatrics, AMA Continuation of Care Record (CCR) Continuity of Care Document (CCD) 6

7 Overview of SPL Content of Physicians Desk Reference (PDR) 7 Text + computable knowledge representation Physician Labeling Rule (2006) support for DSS Each instance of an SPL is a CDA instance Mature HL7/ANSI standard R Drug/Chemical information Implementation experience R Clinical Drug information R3 9/2006 Implementation experience R4 ~2008 adding Devices food items OTC medicines implementation experience

8 Overview of SPL (2) > 2000 labels currently represented Majority of common prescription drugs are in data base FDA working on closing the remaining gaps Preliminary collaboration with ICH and European SPL-like effort SPL Specification underscores the point that CDA is a structured document pattern requiring a context-specific Implementation Guide Including terminiology bindings 8

9 ASTM CCR + HL7 CDA = CCD From its inception, CDA has supported the ability to represent professional society recommendations, national clinical practice guidelines, and standardized data sets. From the perspective of CDA, the ASTM CCR is a standardized data set that can be used to constrain CDA specifically for summary documents. The resulting specification, known as the Continuity of Care Document (CCD), is being developed as a collaborative effort between ASTM and HL7. Bob Dolin, MD (KP) 9

10 CCR: Content Driven by need to exchange data in care settings involving multiple stakeholders separated in time and space Contains necessary clinical data deemed to be clinically relevant as a patient s care is transferred between clinicians: a patient snapshot Demographics Insurance information Diagnosis Problem List Medications Allergies -- Similar in content to GP-to-GP message The CCR has been developed in response to the need to organize and make transportable a set of basic patient information consisting of the most relevant and timely facts about a patient s condition. It is intended to foster and improve continuity of patient care, reduce medical errors, improve patients roles in managing their health, and assure at least a minimum standard of secure health information transportability. -- ASTM.org 10

11 CCR vs CDA: Properties Significant overlap, some differences Both have ability to aggregate into larger document collections CCR has less formal notion of references, particularly to external MIME types CCR has Messaging perspective vs CDA s Document perspective CDA support guarantees Persistence Stewardship Authentication Wholeness Global/Local Context Human Readability 11

12 CCR vs CDA: Structure CCR built using friendly XML Meta-data and data defined by committee of domain experts Is this a relevant requirement? The siren song of XML Target of semantic interoperability? What is the breadth of the interoperability community for CCR?? EHR?? Clinical Research?? Cross-institutional?? Cross discipline? CDA XML derived from HL7 RIM via tooling HDF separates what from how HL7 represents a broader interoperability community CDA is actually a specification of a meta-document or document class Implementation requires specific meta-data and data bindings 12

13 CCR Content Represented in CDA Instance: CCD An implementation of the CDA document pattern Utilizes Clinical Statement Pattern Conceptually similar to openehr archetypes Operationally different (e.g. implementation-level specifics) Terminology bindings included in CCD Implementation Guide Semantics of (implicit) CCR information model (derived from XML) mapped to RIM CDA encourages stepwise interoperability between systems of different levels of interoperability maturity 13

14 Information vs Terminology Models Intersecting and interleaving semantic structures Information Model Common Structures for Shared Semantics Binding/Interface Terminology Model Domain-Specific Terms specifying Domain-Specific Semantics Information Model Common Structures bound to Domain-Specific Structures specifying Domain-Specific Semantics Terminology Model Domain-Specific Terms specifying Domain-Specific Semantics PROBLEM: Consistent semantic (but not necessarily syntactic) representation of Acute appendectomy. The concept can be represented in several ways using various combinations of RIM and SNOMED-CT codes. 14

15 Incremental Computational Semantic Interoperability Highly Informational Systems * * Less Informational Systems *HL7 Clinical Document Architecture: Single standard for computer processable and computer manageable data (Wes Rishel, Gartner Group) 15

16 Document-centricity vs Data-centricity: The Problem Document-centric data are stored within a fixed document boundary Medical-legal utility Medical chart utility The input pattern of much of clinical data is based on documents Data-centric interest in data items that cross document boundaries Trend detection Decision Support/Guideline Compliance The output patterns for clinical data are mixed Document-centric: Give me data items X, Y, and Z from the patient s last H&P Data-centric: Give me all the BP and Na + values for the patient for the last 5 visits Give me all the patients with systolic BPs of > 150mm Hg 16

17 Document-centricity vs Data-centricity: The Problem (2) Document-centric repository query performance characteristics Rapid response for whole documents Rapid response for data within a single document Rapid response for document container attribute searches Document type Patient Author/Authenticator/Signatory/etc Date/Time/Place ID Minimal formatting delays (persistence of human readable format) Poor performance for cross-document-boundary queries Data-centric repository query performance characteristics (RDBMS) Rapid response for random single-patient queries across time/space Rapid response for aggregate population data Poor (unacceptable) performance for document reconstruction queries 17

18 Document-centricity vs Data-centricity: A Solution Develop a data-centric schema/repository Base the schema on the semantics of an established standard Support complex data types including XML blobs (XML representation of document) Support a document standard (ideally based on the same standard as the data schema) Using the same input processor to process messages and documents, recursively parse an incoming document as an observation value Pass 1: persist document as XML blob, e.g. the value of a test Support for document-centric queries Pass 2: deconstruct the value (i.e.) document content Support for data-centric queries Resulting implementation supports separation of input and output patterns 18

19 Document-centricity vs Data-centricity: A Solution NAME: J Strong DOB: GENDER: M ALLERGIES: Penicillin DX: CHF MEDS: Digoxin 0.5mg PO qd Lassix 40mg PO qd D. White, MD Value deconstructed NAME: P Hansen DOB: GENDER: F ALLERGIES: Sulfa DX: RA MEDS: Aspirin 650mg PO qd D. White, MD Observation (Value = XML blob) Value deconstructed Observation (Value = XML blob) Name DOB ObsValue Strong Hansen

20 Summary Adopting a document-centric view of data collection facilitates adoption of (stepwise) computational interoperability Adopting a document standard broadens interoperability community Given the diversity of clinical documents, adopting a document pattern or metadocument standard enables specialization without loss of interoperability Definition of both meta-data (e.g. XML tags) and data (e.g. terminology bindings) is essential to achieving interoperability Adopting CDA facilitates incremental interoperability Adopting a document standard enables separation of input and output patterns through recursive application of the standard in an RDBMS context 20

21 Healthcare (and the Life Sciences) are the only businesses where information sharing is the norm rather than the exception. Those of us who design and build information systems are not (normally) used to this framework. However, if we are to provide clinicians and researchers with the tools they need, we must embrace this paradigm completely, committing ourselves to defining, designing, and building fundamentally different types of systems and interfaces than those with which have consumed most of our historical experience. Bob Herbold (1995)/Charles Mead (2002) The need for a document standard stems from a desire to unlock considerable clinical content currently stored in free-text clinical notes, and to enable comparison of content from documents created on information systems of widely varying characteristics. Dolin et al, JAMIA (2001) CDA Design: Guiding Principles: -- Preference to documents created by clinicians performing clinical care -- Minimum technical implementation barriers (including incremental CSI) -- Promote platform-independent longevity -- Promote document exchange independent of transfer mechanisms Dolin et al, JAMIA (2006) 21

22 QUESTIONS & ANSWERS