History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Codes representing the defined possible states of an Role, as defined by the Role class state machine.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A criterion or condition over service events that must apply for an associated service to be considered.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A relationship between two people characterizing their "familial" relationship
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Identifies the primary means by which an Entity participates in an Act.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "below normal", "change up", "resistant", "susceptible", etc.
Discussion: These interpretation codes are sometimes called "abnormal flags", however, the judgment of normalcy is just one of the common rough interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy", and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions are never considered "normal."
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:The gender of a person used for adminstrative purposes (as opposed to clinical gender)
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A social or legal structure formed by human beings.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A code that provides additional detail about the means or technique used to ascertain the observation.
Examples: Blood pressure measurement method: arterial puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine position, etc.
Constraints: In all observations the method is already partially specified by the Act.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY still be used to identify this method more clearly in addition to what is implied from the Act.code. However, an information consumer system or process SHOULD NOT depend on this methodCode information for method detail that is implied by the Act.code.
If the methodCode is used to express method detail that is also implied by the Act.code, the methodCode MUST NOT be in conflict with the implied method of the Act.code.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:An agent role in which the agent is an Entity acting in the employ of an organization. The focus is on functional role on behalf of the organization, unlike the Employee role where the focus is on the 'Human Resources' relationship between the employee and the organization.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A value representing the specific kind of Entity the instance represents.
Examples: A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy.
Rationale: For each Entity, the value for this attribute is drawn from one of several coding systems depending on the Entity classCode, such as living subjects (animal and plant taxonomies), chemical substance (e.g., IUPAC code), organizations, insurance company, government agency, hospital, park, lake, syringe, etc. It is possible that Entity.code may be so fine grained that it represents a single instance. An example is the CDC vaccine manufacturer code, modeled as a concept vocabulary, when in fact each concept refers to a single instance.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:This code is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (CWE).
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Contains the names (codes) for each of the states in the state-machine of the RIM Act class.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Codes for the representation of the names of human languages.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Types of personal relationships between two living subjects.
Example: Parent, sibling, unrelated friend, neighbor
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.
Discussion: This attribute is used in orders to indicate the ordered priority, and in event documentation it indicates the actual priority used to perform the act. In definition mood it indicates the available priorities.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Description: An act that is intended to result in new information about a subject. The main difference between Observations and other Acts is that Observations have a value attribute. The code attribute of Observation and the value attribute of Observation must be considered in combination to determine the semantics of the observation.
Discussion:
Structurally, many observations are name-value-pairs, where the Observation.code (inherited from Act) is the name and the Observation.value is the value of the property. Such a construct is also known as a variable (a named feature that can assume a value) hence, the Observation class is always used to hold generic name-value-pairs or variables, even though the variable valuation may not be the result of an elaborate observation method. It may be a simple answer to a question or it may be an assertion or setting of a parameter.
As with all Act statements, Observation statements describe what was done, and in the case of Observations, this includes a description of what was actually observed (results or answers); and those results or answers are part of the observation and not split off into other objects.
The method of action is asserted by the Observation classCode or its subclasses at the least granular level, by the Observation.code attribute value at the medium level of granularity, and by the attribute value of observation.methodCode when a finer level of granularity is required. The method in whole or in part may also appear in the attribute value of Observation.value when using coded data types to express the value of the attribute. Relevant aspects of methodology may also be restated in value when the results themselves imply or state a methodology.
An observation may consist of component observations each having their own Observation.code and Observation.value. In this case, the composite observation may not have an Observation.value for itself. For instance, a white blood cell count consists of the sub-observations for the counts of the various granulocytes, lymphocytes and other normal or abnormal blood cells (e.g., blasts). The overall white blood cell count Observation itself may therefore not have a value by itself (even though it could have one, e.g., the sum total of white blood cells). Thus, as long as an Act is essentially an Act of recognizing and noting information about a subject, it is an Observation, regardless of whether it has a simple value by itself or whether it has sub-observations.
Even though observations are professional acts (see Act) and as such are intentional actions, this does not require that every possible outcome of an observation be pondered in advance of it being actually made. For instance, differential white blood cell counts (WBC) rarely show blasts, but if they do, this is part of the WBC observation even though blasts might not be predefined in the structure of a normal WBC.
Clinical documents commonly have Subjective and Objective findings, both of which are kinds of Observations. In addition, clinical documents commonly contain Assessments, which are also kinds of Observations. Thus, the establishment of a diagnosis is an Observation.
Examples:
Recording the results of a Family History Assessment
Laboratory test and associated result
Physical exam test and associated result
Device temperature
Soil lead level
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A living subject of the species homo sapiens.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:A code specifying the extent to which the Entity playing the participating Role (usually as a target Participation) is aware of the associated Act.
Examples: For diagnostic observations, is the patient, family member or other participant aware of his terminal illness?
Discussion: If the awareness, denial, unconsciousness, etc. is the subject of medical considerations (e.g., part of the problem list), one should use explicit observations in these matters as well, and should not solely rely on this simple attribute in the Participation.
History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26
description:Used to enumerate the relationships between two CDA entries.
The embedding of multimedia content (e.g., a small image of an electrophoresis chart) in a Laboratory Report is consistent with the CDA R2 Standard. The CDA schema allows both embedded multimedia objects and referenced external multimedia objects. However, this content module restrains the use to embedded multimedia objects only. Additionally, the embedded content SHALL be B64 encoded. This is indicated by setting observationMedia/value/representation="B64". This profile supports only small images in gif, jpeg, png or bmp format, which are in most cases, not real pictures but simple graphics, such as an electrophoresis chart, embedded in the report, or an illustration of the test results. The sharing of real images (e.g., a picture taken from a microscope, such as the picture of a kariotype) will be addressed in the future by an extension of the Laboratory Technical Framework.
In accordance with CDA R2, without further constraints.
In accordance with CDA R2, without further constraints.
ID for the reference from the narrative block (<renderMultimedia referencedObject="...ID..."/>)
The embedded content SHALL be B64 encoded. This is indicated by setting observationMedia/value/representation="B64".
Mime type
The CDA schema allows both embedded multimedia objects and referenced external multimedia objects. However, this content module restrains the use to embedded multimedia objects only.
The CDA schema allows both embedded multimedia objects and referenced external multimedia objects. However, this content module restrains the use to embedded multimedia objects only.
| Payer name | Policy type / Coverage type | Covered party ID | Authorization(s) |
|---|---|---|---|
| Good Health Insurance | Extended healthcare / Self | 14d4a520-7aae-11db-9fe1-0800200c9a66 | Colonoscopy |
Any condition or allergy may be the subject of a severity observation. This structure is included in the target act using the <entryRelationship> element defined in the CDA Schema.
This observation is of severity, as indicated by the <code> element listed above. This element is required.
The <observation> element shall contain a <text> element. The <text> element shall contain a <reference> element pointing to the narrative where the severity is recorded,
The code attribute of <statusCode> for all severity observations shall be completed. While the <statusCode> element is required in all acts to record the status of the act, the only sensible value of this element in this context is completed.
Any problem or allergy observation may reference a problem status observation. This structure is included in the target observation using the <entryRelationship> element defined in the CDA Schema. The clinical status observation records information about the current status of the problem or allergy, for example, whether it is active, in remission, resolved, et cetera. The example below shows the recording of clinical status of a condition or allergy, and is used as the context for the following sections.
This observation is of clinical status, as indicated by the <code> element. This element must be present.
The <text> element is required and points to the text describing the problem being recorded; including any dates, comments, et cetera. The <reference> contains a URI in value attribute. This URI points to the free text description of the problem in the document that is being described.
The code attribute of <statusCode> for all clinical status observations shall be completed. While the <statusCode> element is required in all acts to record the status of the act, the only sensible value of this element in this context is completed.
This observation is of health status, as indicated by the <code> element. This element must be present.
The <text> element is required and points to the text describing the problem being recorded; including any dates, comments, et cetera. The <reference> contains a URI in value attribute. This URI points to the free text description of the problem in the document that is being described.
The code attribute of <statusCode> for all clinical status observations shall be completed. While the <statusCode> element is required in all acts to record the status of the act, the only sensible value of this element in this context is completed.
Any condition or allergy may be the subject of a comment.
CDA Documents may reference information contained in other documents. While CDA Release 2.0 supports references in content via the <linkHtml> element, this is insufficient for many EMR systems as the link is assumed to be accessible via a URL, which is often not the case. In order to link an external reference, one needs the document identifier, and access to the clinical system wherein the document resides. For a variety of reasons, it is desirable to refer to the document by its identity, rather than by linking through a URL.
Fortunately, CDA Release 2.0 also provides a mechanism to refer to external documents in an entry, as shown below.
This section makes use of the linking, severity, clinical status and comment content specifications defined elsewhere in the technical framework. In HL7 RIM parlance, observations about a problem, complaint, symptom, finding, diagnosis, or functional limitation of a patient is the event (moodCode='EVN') of observing (<observation classCode='OBS'>) that problem. The <value> of the observation comes from a controlled vocabulary representing such things. The <code> contained within the <observation> describes the method of determination from yet another controlled vocabulary. An example appears below in the figure below.
Parent Template
This template is compatible with the ASTM/HL7 Continuity of Care Document template: 2.16.840.1.113883.10.20.1.28
The basic pattern for reporting a problem uses the CDA <observation> element, setting the classCode='OBS' to represent that this is an observation of a problem, and the moodCode='EVN', to represent that this is an observation that has in fact taken place. The negationInd attribute, if true, specifies that the problem indicated was observed to not have occurred (which is subtly but importantly different from having not been observed).
The value of negationInd should not normally be set to true. Instead, to record that there is "no prior history of chicken pox", one would use a coded value indicated exactly that. However, it is not always possible to record problems in this manner, especially if using a controlled vocabulary that does not supply pre-coordinated negations, or which do not allow the negation to be recorded with post-coordinated coded terminology.
A clinical document normally records only those condition observation events that have been completed, not observations that are in any other state. Therefore, the <statusCode> shall always have code='completed'.
The <originalText> element within the <code> element described above is used as follows: the <value> contains a <reference> to the <originalText> in order to link the coded value to the problem narrative text (minus any dates, comments, et cetera). The <reference> contains a URI in value attribute. This URI points to the free text description of the problem in the document that is being described.
This entry is a specialization of the Concern Entry, wherein the subject of the concern is focused on a problem. Elements shown in the example below in gray are explained in the Concern Entry.
Parent Template
The parent of this template is Concern Entry. This template is compatible with the ASTM/HL7 Continuity of Care Document template: 2.16.840.1.113883.10.20.1.27
This entry has a template identifier of 1.3.6.1.4.1.19376.1.5.3.1.4.5.2, and is a subtype of the Concern Entry, and so must also conform to that specification, with the template identifier of 1.3.6.1.4.1.19376.1.5.3.1.4.5.1. These elements are required and shall be recorded exactly as shown.
Allergies and intolerances are special kinds of problems, and so are also recorded in the CDA <observation> element, with classCode='OBS'. They follow the same pattern as the problem entry, with exceptions noted below.
Parent Template
This is a specialization of the IHE PCC Problem Entry 1.3.6.1.4.1.19376.1.5.3.1.4.5 and of the CCD alert observation template 2.16.840.1.113883.10.20.1.18
General template for multiple use (see ART-DECOR 'Used by Template id' for current usings)
The <text> element provides a way to represent the <reference> to the text of the comment in the narrative portion of the document.
No text here. Use the reference to the narrative portion instead.
The reference to the narrative portion in the format '#xxx' where xxx is the ID of the corresponding <content> element.
The template identifier for a comment is 2.16.840.1.113883.10.20.1.40.
Used to contain comments associated with any of the data within the document. Whereas ASTM CCR enumerates all comments in the CCR Footer, CCD defines the comments within the section where they occur. CDA R2 represents comments as Acts.
CONF-502: A CCD section MAY contain one or more comments, either as a clinical statement or nested under another clinical statement.
CONF-503: A comment (templateId 2.16.840.1.113883.10.20.1.40) SHALL be represented with Act.
CONF-504: The value for “Act / @classCode” in a comment SHALL be “ACT” 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-505: The value for “Act / @moodCode” in a comment SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-506: A comment SHALL contain exactly one Act / code.
CONF-507: The value for “Act / code” in a comment SHALL be 48767-8 “Annotation comment” 2.16.840.1.113883.6.1 LOINC STATIC.
The medication series number observation can be used to indicate which in a series of administrations a particular administration represents (e.g. “hepatitis B vaccine number 2 was administered on Feb 07, 2004).
CONF-338: A medication activity MAY contain exactly one medication series number observations.
CONF-339: The value for “entryRelationship / @typeCode” in a relationship between a medication activity and medication series number observation SHALL be “SUBJ” “Subject” 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-340: A medication series number observation (templateId 2.16.840.1.113883.10.20.1.46) SHALL be represented with Observation.
CONF-341: The value for “Observation / @classCode” in a medication series number observation SHALL be “OBS” 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-342: The value for “Observation / @moodCode” in a medication series number observation SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-343: A medication series number observation SHALL include exactly one Observation / statusCode.
CONF-344: A medication series number observation SHALL contain exactly one Observation / code.
CONF-345: The value for “Observation / code” in a medication series number observation SHALL be “30973-2” “Dose number” 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-346: A medication series number observation SHALL contain exactly one Observation / value.
CONF-347: The data type for “Observation / value” in a medication series number observation SHALL be INT (integer).
CDA Release 2.0 does not provide a mechanism to determine when two participants in different roles are in fact the same entity (i.e., an entity can be a person, organization or device). A CDA Document identifies each participant through the application of a role identifier. This identifier can be used to trace the participation of an entity in a given role, but cannot necessarily be used to determine that two entities are the same. While more role identities could be provided whose intended use is to unify the entities, this is better modeled through the use of an entity identifier. Therefore, to facilitate this capability, this guide defines an extension to CDA Release 2.0 that allows the person or organization playing the role to be uniquely identified, by the inclusion of an identifier on the entity.
An entity identifier opaquely represents the entity referenced in a clinical document. It has no required relationship between the entity and the role that they play in that document. Use of an entity identifier therefore gives CDA producing and consuming applications a mechanism to unite the various entities represented in the CDA document, and thereby expose relationships that would otherwise be obscured when entities cannot be recognized as being identical. When two participants have the same entity identifier, they can be assumed to be the same entity.
In the CDA Release 2.0 schema, organizations and the patient already carry an identifier on the entity, and devices can have only one form of participation (as assignedAuthoringDevice). Therefore, only those elements describing participant persons that are not the patient need to support an element to identify the person. To state it simply, each person that is represented by the CDA document that does not already have an id element may now generate one if necessary using this extension. The identifier MAY be provided in an id element from the urn:hl7-org:sdtc namespace. This element SHALL be an instance identifier (II) and SHALL appear just before name element of any person described by any role in the CDA Release 2.0 schema.
A document that identifies one person in this fashion SHOULD identify all persons in this way, otherwise there will be unidentified persons described by the document, and the utility of this extension will be negated.
Because the patient already supports an identifier element according to the CDA schema, an additional id element is not necessary and SHOULD NOT be provided in the patient element. However, to represent the patient in any other role, the identifier used in the corresponding id element SHOULD be the same as the identifier used to represent the patient.
CONF-537: An assignedPerson, informationRecipient, maintainingPerson, guardianPerson, relatedPerson, associatedPerson or subject
MAY include an id element from the urn:hl7-org:sdtc namespace to uniquely identify the person.
CONF-538: The id element SHALL use the instance identifier (II) data type.
CONF-539: The id element SHALL appear just before the name element of the entity.
CDA Release 2.0 does not provide a mechanism to relate participants other than an informant to the patient. Often useful information, such as the relationship between the patient and the policy subscriber, or the patient and the author, cannot be easily determined by traversal of the CDA document. To facilitate this capability, this guide defines an extension to CDA Release 2.0 which allows the relationship to the patient to be expressed for any participant.
Each participant other than an informant may have zero or more relationship roles with the patient. Each of these roles can be expressed by an asPatientRelationship element which further describes the type of role in a code element. The informant participant already supports specification of the relationship between the informant and the patient via the RelatedEntity class, and therefore should not include this extension.
Figure 16. Example use of the sdtc:asPatientRelationship extension
<ClinicalDocument xmlns='urn:hl7-org:v3' xmlns:sdtc='urn:hl7-org:sdtc'>
...
<author>
<time value='20050329224411+0500'/>
<assignedAuthor>
...
<assignedPerson>
<sdtc:id extension='12345' root='2.16.840.1.113883.3.933'/>
<name>
<prefix>Mrs.</prefix>
<given>Abigail</given>
<family>Ruth</family>
</name>
<sdtc:asPatientRelationship classCode='PRS'>
<code code='65656005' codeSystem='2.16.840.1.113883.6.96'
displayName='Biological mother'/>
</sdtc:asPatientRelationship>
</assignedPerson>
</assignedAuthor>
</author>
...
</ClinicalDocument>
CONF-546: sdtc:asPatientRelationship SHALL contain exactly one sdtc:asPatientRelationship / @classCode, valued with “PRS”. CONF-547: sdtc:asPatientRelationship SHALL contain exactly one sdtc:asPatientRelationship / code, of datatype CE. CONF-548: The value for “sdtc:asPatientRelationship / code” SHOULD be selected from ValueSet 2.16.840.1.113883.1.11.19579 FamilyHistoryRelatedSubjectCode DYNAMIC or 2.16.840.1.113883.1.11.20.21 FamilyHistoryPersonCode DYNAMIC. CONF-549: An informant SHALL NOT contain any relatedPerson / sdtc:asPatientRelationship elements.
Observations about members of the patient's family are recorded in the Family history section. The subject of the observation is the family member. In order to record information about whether this family member is deceased and when, the deceasedInd and deceacedTime extensions have been defined.
CONF-540: A subject
MAY include a deceasedInd element from the urn:hl7-org:sdtc namespace to indicate whether the person is deceased.
CONF-541: The deceasedInd element SHALL be of the Boolean (BL) data type.
CONF-542: The deceasedInd element SHALL appear immediately following the birthTime element.
CONF-543: A subject MAY include a deceasedTime element from the urn:hl7-org:sdtc namespace to indicate when the person died.
CONF-544: The deceasedTime element SHALL be of the Time Stamp (TS) data type.
CONF-545: The deceasedTime element SHALL appear immediately following the deceasedInd element.