The ClinicalDocument class is the entry point into the CDA R-MIM, and corresponds to the <ClinicalDocument> XML element that is the root element of a CDA document. A CDA document is logically broken up into a CDA Header and a CDA Body. The CDA Header is comprised of ClinicalDocument attributes, participants, and act relationships. The CDA Body is the target of the ClinicalDocument component act relationship. The ClinicalDocument class inherits various attributes from the InfrastructureRoot class of the RIM, including ClinicalDocument.templateId and ClinicalDocument.typeId. When ClinicalDocument.templateId is valued in an instance, it signals the imposition of a set of template-defined constraints. In addition, the templateId attribute is available in all other CDA classes, thus enabling the imposition of a set of template-defined constraints at any level of granularity. The value of this attribute provides a unique identifier for the template(s) in question. ClinicalDocument.typeId is a technology-neutral explicit reference to this CDA, Release Two specification, and must be valued as follows: ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension = "POCD_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).
HL7 International - Structured Documents
This is a generated StructureDefinition that describes CDA - that is, CDA as it actually is for R2. The intent of this StructureDefinition is to enable CDA to be a FHIR resource. That enables the FHIR infrastructure - API, conformance, query - to be used directly against CDA
Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type.
If a value is an exceptional value (NULL-value), this specifies in what way and why proper information is missing.
When valued in an instance, this attribute signals the imposition of realm-specific constraints. The value of this attribute identifies the realm in question
ClinicalDocument.typeId is a technology-neutral explicit reference to this CDA, Release Two specification, and must be valued as follows: ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension = "POCD_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).
An II instance must have either a root or an nullFlavor.
A human readable name or mnemonic for the assigning authority. The Assigning Authority Name has no computational value. The purpose of a Assigning Authority Name is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the assigning authority name to be present in any form.
Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).
Identifies the type as an HL7 Registered model
A character string as a unique identifier within the scope of the identifier root.
When valued in an instance, this attribute signals the imposition of a set of template-defined constraints. The value of this attribute provides a unique identifier for the templates in question
Represents the unique instance identifier of a clinical document.
The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note).
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.
The statusCode extension attribute allows the implementer to identify a ClinicalDocument that is in other than the completed state. It was created to support the Structured Form Definition IG to identify that the document itself is an unfinished product currently being completed for a patient.
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.
Controls the disclosure of information in this document
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.
Specifies the human language of character data (whether they be in contents or attribute values).
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.
An identifier that is common across all document revisions
An integer value used to version successive replacement documents
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.
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.
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.
Participant who has transformed a dictated note into text
Person that provides relevant information
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.
Organization that is in charge of maintaining the document
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. 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.
A recipient who should receive a copy of the document
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.
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.
Participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document
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.
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.
Other participants not explicitly mentioned by other classes
Used to represent other participants not explicitly mentioned by other classes, that were somehow involved in the documented acts.
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'.
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.
Source of a document revision, addenda, or transformation
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.
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.
Setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred.
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.