Clinical Document Architecture ﴾CDA﴿
Clinical Document Architecture ﴾CDA﴿ is one of the HL7 standards designed to standardize the structure and ensure semantic compatibility of medical systems when exchanging medical information and / or medical documents. The first version of the standard was approved by ANSI back in 2001. The second version, which is still in use today, was approved by ANSI in 2005. The third version, CDA R3, is under development and approval.
CDA R2 (Release 2) guarantees the presence of the following seven characteristics in a CDA document:
• Preservation of the information provided;
• Management of the information provided;
• Support for authentication requirements for all information provided;
• Support for the context of the information provided;
• Support for the integrity of information;
• The ability to read the information provided by a person;
• Support for binary information, such as multimedia components, PDFs, images and more.
Such characteristics make CDA extremely flexible for use in various fields. And even though CDA is considered an extremely difficult standard among developers, it has become one of the most successful HL7 developed for integrating honey data and is consistent with the requirements of the US Meaningful Use 1 and 2. Most medical systems currently encode information in one of nine possible CDA document templates, such as the Continuity of Care Document (CCD) one of these templates.
This article provides an overview or simplified description of the main components of CDA. And so, like any document, CDA contains the title of the document (CDA Header) and the body of the document (CDA Body).
As shown in the following picture, some administrative information based on the classes and entities of the RIM model HL7 is included in the CDA header.
The main class in the CDA title is called the Clinical Document, and, in accordance with its name, contains, among other things, information for identifying the document, title, language used, version, publication date, and privacy level. Next, consider the purpose of some of the above classes. To avoid confusion, class names will be given in their English transcription.
This class is included in the document to identify the person and / or organization that can be used to authenticate the entire contents of the CDA document.
Everything is simple here, in the document header recipient is used to identify the recipient (person and / or organization) of the document and may include data such as name, address and other information. There can be many recipients.
In this class, information is encoded to identify and verify the person or device, as well as the organization of their representatives, who are responsible for the data in the CDA document.
The data class is used to identify and verify the organization responsible for the safety of the document. Such an organization is responsible for the safety of all data in the document (for the entire document).
This class encodes information about the person and / or organization that placed the data in the medical system, on the basis of which the document was created. A similar person may be, for example, Data Entry clerk.
Because a CDA document may be part of another CDA document, such information should be provided somewhere. In this class, information about the relationships between two or more documents is encoded.
Using this class, the title of the CDA document provides information about the main participant in all events - the patient. Name, address, guardians and all other information for the complete identification of the patient. It is worth noting that some types of data are prohibited in some countries. For example, information on racial and religious affiliation is required in the United States, but not valid in Europe.
A document body or CDA Body can be either unstructured for data that is not encoded in XML, or structured for data presented in XML format. The concept of semantic compatibility levels of CDA is closely related to the features of such coding (this article is not considered).
The description below will also use the English names of the components or classes.
An unstructured document body may contain only one attachment with a link to data outside this CDA document, or Base64 encoded binary attachment (PDF, image, audio, video, etc.).
The structured body of the document is designed as an extremely flexible mechanism for incorporating a variety of clinical and administrative data. This is what makes CDA so powerful conceptually that theoretically it can be used to encode a patient’s entire medical history, no matter how difficult it is. The flip side of this flexibility is the complexity of implementing all the available features of the standard. One of the reasons for this is the incorrect or incomplete understanding of the standard itself by various organizations.
To resolve this disagreement, CDA document templates were invented. Creating templates and various developer guides is aimed at simplifying the implementation and limiting the misunderstandings of the standard for the same clinical areas. These include Clinical Notes, CCD, Discharge Summary, and more). All of them are presented on the official website of HL7. In addition, there are about 70 section templates and even more recording templates.
As shown in the figure above, a structured document body may contain one or more sections, each of which may contain honey or administrative information, as well as attachments. At the same time, the CDA standard itself does not say anything how to establish relationships between such data; for this, you need to refer to the numerous developer guides available on the official HL7 website or developed by each organization separately.
CDA R2 (Release 2) guarantees the presence of the following seven characteristics in a CDA document:
• Preservation of the information provided;
• Management of the information provided;
• Support for authentication requirements for all information provided;
• Support for the context of the information provided;
• Support for the integrity of information;
• The ability to read the information provided by a person;
• Support for binary information, such as multimedia components, PDFs, images and more.
Such characteristics make CDA extremely flexible for use in various fields. And even though CDA is considered an extremely difficult standard among developers, it has become one of the most successful HL7 developed for integrating honey data and is consistent with the requirements of the US Meaningful Use 1 and 2. Most medical systems currently encode information in one of nine possible CDA document templates, such as the Continuity of Care Document (CCD) one of these templates.
This article provides an overview or simplified description of the main components of CDA. And so, like any document, CDA contains the title of the document (CDA Header) and the body of the document (CDA Body).
CDA Header
As shown in the following picture, some administrative information based on the classes and entities of the RIM model HL7 is included in the CDA header.
The main class in the CDA title is called the Clinical Document, and, in accordance with its name, contains, among other things, information for identifying the document, title, language used, version, publication date, and privacy level. Next, consider the purpose of some of the above classes. To avoid confusion, class names will be given in their English transcription.
Authenticator
This class is included in the document to identify the person and / or organization that can be used to authenticate the entire contents of the CDA document.
Recipient
Everything is simple here, in the document header recipient is used to identify the recipient (person and / or organization) of the document and may include data such as name, address and other information. There can be many recipients.
Author
In this class, information is encoded to identify and verify the person or device, as well as the organization of their representatives, who are responsible for the data in the CDA document.
Custodian
The data class is used to identify and verify the organization responsible for the safety of the document. Such an organization is responsible for the safety of all data in the document (for the entire document).
Source
This class encodes information about the person and / or organization that placed the data in the medical system, on the basis of which the document was created. A similar person may be, for example, Data Entry clerk.
Parent cpa
Because a CDA document may be part of another CDA document, such information should be provided somewhere. In this class, information about the relationships between two or more documents is encoded.
Patient
Using this class, the title of the CDA document provides information about the main participant in all events - the patient. Name, address, guardians and all other information for the complete identification of the patient. It is worth noting that some types of data are prohibited in some countries. For example, information on racial and religious affiliation is required in the United States, but not valid in Europe.
CDA Body
A document body or CDA Body can be either unstructured for data that is not encoded in XML, or structured for data presented in XML format. The concept of semantic compatibility levels of CDA is closely related to the features of such coding (this article is not considered).
The description below will also use the English names of the components or classes.
Non-structured body
An unstructured document body may contain only one attachment with a link to data outside this CDA document, or Base64 encoded binary attachment (PDF, image, audio, video, etc.).
Structured body
The structured body of the document is designed as an extremely flexible mechanism for incorporating a variety of clinical and administrative data. This is what makes CDA so powerful conceptually that theoretically it can be used to encode a patient’s entire medical history, no matter how difficult it is. The flip side of this flexibility is the complexity of implementing all the available features of the standard. One of the reasons for this is the incorrect or incomplete understanding of the standard itself by various organizations.
To resolve this disagreement, CDA document templates were invented. Creating templates and various developer guides is aimed at simplifying the implementation and limiting the misunderstandings of the standard for the same clinical areas. These include Clinical Notes, CCD, Discharge Summary, and more). All of them are presented on the official website of HL7. In addition, there are about 70 section templates and even more recording templates.
As shown in the figure above, a structured document body may contain one or more sections, each of which may contain honey or administrative information, as well as attachments. At the same time, the CDA standard itself does not say anything how to establish relationships between such data; for this, you need to refer to the numerous developer guides available on the official HL7 website or developed by each organization separately.