HL7 Clinical Document Architecture: Overview and Applications

2,440 views

Published on

Theera-Ampornpunt N. HL7 Clinical Document Architecture: overview and applications. Presented at: HL7 CDA Workshop at the Faculty of Medicine Ramathibodi Hospital; 2013 Jun 20-21; Bangkok, Thailand. Invited speaker, in Thai.

Published in: Technology, Health & Medicine
2 Comments
8 Likes
Statistics
Notes
No Downloads
Views
Total views
2,440
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
213
Comments
2
Likes
8
Embeds 0
No embeds

No notes for slide

HL7 Clinical Document Architecture: Overview and Applications

  1. 1. 1HL7 Clinical DocumentArchitecture:Overview and ApplicationsNawanan Theera-Ampornpunt, M.D., Ph.D.Informatics Division, Faculty of Medicine Ramathibodi HospitalCertified HL7 CDA Specialist
  2. 2. 2A 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 SpecialistFormer Deputy Chief, Informatics DivisionDeputy Executive Director for Informatics,Chakri Naruebodindra Medical InstituteFaculty of Medicine Ramathibodi Hospitalnawanan.the@mahidol.ac.thhttp://groups.google.com/group/ThaiHealthITResearch interests:• EHRs & health IT applications in clinical settings• Health IT adoption• Health informatics education & workforce development
  3. 3. 3Standards Are Everywhere
  4. 4. 4Standards: Why?• The Large N ProblemN = 2, Interface = 1# Interfaces = N(N-1)/2N = 3, Interface = 3N = 5, Interface = 10N = 100, Interface = 4,950
  5. 5. 5Health Information Exchange (HIE)Hospital A Hospital BClinic CGovernmentLab Patient at Home
  6. 6. 6Objectives• Interoperability• Inter-operablesystemsUltimate Goals• Continuity of Care• Quality Safety Timeliness Effectiveness Equity Patient-Centeredness EfficiencyWhy Health Information Standards?
  7. 7. 7Levels of InteroperabilityFunctionalSemanticSyntactic
  8. 8. 8Various 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. 9FunctionalSemanticSyntacticHow Standards Support InteroperabilityTechnical 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 SetsFunctional Standards (HL7 EHRFunctional Specifications)Some may be hybrid: e.g. HL7 v.3, HL7 CCDUnique ID
  10. 10. 10Message Exchange• Goal: Specify formatfor exchange of data• Internal vs. externalmessages• Examples HL7 v.2 HL7 v.3 Messaging DICOM NCPDPDocument Exchange• Goal: Specify formatfor exchange of“documents”• Examples HL7 v.3 Clinical DocumentArchitecture (CDA) ASTM Continuity of CareRecord (CCR) HL7 Continuity of CareDocument (CCD)Exchange Standards
  11. 11. 11Messages• Human Unreadable• Machine ProcessableClinical Documents• Human Readable• (Ideally) MachineProcessableExchange Standards
  12. 12. 12Hospital A Hospital BClinic CGovernmentLab Patient at HomeMessage ExchangeMessageMessageMessageMessageMessage
  13. 13. 13Hospital A Hospital BClinic CGovernmentLab Patient at HomeClinical Document ExchangeMessage containingReferral LetterMessage containingClaims RequestMessage containingLab ReportMessage containingPatient Visit SummaryMessage containingCommunicableDisease Report
  14. 14. 14HL7 Standards• HL7 V2.x– Defines electronic messages supporting hospitaloperations• 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. 15HL7 V3 Standards• A family of standards based on V3information models and developmentmethodology• Components– HL7 V3 Reference Information Model (RIM)– HL7 V3 Messaging– HL7 Development Framework (HDF)
  16. 16. 16Sample 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. 17Sample 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. 18HL7 Reference Information Model (RIM)Source: HL7 CDA R2
  19. 19. 19Source: “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  20. 20. 20HL7 V3 Messaging• V3 provides messaging standards for– Patient administration– Medical records– Orders– Laboratory– Claims & Reimbursement– Care provision– Clinical genomics– Public Health– Etc.
  21. 21. 21How HL7 V3 Works• Message sent from sending application toreceiving application• Mostly triggered by an event• Typical scenario portrayed in a storyboard• Message in XML with machine-processableelements conforming to messagingstandard• Data elements in message conform to RIM• Not designed for human readability
  22. 22. 22What Is HL7 CDA?• “A document markup standard thatspecifies structure & semantics of “clinicaldocuments” for the purpose of exchange”[Source: HL7 CDA Release 2]• Focuses on document exchange, notmessage exchange• A document is packaged in a messageduring exchange• Note: CDA is not designed for documentstorage. Only for exchange!!
  23. 23. 23A Clinical Document (1)• A documentation of clinical observationsand services, with the followingcharacteristics: Persistence - continues to exist in anunaltered state, for a time period defined bylocal and regulatory requirements Stewardship - maintained by an organizationentrusted with its care Potential for authentication - an assemblageof information that is intended to be legallyauthenticated Source: HL7 CDA R2
  24. 24. 24A Clinical Document (2)• A documentation of clinical observationsand services, with the followingcharacteristics: Context - establishes the default context for itscontents; can exist in non-messaging contexts Wholeness - Authentication of a clinicaldocument applies to the whole and does notapply to portions of the document without fullcontext of the document Human readability - human readableSource: HL7 CDA R2
  25. 25. 25A Clinical Document (3)• A CDA document is a defined & completeinformation object that can include Text Images Sounds Other multimedia contentSource: HL7 CDA R2
  26. 26. 26Key Aspects of CDA• CDA documents are encoded in XML When alternative implementations are feasible,new conformance requirements will be issued• CDA documents derive their machineprocessable meaning from HL7 RIM anduse HL7 V3 Data Types• CDA specification is richly expressive &flexible Templates can be used to constrain genericCDA specificationsSource: HL7 CDA R2
  27. 27. 27Scope of CDA• Standardization of clinical documents forexchange• Data format of clinical documents outsideof exchange context (such as data formatused to store clinical documents) is out-of-scopeSource: HL7 CDA R2
  28. 28. 28Scope of CDA• CDA doesn’t specify creation ormanagement of documents and messagesrelated to document management• Instead, HL7 V3 Structured DocumentsWG provides specifications on standardsfor document exchange within HL7 V3messages (where CDA clinical documentscan become contents of the messages)Source: HL7 CDA R2
  29. 29. 29Scope of CDALab Technician PhysicianLab ReportCreatedocumentProcess &StoredocumentTransmitdocumentCDA
  30. 30. 30Goals of CDA (1)• Give priority to delivery of patient care• Allow cost effective implementation acrossas wide a spectrum of systems as possible• Support exchange of human-readabledocuments between users, including thosewith different levels of technicalsophistication• Promote longevity of all informationencoded according to this architectureSource: HL7 CDA R2
  31. 31. 31Goals of CDA (2)• Enable a wide range of post-exchangeprocessing applications• Be compatible with a wide range of documentcreation applications• Promote exchange that is independent of theunderlying transfer or storage mechanism• Prepare the design reasonably quickly• Enable policy-makers to control their owninformation requirements without extension to thisspecificationSource: HL7 CDA R2
  32. 32. 32Design Principles of CDA (1)• Must be compatible with XML & HL7 RIM• Must be compatible with representations ofclinical information arising from other HL7committees• Technical barriers to use of CDA should beminimized• Specifies representation of instancesrequired for exchangeSource: HL7 CDA R2
  33. 33. 33Design Principles of CDA (2)• Should impose minimal constraints orrequirements on document structure and contentrequired for exchange• Must be scalable to accommodate fine-grainedmarkup such as highly structured text & codeddata• Document specifications based on CDA(“Implementation Guides”) shouldaccommodate constraints & requirements assupplied by appropriate professional, commercial& regulatory agenciesSource: HL7 CDA R2
  34. 34. 34Design Principles of CDA (3)• Document specifications for document creation &processing, if intended for exchange, should mapto this exchange architecture• CDA documents must be human readable usingwidely-available & commonly-deployed XML-aware browsers & print drivers and a genericCDA style sheet written in a standard style sheetlanguage• Use open standardsSource: HL7 CDA R2
  35. 35. 35CDA & HL7 Messages• Documents complement HL7 messagingspecifications• Documents are defined and complete informationobjects that can exist outside of a messagingcontext• A document can be a MIME-encoded payloadwithin an HL7 messageSource: “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  36. 36. 36CDA & Message Exchange• CDA can be payload (or content) in any kind ofmessage– 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 toanotherSource: “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  37. 37. 37CDA & Message ExchangeClinical Document(Payload)HL7 V3 Message(Message)HL7 V2 Message(Message)Source: Adapted from “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  38. 38. 38CDA As PayloadSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  39. 39. 39MIME• 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 into64 ASCII charactersSource: http://en.wikipedia.org/wiki/MIME
  40. 40. 40Base64 Encoding• TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=• Man is distinguished, not only by his reason, but by this singularpassion from other animals, which is a lust of the mind, that by aperseverance of delight in the continued and indefatigable generationof knowledge, exceeds the short vehemence of any carnal pleasure.Source: http://en.wikipedia.org/wiki/Base64
  41. 41. 41Components of CDA Document• Header• Body– Section– Entry (machine processable)– Narrative Block (human readable)Source: HL7 CDA R2
  42. 42. 42CDA ModelSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  43. 43. 43A Closer Look at a CDA Document<ClinicalDocument> ... CDA Header ...<structuredBody> <section> <text>... SingleNarrative Block ...</text><observation>...</observation><substanceAdministration><supply>...</supply></substanceAdministration> <observation><externalObservation>...</externalObservation> </observation></section> <section> <section>...</section></section> </structuredBody></ClinicalDocument>Source: HL7 CDA R2Human Readable PartMachine Processable Parts
  44. 44. 44Rendering CDA Documents (1)Source: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  45. 45. 45Rendering CDA Documents (2)Source: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  46. 46. 46Rendering CDA Documents (3)• Different recipients may use different style sheetsto render the same CDA document, and thus maydisplay it differently (but the same content ispresented)• This can help facilitate display of CDA documentswith specific preferences or local requirements
  47. 47. 47Human Readability & RenderingCDA Documents (1)• Receiver of a CDA document can algorithmicallydisplay clinical content of the note on a standardWeb browser• Sender should not be required to transmit aspecial style sheet along with a CDA document• Must be possible to render all CDA documentswith a single style sheet and general-marketdisplay tools• Human readability applies to authenticatedcontent (but no need to render other machineprocessable parts)Source: HL7 CDA R2
  48. 48. 48Human Readability & RenderingCDA Documents (2)• When structured content is derived fromnarrative, there must be a mechanism to describethe process by which machine-processableportions were derived from a block of narrative(e.g. by author, by human coder, by naturallanguage processing algorithm, by specificsoftware)• When narrative is derived from structuredcontent, there must be a mechanism to identifythe process by which narrative was generatedfrom structured dataSource: HL7 CDA R2
  49. 49. 49Human Readability & RenderingCDA Documents (3)Source: HL7 CDA R2<ClinicalDocument> ... CDA Header ...<structuredBody> <section> <text>... SingleNarrative 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. 50XML Markup of CDA Documents• CDA instances are valid against CDA Schema• May be subject to additional validation• No prohibition against multiple schemalanguages (W3C, DTD, RELAXNG, etc.) as longas conforming instances are compatibleSource: HL7 CDA R2
  51. 51. 51Design Principles ofCDA Schema (1)• Design of CDA Schema follows more generalrequirements for CDA• Follow general V3 XML ITS• CDA Schema is syntactic and not an adequatemap between conforming instance and HL7 RIM(semantics)• Semantic interoperability of CDA instancesrequires CDA Schema, R-MIM & HD andcorresponding RIMSource: HL7 CDA R2
  52. 52. 52Design Principles ofCDA Schema (2)• Forward and backward compatibility• Tag names should be clear, human-understandable and map directly to RIM• Vocabulary can be enumerated within CDASchema or in an external, referenced source.– A vocabulary that is too large or is subject to changeshould be maintained externally and referenced inCDA Schema• CDA Schema should adhere to requirements ofdocument analysis in derivation of content modelSource: HL7 CDA R2
  53. 53. 53Security, Confidentiality & DataIntegrity• Application systems sending and receiving CDAdocuments are responsible for meeting all legalrequirements for– Document authentication– Document confidentiality– Document retention• Encryption & source/recipient authentication maybe necessary but is not part of CDA specs• Confidentiality status is available within CDASource: HL7 CDA R2
  54. 54. 54CDA Conformance (1)• CDA document originator application isresponsible for ensuring that generated CDAdocuments are fully conformant to thisspecification• Document recipient is responsible for ensuringthat received CDA documents are rendered inaccordance to this specification• No persistent storage requirements for CDAdocuments defined by CDA (out-of-scope)Source: HL7 CDA R2
  55. 55. 55CDA Conformance (2)Recipient Responsibilities• Assume default values where defined and the documentinstance doesn’t contain a value• Be able to parse & interpret complete CDA header (butmay or may not render header at its discretion)• Parse & interpret CDA body sufficiently to be able torender it (title & narrative block)• Not required to parse & interpret complete set of CDAentries in body• Not required to validate CDA document againstreferenced templatesSource: HL7 CDA R2
  56. 56. 56CDA Conformance (3)Originator Responsibilities• Properly construct CDA Narrative Blocks– Section label is conveyed in Section.title component (except whenunlabeled)– Narrative contents are placed in Section.text (even if alsoconveyed in machine-processable entries)– Contents of Section.text field must follow rules of SectionNarrative Block• Not required to fully encode all narrative into CDA entrieswithin CDA bodySource: HL7 CDA R2
  57. 57. 57CDA & Document Management• CDA focuses on document exchange, notstorage or processing• Clinical documents are used for various reasons– Clinical care– Medico-legal reasons (as evidence)– Auditing– Etc.• Clinical documents may contain errors or needdata updates (e.g. preliminary lab results vs. finalresults)
  58. 58. 58CDA & Document Management• CDA supports appending and replacement ofdocuments through use of Document ID, setID,versionNumber & parent document– Supports version control of documents– Both old (replaced) and new versions of documentscan be stored in and retrieved from documentmanagement systems depending on situation– Addendum is possible through append– Addendum itself can also be replaced with sameversion control mechanism– Document management system (not CDA) isresponsible for keeping track of most up-to-datedocuments
  59. 59. 59Document Management ExamplesSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  60. 60. 60CDA 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 cancontain entries– Derived from HL7 RIM Version 2.07Source: HL7 CDA R2
  61. 61. 61Changes Between CDA R1 & R2• In CDA R2, both header & body are fully RIM-derived• Much richer assortment of entries to use withinCDA sections• R2 enables clinical content to be formallyexpressed 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 vocabulariesSource: HL7 CDA R2
  62. 62. 62Some Possible Use Cases of CDA Intra-institutional Exchange of parts of medical records (scanned orstructured 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. 63Some 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. 64Achieving Interoperability CDA is a general-purpose, broad standard Use in each use case or context requiresimplementation 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. 65CDA Extensibility Locally-defined markup possible when localsemantics have no corresponding representationin CDA specification Additional XML elements & attributes that are notincluded in CDA Schema are permitted in localextensions
  66. 66. 66Summary CDA is a markup standard for documentexchange Not message exchange Not document storage or processing CDA is a general-purpose standard Use in specific context requiresImplementation Guides (and possiblyExtensions)
  67. 67. 67Summary CDA is XML-based and RIM-based CDA documents can be exchanged asencapsulated data (payload) in any message(HL7 V2, HL7 V3, etc.) CDA is not dependent on using HL7 V3messages Most likely early use cases for CDA Referrals Claims & Reimbursements Lab/imaging Reports Electronic Health Records Documents

×