• Like
HL7 Clinical Document Architecture: Overview and Applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

HL7 Clinical Document Architecture: Overview and Applications

  • 960 views
Published

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. …

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
960
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
96
Comments
2
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1HL7 Clinical DocumentArchitecture:Overview and ApplicationsNawanan Theera-Ampornpunt, M.D., Ph.D.Informatics Division, Faculty of Medicine Ramathibodi HospitalCertified HL7 CDA Specialist
  • 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. 3Standards Are Everywhere
  • 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. 5Health Information Exchange (HIE)Hospital A Hospital BClinic CGovernmentLab Patient at Home
  • 6. 6Objectives• Interoperability• Inter-operablesystemsUltimate Goals• Continuity of Care• Quality Safety Timeliness Effectiveness Equity Patient-Centeredness EfficiencyWhy Health Information Standards?
  • 7. 7Levels of InteroperabilityFunctionalSemanticSyntactic
  • 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. 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. 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. 11Messages• Human Unreadable• Machine ProcessableClinical Documents• Human Readable• (Ideally) MachineProcessableExchange Standards
  • 12. 12Hospital A Hospital BClinic CGovernmentLab Patient at HomeMessage ExchangeMessageMessageMessageMessageMessage
  • 13. 13Hospital A Hospital BClinic CGovernmentLab Patient at HomeClinical Document ExchangeMessage containingReferral LetterMessage containingClaims RequestMessage containingLab ReportMessage containingPatient Visit SummaryMessage containingCommunicableDisease Report
  • 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. 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. 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. 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. 18HL7 Reference Information Model (RIM)Source: HL7 CDA R2
  • 19. 19Source: “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 29Scope of CDALab Technician PhysicianLab ReportCreatedocumentProcess &StoredocumentTransmitdocumentCDA
  • 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. 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. 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. 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. 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. 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. 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. 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. 38CDA As PayloadSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 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. 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. 41Components of CDA Document• Header• Body– Section– Entry (machine processable)– Narrative Block (human readable)Source: HL7 CDA R2
  • 42. 42CDA ModelSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 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. 44Rendering CDA Documents (1)Source: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 45. 45Rendering CDA Documents (2)Source: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 59Document Management ExamplesSource: From “What is CDA R2? by Calvin E. Beebeat HL7 Educational Summit in July 2012
  • 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. 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. 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. 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. 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. 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. 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. 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