HL7 Clinical Document Architecture: Overview and Applications
14 likes5,201 views
The document provides an overview of the HL7 Clinical Document Architecture (CDA), detailing its purpose, structure, and standards for exchanging clinical documents in healthcare. It emphasizes the importance of interoperability and outlines the various components and design principles of CDA, including its goals for enhancing patient care and ensuring document exchange across different systems. The CDA is presented as a markup standard for clinical documents, focusing on both human readability and machine-processable elements.
![22
What Is HL7 CDA?
• “A document markup standard that
specifies structure & semantics of “clinical
documents” for the purpose of exchange”
[Source: HL7 CDA Release 2]
• Focuses on document exchange, not
message exchange
• A document is packaged in a message
during exchange
• Note: CDA is not designed for document
storage. Only for exchange!!](https://image.slidesharecdn.com/hl7cda-overviewandapplications-130623111526-phpapp02/85/HL7-Clinical-Document-Architecture-Overview-and-Applications-22-320.jpg)
HL7 Clinical Document Architecture: Overview and Applications
- 1. 1 HL7 Clinical Document Architecture: Overview and Applications Nawanan Theera-Ampornpunt, M.D., Ph.D. Informatics Division, Faculty of Medicine Ramathibodi Hospital Certified HL7 CDA Specialist
- 2. 2 A Bit About Myself... 2003 M.D. (Ramathibodi) 2009 M.S. in Health Informatics (U of MN) 2011 Ph.D. in Health Informatics (U of MN) 2012 Certified HL7 CDA Specialist Former Deputy Chief, Informatics Division Deputy Executive Director for Informatics, Chakri Naruebodindra Medical Institute Faculty of Medicine Ramathibodi Hospital nawanan.the@mahidol.ac.th http://groups.google.com/group/ThaiHealthIT Research interests: • EHRs & health IT applications in clinical settings • Health IT adoption • Health informatics education & workforce development
- 4. 4 Standards: Why? • The Large N Problem N = 2, Interface = 1 # Interfaces = N(N-1)/2 N = 3, Interface = 3 N = 5, Interface = 10 N = 100, Interface = 4,950
- 5. 5 Health Information Exchange (HIE) Hospital A Hospital B Clinic C Government Lab Patient at Home
- 6. 6 Objectives • Interoperability • Inter-operable systems Ultimate Goals • Continuity of Care • Quality Safety Timeliness Effectiveness Equity Patient-Centeredness Efficiency Why Health Information Standards?
- 8. 8 Various Kinds of Standards • Unique Identifiers • Standard Data Sets • Vocabularies & Terminologies • Exchange Standards – Message Exchange – Document Exchange • Functional Standards • Technical Standards: Data Communications, Encryption, Security
- 9. 9 Functional Semantic Syntactic How Standards Support Interoperability Technical Standards (TCP/IP, encryption, security) Exchange Standards (HL7 v.2, HL7 v.3 Messaging, HL7 CDA, DICOM) Vocabularies, Terminologies, Coding Systems (ICD-10, ICD-9, CPT, SNOMED CT, LOINC) Information Models (HL7 v.3 RIM, ASTM CCR, HL7 CCD) Standard Data Sets Functional Standards (HL7 EHR Functional Specifications) Some may be hybrid: e.g. HL7 v.3, HL7 CCD Unique ID
- 10. 10 Message Exchange • Goal: Specify format for exchange of data • Internal vs. external messages • Examples HL7 v.2 HL7 v.3 Messaging DICOM NCPDP Document Exchange • Goal: Specify format for exchange of “documents” • Examples HL7 v.3 Clinical Document Architecture (CDA) ASTM Continuity of Care Record (CCR) HL7 Continuity of Care Document (CCD) Exchange Standards
- 11. 11 Messages • Human Unreadable • Machine Processable Clinical Documents • Human Readable • (Ideally) Machine Processable Exchange Standards
- 12. 12 Hospital A Hospital B Clinic C Government Lab Patient at Home Message Exchange Message Message Message Message Message
- 13. 13 Hospital A Hospital B Clinic C Government Lab Patient at Home Clinical Document Exchange Message containing Referral Letter Message containing Claims Request Message containing Lab Report Message containing Patient Visit Summary Message containing Communicable Disease Report
- 14. 14 HL7 Standards • HL7 V2.x – Defines electronic messages supporting hospital operations • HL7 V3 • HL7 Clinical Document Architecture (CDA) Releases 1 and 2 • HL7 Arden Syntax – Representation of medical knowledge • HL7 EHR & PHR Functional Specifications • Etc.
- 15. 15 HL7 V3 Standards • A family of standards based on V3 information models and development methodology • Components – HL7 V3 Reference Information Model (RIM) – HL7 V3 Messaging – HL7 Development Framework (HDF)
- 16. 16 Sample HL7 v.2 Message (Lab Result) OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml| 0-1.3|H||H|F|19980309…
- 17. 17 Sample HL7 v.3 Message (Patient Registration) <?xml version="1.0" encoding="UTF-8"?> <PRPA_IN101311UV02 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ITSVersion="XML_1.0" xsi:schemaLocation="urn:hl7-org:v3 ../schemas/PRPA_IN101311UV02.xsd"> ... <name use="SYL" > <given>นวนรรน</given> <family>ธีระอัมพรพันธุ</family> </name> <name use="ABC"> <given>Nawanan</given> <family>Theera-Ampornpunt</family> </name> <administrativeGenderCode code="M"/> ... </PRPA_IN101311UV02> Message source adapted from Ramathibodi HL7 Project by Supachai Parchariyanon, Kavin Asavanant, Sireerat Srisiriratanakul & Chaiwiwat Tongtaweechaikit
- 18. 18 HL7 Reference Information Model (RIM) Source: HL7 CDA R2
- 19. 19 Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 20. 20 HL7 V3 Messaging • V3 provides messaging standards for – Patient administration – Medical records – Orders – Laboratory – Claims & Reimbursement – Care provision – Clinical genomics – Public Health – Etc.
- 21. 21 How HL7 V3 Works • Message sent from sending application to receiving application • Mostly triggered by an event • Typical scenario portrayed in a storyboard • Message in XML with machine-processable elements conforming to messaging standard • Data elements in message conform to RIM • Not designed for human readability
- 22. 22 What Is HL7 CDA? • “A document markup standard that specifies structure & semantics of “clinical documents” for the purpose of exchange” [Source: HL7 CDA Release 2] • Focuses on document exchange, not message exchange • A document is packaged in a message during exchange • Note: CDA is not designed for document storage. Only for exchange!!
- 23. 23 A Clinical Document (1) • A documentation of clinical observations and services, with the following characteristics: Persistence - continues to exist in an unaltered state, for a time period defined by local and regulatory requirements Stewardship - maintained by an organization entrusted with its care Potential for authentication - an assemblage of information that is intended to be legally authenticated Source: HL7 CDA R2
- 24. 24 A Clinical Document (2) • A documentation of clinical observations and services, with the following characteristics: Context - establishes the default context for its contents; can exist in non-messaging contexts Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without full context of the document Human readability - human readable Source: HL7 CDA R2
- 25. 25 A Clinical Document (3) • A CDA document is a defined & complete information object that can include Text Images Sounds Other multimedia content Source: HL7 CDA R2
- 26. 26 Key Aspects of CDA • CDA documents are encoded in XML When alternative implementations are feasible, new conformance requirements will be issued • CDA documents derive their machine processable meaning from HL7 RIM and use HL7 V3 Data Types • CDA specification is richly expressive & flexible Templates can be used to constrain generic CDA specifications Source: HL7 CDA R2
- 27. 27 Scope of CDA • Standardization of clinical documents for exchange • Data format of clinical documents outside of exchange context (such as data format used to store clinical documents) is out-of- scope Source: HL7 CDA R2
- 28. 28 Scope of CDA • CDA doesn’t specify creation or management of documents and messages related to document management • Instead, HL7 V3 Structured Documents WG provides specifications on standards for document exchange within HL7 V3 messages (where CDA clinical documents can become contents of the messages) Source: HL7 CDA R2
- 29. 29 Scope of CDA Lab Technician Physician Lab Report Create document Process & Store document Transmit document CDA
- 30. 30 Goals of CDA (1) • Give priority to delivery of patient care • Allow cost effective implementation across as wide a spectrum of systems as possible • Support exchange of human-readable documents between users, including those with different levels of technical sophistication • Promote longevity of all information encoded according to this architecture Source: HL7 CDA R2
- 31. 31 Goals of CDA (2) • Enable a wide range of post-exchange processing applications • Be compatible with a wide range of document creation applications • Promote exchange that is independent of the underlying transfer or storage mechanism • Prepare the design reasonably quickly • Enable policy-makers to control their own information requirements without extension to this specification Source: HL7 CDA R2
- 32. 32 Design Principles of CDA (1) • Must be compatible with XML & HL7 RIM • Must be compatible with representations of clinical information arising from other HL7 committees • Technical barriers to use of CDA should be minimized • Specifies representation of instances required for exchange Source: HL7 CDA R2
- 33. 33 Design Principles of CDA (2) • Should impose minimal constraints or requirements on document structure and content required for exchange • Must be scalable to accommodate fine-grained markup such as highly structured text & coded data • Document specifications based on CDA (“Implementation Guides”) should accommodate constraints & requirements as supplied by appropriate professional, commercial & regulatory agencies Source: HL7 CDA R2
- 34. 34 Design Principles of CDA (3) • Document specifications for document creation & processing, if intended for exchange, should map to this exchange architecture • CDA documents must be human readable using widely-available & commonly-deployed XML- aware browsers & print drivers and a generic CDA style sheet written in a standard style sheet language • Use open standards Source: HL7 CDA R2
- 35. 35 CDA & HL7 Messages • Documents complement HL7 messaging specifications • Documents are defined and complete information objects that can exist outside of a messaging context • A document can be a MIME-encoded payload within an HL7 message Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 36. 36 CDA & Message Exchange • CDA can be payload (or content) in any kind of message – HL7 V2.x message – HL7 V3 message – EDI ANSI X12 message – IHE Cross-Enterprise Document Sharing (XDS) message • And it can be passed from one kind to another Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 37. 37 CDA & Message Exchange Clinical Document (Payload) HL7 V3 Message (Message) HL7 V2 Message (Message) Source: Adapted from “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 38. 38 CDA As Payload Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 39. 39 MIME • Multipurpose Internet Mail Extensions • An Internet standard that extends the format of e- mail to support – Text in non-ASCII character sets – Non-text attachments – Message bodies with multiple parts – Etc. • Often used in e-mails & some HTTP data • Encoding: e.g. base64 (converting bits into 64 ASCII characters Source: http://en.wikipedia.org/wiki/MIME
- 40. 40 Base64 Encoding • TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ 5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bG FyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3a GljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQg YnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB 0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIG dlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzI HRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5h bCBwbGVhc3VyZS4= • Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure. Source: http://en.wikipedia.org/wiki/Base64
- 41. 41 Components of CDA Document • Header • Body – Section – Entry (machine processable) – Narrative Block (human readable) Source: HL7 CDA R2
- 42. 42 CDA Model Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 43. 43 A Closer Look at a CDA Document <ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>... Single Narrative Block ...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument> Source: HL7 CDA R2 Human Readable Part Machine Processable Parts
- 44. 44 Rendering CDA Documents (1) Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 45. 45 Rendering CDA Documents (2) Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 46. 46 Rendering CDA Documents (3) • Different recipients may use different style sheets to render the same CDA document, and thus may display it differently (but the same content is presented) • This can help facilitate display of CDA documents with specific preferences or local requirements
- 47. 47 Human Readability & Rendering CDA Documents (1) • Receiver of a CDA document can algorithmically display clinical content of the note on a standard Web browser • Sender should not be required to transmit a special style sheet along with a CDA document • Must be possible to render all CDA documents with a single style sheet and general-market display tools • Human readability applies to authenticated content (but no need to render other machine processable parts) Source: HL7 CDA R2
- 48. 48 Human Readability & Rendering CDA Documents (2) • When structured content is derived from narrative, there must be a mechanism to describe the process by which machine-processable portions were derived from a block of narrative (e.g. by author, by human coder, by natural language processing algorithm, by specific software) • When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data Source: HL7 CDA R2
- 49. 49 Human Readability & Rendering CDA Documents (3) Source: HL7 CDA R2 <ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>... Single Narrative Block ...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument> Text to be rendered
- 50. 50 XML Markup of CDA Documents • CDA instances are valid against CDA Schema • May be subject to additional validation • No prohibition against multiple schema languages (W3C, DTD, RELAXNG, etc.) as long as conforming instances are compatible Source: HL7 CDA R2
- 51. 51 Design Principles of CDA Schema (1) • Design of CDA Schema follows more general requirements for CDA • Follow general V3 XML ITS • CDA Schema is syntactic and not an adequate map between conforming instance and HL7 RIM (semantics) • Semantic interoperability of CDA instances requires CDA Schema, R-MIM & HD and corresponding RIM Source: HL7 CDA R2
- 52. 52 Design Principles of CDA Schema (2) • Forward and backward compatibility • Tag names should be clear, human- understandable and map directly to RIM • Vocabulary can be enumerated within CDA Schema or in an external, referenced source. – A vocabulary that is too large or is subject to change should be maintained externally and referenced in CDA Schema • CDA Schema should adhere to requirements of document analysis in derivation of content model Source: HL7 CDA R2
- 53. 53 Security, Confidentiality & Data Integrity • Application systems sending and receiving CDA documents are responsible for meeting all legal requirements for – Document authentication – Document confidentiality – Document retention • Encryption & source/recipient authentication may be necessary but is not part of CDA specs • Confidentiality status is available within CDA Source: HL7 CDA R2
- 54. 54 CDA Conformance (1) • CDA document originator application is responsible for ensuring that generated CDA documents are fully conformant to this specification • Document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification • No persistent storage requirements for CDA documents defined by CDA (out-of-scope) Source: HL7 CDA R2
- 55. 55 CDA Conformance (2) Recipient Responsibilities • Assume default values where defined and the document instance doesn’t contain a value • Be able to parse & interpret complete CDA header (but may or may not render header at its discretion) • Parse & interpret CDA body sufficiently to be able to render it (title & narrative block) • Not required to parse & interpret complete set of CDA entries in body • Not required to validate CDA document against referenced templates Source: HL7 CDA R2
- 56. 56 CDA Conformance (3) Originator Responsibilities • Properly construct CDA Narrative Blocks – Section label is conveyed in Section.title component (except when unlabeled) – Narrative contents are placed in Section.text (even if also conveyed in machine-processable entries) – Contents of Section.text field must follow rules of Section Narrative Block • Not required to fully encode all narrative into CDA entries within CDA body Source: HL7 CDA R2
- 57. 57 CDA & Document Management • CDA focuses on document exchange, not storage or processing • Clinical documents are used for various reasons – Clinical care – Medico-legal reasons (as evidence) – Auditing – Etc. • Clinical documents may contain errors or need data updates (e.g. preliminary lab results vs. final results)
- 58. 58 CDA & Document Management • CDA supports appending and replacement of documents through use of Document ID, setID, versionNumber & parent document – Supports version control of documents – Both old (replaced) and new versions of documents can be stored in and retrieved from document management systems depending on situation – Addendum is possible through append – Addendum itself can also be replaced with same version control mechanism – Document management system (not CDA) is responsible for keeping track of most up-to-date documents
- 59. 59 Document Management Examples Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
- 60. 60 CDA Releases • CDA Release 1 (ANSI-approved in 2000) – First specification derived from HL7 RIM • CDA Release 2 (2005) - Current Release – Basic model essentially unchanged from R1 • Document has a header & a body • Body contains nested sections • Sections can be coded using standard vocabularies and can contain entries – Derived from HL7 RIM Version 2.07 Source: HL7 CDA R2
- 61. 61 Changes Between CDA R1 & R2 • In CDA R2, both header & body are fully RIM- derived • Much richer assortment of entries to use within CDA sections • R2 enables clinical content to be formally expressed to the extent that it is modeled in RIM • A number of other changes – Deprecated components (retained for backward compatibility) – Changes in some component structure or vocabularies Source: HL7 CDA R2
- 62. 62 Some Possible Use Cases of CDA Intra-institutional Exchange of parts of medical records (scanned or structured electronic health records) Lab/Imaging requests & reports Prescriptions/order forms Admission notes Progress notes Operative notes Discharge summaries Payment receipts Other forms/documents (clinical or administrative)
- 63. 63 Some Possible Use Cases of CDA Inter-institutional Referral letters Claims requests or reimbursement documents External lab/imaging reports Visit summary documents Insurance eligibility & coverage documents Identification documents Disease reporting Other administrative reports
- 64. 64 Achieving Interoperability CDA is a general-purpose, broad standard Use in each use case or context requires implementation guides to constrain CDA Examples Operative Note (OP) Consultation Notes (CON) Care Record Summary (CRS) Continuity of Care Document (CCD) CDA for Public Health Case Reports (PHCRPT) Quality Reporting Document Architecture (QRDA)
- 65. 65 CDA Extensibility Locally-defined markup possible when local semantics have no corresponding representation in CDA specification Additional XML elements & attributes that are not included in CDA Schema are permitted in local extensions
- 66. 66 Summary CDA is a markup standard for document exchange Not message exchange Not document storage or processing CDA is a general-purpose standard Use in specific context requires Implementation Guides (and possibly Extensions)
- 67. 67 Summary CDA is XML-based and RIM-based CDA documents can be exchanged as encapsulated data (payload) in any message (HL7 V2, HL7 V3, etc.) CDA is not dependent on using HL7 V3 messages Most likely early use cases for CDA Referrals Claims & Reimbursements Lab/imaging Reports Electronic Health Records Documents