Clinical Document Architecture. Outline History Introduction Levels Level One Structures.

Clinical Document Clinical Document ArchitectureArchitecture

Clinical Document Clinical Document ArchitectureArchitecture

Outline• History• Introduction• Levels• Level One Structures

History• 1996 Kona Architecture• 1998 Patient Record

Architecture• 2000 ANSI/HL7 CDA R1.0

Scope• The scope of the CDA is

– standardization of clinical documents for exchange

• CDA enables, but does not constrain:– authoring– document management– storage– display

Differences to other standards

• Others focus on EHR• CDA focuses on document for

exchange• Other abstract the architecture as

directory structure• CDA abstracts the architecture as

document structures

CDA Implementations• PICNIC (EU)• SCIPHOX (Germany)• WebOnColl (Greece)• NHS South Staffordshire (United

Kingdom)

What is a document?• CDA documents are not birth-to-

death aggregate records• CDA documents are defined and

complete information object that can exists outside of a message and can include text, images, sounds and other multimedia content

CDA Documents• Level One consists of three

technical specifications– CDA Header– CDA Body – HL7 Datatypes

CDA Levels• This specification defines a multi level architecture

where each level is derived from a more basic level• levels refer to varying degrees of required markup

granularity and specificity• does not refer to the depth or granularity of the

content

CDA Levels• Level One specify one core DTD• At level 2 and 3, DTDs differ for different

document types – History Summary – Physical Summary– Discharge Summary

• Cardiology Discharge Summary • Respirology Discharge Summary

• the classification has not been defined• There is only one DTD for level one

CDA Levels• Levels provide iteratively adding

greater markup to clinical documents

• Levels establish baselines for conformance

CDA Levels & RIM Semantics

• Levels are distinguished by:– markup granularity– RIM-derived markup

• Level One: RIM-derived document header. Body is largely structural, although codes can be inserted.

• Level Two: HL7 Templates can constrain the general Level One DTD, resulting in Level Two DTDs.

• Level Three: Clinical content can be marked up to the extent that it is modeled in the RIM.

Level 1 (Coded Header)

•good for largely narrative clinical notes

Level 1• Only header includes semantics• There is no semantic in level one

body• Level one compliance offers

interoperability for human-readable content

• Header is derived from RIM

Level 2

•templates layered on top of CDA Level One. These templates constrain the CDA Level One tags, without introducing any new markup

HL7 Templates• created by domain experts, like archetypes• A template is a structured collection of data,

aggregated for some purpose, of interest to one or more healthcare stakeholders

• constrained at abstract level and at the level of syntax

• What is a “constraint”?– <section> called “ROS” must contain <section>

on “vital signs”– <document> called “H&P” must contain

<section> called “ROS”

Level 2 (Coded Structure)

• Domain specializations or differences starts at this level

• It contains the same coded header as Level 1

Level 3

•adds additional RIM-derived markup to the CDA Level One specification, enabling clinical content to be formally expressed to the extent that is it modeled in the RIM.

Level 3 (Coded Content)

• in Level 3 full document semantics for arbitrary machine processing is required

• specificity should be consistent with the RIM and be consistent with the coded header and coded structures of Level 1 and 2

• The aim is to meet the machine processing requirement

Level 3 Body Example

CDA Levels• CDA Levels are distinguished by

the degree of granularity of the markup

• Clinical content remains constant

Levels

Relationship to HL7 messages

• CDA complements HL7 messaging specs

• A CDA document is a defined and complete information object that can exist outside of a messaging context

• A CDA document can be a MIME encoded payload within an HL7 message

Relationship to HL7 messages

• CDA documents are encapsulated as MIME packages within HL7 messages

• exchanged in any event/message that exchange documents

CDA & Document Management (Chapter

9)• Chapter 9 messages can be useful

in sending CDA documents between document management systems

Local Document Management System

• Local DMS can utilize CDA to exchange documents

Outline• Level One:

– HL7 Datatypes– CDA Level One Header– CDA Level One Body

HL7 datatypes• specification that attempts to define all data

types needed for healthcare information exchange

• provide semantic constraints for the attributes of the RIM classes

• Datatypes are defined for:– character strings and display data– codes and identifiers – quantities

• Coded CDA components or elements have the two-letter ending “cd” (SNOMED)

HL7 datatypes • Every vocabulary has a unique HL7

assigned identifier • The root object identifier

– 2.16.840.1.113883

• ICD10– 2.16.840.1.113883.6.3

The CDA Header - Purpose

• The CDA Header is constant across all CDA documents (levels). Its purpose is

• to:– Enable clinical document exchange across

and within institutions– Facilitate clinical document management– Facilitate compilation of an individual

patient’s clinical documents into a lifetime electronic patient record (“uniquely identify a single patient”)

CDA Header• There are four logical components

of the CDA Header:– Document information– Encounter data– Service actors (such as providers)– Service targets (such as patients)

CDA Level One Header DTD - Example

CDA Header DTD

CDA Header Instance (Patient Part)

CDA Instance

CDA Instance

CDA Header: local_header

• Local Header Markup: Local Header Markup:<status_cd V=“Final”S=“OID value”DN=“Legally Attested”/>

<local_header descriptor = “status_cd”><local_attr name = “V” value = “Final”/><local_attr name = “S” value = “OID value”/><local_attr name = “DN” value = “Legally Attested”/>

</local_header>

CDA Level One Body• The body consists of either

– nested containers (sections, paragraph, lists, tables)

– non-xml blob (Encapsulated Data)

• The body may be coded

Level One Body Example

CDA Body

Section• The same purpose as in the usual

documents• A container used to wrap other

containers (“folder” in CEN)• has:

– optional caption– nested section or structure elements– optional coded_entry elements

CDA Level One Body• Structures

– Paragraphs– Lists– Items– Tables

• Entries– Character Data (#PCDATA)– Content– Links– Coded Entries– Observation Media– Localization

Body structures: paragraph

• Can occur in section, item and table cells

caption element• The same purpose as in the usual

documents• A label for a container• Occurs in section, paragraph, list, item

and table• Contains text and links and can be

coded using caption_cd• represents context of a container but

do not have to

Body entries: content• Occurs in local_markup, table

cells, paragraph, item and nested within content

• Contains zero or more other entries (that is, like containers for entries)

Body entries: character data

• #PCDATA• Occurs in content, local_markup,

caption, link_html or table cells

Body entries: coded_entry

• Inserts codes from HL7 recognized coding schemes or locally defined codes into document

• uses concept descriptor (CD) data type• Can occur in section and content

Body: content & coded entry

Local Markup• CDA seeks to standardize the highest

level of shared meaning while providing a clean and standard mechanism for expressing meaning that is not shared

• transform local tag set into CDA tag set and where there is no equivalent use “local_markup”

CDA Body Localization: local_markup

• Can occur in coded_entry, observation_media, content, table cells

• Contains zero or more entries

• Value can be drawn from local vocabulary domain