1 Clinical Document Architecture (previously "Patient Record Architecture") HL7 Meeting St. Louis, Missouri September 13, 2000 Bob D olin, MD Kaiser Permanente.

Clinical Document ArchitectureClinical Document Architecture(previously "Patient Record Architecture")(previously "Patient Record Architecture")

HL7 MeetingHL7 MeetingSt. Louis, MissouriSt. Louis, MissouriSeptember 13, 2000September 13, 2000

Bob Dolin, MDKaiser Permanente

•Objectives•Overview of August 2000 Clinical Document Architecture ballot proposal

•Introduction•What is the CDA?•The "A" in "CDA"•Relationship of CDA to HL7 Messaging Standards

•Technical Specifications•CDA Header•CDA Body•HL7 V3 Data Types

OutlineOutline

•The models and examples presented here are based on the August 2000 membership-level ballot draft. While the ballot did pass, there will be some minor edits before finalizing the standard.

•The examples displayed in the slides leave out required components and introduce modifications to illustrate a point. The examples in the other handout are complete and accurate.

•The exact representation of CDA instances is contingent on the outcome of the HL7 V3 data type DTD ballot.

DisclaimerDisclaimer

IntroductionIntroduction

•What is the CDA?

The CDA is a document markup standard for the structure and semantics of exchanged "clinical documents".

A clinical document is a documentation of observations and other services with the following characteristics:

•Persistence•Stewardship•Potential for authentication•Wholeness•Human readability

A CDA document is a defined and complete information object that can exist outside of a message, and can include text, images, sounds, and other multimedia content.

•What is the CDA? (cont.)

Key aspects of the CDA:

•CDA documents are encoded in Extensible Markup Language (XML).

•CDA documents derive their meaning from the HL7 Reference Information Model (RIM ) and use HL7 V3 data types.

•The complete CDA will include a hierarchical set of document specifications. This hierarchy is referred to as an "architecture".

•The "A" in "CDA"

CDA Level One DTD CDA Level Two DTD Level Two :: Progress Note DTD Level Two :: Cardiology Progress Note DTD Level Two :: Endocrine Progress Note DTD Level Two :: Diabetes Progress Note DTD CDA Level Three DTD Level Three :: Progress Note DTD Level Three :: Cardiology Progress Note DTD Level Three :: Endocrine Progress Note DTD Level Three :: Diabetes Progress Note DTD

CDA "Levels" - Quantum sets of specializations, to which further constraints can be applied.

•The "A" in "CDA" (cont.)

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

CDA Level One DTD* CDA Level Two DTD CDA Level Three DTD

*The current spec only includes CDA Level One. Higher levels are under development.

•The "A" in "CDA" (cont.)

•Level One minimizes the technical barriers to entry, while providing a "gentle introduction" to the HL7 RIM.

•Levels provide a migration pathway for iteratively adding greater markup to clinical documents.

•Levels establish baselines for conformance claims.

CDA Level One DTD CDA Level Two DTD CDA Level Three DTD

HL7 V3

<service_cd> <service_txt T="ED">

</service_txt></service_cd>

HL7 V2.x

MSH|...EVN|...PID|...PV1|...TXA|...OBX|1|ED|...

•Relationship of CDA to HL7 Messaging Standards

CDA documents are encapsulated as MIME packages within HL7 messages

OutlineOutline

•Introduction

•CDA Header :: Specified in the CDA Header DTD; derived using the V3 Message Development process.

•CDA Level One Body :: Specified in the CDA Level One DTD; derived from document analysis, building on the modeling employed by document markup standards.

•HL7 V3 Data Types :: An XML implementation of the abstract data type specification used by both the CDA and the HL7 Version 3 message specifications.

•A CDA Level One document references the CDA Level One DTD (which references the CDA Header DTD, which references the HL7 V3 data type DTD).

Technical SpecificationsTechnical Specifications

•Introduction :: Vocabulary Domains

•Vocabulary domains represent value sets for coded CDA components.

•HL7-defined or drawn from HL7-recognized coding systems.

•CNE (Coded, No Extensions) vs. CWE (Coded, With Extensions)

•Vocabulary terms are transmitted via special data types (CS, CE, CD)

Code Display Name DefinitionN normal Normal confidentiality.D clinician Only clinicians may see this item.R restricted Restricted access.I individual Access only to individual persons.S sensitive Sensitive information.C celebrity Celebrities.

Vocabulary domain for <confidentiality_cd> (CWE)

<!ELEMENT confidentiality_cd %CE-cont.model;><!ATTLIST confidentiality_cd T NMTOKEN #FIXED "CE" %CE-attrib.list; ...>

<confidentiality_cd V="N" S="2.16.840.1.113883.5.10228" DN="normal"/>

Code Display Name DefinitionAPND appends An appendage to an existing report.RPLC replaces A replacement to an existing report.

Vocabulary domain for <document_relationship.type_cd> (CNE)

<!ELEMENT document_relationship.type_cd %CS-cont.model;><!ATTLIST document_relationship.type_cd T NMTOKEN #FIXED "CS" V (APND|RPLC) #REQUIRED ... >

<document_relationship.type_cd V="APND"/>

CDA HeaderCDA Header

•Overview

The CDA Header is specified by the CDA Header DTD which is derived from a Hierarchical Description (HD), using a method that closely parallels the V3 Message Development Framework.

There are four logical components of the CDA Header:

1. Document information;

2. Encounter data;

3. Service actors (such as providers);

4. Service targets (such as patients).

HL7 CDA

HL7 V3 Message

HL7 Reference Information Model

Reference Information Model Header Information Model

Hierarchical Description<!ELEMENT birth_dttm %TS-cont.model;>

<!ATTLIST birth_dttm %TS-attrib.list; %common-atts; HL7-NAME CDATA #FIXED 'birth_dttm'>

XML DTD

• subset of RIM• tighten constraints

• linearization• additional constraints

• algorithm

19http://www.hl7.org/library/data-model/Rose_tooling/RoseTree_II.zip

HL7 RIM(MS Access or Rational Rose)

CDA HeaderCDA Header XML Element Name Data Type Cardinalityclinical_document_header document_service 1..1 id II 1..1 document_type_cd CE 1..1 document_relationship service_relationship 0..* document_ relationship.type_cd

CS 1..1

related_document service 1..1 id II 1..1 patient_encounter patient_encounter 0..1 id II 0..1

CDA HeaderCDA Header<clinical_document_header> <id EX="a123" RT="2.16.840.1.113883.3.933"/> <document_type_cd V="11488-4" S="2.16.840.1.113883.6.1" DN="Consultation note"/> <document_relationship> <document_relationship.type_cd V="RPLC"/> <related_document> <id EX="a234" RT="2.16.840.1.113883.3.933"/> </related_document> </document_relationship> <patient_encounter> <id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>

XML Element Name Data Type Cardinalityclinical_document_header document_service 1..1 id II 1..1 document_type_cd CE 1..1 document_relationship service_relationship 0..* document_ relationship.type_cd

CS 1..1

related_document service 1..1 id II 1..1 patient_encounter patient_encounter 0..1 id II 0..1

•RIM 0.98 :: CDA Header Information Model

Service_target

type_cd : CVtmr : IVL<TS>

Document_service

set_id : IIversion_nbr : INTcopy_dttm : TSorigination_dttm : TS

Service_actor

type_cd : CVtmr : IVL<TS>signature_cd : CVfunction_cd : CD

Stakeholder

addr : SET<AD>phon : SET<TEL>id : SET<II>

Person

birth_dttm : TSadministrative_gender_cd : CE

0..*0..1

Organization

nm : SET<ON>

Service

id : SET<II>service_cd : CDactivity_time : GTSconfidentiality_cd : SET<CV>

0..* 10..* 1

Service_relationship

type_cd : CV

1 Patient_encounter

id : IIactive_tmr : IVL<TS>practice_setting_cd : CV0..10..* 0..10..*

•Document information

Service_target

Document_service

Service_actor

Stakeholder

Person

0..*0..1

Organization

nm : SET<ON>

Service

0..* 10..* 1

type_cd : CV

1 Patient_encounter

•Encounter data

Service_target

Document_service

Service_actor

Stakeholder

Person

0..*0..1

Organization

nm : SET<ON>

Service

0..* 10..* 1

type_cd : CV

1 Patient_encounter

•Service actors

Service_target

Document_service

Service_actor

Stakeholder

Person

0..*0..1

Organization

nm : SET<ON>

Service

0..* 10..* 1

type_cd : CV

1 Patient_encounter

•Service targets

Service_target

Document_service

Service_actor

Stakeholder

Person

0..*0..1

Organization

nm : SET<ON>

Service

0..* 10..* 1

type_cd : CV

1 Patient_encounter

encounter data

service actors

service targets

document information

•XML element identification

Every XML element within a CDA document has an optional identifier, which must be unique within the document. The identifier is an XML "ID" data type.

<!ATTLIST Every_CDA_ELEMENT

ID ID #IMPLIED

•Document identification (<id>, <set_id>, <version_nbr>, <document_type_cd>)

Every document has a required, globally-unique instance identifier, <id>, an identifier that remains constant across all document revisions that derive from a common root, <set_id>, and a version number, <version_nbr>.

Every document has a required document type code, <document_type_cd>. The externally-defined vocabulary domain for <document_type_cd> is drawn from LOINC.

•Document time stamps (<service_tmr>, <encounter_tmr>, <origination_dttm>, <copy_dttm>, <participation_tmr> )

Some temporal events can be represented as a specific point in time (indicated by "_dttm" and using the HL7 V3 TS data type), while other temporal events include time intervals (indicated by "_tmr" and using the HL7 V3 IVL_TS or GTS data type).

•Document relationships (<document_relationship>, <fulfills_order>)

The CDA Header enables the explicit representation of the relationship between documents. A clinical document can append or replace another clinical document.

Documents may be generated in response to one or more orders. The <fulfills_order> element points to fulfilled orders.

•Encounter data (<patient_encounter>, <id>, <practice_setting_cd>, <encounter_tmr>, <service_location>)

Encounter data include a globally-unique identifier, the time of the encounter, a location, and an optional practice setting code, which is a categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) in which care is delivered.

•Service actors (<authenticator>, <legal_authenticator>, <intended_recipient>, <originator>, <originating_organization>, <transcriptionist>, <provider>, <service_actor>)

Service actors include those who authenticate the document, those intended to receive a copy of the document, document originators and transcriptionists, and health care providers who participated in the service(s) being documented. Service actors are capable of and accountable for their independent decisions.

•Service actors (cont.)

•Service targets (<patient>, <originating_device>, <service_target>)

Service targets are physical entities, including living subjects and inanimate material, that are typically the object of services being documented. Service targets include the patient, other significant participants (such as family members), and those devices that may have originated portions of the document.

•Service targets (cont.)

•Localization (<local_header>, <local_attr>)

The CDA adds markup declarations that enable localization. The <local_header> element is an optionally repeating, recursive element tacked on to the end of every content model. The "descriptor" attribute describes the element, and the value can be drawn from a local vocabulary domain. The "ignore" attribute tells the receiver to ignore just the local_header tag (ignore="markup"), or to ignore the local_header tag and all contained content (ignore="all"). The "render" attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.

•Localization (cont.)

<!ELEMENT authenticator ( authenticator.type_cd, participation_tmr, signature_cd, person, local_header* )>

<!ELEMENT local_header

(#PCDATA |

local_header |

local_attr)* >

<!ATTLIST local_header

ignore (all | markup) "markup"

descriptor CDATA #IMPLIED

render CDATA #IMPLIED

ID ID #IMPLIED

xml:lang NMTOKEN #IMPLIED >

<!ELEMENT local_attr EMPTY>

<!ATTLIST local_attr

name NMTOKEN #REQUIRED

value CDATA #REQUIRED

ID ID #IMPLIED

xml:lang NMTOKEN #IMPLIED>

<clinical_document_header> <id EX="a123" RT="2.16.840.1.113883.3.933"/> <document_type_cd V="11488-4" S="2.16.840.1.113883.6.1" DN="Consultation note"/> <origination_dttm V="2000-04-07"/> <document_relationship> <document_relationship.type_cd V="RPLC"/> <related_document> <id EX="a234" RT="2.16.840.1.113883.3.933"/> </related_document> </document_relationship> <patient_encounter> <id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/> <encounter_tmr V="2000-04-07"/> </patient_encounter> <local_header ignore="all" descriptor="MyLocalTag"> ... extra stuff that is only used locally ... </local_header></clinical_document_header>...

•Sample CDA document*

* Note that the exact representation is contingent on the outcome of the HL7 V3 data type DTD ballot.

CDA Level One BodyCDA Level One Body

•Overview

The CDA Level One Body is comprised of sections or a single non-XML block. A section can contain "structures", nested section's, and codes. CDA structures contain "entries".

Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed in XML using industry-standard constructs. The structural components themselves are not part of RIM 0.98.

Where CDA entries are derivable from the RIM, they have an XML representation that follows the style used for the CDA Header.

•Overview (cont.)

CDA "structures"

CDA "entries"

•Shared XML Attributes

These attributes are assigned to all XML elements in the CDA Level One Body. Their values are inherited by nested content, unless overridden.

<!ATTLIST Every_CDA_Body_Element

ID ID #IMPLIED

confidentiality IDREFS #IMPLIED

originator IDREFS #IMPLIED

xml:lang NMTOKEN #IMPLIED

•Non_xml body

The CDA <non_xml> container represents a document body that is in some format other than XML. CDA's <non_xml> uses the HL7 V3 Encoded Data data type to reference data that is stored externally to the CDA Level One document (as opposed to encapsulating the data within the CDA document itself).

•Captions

The CDA <caption> is a label for a container. The <caption> element can occur in a <section>, <paragraph>, <list>, <item>, or <table> element. A <caption> contains plain text and may contain links, and can be coded using the <caption_cd> element. The vocabulary domain for <caption_cd> is externally-defined by LOINC.

CDA "structures"

CDA "entries"

•CDA "structures" (<paragraph>, <list>, <table>)

•CDA "structures" (cont.)

Structures have optional captions.

A <paragraph> contains CDA "entries".

A <list> contains one or more <item>'s. An <item> contains entries and nested structures.

The CDA <table> is a modification of the strict XHTML table model. In CDA Level One, any information can be presented as a table. The table markup is for presentation purposes only and, unlike a database table, does not possess meaningful field names.

•CDA "structures" (cont.)

CDA "structures"

CDA "entries"

•CDA "entries" (character data, <link>, <coded_entry>, <content>, <observation_media>, <local_markup>)

•Link

The CDA <link> is a generic referencing mechanism based on the HTML anchor tag. Multimedia that is part of the attestable content of the document requires the use of <observation_media>. Multimedia that is simply referenced should use <link>.

<!ELEMENT link (link_html) >

<!ELEMENT link_html (#PCDATA) >

<!ATTLIST link_html

name CDATA #IMPLIED

href CDATA #IMPLIED

rel CDATA #IMPLIED

rev CDATA #IMPLIED

title CDATA #IMPLIED >

•Coded_entry

The CDA <coded_entry> uses the HL7 V3 Concept Descriptor data type to insert codes from HL7-recognized coding schemes into CDA documents. Where there are no suitable HL7-recognized codes available, locally-defined codes can be used.

<content> Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper. <coded_entry> <coded_entry.value V="D2-51000" S="2.16.840.1.113883.6.5" DN="Asthma"/> </coded_entry></content>

•Content

The <content> element nests recursively, enabling wrapping a string of text down to as small a chunk as desired. These <content> elements can serve as anchors to be referenced by <coded_entry> elements to indicate the original text that supports the use of a code.

<content> <content ID="String001">Asthma</content>, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper. <coded_entry> <coded_entry.value ORIGTXT="String001" V="D2-51000" S="2.16.840.1.113883.6.5" DN="Asthma"/> </coded_entry></content>

•Observation_media

The <observation_media> element, derived from the RIM Observation class, represents media that is logically part of a CDA document, but is stored outside the document and incorporated by reference (using the HL7 V3 Encoded Data data type).

<content> Erythematous rash, palmar surface, left index finger. <observation_media> <observation_media.value MT="image/jpeg"> <REF V="rash.jpeg"/> </observation_media.value> </observation_media></content>

Physical ExamErythematous rash, palmar surface, left index finger.

•Localization

The implementation of localization in the CDA Level One Body using the <local_markup> element parallels the approach used in the CDA Header.

OutlineOutline

1 Clinical Document Architecture (previously "Patient Record Architecture") HL7 Meeting St. Louis, Missouri September 13, 2000 Bob D olin, MD Kaiser Permanente.

cda cda level

cda relationship of

cda documents

complete cda

general level

membershiplevel ballot

hl7 rim

hl7 v3 data type dtd

Documents

Clinical Document Architecture (previously "Patient Record.....

Slide 1 · Web viewGenerate HL7 message (using HL7 v2.4...

HL7 and Service-oriented Architecture (SOA) Ambassador...

HL7 & HL7 CDA: The - Office of Standard, ETDA · HL7 & HL7....

Olin stourhead

The Use of HL7 Clinical Document Architecture Schema to...

HL7 Implementation Guide for CDA Release 2.0 CDA … · HL7...

HL7 Clinical Document Architecture, Release 2.0

Olin Representatives

HL7 CDA Clinical Document Architecture

A Summary Care Record Architecture based on HL7 CDA and SOA

HL7 Specifications ADT-MDM - HL7 Reference

ISO/CEN Interoperability Reference Architecture and its...

Hl7 Standards, Reference Information Model & Clinical...

HL7 Clinical Document Architecture, Release 2 -...

Catching FHIR - HL7 › wp-content › uploads › 2015 ›....