Clinical Document

Architecture
Update & Preview
 Overview
n CDA Release 1.0
n An basic review…
n Update CDA at Mayo…

n CDA Release 2.0

n New Features in the ballot
n Challenges & Opportunities
 HL7 Messaging and more …

n HL7 Messaging Standards and …

n Clinical Context Management (CCOW)
n Arden Syntax for Medical Logic Systems
n Reference Information Model (RIM)
n Clinical Document Architecture (CDA)
n Electronic Healthcare Records (EHR)
 Messaging and more …

n HL7 Messaging Standards

n Clinical Context Management (CCOW)
n Arden Syntax for Medical Logic Systems

n Reference Information Model (RIM)

Ø Clinical Document Architecture (CDA)

n Electronic Healthcare Records (EHR)

 Document Exchange Standard

Local Document Management System

Document Repository
 Document vs. Message
n Persistence
n A clinical document continues to exist in an unaltered
state, for a time period defined by local and regulatory
requirements.
n Stewardship
n A clinical document is maintained by a person or
organization entrusted with its care.
n Potential for authentication
n A clinical document is an assemblage of information that
is intended to be legally authenticated.
 Document vs. Message
n Wholeness
n Authentication of a clinical document applies to the
whole and does not apply to portions of the document
without the full context of the document.
n Human readability
n A clinical document is human readable, guarantees that a
receiver of a CDA document can readily display the
clinical content of the note on a standard Web browser.

A standard XML syntax by which

Clinical Documents can be conveyed as a … Documents.
 CDA documents are encoded in
XML.
n XML provides extreme flexibility.
n Anyone can define a set of tags for a their documents or
document types.
n A document type definition or schema defines the
expected tags or elements in a document.
n It also defines the attributes and containment models
for the various elements defined in a given document
type.
An XML Standard for Healthcare

n Given this extensibility, how do we define a common

set of <tags> for healthcare?
n HL7 has an initiative to define a common set of <tags>
for clinical document exchange.

n Thisinitiative is referred to as the Clinical

Document Architecture.
Clinical Document Architecture
An XML markup standard that specifies the
structure and semantics of "clinical documents" for
the purpose of exchange.

n Originally presented at the HL7 Plenary meeting in

September of 1998.
n CDA Release 1.0 was approved as an ANSI standard on
November of 2000.
n CDA Release 2.0 is currently in ballot at HL7.
 CDA Structure
n A CDA document is defined in two parts.:

n Header - highly structured, used to specify information

useful in the indexing and retrieval of clinical documents.

n Body - very generic, supporting multiple sections,

containing the authenticated hyper-text content presented
in paragraphs, lists and tables.
 CDA - Header
n The CDA Header is derived from the HL7
Reference Information Model (RIM) and contains:

n Document information
n Encounter data
n Service actors (such as providers)
n Service targets (such as patients)
n Local markup
 CDA R1 Header
document information

encounter data

service actors

service targets
 CDA Body

n CDA Release 1.0 document body is very generic:

n Supporting
n Multiple sections containing:

n Tables

n List Which can contain text, coded entries,

n Paragraphs local markup and links to d ocuments,
images and other multimedia.
n Sections
 CDA R1 Body

CDA "structures"

CDA "entries"
 Mayo’s use of CDA
n Regional In-bound Interfaces to Mayo
n Replication to documents to:
n MICS System
n Genomics project

n Notes II project
n MICS Clinical Notes II editor
n XML Repository
 Mayo’s use of CDA
Clinical Notes
CDA
Documents
Mayo is currently operating
an outbound interface which
generates CDA documents.

Interface engine
converts XML to RTF

Loads RTF
Documents
MICS
 Mayo’s use of CDA
Clinical Notes
CDA
Documents
We are loading CDA
documents into the
Genomics Repository.

Loads CDA
Documents
Genomics
Repository
 Barron Cameron

Meditech/Dictaphone
Meditech/Dictaphone
2004 Prairie Farm
Chetek

Meditech/Dolbey Bloomer
Glenwood Colfax
Cerner/Dictaphone
Cerner /Dictaphone City
Menomonie Chippewa Falls
Dolbey
Elmwood Eau Claire

Mondovi Osseo
Le Sueur Lake City
Lamberton St. Peter Northfield
Wabasha
Waterville Faribault Alma Arcadia
Springfield Mankato Plainview
Janesville
Owatonna Galesville
Madelia Sparta Tomah
Lake Crystal Waseca Rochester
Blooming Holmen
St. James
New Richland Prairie Onalaska
Truman La Crescent West Salem
Wells Alden Austin Grand Meadow
Fairmont Houston La Crosse
MINNESOTA Sherburn
Kiester Albert Lea Adams LeRoy Mabel
Caledonia
IOWA WISCONSIN
Lake Mills Decorah
Armstrong
Waukon
Charles City
Prairie du Chien
New Hampton
 Mayo’s use of CDA
Mayo Notes Regional Systems
CDA
Documents

Interface engine
converts XML to RTF
CDA RFT

Genomics MICS
Repository System
 MICS Clinical Notes II
• Project Goals:
- Entry automation
- Templated document entry
- Digital dictation integration

• Support to work with HL7 on Structured

Documents Standards (CDA).
Mayo Usability Lab
 Mayo’s use of CDA
Editor
 Mayo’s use of CDA
Editor
 CDA Benefits to Mayo
n Readable
n CDA Level 1 - looked like our documents: narrative, multi-sectioned
n Version 3 modeling approach promises machine processability
n Durable
n Our documents needed to survive technology changes
n Our paper based system has lasted 100 years
n Shareable
n Standards based document exchange - $$ savings
n Developing needs for Regional partners and others
n Flexible
n Multi-media & web technology support - day one
n An architecture to cover all the documentation needs of Mayo.
 CDA – Release 2.0
n New Capabilities
n RIM based modeling…
n Clinical Statement Support

n Image annotation
n Legacy
 RIM - Act & Observation
n The Act and Observation classes are found in the HL7
Reference Information Model (RIM). These classes
are used to model findings in the RIM and are useful
references when considering the modeling of vital
signs within a clinical document.

n Below is the panel used to capture vital signs in our editor.

 RIM - Act & Observation
Required Act Attributes:

ü 1. activity_time The time when the action happened.

2. availability_dttm The time at which a receiving system obtained information.
ü 3. confidentiality_cd A code that limits disclosure of information about this act.
4. critical_time The biologically relevant time of the action.
ü 5. id The instance identifier for the act.
6. interruptible_ind Indicates if an act can be interrupted by asynchronous events.
7. max_repeat_nmr This is the maximum number of repetitions of an act.
8. mood_cd Set for observation mood, as opposed to ordered, master reference or goal.
9. orderable_ind Used in master reference mood for orderable acts.
10. priority_cd Specifies the urgency under which an act is scheduled or performed.
11. status_cd State of an action, pending, active, completed, cancelled or deleted.
12. txt Description of the act.
ü 13. type_cd A code to specify the act conceptually.
Vital Signs - Presentation
Activity time use to record
the ACT.Activity_time of
the service act.

Caption code used to

record Act.type_cd for the
vital entries on current
row.

Value use to encode the

Observation.value (finding)
of the activity.
 Vital Signs - Conformance
Entries XPath Expression Notes
Vitals Table /table[caption/caption_cd/@V = “2000-1”] Only one vital signs table is assumed.
Activity Time tr/th [n]/@activity_tmr n = vitals column + 1
Observation(s)
Height tr[th/caption_cd/@V=”30029”]/td [m] m = vitals observation column
Weight tr[th/caption_cd/@V =”30030”]/td [m] m = vitals observation column
BMI tr[th/caption_cd/@V =”30031”]/td [m] m = vitals observation column
BSA tr[th/caption_cd/@V =”30032”]/td [m] m = vitals observation column
Temperature tr[th/caption_cd/@V =”30033”]/td [m] m = vitals observation column
Head Circ tr[th/caption_cd/@V =”30034”]/td [m] m = vitals observation column
Resp Rate tr[th/caption_cd/@V =”30035”]/td [m] m = vitals observation column
Resp Desc tr[th/caption_cd/@V =”30036”]/td [m] m = vitals observation column
Pulse tr[th/caption_cd/@V =”30037”]/td [m] m = vitals observation column
Rhythm tr[th/caption_cd/@V =”30038”]/td [m] m = vitals observation column
Systolic tr[th/caption_cd/@V =”30039”]/td [m] m = vitals observation column
Diastolic tr[th/caption_cd/@V =”30040”]/td [m] m = vitals observation column
Position / Cuff tr[th/caption_cd/@V =”30041”]/td [m] m = vitals observation column
ID / Value / Unit
ID id/@id
Metric Value value/@V[1]
Metric Unit value/@U[1]
English Value value/@V[2]
English Unit value/@U[2]
 Observation
n CDA Release 1.0 does not define a standard way in
which to represent vital signs within clinical documents.

n Mayo adopted a strategy to include observations within

CDA release 1.0 document, using local markup.

n By using the RIM, we were able to anticipate the CDA

Release 2.0 standard.
 Vital Signs Conformance

ü Id Optionally in <td> elements.

ü Value Found in <td> elements.
ü Activity time Found in row = 1, column > 1
ü Type code Found in column =1, row > 1
ü Patient Context taken from doc header
ü Authentication Context taken from doc header
ü Confidentiality Level One
ü Originator Level One
Observation (Entry) *Observation
Occurs
Sequence of Elements Type Min Max Notes
id II 0 1
code CD 1 1 Observation Type+
derivationExpr ST 0 1
text ED 0 1
statusCode CS 0 1 Act Status
effectiveTime IVL_TS 0 1
priorityCode CE 0 1 Act Priority +
repeatNumber IVL_INT 0 1
languageCode CS 0 1 Human Language
value xs:anyType 0 *
interpretationCode CE 0 * Observation Interpretation
methodCode CE 0 1 Observation Method+
targetSiteCode CD 0 1 Act Site+
referenceRange *ReferenceRange 0 *
author *Author 0 *
informant *Informant12 0 *
subject *Subject2 0 1
performer *Performer 0 *
specimen *Specimen 0 *
participant1 *Participant4 0 *
precondition *Precondition 0 *
entryRelationship *EntryRelationship 0 *
reference *Reference 0 *
 Business Benefits
n Using the HL7 / Version 3.0 methodology,
Mayo was able to move forward with its
implementations and projects.

n With CDA Release 2.0, we will be able to

transform our CDA Release 1.0 documents into
CDA Release 2.0 and share vital sign
observations with others.
 New in CDA Release 2.0
n New Constructs in CDA Release 2.0
n Observation
n Procedure
n Encounter
n Substance Administration
n Supply
n Organizer
n Act
… the unifying construct - Clinical Statements
 Clinical Statement
n An expression of a discrete item of clinical (or clinically related) information
that is recorded because of its relevance to the care of a patient.

n Clinical information is fractal in nature and therefore the extend extent and
detail convert conveyed in a single statement may vary.

n To be regarded as a clinical statement, a concept must be associated with a

patient in a manner which to makes clear:
n Its temporal time context, relationship to the patient
n In the case of an observation
n Its mood and presence, absence or value
n In the case of a procedure
n Its mood and status

n This clarity may be achieved by

n Explicit representation; or
n Implicit application of defaults ONLY where explicitly modeled rules state the
appropriate defaults.

David Markwell
CDA – Release 2.0
Clinical Statements
 Challenges & Opportunities
n Templates
n The current specification consists of a single CDA XML
Schema, and the architecture arises from the ability to apply
one or more of a hierarchical set of HL7 Templates, which
serve to constrain the richness and flexibility of CDA.

n Although still a work in progress, there are several ways by

which CDA can be constrained today:
n by the creation of a derived static models
n the creation of a local implementation guide
n the creation of a more constrained XML schemas
Thank You