Header

1 CDA Overview

(content on separate page)

2 Introduction to CDA Technical Artifacts

(content on separate page)

3 CDA Document Exchange in HL7 Messages

(content on separate page)

4 CDA R-MIM

(remaining content on other page)

4.1 Header

The purpose of the CDA header is to enable clinical document exchange across and within institutions; facilitate clinical document management; and facilitate compilation of an individual patient's clinical documents into a lifetime electronic patient record.

4.1.1 Header Attributes

This section describes attributes of the root ClinicalDocument class.

The table below identifies the attributes for the ClinicalDocument class. For each attribute the name, data type, cardinality, code bindings, and binding strength are provided. The links will enable the access to the attribute definitions, data type definitions, and when appropriate, the value set or concept domain associated with the codes found in the class.

Table X: ClinicalDocument Attributes

RIM Attribute(s)	Data Type	Cardinality	Value Set Binding	Binding Type
classCode	CS	[1..1]	V:ActClassClinicalDocument	CLOSED
moodCode	CS	[1..1]	V:ActMoodEventOccurrence	CLOSED
id	II	[1..1]
code	CE	[1..1]	D:DocumentType	OPEN
title	TS	[0..1]
effectiveTime	TS	[0..1]
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	OPEN
languageCode	CE	[0..1]	D:HumanLanguage	CLOSED
setId	II	[0..1]
versionNumber	ST.SIMPLE	[0..1]
copyTime (Deprecated)	TS	[0..1]

Table X: Value set for ClinicalDocument.classCode

v:ActClassClinicalDocument [2.16.840.1.113883.1.11.13948] (CLOSED)
Code	Print Name		Code	Print Name
DOCCLIN (Default)	clinical document		CDALVLONE	CDA Level One clinical document
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Table X: Value set for ClinicalDocument.moodCode

v:ActMoodEventOccurrence [2.16.840.1.113883.1.11.20267] (CLOSED)
Code	Print Name
EVN (Fixed)	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

4.1.1.1 ClinicalDocument.id

Represents the unique instance identifier of a clinical document.

4.1.1.2 ClinicalDocument.code

The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note). The value set is drawn from LOINC, and has a CWE coding strength.

Within the LOINC database, beginning with version 2.09, May 2003, document type codes are those that have a value of "DOC" in the Scale component. This subset of LOINC is included in the appendix (see LOINC Document Codes).

NOTE: The hierarchical relationship among LOINC document codes is in evolution. Per the LOINC version 2.14 (December 2004) manual: As soon as possible, the component terms used in the creation of the names of document type codes will be mapped to either the UMLS Metathesaurus or SNOMED CT. This mapping will help to establish the meaning of the terms and will allow aggregation and classification of document type codes based on definitions, computable relationships, and subsumption hierarchies that exist in the reference terminology.

4.1.1.3 ClinicalDocument.title

Represents the title of the document. It's commonly the case that clinical documents do not have a title, and are collectively referred to by the display name of ClinicalDocument.code (e.g. a "consultation" or "progress note"). Where these display names are rendered to the clinician, or where the document has a unique title, the ClinicalDocument.title component should be used. In the example document in the appendix (see Sample Document), the value of ClinicalDocument.title = "Good Health Clinic Consultation Note".

4.1.1.4 ClinicalDocument.effectiveTime

Signifies the document creation time, when the document first came into being. Where the CDA document is a transform from an original document in some other format, the ClinicalDocument.effectiveTime is the time the original document is created. The time when the transform occurred is not currently represented in CDA.

4.1.1.5 ClinicalDocument.ConfidentialityCode

Confidentiality is a required contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by a nested value (as further described in CDA Context).

Table X: Value set for ClinicalDocument.confidentialityCode

X_BasicConfidentialityKind [2.16.840.1.113883.1.11.16926] (OPEN)
Code	Print Name		Code	Print Name
N	normal		R	restricted
V	very restricted
Code System: Confidentiality (HL7) Code System OID: 2.16.840.1.113883.5.25

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.

4.1.1.6 ClinicalDocument.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066 for the Identification of Languages, ed. H. Alvestrand. 1995, which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121". Language is a contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by a nested value (as further described in CDA Context).

4.1.1.7 ClinicalDocument.setId

Represents an identifier that is common across all document revisions.

4.1.1.8 ClinicalDocument.versionNumber

An integer value used to version successive replacement documents.

4.1.1.9 ClinicalDocument.copyTime (Deprecated)

Represents the time a document is released (i.e. copied or sent to a display device) from a document management system that maintains revision control over the document. Once valued, it cannot be changed. The intent is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.

Included for backwards compatibility with CDA, Release One. ClinicalDocument.copyTime has been deprecated because it is not part of the document at the time it is authenticated, but instead represents metadata about the document, applied at some variable time after authentication. Further use is discouraged.

4.1.2 Header Participants

This section describes classes related to the root ClinicalDocument class via a Participation.

4.1.2.1 authenticator

Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it. (See also legalAuthenticator)

A clinical document can have zero to many authenticators. While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. An authenticator has a required authenticator.time indicating the time of authentication, and a required authenticator.signatureCode, indicating that a signature has been obtained and is on file.

Table X: Value set for authenticator.typeCode

v:ParticipationAuthenticator [2.16.840.1.113883.1.11.20065] (CLOSED)
Code	Print Name
AUTHEN (Fixed)	authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for authenticator.signatureCode

v:ParticipationSignature [2.16.840.1.113883.5.89] (CLOSED)
Code	Print Name		Code	Print Name
S (Fixed)	signed		I (Deprecated)	intended
X (Deprecated)	required
Code System: ParticipationSignature (HL7) Code System OID: 2.16.840.1.113883.5.89

Note: CDA Release One represented either an intended ("X") or actual ("S") authenticator. CDA Release 2 and 2.1 only represents an actual authenticator, so usage of "X" and "I" are deprecated.

An authenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class). (See here for a description of "player" and "scoper" role associations.)

Table X: Value set for AssignedEntity.classCode

v:RoleClassAssignedEntity [2.16.840.1.113883.1.11.11595] (CLOSED)
Code	Print Name		Code	Print Name
ASSIGNED (Default)	assigned entity		COMPAR	commissioning party
SGNOFF	signing authority or officer
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

Table X: Value set for Person.classCode

v:EntityClassPerson [2.16.840.1.113883.1.11.20049] (CLOSED)
Code	Print Name
PSN (Fixed)	person
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Table X: Value set for Person.determinerCode

v:EntityDeterminerSpecific [2.16.840.1.113883.1.11.20052] (CLOSED)
Code	Print Name
INSTANCE (Fixed)	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Table X: Value set for Organization.classCode

v:EntityClassOrganization [2.16.840.1.113883.1.11.10889] (CLOSED)
Code	Print Name		Code	Print Name
ORG (Default)	organization		PUB	public institution
STATE	state		NAT	Nation
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Table X: Value set for Organization.determinerCode

v:EntityDeterminerSpecific [2.16.840.1.113883.1.11.20052] (CLOSED)
Code	Print Name
INSTANCE (Fixed)	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

A scoping organization can be part of a larger organization. Where there is a need to include whole-part relationships, the OrganizationPartOf role can be used. OrganizationPartOf.statusCode indicates the state of the whole-part relationship (e.g. "active", "terminated"). OrganizationPartOf.effectiveTime is an interval of time specifying the period during which the whole-part relationhship is in effect, if such time limit is applicable and known.

Table X: Value set for OrganizationPartOf.classCode

v:RoleClassPart [2.16.840.1.113883.1.11.20154] (CLOSED)
Code	Print Name		Code	Print Name
PART (Default)	part		ACTM	active moiety
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

Table X: Value set for OrganizationPartOf.statusCode

v:RoleStatus [2.16.840.1.113883.5.1068] (CLOSED)
Code	Print Name		Code	Print Name
normal	normal		active	active
cancelled	cancelled		pending	pending
suspended	suspended		terminated	terminated
nullified	nullified
Code System: RoleStatus (HL7) Code System OID: 2.16.840.1.113883.5.1068

4.1.2.2 author

Represents the humans and/or machines that authored the document.

In some cases, the role or function of the author is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Medical Student Progress Note". The role of the author can also be recorded in the Author.functionCode or AssignedAuthor.code attribute. If either of these attributes is included, they should be equivalent to or further specialize the role inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Physician Progress Note" and the value of Author.functionCode is "rounding physician"), and shall not conflict with the role inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

Table X: Value set for author.typeCode

v:ParticipationAuthorOriginator [2.16.840.1.113883.1.11.20064] (CLOSED)
Code	Print Name
AUT (Fixed)	author
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for author.contextControlCode

v:ContextControlOverridingPropagating [2.16.840.1.113883.1.11.20034] (CLOSED)
Code	Print Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

An author is a person in the role of an assigned author (AssignedAuthor class). The entity playing the role is a person (Person class) or a device (AuthoringDevice class). The entity scoping the role is an organization (Organization class), and is the organization from which the document originates.

Table X: Value set for AssignedAuthor.classCode

v:RoleClassAssignedEntity [2.16.840.1.113883.1.11.11595] (CLOSED)
Code	Print Name		Code	Print Name
ASSIGNED (Default)	assigned entity		COMPAR	commissioning party
SGNOFF	signing authority or officer
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

Table X: Value set for AuthoringDevice.classCode

V:EntityClassDevice [2.16.840.1.113883.1.11.11623] (CLOSED)
Code	Print Name		Code	Print Name
DEV (Default)	role		CER	certificate representation
MODDV	imaging modality, ImagingModalityEntity
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Table X: Value set for AuthoringDevice.determinerCode

v:EntityDeterminerSpecific [2.16.840.1.113883.1.11.20052] (CLOSED)
Code	Print Name
INSTANCE (Fixed)	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

NOTE: In CDA, Release One, it was possible to specify those individuals responsible for the device. This functionality has been deprecated in CDA, Release Two. The MaintainedEntity class is present for backwards compatibility, and its use is discouraged, except where needed to support the transformation of CDA, Release One documents.

Table X: Value set for MaintainedEntity.classCode

v:RoleClassMaintainedEntity [2.16.840.1.113883.1.11.20147] (CLOSED)
Code	Print Name
MNT (Fixed)	maintained entity
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

4.1.2.3 custodian

Represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian.

The custodian participation satisfies the CDA definition of Stewardship (see What is the CDA). Because CDA is an exchange standard and may not represent the original form of the authenticated document, the custodian represents the steward of the original source document.

Table X: Value set for custodian.typeCode

v:ParticipationCustodian [2.16.840.1.113883.1.11.20073] (CLOSED)
Code	Print Name
CST (Fixed)	custodian
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

A custodian is a scoping organization in the role of an assigned custodian (AssignedCustodian class). The steward organization (CustodianOrganization class) is an entity scoping the role of AssignedCustodian, and has a required CustodianOrganization.id.

Table X: Value set for AssignedCustodian.classCode

v:RoleClassAssignedEntity [2.16.840.1.113883.1.11.11595] (CLOSED)
Code	Print Name		Code	Print Name
ASSIGNED (Default)	assigned entity		COMPAR	commissioning party
SGNOFF	signing authority or officer
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

Table X: Value set for CustodianOrganization.classCode

v:EntityClassOrganization [2.16.840.1.113883.1.11.10889] (CLOSED)
Code	Print Name		Code	Print Name
ORG (Default)	organization		PUB	public institution
STATE	state		NAT	Nation
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Table X: Value set for CustodianOrganization.determinerCode

v:EntityDeterminerSpecific [2.16.840.1.113883.1.11.20052] (CLOSED)
Code	Print Name
INSTANCE (Fixed)	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

4.1.2.4 dataEnterer (Transcriptionist)

Represents the participant who has transformed a dictated note into text.

Table X: Value set for dataEnterer.typeCode

v:ParticipationDataEntryPerson [2.16.840.1.113883.1.11.20079] (CLOSED)
Code	Print Name
ENT (Fixed)	data entry person
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for dataEnterer.contextControlCode

v:ContextControlOverridingPropagating [2.16.840.1.113883.1.11.20034] (CLOSED)
Code	Print Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

4.1.2.5 encounterParticipant

See EncompassingEncounter for a description of the encounterParticipant participant.

4.1.2.6 informant

An informant (or source of information) is a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma.

Table X: Value set for informant.typeCode

v:ParticipationInformant [2.16.840.1.113883.1.11.20086] (CLOSED)
Code	Print Name
INF (Fixed)	informant
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for informant.contextControlCode

v:ContextControlOverridingPropagating [2.16.840.1.113883.1.11.20034] (CLOSED)
Code	Print Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

An informant can be a person in one of two roles. The RelatedEntity role is used to represent an informant without a role.id (e.g. a parent or guy on the street). The informant in this case bears some formal or personal relationship to the patient. The role is unscoped, with the assumption that the patient is always the implied scoper. RelatedEntity.code can be used to specify the nature of the relationship. The AssignedEntity role is used for an identified informant, and is scoped by an Organization.

Table X: Value set for RelatedEntity.classCode

v:RoleClassMutualRelationship [2.16.840.1.113883.1.11.19316] (CLOSED)
Code	Print Name		Code	Print Name
AFFL	affiliate		AGNT	agent
ASSIGNED	assigned entity		COMPAR	commissioning party
SGNOFF	signing authority or officer		CON	contact
ECON	emergency contact		NOK	next of kin
GUARD	guardian		CIT	citizen
COVPTY	covered party		CLAIM	claimant
NAMED	named insured		DEPEN	dependent
INDIV	individual		SUBSCR	subscriber
PROG	program eligible		CRINV	clinical research investigator
CRSPNSR	clinical research sponsor		EMP	employee
MIL	military person		GUAR	guarantor, GuarantorRole
INVSBJ	Investigation Subject		CASEBJ	Case Subject
RESBJ	research subject		LIC	licensed entity
NOT	notary public		PROV	healthcare provider
PAT	patient		PAYEE	payee
PAYOR	invoice payor		POLHOLD	policy holder
QUAL	qualified entity		SPNSR	coverage sponsor
STD	student		UNDWRT	underwriter
CAREGIVER	caregiver		PRS	personal relationship
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

4.1.2.7 informationRecipient

Represents a recipient who should receive a copy of the document.

NOTE: The information recipient is an entity to whom a copy of a document is directed, at the time of document authorship. It is not the same as the cumulative set of persons to whom the document has subsequently been disclosed, over the life-time of the patient. Such a disclosure list would not be contained within the document, and it outside the scope of CDA.

Table X: Value set for informationRecipient.typeCode

v:x_InformationRecipient [2.16.840.1.113883.1.11.19366] (CLOSED)
Code	Print Name		Code	Print Name
PRCP (Default)	primary information recipient		TRC	tracker
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Where a person is the intended recipient (IntendedRecipient class), the playing entity is a person (Person class), optionally scoped by an organization (Organization class). Where the intended recipient is an organization, the IntendedRecipient.classCode is valued with "ASSIGNED", and the recipient is reflected by the presence of a scoping Organization, without a playing entity. Where a health chart is the intended recipient, the IntendedRecipient.classCode is valued with "HLTHCHRT" (health chart). In this case there is no playing entity, and an optional scoping organization (Organization class).

Table X: Value set for IntendedRecipient.classCode

v:x_InformationRecipientRole [2.16.840.1.113883.1.11.16772] (CLOSED)
Code	Print Name		Code	Print Name
ASSIGNED (Default)	assigned entity		HLTHCHRT	health chart
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

4.1.2.8 legalAuthenticator

Represents a participant who has legally authenticated the document.

The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a local document is transformed into a CDA document for exchange, authentication occurs on the local document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being either authenticated or legally authenticated).

While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. A legalAuthenticator has a required legalAuthenticator.time indicating the time of authentication, and a required legalAuthenticator.signatureCode, indicating that a signature has been obtained and is on file.

Table X: Value set for legalAuthenticator.typeCode

v:ParticipationAuthenticator [2.16.840.1.113883.1.11.20065] (CLOSED)
Code	Print Name
LA (Fixed)	legal authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for legalAuthenticator.signatureCode

v:ParticipationSignature [2.16.840.1.113883.5.89] (CLOSED)
Code	Print Name		Code	Print Name
S (Fixed)	signed		I (Deprecated)	intended
X (Deprecated)	required
Code System: ParticipationSignature (HL7) Code System OID: 2.16.840.1.113883.5.89

Note: CDA Release One represented either an intended ("X") or actual ("S") authenticator. CDA Release 2 and 2.1 only represents an actual authenticator, so usage of "X" and "I" are deprecated.

Table X: Value set for legalAuthenticator.contextControlCode

v:ContextControlOverridingPropagating [2.16.840.1.113883.1.11.20034] (CLOSED)
Code	Print Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

A legalAuthenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

4.1.2.9 participant

Used to represent other participants not explicitly mentioned by other classes, that were somehow involved in the documented acts.

Table X: Value set for participant.typeCode

v:ParticipationType [2.16.840.1.113883.1.11.10901] (CLOSED)
Code	Print Name		Code	Print Name
PART	Participation		ADM	admitter
ATND	attender		ADM	admitter
CALLBCK	callback contact		CON	consultant
DIS	discharger		ESC	escort
REF	referrer		TRANS	Transcriber
ENT	data entry person		WIT	witness
CST	custodian		DIR	direct target
BBY	baby		DEV	device
NRD	non-reuseable device		RDV	reusable device
EXPAGNT	ExposureAgent		EXPART	ExposureParticipation
EXPTRGT	ExposureTarget		EXSRC	ExposureSource
IND	indirect target		BEN	beneficiary
CAGNT	causative agent		COV	coverage target
GUAR	guarantor party		HLD	holder
DON	donor		RCV	receiver
IRCP	information recipient		NOT	ugent notification contact
PRCP	primary information recipient		REFB	Referred By
REFT	Referred to		TRC	tracker
LOC	location		DST	destination
ELOC	entry location		ORG	origin
RML	remote		VIA	via
RESP	responsible party		VRF	verifier
AUTHEN	authenticator
Use the following participations, only if the other participations provided in CDA will not work
RCT	record target		AUT	author (originator)
INF	informant		CSM	consumable
PRD	product		SBJ	subject
SPC	specimen		PRF	performer
DIST	distributor		PPRF	primary performer
SPRF	secondary performer		LA	legal authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

Table X: Value set for participant.contextControlCode

v:ContextControlOverridingPropagating [2.16.840.1.113883.1.11.20034] (CLOSED)
Code	Print Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

A participant is a person or organization in the role of a participating entity (AssociatedEntity class). The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

Table X: Value set for ParticipatingEntity.classCode

V:RoleClassAssociative [2.16.840.1.113883.1.11.19313] (CLOSED)
Code	Print Name		Code	Print Name
ROL (Default)	role		AFFL	affiliate
AGNT	agent		ASSIGNED	assigned entity
COMPAR	commissioning party		SGNOFF	signing authority or officer
CON	contact		ECON	emergency contact
NOK	next of kin		GUARD	guardian
CIT	citizen		COVPTY	covered party
CLAIM	claimant		NAMED	named insured
DEPEN	dependent		INDIV	individual
SUBSCR	subscriber		PROG	program eligible
CRINV	clinical research investigator		CRSPNSR	clinical research sponsor
EMP	employee		MIL	military person
GUAR	guarantor		INVSBJ	Investigation Subject
CASEBJ	Case Subject		RESBJ	research subject
LIC	licensed entity		NOT	notary public
PROV	healthcare provider		PAT	patient
PAYEE	payee		PAYOR	invoice payor
POLHOLD	policy holder		QUAL	qualified entity
SPNSR	underwriter		STD	student
UNDWRT	coverage sponsor		CAREGIVER	caregiver
PRS	personal relationship		ACCESS	access
ADMM	Administerable Material		BIRTHPL	birthplace
DEATHPLC	place of death		DST	distributed material
RET	retailed material		EXPR	exposed entity
HLD	held entity		HLTHCHRT	health chart
IDENT	identified entity		MANU	manufactured product
THER	therapeutic agent		MNT	maintained entity
OWN	owned entity		RGPR	regulated product
SDLOC	service delivery location		DSDLOC	dedicated service delivery location, health care facility
ISDLOC	incidental service delivery location		TERR	territory of authority
USED	used entity		WRTE	warranted product
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

When the participating entity is an organization, this is reflected by the presence of a scoping Organization, without a playing entity.

4.1.2.10 performer

See ServiceEvent for a description of the performer participant.

4.1.2.11 recordTarget

The recordTarget represents the medical record that this document belongs to.

A clinical document typically has exactly one recordTarget participant. In the uncommon case where a clinical document (such as a group encounter note) is placed into more than one patient chart, more than one recordTarget participants can be stated.

The recordTarget(s) of a document are stated in the header and propagate to nested content, where they cannot be overridden (see See CDA Context).

Table X: Value set for recordTarget.typeCode (CNE)

Code	Definition
RCT (record target) [default]	The record target indicates whose medical record holds the documentation of this act.

Table X: Value set for recordTarget.contextControlCode (CNE)

Code	Definition
OP (overriding propagating) [default]	The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.)

A recordTarget is represented as a relationship between a person and an organization, where the person is in a patient role (PatientRole class). The entity playing the role is a patient (Patient class). The entity scoping the role is an organization (Organization class). A patient is uniquely identified via the PatientRole.id attribute.

CDA Release One allowed for additional person identifiers, corresponding to the Patient.id attribute in CDA Release Two. This attribute is included for backwards compatibility and has been deprecated because having two different ways to identify a patient can result in inconsistent usage. Further use of Patient.id is discouraged.

Table X: Value set for PatientRole.classCode (CNE)

Code	Definition
PAT (patient) [default]	A person that receives health care services from a provider.

Table X: Value set for Patient.classCode (CNE)

Code	Definition
PSN (person) [default]	A living subject of the species homo sapiens.

Table X: Value set for Patient.determinerCode (CNE)

Code	Definition
INSTANCE (instance) [default]	The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind).

A patient's language communication skills can be expressed in the associated LanguageCommunication class. A Patient's birthplace is represented as a relationship between a patient and a place. The Birthplace class is played by a place (Place class), and scoped by the patient (Patient class).

Table X: Value set for Birthplace.classCode (CNE)

Code	Definition
BIRTHPL (birthplace) [default]	Relates a place as the location where a living subject was born.

Table X: Value set for Place.classCode (CNE)

Code	Definition
PLC (place) [default]	A physicial place or site with its containing structure.

Table X: Value set for Place.determinerCode (CNE)

Code	Definition
INSTANCE (instance) [default]	The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind).

A patient's guardian is a person or organization in the role of guardian (Guardian class). The entity playing the role of guardian is a person (Person class) or organization (Organization class). The entity scoping the role is the patient (Patient class).

Where a guardian is not explicitly stated, the value should default to local business practice (e.g. the patient makes their own health care decisions unless incapacitated in which case healthcare decisions are made by the patient's spouse).

Table X: Value set for Guardian.classCode (CNE)

Code	Definition
GUARD (guardian) [default]	An entity (player) that acts or is authorized to act as the guardian of the patient.

4.1.2.12 responsibleParty

See EncompassingEncounter for a description of the responsibleParty participant.

4.1.2.13 Participant Scenarios

Several CDA Header participations can be played by the same person. In such cases, the person should be identified as the player for each appropriate participation. For instance, if a person is both the author and the authenticator of a document, the CDA Header should identify that person as both the author participant and the authenticator participant.

On other occasions, CDA Header participants are played by different people. The following table shows a number of scenarios and the values for various participants.

Table X: CDA participation scenarios

1. StaffPhysicianOne sees a patient as a consultant, dictates a note, and later signs it.

*Author — StaffPhysicianOne Encounter Participant — StaffPhysicianOne (typeCode="CONS") Legal Authenticator — StaffPhysicianOne

2. StaffPhysicianOne sees a patient and dictates a note. StaffPhysicianTwo later signs the note. *

*Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianTwo

3. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianOne. *

*Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne

4. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianTwo. *

Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo

5. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, and goes off on vacation. The note is signed by ResidentTwo and by StaffPhysicianOne. *

Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne

6. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, which is later signed by ResidentTwo and StaffPhysicianTwo. *

Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo

7. StaffPhysicianOne receives an abnormal lab result, attempts to contact patient but can't, and writes and signs a progress note.

Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianOne

8. ResidentSurgeonOne is operating on a patient with StaffSurgeonOne. StaffSurgeonOne dictates an operative report and later signs it.

Author — StaffSurgeonOne Authenticator — null (need not be included) Legal Authenticator — StaffSurgeonOne Performer — StaffSurgeonOne (typeCode="PPRF") Performer — ResidentSurgeonOne (typeCode="SPRF")

* Note that the ability of one clinician to co-sign or to sign on behalf of another clinician is subject to regulatory and local practice constraints.

4.1.3 Header Relationships

This section describes classes related to the root ClinicalDocument class via an ActRelationship.

4.1.3.1 ParentDocument

The ParentDocument represents the source of a document revision, addenda, or transformation. ParentDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the parent document. It is not to be used to embed the related document, and thus ParentDocument.text.BIN is precluded from use.

Allowable values for the intervening relatedDocument.typeCode are shown in the following table.

Table X: Value set for relatedDocument.typeCode (CNE)

Code	Definition
APND (append)	The current document is an addendum to the ParentDocument.
RPLC (replace)	The current document is a replacement of the ParentDocument.
XFRM (transform)	The current document is a transformation of the ParentDocument.

A conformant CDA document can have a single relatedDocument with typeCode "APND"; a single relatedDocument with typeCode "RPLC"; a single relatedDocument with typeCode "XFRM"; a combination of two relatedDocuments with typeCodes "XFRM" and "RPLC"; or a combination of two relatedDocuments with typeCodes "XFRM" and "APND". No other combinations are allowed.

Table X: Value set for ParentDocument.classCode (CNE)

Code	Definition
DOCCLIN (clinical document) [default]	A clinical document.

Table X: Value set for ParentDocument.moodCode (CNE)

Code	Definition
EVN (event) [default]	An actual occurrence of an event.

Document Identification, Revisions, and Addenda

A clinical document can be replaced by a new document and/or appended with an addendum.

A replacement document is a new version of the parent document. The parent document is considered superseded, but a system may retain it for historical or auditing purposes. The parent document being replaced is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "RPLC" (for "replaces"). An example is a report found to contain an error that is subsequently replaced by the corrected report.

An addendum is a separate document that references the parent document, and may extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients. The parent report (represented by the ParentDocument class) being appended is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "APND" (for "appends").

Every CDA document must have a unique ClinicalDocument.id, and thus the replacement or addendum documents each have ClinicalDocument.id that is different from that of the parent document.

CDA documents may also contain a ClinicalDocument.setId and a ClinicalDocument.versionNumber, which together support a document identification and versioning scheme used in some document management systems. In this scheme, all documents in a chain of replacements have the same ClinicalDocument.setId and are distinguished by an incrementing ClinicalDocument.versionNumber. The initial version of a document gets, in addition to a new unique value for ClinicalDocument.id, a new value for ClinicalDocument.setId, and has the value of ClinicalDocument.versionNumber set to equal "1". A replacement document gets a new globally unique ClinicalDocument.id value, and uses the same value for ClinicalDocument.setId as the parent report being replaced, and increments the value of ClinicalDocument.versionNumber by 1. (Note that version number must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.)

These relationships are illustrated in the following exhibit "Document Identification, Revisions, and Addenda Scenarios". Typical scenarios are a simple relacement (e.g. ClinicalDocument.id "1.2.345.6789.266" replacing ClinicalDocument.id "1.2.345.6789.123") and a simple append (e.g. ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123"). More complex scenarios that might be anticipated include: [1] replacement of an addendum (e.g. ClinicalDocument.id "1.2.345.6789.224" replaces ClinicalDocument.id "1.2.345.6789.456", which itself is an addendum to ClinicalDocument.id "1.2.345.6789.123") - expected behavior would be to render the replacement as the addendum (e.g. render ClinicalDocument.id "1.2.345.6789.224" as the addendum to ClinicalDocument.id "1.2.345.6789.123"); [2] addendum to a replaced document (e.g. ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123", which has been replaced by ClinicalDocument.id "1.2.345.6789.266") - expected behavior would be to render the addendum along with the replacement (e.g. render ClinicalDocument.id "1.2.345.6789.456" as an addendum to ClinicalDocument.id "1.2.345.6789.266").

Document transformations

A CDA document can be a transformation from some other format, meaning that it has undergone a machine translation from some other format (such as DICOM SR). In this case, relatedDocument.typeCode should be set to "XFRM".

A proper transformation must ensure that the human readable clinical content of the report is not impacted. Local business rules determine whether or not a transformed report replaces the source, but typically this would not be the case. If it is, an additional relationship of type "RPLC" is to be used. The "XFRM" relationship can also be used when translating a document in a local format into CDA for the purpose of exchange. In this case, the target of the "XFRM" relationship is the local document identifier.

Link to wide graphic (opens in a new window)

4.1.3.2 ServiceEvent

This class represents the main Act, such as a colonoscopy or an appendectomy, being documented.

In some cases, the ServiceEvent is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "History and Physical Report" and the procedure being documented is a "History and Physical" act. A ServiceEvent can further specialize the act inherent in the ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Procedure Report" and the procedure was a "colonoscopy". If ServiceEvent is included, it must be equivalent to or further specialize the value inherent in the ClinicalDocument.code, and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the encounter surrounding the event) took place.

Table X: Value set for documentationOf.typeCode (CNE)

Code	Definition
DOC (documents) [default]	The current document is a documentation of the related ServiceEvent.

Table X: Value set for ServiceEvent.classCode (CNE)

Code	Definition
ACT (act) [default]	A healthcare service.
Any ACT subtype	See vocabulary domain "ActClassRoot" for allowable values.

Table X: Value set for ServiceEvent.moodCode (CNE)

Code	Definition
EVN (event) [default]	An actual occurrence of an event.

The performer participant represents clinicians who actually and principally carry out the ServiceEvent. Performer.time can be used to specify the time during which the performer is involved in the activity. Performer.functionCode can be used to specify addition detail about the function of the performer (e.g. scrub nurse, third assistant). Its value set is drawn from the ParticipationFunction vocabulary domain, and has a CWE coding strength.

Table X: Value set for performer.typeCode (CNE)

Code	Definition
PRF (performer)	A person who actually and principally carries out an action.
PPRF (primary performer)	The principal performer of the ServiceEvent.
SPRF (secondary performer)	A person assisting in the ServiceEvent through their substantial presence and involvement. This may include assistants, technicians, associates, or other performers.

A performer is an entity in the role of assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

4.1.3.3 Order

This class represents those orders that are fulfilled by this document. For instance, a provider orders an X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order identifier is transmitted in the Order class, the performed X-Ray procedure is transmitted in the ServiceEvent class, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".

Table X: Value set for InFulfillmentOf.typeCode (CNE)

Code	Definition
FLFS (fulfills) [default]	The current document fulfills the order stated in ActOrder.

Table X: Value set for Order.classCode (CNE)

Code	Definition
ACT (act) [default]	A healthcare service.
Any ACT subtype	See vocabulary domain "ActClassRoot" for allowable values.

Table X: Value set for Order.moodCode (CNE)

Code	Definition
RQO (request) [default]	A request or order to perform the stated act.

4.1.3.4 Consent

This class references the consents associated with this document. The type of consent (e.g. a consent to perform the related ServiceEvent, a consent for the information contained in the document to be released to a third party) is conveyed in Consent.code. Consents referenced in the CDA Header have been finalized (Consent.statusCode must equal "completed") and should be on file.

Table X: Value set for authorization.typeCode (CNE)

Code	Definition
AUTH (authorized by) [default]	The consent authorizes or certifies acts specified in the current document.

Table X: Value set for Consent.classCode (CNE)

Code	Definition
CONS (consent) [default]	The Consent class represents informed consents and medico-legal transactions.

Table X: Value set for Consent.moodCode (CNE)

Code	Definition
EVN (event) [default]	An actual occurrence of an event.

Table X: Value set for Consent.statusCode (CNE)

Code	Definition
completed	The consent being referenced by the CDA document has been finalized and is on file.

4.1.3.5 EncompassingEncounter

This optional class represents the setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred. Documents are not necessarily generated during an encounter, such as when a clinician, in response to an abnormal lab result, attempts to contact the patient but can't, and writes a Progress Note.

In some cases, the setting of the encounter is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Diabetes Clinic Progress Note". The setting of an encounter can also be transmitted in the HealthCareFacility.code attribute. If HealthCareFacility.code is sent, it should be equivalent to or further specialize the value inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Clinic Progress Note" and the value of HealthCareFacility.code is "cardiology clinic"), and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).

Table X: Value set for componentOf.typeCode (CNE)

Code	Definition
COMP (component) [default]	The current document is a documentation of events that occurred during the EncompassingEncounter.

Table X: Value set for EncompassingEncounter.classCode (CNE)

Code	Definition
ENC (encounter) [default]	An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient.

Table X: Value set for EncompassingEncounter.moodCode (CNE)

Code	Definition
EVN (event) [default]	An actual occurrence of an event.

The location participant (location class) relates a healthcare facility (HealthCareFacility class) to the encounter to indicate where the encounter took place. The entity playing the role of HealthCareFacility is a place (Place class). The entity scoping the HealthCareFacility role is an organization (Organization class).

The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. Note that setting and physical location are not the same. There is a many-to-many relationship between setting and the physical location where care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.

When the location is an organization, this is indicated by the presence of a scoping Organization, without a playing Place.

Table X: Value set for location.typeCode (CNE)

Code	Definition
LOC (location) [default]	The location where the service is done. May be a static building (or room therein) or a moving location (e.g., ambulance, helicopter, aircraft, train, truck, ship, etc.)

Table X: Value set for HealthCareFacility.classCode (CNE)

Code	Definition
SDLOC (service delivery location) [default]	A role played by a place at which services may be provided.
Any SDLOC (RoleClassServiceDeliveryLocation) subtype	See vocabulary domain "RollClassServiceDeliveryLocation" for allowable values.

The responsibleParty participant represents the participant having primary legal responsibility for the encounter. This differs from the legalAuthenticator participant in that the legalAuthenticator may or may not be the responsible party, and is serving a medical records function by signing off on the document, moving it into a completed state.

Table X: Value set for responsibleParty.typeCode (CNE)

Code	Definition
RESP (responsible party) [default]	The provider (person or organization) who has primary responsibility for the encounter. The responsible provider is not necessarily present in an encounter, but is accountable for the action through the power to delegate, and the duty to review actions with the performing participant.

A responsibleParty is a person or organization in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

When the responsible party is an organization, the value for AssignedEntity.classCode is "ASSIGNED", and the responsible party is reflected by the presence of a scoping Organization, without a playing entity.

The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).

Table X: Value set for encounterParticipant.typeCode (CNE)

Code	Definition
ADM (admitter)	The practitioner who admits a patient to a hospital stay.
ATND (attender)	The primary practitioner that oversees a patient's care during an encounter.
CONS (consultant)	An advising practioner participating in the encounter by performing evaluations and making recommendations.
DIS (discharger)	The practitioner who discharges a patient from a hospital stay.
REF (referrer)	A person having referred the patient for services resulting in the encounter.

An encounterParticipant is an entity in the role of assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

4.2 Body

(content on separate page)

5 CDA Hierarchical Description

(content on separate page)

6 CDA XML Implementation

(content on separate page)

7 Appendix

(content on separate page)