Implementing a Document Standard · Overview of SPL 7 Content of Physicians Desk Reference (PDR)...
Transcript of Implementing a Document Standard · Overview of SPL 7 Content of Physicians Desk Reference (PDR)...
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
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
“Protocol” – a ‘common’ term…
Symbol“Protocol”
“We need to sign off on the protocol by Friday”
Concept 1
Thing 1(Document)
“Protocol XYZ has enrolled 73 patients”
Concept 2
Thing 2(Study)
“Per the protocol, you must be at least
18 to be enrolled”
Concept 3Thing 3(Plan) Ogden/Richards
Mead/Speakman
3 Source: John Speakman
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
Information vs Terminology ModelsIntersecting and interleaving semantic structures
Common Structuresfor
Shared Semantics
Common Structuresfor
Shared Semantics
Information ModelInformation Model
Domain-Specific Terms specifying
Domain-Specific Semantics
Domain-Specific Terms specifying
Domain-Specific Semantics
Terminology ModelTerminology Model
Binding/InterfaceBinding/Interface
5
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
Overview of SPL
7
Content of Physicians Desk Reference (PDR)
– Text + computable knowledge representation– Physician Labeling Rule (2006) support for DSS– Each instance of an SPL is a CDA instance
Mature HL7/ANSI standard
– R1 2004• Drug/Chemical information• Implementation experience
– R2 2005• Clinical Drug information
– R3 9/2006• Implementation experience
– R4 ~2008 adding…• Devices• food items• OTC medicines• implementation experience
Overview of SPL (2)> 2000 labels currently represented
– Majority of common prescription drugs are in data base• FDA working on closing the remaining gaps
– http://dailymed.nlm.nih.gov/dailymed/about.cfm
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
ASTM CCR + HL7 CDA = CCDASTM 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
CCR: ContentDriven 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 transportablea set of basic patient information consisting of the most relevant and timely facts about apatient’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 leasta minimum standard of secure health information transportability.” -- ASTM.org
10
CCR vs CDA: PropertiesSignificant 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
CCR vs CDA: StructureCCR 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
CCR Content Represented in CDA Instance: CCDAn ‘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
Information vs Terminology ModelsIntersecting and interleaving semantic structures
Common Structuresfor
Shared Semantics
Common Structuresfor
Shared Semantics
Information ModelInformation Model
Domain-Specific Terms specifying
Domain-Specific Semantics
Domain-Specific Terms specifying
Domain-Specific Semantics
Terminology ModelTerminology Model
Binding/InterfaceBinding/Interface
Common Structuresbound to
Domain-Specific Structures specifying
Domain-Specific Semantics
Common Structuresbound to
Domain-Specific Structures specifying
Domain-Specific Semantics
Information ModelInformation Model
Terminology ModelTerminology Model
Domain-Specific Terms specifying
Domain-Specific Semantics
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
Incremental Computational Semantic Interoperability
Less “Informational” Systems
Highly “Informational” Systems
1001 0100 01001011 1110 0101
1001 0100 01001011 1110 0101
*
1001 0100 01001011 1110 0101 1001 0100 01001011 1110 0101
*
*HL7 Clinical Document Architecture: Single standard forcomputer processable and computer manageable data
(Wes Rishel, Gartner Group)
15
Document-centricity vs Data-centricity: The ProblemDocument-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
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
Document-centricity vs Data-centricity: A SolutionDevelop 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
Document-centricity vs Data-centricity: A Solution
NAME: J StrongDOB: 22.05.47GENDER: MALLERGIES: PenicillinDX: CHFMEDS:
Digoxin 0.5mg PO qdLassix 40mg PO qd
- - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - -- - -- - - - - - - - - - - - - - - - - -- - - - - - - -
D. White, MD
NAME: P HansenDOB: 04.10.59GENDER: FALLERGIES: SulfaDX: RAMEDS:
Aspirin 650mg PO qd
- - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - -- - -- - - - - - - - - - - - - - - - - -- - - - - - - -
D. White, MD
Name DOB --- --- ObsValue
StrongHansen
--- --- ------ --- ------ --- ---
--- --- ---
---
---
Observation (Value = XML blob)
“Value”deconstructed
“Value”deconstructed
Observation (Value = XML blob)
19
SummaryAdopting 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 ‘meta-document’ 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
“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 unlockconsiderable clinical content currently stored in free-text clinical notes,and to enable comparison of content from documents created oninformation 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
QUESTIONS & ANSWERS