hl7-canada 20051112 cda

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.


Part 1 – CDA Introduction


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.


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?


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


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


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


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


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


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


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


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


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


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


CDA Release 2.0 RMIMHeader Extl.

Ref.CDA EntriesBody


Header Sections

� Consistent across all CDA documents

� Identifies the document, encounter, patient and provider etc.


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


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


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


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


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


Body Reference Example

<entryRelationship typeCode="COMP"><ObservationMedia>

<value mediaType="image/jpeg"><reference value="test.jpg"/></value>

</ObservationMedia></entryRelationship>

XML Instance

N/A

Human Readable


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


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


Part 2 – The e-MS Project


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


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


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.


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.


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?


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.


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


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


Document Walkthrough


Questions?

� Presenter:� [email protected]

� e-MS Project: � Karen Kuhn [email protected]� www.e-ms-ca

� HL7 Structured Documents: � [email protected]