gpi gordon point informatics www.gpinformatics.com Clinical Document Architecture Helen Stevens Gordon Point Informatics Ltd.
gpi gordon point informaticswww.gpinformatics.com
Clinical Document Architecture
Helen StevensGordon Point Informatics Ltd.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 2 gpi
Overview
� Tutorial Objectives:� introduce the CDA (Clinical Document
Architecture) principles and methodology;� demonstrate an implementation of CDA in the
VIHA e-MS project and � Discuss lessons learnt from the e-MS project
� The focus of the tutorial will be on understanding the role of CDA and how it can be successfully implemented.
gpi gordon point informaticswww.gpinformatics.com
Part 1 – CDA Introduction
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 4 gpi
What is CDA?
� Document markup standard that specifies the structure and semantics of "clinical documents“ for the purpose of exchange.
� A clinical document contains observations and services and has the following characteristics:� Persistence: continues to exist in an unaltered state, for a time period
defined by local and regulatory requirements.� Stewardship: maintained by a person or organization entrusted with
its care. � Potential for authentication: Assemblage of information that is
intended to be legally authenticated.� Wholeness: Authentication applies to the whole and does not portions
of the document without the full context of the document.� Human readability
� Document: a clinician will affix a signature� Defined and complete information object that can include text,
images, sounds, and other multimedia content.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 5 gpi
CDA Key Aspects
� Encoded in Extensible Markup Language (XML).� Derive meaning from the HL7 Reference
Information Model (RIM) and use the HL7 Version 3 Data Types.
� Complete CDA includes hierarchical set of document specifications: “architecture”. � How can we:
� Impose minimal constrains on local practice
� yet…� Ensure that senders and receivers can share meaning and
apply common processing applications?
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 6 gpi
CDA Scope� “The standardization of clinical documents for exchange.”� Enables, but does not constrain: authoring, document
management, storage, distribution and display� In Scope:
� Specifying how to package CDA documents within HL7 messages (2.x and 3.x)
� Not in Scope:� Specifying the messages designed to transfer clinical documents� The data format of clinical documents outside of the exchange
context.� Modeling clinical content (uses HL7 RIM)� Specifying the creation or management of documents� Cryptographic techniques for source/recipient authentication and
secure transport of encapsulated documents communicated over public media
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 7 gpi
CDA Concepts
� CDA Document� Includes “CDA Header” to identify and classify the
document and provides information on authentication, the encounter, the patient, and the provider.
� Includes “CDA Body” containing the clinical report
Header
Body
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 8 gpi
CDA Investing in Information
� CDA encoding can be simple or complex� Simple encoding is relatively inexpensive (out of the
box standards)� Complex encoding is more effort� The more detailed the encoding the greater the
potential for reuse.� Return on Investment:
� Low end: Access to documents� A referral letter that is human readable
� High end: Reuse of document information� Automatically registering patient from referral letter � Using referral letter information to create/update EMR
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 9 gpi
Level One� Root of the hierarchy and most
general document specification� Single DTD for all types of
clinical documents regardless of content. Uses Document Type Code attribute in header to differentiate document types.
� RIM classes are used in the specification of the document header
� Body is comprised of nested containers (sections, paragraphs, lists & tables); Containers have contents and optional captions; Contents include plain text, links & multimedia
Clinical DocumentClinical Document
SectionSection
ParagraphParagraph
ParagraphParagraph
ListList
TableTable
• A• B• C
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 10 gpi
Referral Letter
Discharge NoteTransfer Summary
Referral Letter
Discharge NoteTransfer Summary
Referral ReasonActive Problems
Medication
…
Referral ReasonActive Problems
Medication
…
ParagraphParagraph
Level Two
� Specialization of Level One
� Distinct XML DTDs for different types of clinical documents
� Constrains the set of allowable structures and semantics based on document type code, and may add additional markup
TableTable
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 11 gpi
Level Three
� Specialization of Level Two
� Additional markup enabling clinical content to be formally expressed to the extent that is it modeled in the RIM
Referral LetterReferral Letter
Referral ReasonActive ProblemsReferral ReasonActive Problems
HypertensionHypertension
SeveritySeverity
Onset DateOnset Date
NotesNotes
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 12 gpi
Multi-Level
� CDA Document may combine different levels
� Referral Reason as unformatted paragraph (L-2)
� Active Problems as encoded data (L-3)
Referral LetterReferral Letter
Referral Reason
Active Problems
Referral Reason
Active ProblemsHypertensionHypertension
SeveritySeverity
Onset DateOnset Date
ParagraphParagraph
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 13 gpi
CDA Schemas
� CDA Level One defined by three Schemas:� CDA Header Schema
� Derived using the V3 Message Development Process
� CDA Level One Body Schema� Derived from document analysis, building on the
modeling employed by document markup standards� HL7 Version 3 Data Type Schema
� An XML implementation of the abstract data type specifications used by both the CDA and the HL7 V3 Messaging Specifications
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 14 gpi
Sending CDA in HL7 messages� CDA document is a multimedia object, to be exchanged as a
Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED)
� Version 2.x� Use OBX segment in any message that can exchange documents (such
as MDM and ORU)� Example:
� OBX|1|ED| |...� Version 3.x
� Use any message that can exchange documents. � The Service.txt RIM attribute contains the MIME package, encoded as an
encoded data type.� <service_cd>
� <service_text T=“ED”>
� <service_text T=“ED”>� <service_cd>
CDA
CDA
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 15 gpi
CDA Release 2.0
� CDA Basic Model is essentially unchanged� Both header and body are fully RIM-derived� Richer assortment of entries to use within
CDA structures� Enables clinical content to be formally
expressed to the extent that is it modeled in the RIM
� Model-based XML standards� Compatibility issues between the 2.0 and
1.0 due to changes in RIM
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 16 gpi
CDA Release 2.0 RMIMHeader Extl.
Ref.CDA EntriesBody
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 17 gpi
Header Sections
� Consistent across all CDA documents
� Identifies the document, encounter, patient and provider etc.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 18 gpi
Header Section Examples
ORelates this document to one or more other documents. E.g. a Consult report could be related to a Referral.
Related Document
OMay include patient emergency and non-emergency contact information.
Participant
MPatient information (patient identification mechanisms, patient characteristics, the patient’s name, address and phone number etc.
Record Target
MOrganization from which the document originates and that is in charge of maintaining the document.
Custodian
MDemographic information on the creator (and sender) of the document. A document may not be edited and forwarded under the previous author’s name. The author will always be the person who last sent the document.
Author
MDemographic information on the receiver of the document (not a delegate)
Information Recipient
MAudit data that provides detailed information on document creation. Clinical Document
DescriptionSection Name
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 19 gpi
Body Section(s)
� Different for each CDA Document
� Section class defines the type of section� Code: coded section
identifier � (e.g. LOINC 11450-4 =
Active Problem List)
� Text: human readable rendition
� entry: link to Level 3
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 20 gpi
Body L-2 Example
<component><section>
<code code="10157-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"displayName="Family History"/>
<title>Family History</title><text>The patient’s father died of a myocardial infarction at the age of 65.</text>
</section></component>
XML Instance
Family HistoryThe patient’s father died of a myocardial infarction at the age of 65.
Human Readable
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 21 gpi
Body L-3 Example
<component><section>
<code code="007" codeSystem="7BA9BFFD-D25F-44e8-A7B0-0DF214D6845B" codeSystemName="e-MS Document Section Codes" displayName="Other Treatments"/>
<title>Other Treatments</title><text>
<table border="1"><tbody> (text removed from example)
<tr><td>
<content emphasis="bold">January 13, 2000</content></td><td>172 cm</td><td>65 Kg</td><td>130/80</td><td>80 BPM</td>
</tr></table>
</text>Continued…
XML Instance
Other Treatments
Human Readable
80 BPM130/8065 kg172 cmJanuary 13, 2000PulseBlood PressureWeightHeight
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 22 gpi
Body L-3 Example continued
<entry typeCode="COMP"><Observation moodCode="EVN">
<code code="8302-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"displayName="Height"/>
<effectiveTime value="20000113"/><value xsi:type="PQ" value="172" unit="cm"/>
</Observation></entry><entry typeCode="COMP">
<Observation moodCode="EVN"><code code="3141-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Weight"/><effectiveTime value="20000113"/><value xsi:type="PQ" value="65" unit="kg"/>
</Observation></entry><entry typeCode="COMP">
<Observation moodCode="EVN"><code code="11328-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Pulse"/><effectiveTime value="20000113"/><value xsi:type="PQ" value="80" unit="bpm"/>
</Observation></entry>
… continued …
XML Instance
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 23 gpi
Body Reference Example
<entryRelationship typeCode="COMP"><ObservationMedia>
<value mediaType="image/jpeg"><reference value="test.jpg"/></value>
</ObservationMedia></entryRelationship>
XML Instance
N/A
Human Readable
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 24 gpi
Cardinality
� Cardinality rules defined for each section � If section is encoded to level 3 cardinality rules
exist for each defined data element
The section or data element must have two instances.2..2The section or data element may have one or more instances.1..*The section or data element may have zero or more instances.0..*
The section or data element may have one and only one instance.
1..1The section or data element may have zero or one instance.0..1DescriptionCardinality
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 25 gpi
Mandatory / Optional / Required
� M/O/R rules defined for each section � If section is encoded to level 3 M/O/R rules exist
for each defined data element
section / data element may or may not be sent. Receiving system cannot assume that data will be present
Optional
DescriptionLevel
section / data element must be supported. If the data isn’t available and cardinality is 1 then a NullFlavor(e.g. Unknown) must be used
Required
section / data element may not be included in the document)Not supported
section / data element must be present for document to be valid
Mandatory
gpi gordon point informaticswww.gpinformatics.com
Part 2 – The e-MS Project
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 27 gpi
e-MS Overview
� Electronic Medical Summary � An e-MS is a subset of patient data suitable for
communication among primary health care practitioners and other health care providers for the purpose of sharing the care of a patient.
� Transferring clinical data to streamline the referral process / enable information sharing� EMR�EMR� EMR� e-MS Web Application� e-MS Web Application � EMR
� Initial Scope: Referral Requests and Consultation Reports
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 28 gpi
e-MS Data Scope� Information Recipient� Author� Record Target / Patient� Emergency Contact(s)� Related Document� Purpose� Alerts� Social History/Risks� Examination
Measurements� Active Problem List� Current Medications� Medical History
� Surgical History� Medical Imaging
History� Other Treatments� Allergies� Immunization� Labs� Past Referrals and/or
Hospitalizations� Family History� Observation Media
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 29 gpi
Why did e-MS use CDA?� It’s an approved and ANSI accredited standard for clinical
data interchange.� Rich document structure� Not dependent upon the transport� Closely resembles the purpose of the e-MS document� Supports any coding system vocabulary� Mandatory fields are minimal� Supports much richer data set than required – allowed
evolution of the e-MS dataset without introducing a new schema definition
� Is intended to become the de facto standard for clinical document interchange
� “attachment” support is included in the specification.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 30 gpi
Project Approach� Start with the HL7 CDA Domain Refined Message
Information Model (CDA:RMIM). � Using the HL7 RMIM-Designer tool, constrain the
CDA:RMIM to remove functionality not required by e-MS� Use the HL7 Schema-Generator to generate the e-
MS:RMIM schema� Manually modify the e-MS:RMIM schema as required to
complete constraints required to validate e-MS business rules.� Note manual modifications and contribute to HL7 towards
improving the RMIM-Designer tool’s capabilities.� Build an example instance that is compliant to the e-
MS:RMIM� Build a Schematron schema to validate the e-MS business
rules not contained within the e-MS:RMIM schema.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 31 gpi
Challenges
� e-MS CDA Schema does not validate all of the rules required by the project.
� Visio modeling tool was ‘buggy’� Schema Generator does not produce the
same schema structure that is in the HL7 Ballot.
� Cardinality of elements not retained.� How do you know what the normative
schema is?
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 32 gpi
Schematron� business rules that aren’t automatically enforced
by the e-MS CDA Schema are enforced through Schematron schema � Schematron is an XML structure validation language
using patterns in trees (XPath)� A CDA document is validated against both the W3C
schema and a Schematron schema� Schematron is needed because W3C schemas are very
limited in their ability to describe constraints on the structure of an XML document (i.e. the business rules).
� Schematron can specify a choice of attributes or vary the content based on the value of an element or attribute. These are examples of co-occurrence constraints.
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 33 gpi
Sending Application Process� A document instance is generated
based on the e-MS implementation guide
� If no validation is required this document may be immediately packaged and transmitted to the e-MS broker.
� If validation is required (for example during testing of new document generation software) then the instance is validated against the e-MS CDA compliant schema (as documented in this Implementation Guide) and the Schematron schema (also documented in this guide).
� The web service will accept a document instance and return a pass/fail and if appropriate an error log.
� Once the validation is confirmed the sending application may package and transmit the document to the e-MS broker confident that it will pass the e-MS broker validation.
e-MSImplementation
Guide
IsValidationrequired?
SchemaValidation
DocumentInstance.xml
SchematronValidation
Sending Application
No
Yes
DocumentPackaging
YesNo
ValidationConfirmed
Sendingsystem
receives “ok”response
Validation Web Service
Sending systemreceives “error”
response
Resolve IssueReturn to Start
Send sendingsystem “ok”response
Send sendingsystem “error”
response
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 34 gpi
E-MS Broker Process� Broker responsible for validating
that instance is complaint with e-MS CDA compliant schema.� The document is unpackaged
from the transportation wrapper. Part of this step is the confirmation that the document is a CDA document and the document type is confirmed.
� To validate, the instance is validated against the e-MS CDA compliant schema and the Schematron schema.
� If the document passes the validation it is then repackaged and transmitted on to the recipient application. If the document does not validate correctly an appropriate rejection message is returned to the originating application.
Document Instance.xml
e-MS Broker
Document Un-packaging
DocumentPackaging
SchemaValidation
SchematronValidation
YesNo
ValidationConfirmed
Validation Web Service
Send broker“ok” response
Send broker“error”
response
Brokerreceives “ok”
response
Broker receives“error” response
DocumentRejection
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 35 gpi
Document Walkthrough
November 12, 2005 © 2005 HL7, Gordon Point Informatics Ltd. 36 gpi
Questions?
� Presenter:� [email protected]
� e-MS Project: � Karen Kuhn [email protected]� www.e-ms-ca
� HL7 Structured Documents: � [email protected]