California Public Health Data Exchange:
Using HL7 Clinical Document Architecture (CDA)
PHIN Conference Atlanta, Sept. 2006
A Collaborative Project Report by: Nancy McQuillen M.S., Data Architect, CA DHS Jason Siegel M.D., Atlas Development Corp.
AGENDA
1) Functional Needs - California In-State data exchange
• • 3 categories of requirements Local terminology and acronyms
2) Messaging Needs • Interaction Diagrams
3) Message Content • • Data fields per message (and per “concept”) Relationships between concepts (Domain Analysis Model)
4) Mapping message content to HL7 • • •
PHIN 2006
HL7 v.3 CDA HL7 v.2.x Contrasts between HL7 versions: v.2, v.3 messages, v.3 CDA
2
Three Dimensions of California In-State Data Exchange
IN – to Public Health from clinical sources, i.e. first
indications to local Public Health jurisdictions (mandated reporting by licensed healthcare providers including physicians, nurses, dentists, veterinarians, etc.)
ACROSS – from one Public Health jurisdiction to
another, e.g. re-directing in-coming reports, or transferring existing cases and investigations to the proper “owning” jurisdiction and program.
UP
– from local Public Health jurisdictions to State, for review, counting and further upward reporting to CDC; (and DOWN to complete the State-Local feedback loop, e.g. regarding case classifications -suspect, probable, confirmed).
PHIN 2006 3
Acronyms Used for the Three Dimensions of Data Exchange
IN – • CMR (confidential morbidity report – from licensed provider to local public health jurisdiction) ACROSS – • CMR (redirected to proper jurisdiction, based on patient address) • CTR (case/investigation transfer report, e.g. when a patient moves) UP – • CRR (case report from Local to State Public Health, for counting, State review, and feedback) • ORR (outbreak report from Local to State Public Health, or between any two Local/State jurisdictions)
PHIN 2006
4
Summarized Interaction Diagram – CA Public Health Data Exchanges
Up to: 1 State Jurisdiction: CMR2 Across between: 61 Local Jurisdictions: CRR1 CRR2
5 4
3 2
CMR1 CTR
....
…
5
In from: 100’s of Licensed Providers:
1
(case investigation detail)
PHIN 2006
1. CMR: In to Public Health
(future goal; from selected providers with automated clinical systems and messaging capabilities)
PHIN 2006
6
2. CMR: re-directed to correct jurisdiction
(current goal, for integration of multiple CA PH systems)
PHIN 2006
7
3. CTR: In-progress “Case” Investigation Transfer
PHIN 2006
8
4. & 5. CRR: Case Report (Local to State, and return)
PHIN 2006
9
Participants in Data Exchanges
CDA Header “Participants” – for CA Data Exchanges
Interaction Codes (temporary labels for specific interactions *)
CMR1 (Morbidity Rpt)
CMR2 (Morb. Rpt. Redirect)
Licensed Provider LHJ Org. (from) N/A
CTR (Case Transfer)
LHJ Investigator LHJ Org. (from) N/A
CRR1 (Case Rpt. To State)
LHJ Investigator LHJ Org.
CRR2 (Return to Local)
SHJ Reviewer SHJ Org.
Author (Person) Custodian (Organization) Data Enterer (Person) Intended Recipient (Organization) Record Target (Person)
Licensed Provider Provider’s Org. Provider Staff LHJ Org.
N/A
N/A
LHJ Org. (to)
LHJ Org. (to)
SHJ Org.
LHJ Org./Pers on Patient
Patient
Patient
Patient
Patient
* Legend to Interaction/Document types (see Interaction Diagrams also): CMR1 – CMR submitted by Provider to Local Health Jurisdiction (LHJ) CMR2 – CMR redirected from one LHJ to another LHJ CTR – Case/Investigation “stub” transferred from one LHJ to another LHJ CRR1 – Case reported by LHJ to State Health Jurisdiction CRR2 – Case returned from State Health Jurisdiction (SHJ) to submitting LHJ, with reviewer’s comments PHIN 2006
10
ORR Domain Analysis Model (DAM)
PHIN 2006
11
CRR Domain Analysis Model (DAM)
PHIN 2006
12
HL7 Reference Information Model (RIM) Backbone and Color Coding
Role Link
0..* 0..*
Act Relationship
0..* 1 0..* 1 1 0..* 1 0..* 1
1
Plays
0..* 0..*
Entity
0..1 0..1
Role
Participation
Act
Scopes
PHIN 2006
13
The CDA Model – An HL7 v.3 RIM-derived message model (RMIM)
CDA Header (Left side)
• The focal Act: ClinicalDocument • Main Participants: Author (e.g. licensed clinical provider) InformationRecipient (e.g. local health department) RecordTarget (e.g. the patient)
CDA Body (Right side)
• Component Sections of the Document, e.g.: Diagnosis Section Lab results section • Entries within Sections (Clinical Statements, e.g.): Observations SubstanceAdministrations
PHIN 2006 14
CDA Header Participants
CDA RMIM - upper left
PHIN 2006
15
CDA Header Participants, cont’d
CDA RMIM lower left
PHIN 2006
16
Mapping DAM attributes to CDA
Data Element Name
Local to State Case Report (CRR) LHD ID (II) LHD name Case report date-time Case report comments Investigator/submitter name Investigator/submitter phone # Investigator/submitter fax # Document ID (II) Reporting Provider
Hdr Hdr Hdr Body Hdr Hdr Hdr Hdr
SHALL SHALL SHALL MAY
Hdr/ Body
Conform Stmt.
CDA RMIM Location (partial path)
ClinicalDocument/author/assignedAuthor/representedOrganization/id ClinicalDocument/author/assignedAuthor/representedOrganization/name ClinicalDocument/effectiveTime entryRelationship/observation.text (Note: Act.text of the PH Case related to the Condition) ClinicalDocument/author/assignedAuthor/assignedPerson/name ClinicalDocument/author/assignedAuthor/representedOrganization/telecom ClinicalDocument/author/assignedAuthor/representedOrganization/telecom ClinicalDocument/id Note: Required on a CMR, but not absolutely required on this report to State (CRR)
SHOULD
SHOULD
SHOULD
SHALL
Provider name
Body
SHOULD
component/section/entry/observation/performer/AssignedEntity/assignedPerson
17
etc.2006 .. PHIN
XML Example: Author (1 of 5 CMR Header Participants)
Name of CMR Author
Organizational Context of Author
PHIN 2006
18
Clinical statement model
CDA RMIM upper right
PHIN 2006
19
CDA RMIM – lower right
Clinical statement, cont’d
PHIN 2006
20
CDA Body: Clinical Statements
Acts -- e.g. time-dependent statements regarding
real-world events, including: • Observations • Substance Administrations • Procedures • Etc.
Relationships between the statements (internal to
this clinical document)
Act references - to ExternalDocuments and
ExternalActs and ExternalObservations, e.g. point from a CTR (case report) to related CMRs and/or Lab Reports
PHIN 2006 21
Act Relationships Model (Draft)
Potential Acts (and ActRelationships) in a Case Notification (CRR)
Outbreak OUTB
This outbreak has a component of this case. (Optional relationship in the CRR, when a case is known to be associated to an outbreak.) COMP
PH Case / Investigation
CASE
The reason for this case/investigation is the observation of this disease condition.
RESN
Condition COND
COMP
Component Observations OBS
These observations (e.g. lab result or epidemiological conclusions) comprise the additional PH case/investigation information.
PHIN 2006
22
XML Snippet Example: Diagnosis
Text Rendering of the coded entry
PHIN 2006
23
Low-tech option: the clinical document viewed by human (with web browser)
Text as rendered by previous XML snippet
PHIN 2006
24
Continuum of HL7 Versions and Implementation Options
Toward “semantic interoperability”:
• Can your system properly interpret and act upon the message sent by my system? • Can you confidently and accurately aggregate coded data from many sources for analysis, slicing, and dicing?
Is the standard alone “tight” enough to constrain the message and the vocabulary? A continuum toward precision:
• HL7 v.2 => CDA => v.3 messages
PHIN 2006
25
Mapping California Messages to v.2.5 (a former experiment)
Applicable HL7 2.5 Messages and Trigger Events:
Public Health Data Exchange 1. Report case (to LHD, State) 2. Request clinical information 3. Transfer case (responsibility) 4. Report to State (for counting) 5. Query name matches Related Ch. 11 Referral Messages and Trigger Events REF/RRI - Patient Referral (Event I12) * RQC/RCI - Request For Patient Clinical Information (Event I05) RQC/RCL - Request/Receipt Of Clinical Data Listing (Event I06) REF/RRI - Patient Referral (Event I12) * REF/RRI - Patient Referral (Event I12) * RQI/RPL - Request/Receipt Of Patient Selection Display List (Event I02) RQI/RPR - Request/Receipt Of Patient Selection List (Event I03) RQP/RPI - request for patient demographic data (Event I04) •REF/RRI - Modify Patient Referral (Event I13) •REF/RRI - Cancel Patient Referral (Event I14) •REF/RRI - Request Patient Referral Status (Event I15)
6. Update patient (demographics) 7. Update (case) status/information
PHIN 2006
26
Mapping a CMR DAM to v.2.5
Referral Message Segments (relevant to Public Health use):
• • • • • • • • Patient (PID) Provider (i.e. Jurisdiction) (PRD) Referral (RF1) Diagnosis (DG1) Observation Orders and Results (OBR, OBX) Procedures (PR1) Allergies (AL1) Treatments? (Not available in Chapter 11 Referral message, but potentially useful in future)
PHIN 2006
27
Pros of HL7 v.2.x
Broad U.S. installed base of v.2.x. (in hospitals and laboratories). Mature HL7 standard, conformance approach, and tooling (e.g. Messaging WorkBench (MWB) for message profiles, and v.2 XML Implementable Technology Specification (ITS) for XML syntax specification). Currently more available commercial and open source parsers and integration brokers (vs. v3/CDA). CDC focusing on 2.5 for most PHIN-compliant messaging, including ELR and State-CDC reporting. Simpler to implement
PHIN 2006
28
Cons of HL7 v.2.x
Most legacy 2.x messages use EDI-style bar syntax vs. XML syntax (thus messages are not available for direct manipulation using XML-family tools such as XSLT style sheet transforms). Lacks some advanced datatypes:
• Does not directly support post-coordinated “phrases” (vs. single concepts) i.e. lacks CD datatype, e.g. for SNOMED phrases: complex symptoms, diagnoses, etc. • Does not support terminology version #.
Does not represent the long-term future direction of HL7 for achieving semantic interoperability (an older standard, but it continues to evolve, v.2.6, v.2.7 . . ) Not based on a unifying conceptual data model (RIM); fewer complex relationships; fewer entity/act classes modeled (e.g. public health case, investigation.)
PHIN 2006
29
Pros of HL7 v.3
More robust datatypes (e.g. concept descriptor (CD)). Model-based; rich relationships, and extensibility due to abstract RIM + structural vocabulary for classes. Some public health constructs such as cases and investigations have been modeled, and many more are currently in development (e.g. currently several in progress via Canadian Infoway Project, CDC, and PHER SIG of HL7.) Message wrappers (“outer” generic transmission wrappers and “inner” control act wrappers with interaction semantics) capable of handling intricate real-time transactions and application acknowledgements.
PHIN 2006 30
Cons of HL7 v.3
Complexity of v3; both in message construction, due to complex XML schemas, and in understanding v3 artifacts in general – (especially for those without data modeling and XML background). Standard is immature; several aspects are still evolving – but significant inter-organizational and/or national projects are currently progressing (especially in other countries, including the UK, Canada, Mexico, Germany, and the Netherlands.)
PHIN 2006
31
Pros of HL7 v.3 CDA
Formal mechanisms to retain documents, including all context (e.g. authors of subsections); mechanisms to replace, append, document content, etc. More support for unstructured text, along with and related to discrete data fields. Formalized support for standard rendering (for human viewing with a web browser, without need for computer parsing.) Gaining quite wide acceptance and adoption by several national interoperability projects for clinical documents/content; Sample implementation guides available.
PHIN 2006
32
Cons of HL7 v.3 CDA
Cons are primarily the same as stated above for v.3, since CDA is also a v.3 standard; i.e. it is a newer, more complex standard compared with v.2.x. CDA has a regular structure (predefined framework for the header and body), but requires more constraining and specification, compared to v.3 messages, which can be more “custom tailored” to a specific use case at the RMIM level.
PHIN 2006
33
In Summary
Reasons why we chose to pursue this project to define the use of CDA for California’s in-State disease surveillance messaging needs. Where to find more information on HL7’s UML-based methodology for messaging project designs, progressing from requirements to domain analysis models to message models and specifications.
PHIN 2006
34
Reasons for transitioning to v3 using CDA
Enable a “lower-tech” approach for some PH players
• Sending and receiving applications could interpret just the CDA header (and detach the accompanying image/text)
CDA document is “just” an XML document with two parts:
• 1) a header (required to be standardized in all CDA documents, i.e. by listing “participations” such as author and intended recipient), and 2) a body – which can optionally be: A visual text rendering (only) of the document/portions Partially text, partially coded (with links between the two)
Totally coded (e.g. all observations LOINC/SNOMED encoded)
•
An image of the document (no code, no text, just picture)
PHIN 2006
35
Reasons for transitioning to v3 using CDA
CDA provides a transition path from text to coded/formalized data For some use cases, CDA documents may be exchanged just as XML documents (no v3 wrappers, no intricate real-time v3 message negotiation) CDA already has a validated, standard RMIM and XML schema CDA plus an implementation guide provides a standard that is ready to go; precludes HL7 ballot cycles (many months)
PHIN 2006 36
Reasons for transitioning to v3 using CDA
CDA documents can be embedded as the “payload” (the XML document content) of HL7 v2 or v3 messages The Structured Documents committee of HL7 (the keepers of the CDA standard) have done an exemplary job of creating an accessible standard, i.e. explained for newcomers, including well developed: • examples, tutorials, a community of followers and specialized conferences, and a “CDA quick-start guide” There is significant interest in CDA applications within electronic health records efforts, e.g. the ASTM and HL7 are jointly developing and balloting the Continuity of Care Document (CCD), which is the content of the ASTM Continuity of Care Record (CCR) mapped into CDA. The project includes an implementation guide to further constrain CDA (using validators written in constraint languages and open source XML tools like Schematron, plus XSLT and XPATH.)
PHIN 2006 37
HL7 Development Framework (HDF):
A Methodology for Producing Design Artifacts
1) Functional needs • Storyboards
2) Messaging needs • Interaction Diagrams
3) Message content • Domain Analysis Models
4) Mapping message content to the HL7 RIM • Refined Message Information Models (RMIMs)
5) Serializing the RMIM diagram • Hierarchical Message Description (HMD)
6) Casting the serialized message into XML PHIN 2006
•
HL7 XML Implementable Technology Specification (ITS)
38
Discussion (and/or thought questions)
• What are the Local/State messaging needs of your jurisdiction/program/agency? • Which of these requirements are “document-like” vs. “transaction-like”? • Which HL7 versions or other techniques seem optimal for your requirements?
PHIN 2006
39
Acknowledgements
The authors would like to thank the following persons and organizations who have consulted with us on the messaging requirements, models, mappings, vocabulary, and/or XML code samples in this presentation:
• • • • • • • •
PHIN 2006
Dr. Mark Starr, NEDSS Principal Investigator and Acting Chief, Division of Communicable Disease Control, CA DHS Abdul-Malik Shakir, Shakir Consulting AbdulDr. Cecil Lynch, OntoReason LLC and UC Davis Informatics Los Angeles County Public Health, epidemiology, BT, and information technology staff Amnon Shabo, IBM Israel Bob Dolin, M.D. and Liora Alschuler, Co-chairs of HL7 Structured CoDocuments Technical Committee HL7 Public Health and Emergency Response (PHER) SIG The management team of Atlas Development Corp.
40