1 / 83

Clinical Document Architecture CDA::CCR and the Continuity of Care Record

Clinical Document Architecture CDA::CCR and the Continuity of Care Record. MRI Conference August 2004, Boston Liora Alschuler. Liora Alschuler alschuler.spinosa, consultants Co-chair, HL7 Structured Documents TC Co-chair, HL7 Marketing Committee Co-editor, CDA Single Source, principal

kathyg
Download Presentation

Clinical Document Architecture CDA::CCR and the Continuity of Care Record

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. Clinical Document ArchitectureCDA::CCRand the Continuity of Care Record MRI Conference August 2004, Boston Liora Alschuler

  2. Liora Alschuler • alschuler.spinosa, consultants • Co-chair, HL7 Structured Documents TC • Co-chair, HL7 Marketing Committee • Co-editor, CDA • Single Source, principal • Manager, 2004 HL7 HIMSS Technical Demo • liora@the-word-electric.com

  3. Outline • Introduction to the CDA • What is the CDA & What Does It Do? • Key Design Decisions • Implementing CDA • CDA and CCR • Current & future

  4. CDA • Clinical Document Architecture • ANSI/HL7 CDA R1.0-2000 • first certified XML spec for healthcare • first balloted portion of HL7’s “V3” • first RIM-based specification • created & maintained by HL7 Structured Documents Technical Committee (SDTC)

  5. Short history of CDA • Jan. 1997: 1st meeting as HL7 SGMLSIG • July 1997: Operation Jumpstart at Kona Mansion • Jan. 1998: Kona Editorial Group (KEG) • Sept. 1998: Presentation of (renamed & RIM-based)Patient Record Architecture (PRA) • Jan. 2000: First committee level ballot passes • May 2000: Second committee level ballot passes • Sept. 2000: Membership ballot passes unanimously • Nov. 2000:ANSI/HL7 CDA R1.0-2000 • July 2003: First committee ballot CDA Release 2 • August 2004: Third committee ballot now open

  6. Clinical Document Architecture Release 1.0: 3 ballots; 108 votes; all negatives reconciled; unanimous final ballot McKessonHBOC Medic Computer Systems, LLC Medical Center of Boston Intl Medical Informatics Project, UCSF Medical Manager Research & Development, Inc. MedicaLogic, Inc. Netfish Technologies, Inc. Oacis Healthcare Systems, Inc. Oracle Corporation Partners HealthCare System, Inc. PBM Micro, Inc. Per-Se Technologies, Inc. Pitt County Mem. Hospital /University Systems QuadraMed Corporation Queensland Health Saint Vincent Hospital and Health Center scheduling.com Shafarman Consulting Shared Medical Systems (SMS) St. Alphonsus Regional Medical Center SUNY Stony Brook Sutter Health the BREENs The Word Electric U.S. Department of Veterans Affairs University of California Arthur ASHE Student University of Chicago Hospitals & Health Systems Washoe Medical Center 3M Health Information Systems Akron General Medical Center Care Data Systems CareScience, Inc. Danica Biomedical AB Electronic Data Systems Corporation Epic Systems Corporation Figler Consulting Health Network Ventures Healtheon/WebMD Corporation HL7 Australia HL7 Canada HL7 Germany HL7 Japan HL7 United Kingdom IDX Systems Corporation Intermountain Health Care Kaiser Permanente Labtest.com, Inc. Lanier Worldwide, Inc. LifeGard Technologies Los Alamos National Laboratory Magnolia Technologies Mayo Foundation

  7. The HL7 Clinical Document Architecture • priority is patient care, other applications facilitated • minimize technical barriers to implementation • promote longevity of clinical records • scoped by exchange, independent of transfer or storage • enable policy-makers to control information requirements

  8. CDA: scope • The scope of the CDA is the standardization of clinical documents for exchange.

  9. CDA: A Document Exchange Specification • This is a CDA • and this • and this • and this • and this • and this • and this

  10. CDA: A Document Exchange Specification • A CDA can be a • Discharge Summary • Referral • Progress Note • H&P • Public health report • … any content that carries a signature

  11. Clinical Document Architecture on One Leg • (Relatively) simple XML specification for exchange of clinical documents • The rest is commentary

  12. Sample CDA: Ballot R1 2000

  13. Sample CDA: HIMSS 2004

  14. Why ? • Lackofusable and re-usable electronic data:Numbers moving slowly upward, if at all • Need to get information to the point of care, as-needed, when needed • Need to leverage investment in information through re-use for decision support, claims, clinical trials…

  15. Applications of the CDA…or What can you dowith a few tags? • access/portability/exchange • query/locate by patient, provider, practioner, setting, encounter, date • access distributed information through common metadata • integration • multiple transcription systems • with EHR records • re-use/derivative data • summaries, reports • decision support

  16. The CDA document defined CDA Release 2 (draft), section 2.1: A clinical document ... has the following characteristics: • Persistence • Stewardship • Potential for authentication • Context • Wholeness • Human readability “Context - Contents of a clinical document share a common context unless all or part of that context is overridden or nullified.” (material in blue is quoted from the Clinical Document Architecture Release 1.0)

  17. Other Key Aspects of CDA • CDA documents are encoded in XML • CDA documents derive their meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 data types • The CDA specification is generic to all clinical content • CDA documents can be constrained to meet the requirements of specific document types

  18. CDA::Readability • CDA documents are“human readable”= • This principle means that CDA documents are human readable using: a) widely-available and commonly deployed XML-aware browsers and print drivers and b) a generic CDA style sheet written in a standard style sheet language. • CDA documents are also “machine processable”to the degree that markup has been added • required markup provides initial functionality • optional markup can augment processing

  19. XML-encoded info <Section> <code code="10123-x" codeSystem="LOINC">Allergies and Adverse Reactions</code> <text> <list> <item><content>Penicillin - Hives</content></item> </list> </text> <component> <Observation> <code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/> <value xsi:type="CD" code="DF-10074" codeSystem="SNOMED" displayName="Allergy to penicillin"/> <pertinentInformation typeCode="MFST"> <Observation> <code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/> <value xsi:type="CD" code="D0-00165" codeSystem="SNOMED" displayName="Hives"/> </Observation> human readable machine processible CDA Release 2.0: Draft

  20. Header Body The CDA Document • A CDA document is comprisedof a header, referred to as the “CDA Header",and a body referredto as the“CDA Level One Body".

  21. The CDA Header: Purpose • The CDA Header is constant across all CDA documents. Its purpose is to: • Enable clinical document exchange across and within institutions • Facilitate clinical document management • Facilitate compilation of an individual patient’s clinical documents into a lifetime electronic patient record(“uniquely identify a single patient”)

  22. CDA Level One Body • The body consists of either nested containers (sections, paragraphs, lists, tables) or a non-XML blob

  23. A section can contain "structures", nested section's, and codes. CDA structures contain "entries". CDA "structures" CDA "entries"

  24. CDA: How to Create • creating CDA documents • eForms • transcription • EHR • knowledge base • dynamic query • HL7 message conversion (V2 & V3) • DICOM Structured Report transform

  25. CDA: How to Display • any way you like

  26. XML data is accessible <section>Allergy List</section> <para>…</para> <para>…</para> <section>Medications List</section> automated table of contents creation, linked to content, through style sheet transformations

  27. CDA: How to Display • One document, many views • Many documents, one view

  28. CDA::HIMSS demo 2004 • Document creation: • Epic • Microsoft InfoPath (2) • Dictaphone • Adobe • Microsoft BizTalk Server • GE • Management/display: • NIST ebXML registry/repository (open source): model for NHII • Siemens • MS BizTalk, Sharepoint • Raining Data • Kryptiq • Digital Infuzion • CommerceNet • Simi • Document types: • Clinical documentation: surgical note, imaging report, discharge summary • Claims attachments (HIPAA) • Continuity of Care/Referral (Massachusetts Medical Society) • Public health reporting (CA Dept of PH Botulism Case Report) • Tumor registry report (College of American Pathologists) • Structured Product Label (SPL)

  29. CDA::HIMSS demo 2004 • Continuity of Care scenario • Developed by physicians at Massachusetts Medical Society, Duke University Medical Center, Northwestern (Chicago) • Document types: • MMS/ASTM Continuity of Care (CCR) implemented as a R2 CDA • R1 from dictation with voice recognition and NLP • R2 Pathology report • R2 Discharge Summary • R2 Imaging report transformed from DICOM SR

  30. One CDA, many applications: pathology Display or print (referring physician’s view Source CDA (pathologist, author’s view) Archival CDA XML Tumor Board, synopsis, meets CAP reporting guidelines

  31. Relationship to HL7 messages • CDA complements HL7 messaging specs • A CDA document is a defined and complete information object that can exist outside of a messaging context • A CDA document can be a MIME-encoded payload within an HL7 message

  32. Relationship to HL7 messages • CDA documents are encapsulated as MIME packages within HL7 messages HL7 V2.x MSH|... EVN|... PID|... PV1|... TXA|... OBX|1|ED|... |... HL7 V3 <service_cd> <service_txt T="ED"> </service_txt> </service_cd> CDA CDA

  33. HL7’s Development Framework Reference Information Model RMIM • subset of RIM • tighten constraints • linearization • additional constraints XML Schema • algorithm <xs:element name="ClinicalDocument" type="CDA_MT000017.ClinicalDocument" /> - <xs:group name="CDA_MT000017"> - <xs:sequence> <xs:element name="ClinicalDocument" type="CDA_MT000017.ClinicalDocument" /> Hierarchical Description

  34. Table 17. Vocabulary domain for <function_cd> (CWE)

  35. Low End Applications for CDA • Persistant, accessible, human-readable documents • Requirements: • CDA header • Release One or Two body • Narrative block • Non-semantic markup (HTML-like) • Options: • More complex markup can be inserted, to be used or ignored

  36. What you can do with simple CDA documents: the registry hub • Ubiquitous access to distributed information • By class of document, patient, provider, encounter (CDA header metadata) • Documents remain under local control • Document creation technology evolves under local control • Registry (hub) for access control, identifier xRef 4. Retrieve “what imaging reports are available from the last episode?” 1. Create documents 2. Register 3. Discover

  37. Investing in Information • CDA XML can be simple • CDA XML can be complex • Simple encoding relatively inexpensive • Complex encoding costs more • You get what you pay for: • like charging a battery, • the more detailed the encoding • the greater the potential for reuse

  38. CDA: Return on Investment • Low end: Access to documents • “please send referral letter to…” • “please get me the discharge summary…” • “what imaging reports are available from the last episode?” • High end: Reuse • Send synopsis to tumor board • Attach to claim for automated adjudication of payment • Extract data for clinical research

  39. Investing in Information cost x 80/20? √ benefit

  40. Why do we need a CDA? A document specification that hits the 80/20 sweet spot: Jim Klein, Gartner Group, on HL7’s CDA, April, 2001 RU: “HL7's Clinical Document Architecture (CDA) defines a new target for clinical information exchange that is substantiallyeasier to hit than one based on standards for discrete data while delivering 80 percent of the value of the latter approach.”

  41. So, how does this relate to the CCR? • History: • Meetings initiated one year ago • Massachusetts Medical Society taking lead in coordination effort • Series of joint meetings, teleconferences • Combined with international effort on referrals (show spreadsheet) • Proof of concept at HIMSS 2004

  42. ASTM/HL7 MOU • “ASTM has just adopted a standard set of core data elements for a Continuity of Care Record (CCR) and is in the process of developing an implementation guide for same, and HL7 has adopted a standard for Clinical Document Architecture (CDA) and a standard for the functionality of an Electronic Health Record (EHR) system. Since both SDOs want implementations based on these standards to be semantically interoperable, we agree to cooperate in the process of harmonizing the definitions of the data elements and the methods for representing instances of the data elements in XML….

  43. HL7/ASTM MOU • “…We agree that compatibility will be enhanced by using the HL7 Reference Information Model (RIM) as a common basis for such harmonization and that the CCR standard, the EHR standard(s), the CDA standard, and the RIM are all open to appropriate modifications (with appropriate ballot cycles for approve of same for each SDO) to enable such harmonization.”

  44. …but wait, there’s more • Mapping of data elements is good • We will establish a canonical method of implementing CCR as a template layered on top of CDA • Benefits: • Interoperability with HL7 Reference Information Model • Compatibility with HIPAA, NHII document standard • Compatible with international approach to interoperability • EHR compatibility • Drive decision support, advanced processing applications • Public health, clinic trials tie-ins • Automated validation of specific, local requirements

  45. HL7 Templates • Constraints on HL7 specifications • What is a “constraint”? • <section> called “ROS” must contain <section> on “vital signs” • <document> called “H&P” must contain <section> called “ROS” • CDA schema says “documents have sections” • CCR template says: “CDA CCR documents have ASTM-specified required sections”

  46. HL7 Templates • A template can constrain: • sections of a CDA document • set of laboratory observation result codes • coding scheme for a coded element • data type subcomponent

  47. HL7 Templates • Who creates HL7 Templates? • domain experts • standards groups (e.g., ASTM) • regulatory agencies • Where are templates used? • within CDA documents • within HL7 V3 messages

  48. CDA CCR compatibility • Questions that need resolution: • Levels of machine processibility, reuse, interoperability • Levels of generality, constraint, validation

  49. CDA::CCR processibility <Section> <code code="10123-x" codeSystem="LOINC">Allergies and Adverse Reactions</code> <text> <list> <item><content>Penicillin - Hives</content></item> </list> </text> <component> <Observation> <code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/> <value xsi:type="CD" code="DF-10074" codeSystem="SNOMED" displayName="Allergy to penicillin"/> <pertinentInformation typeCode="MFST"> <Observation> <code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/> <value xsi:type="CD" code="D0-00165" codeSystem="SNOMED" displayName="Hives"/> </Observation> CCR: clinical content all optional required: human readable optional: machine processible CDA Release 2.0: Draft

  50. CDA::CCR processibility • CDA: single-styesheet rendering favors simple exchange for point of care review • CDA CCR: will integrate required semantics for additional machine processing, reuse, RIM-based interoperability, retaining single-stylesheet rendering

More Related