Description
HL7 Clinical Document Architecture (CDA) schema instances are machine processable because
they are XML documents with Structured body, Coded elements, using HL7 Data Types.
CDA Entry classes are created from RIM Act, Observation, SubstanceAdministration,
Supply, Encounter, Procedure, ObservationMedia, Organizer, and RegionOfInterest.
However, HL7 CDA Documents can have any structure by nesting the Sections
and Entries at any depth and in any way. Furthermore, there can be data elements
that are not defined for CDA but are necessary for local implementations such as
Vaccination, Discharge Method (referral, death or cured), Type of Contagiousness,
etc. in local implementations. Additionally, there is a need for expressing
the CDA concepts in local languages for local implementations.
In creating CDA documents at the Regional or National level, we
propose to start from UN/CEFACT CCTS:
- Define BCCs by using existing HL7 Data Types and Data Elements
- Define the missing data elements by constraining relevant RIM classes
- Then define ACCs (minimum health data sets) by using BCCs
- Hence create a local (or national) data dictionary
- It may be much better if HL7 defines these constructs and the countries customize these according to their context
Building a local or national common data dictionary consisting of data elements (BCCs) and minimum health data sets (ACCs) will
- Clearly define the meaning of data elements
- Give their corresponding explanation in the local language
- Create the additional data elements needed locally from the corresponding RIM Classes
- Also note that defining minimum health data sets as Aggregate Core Components will determine their structure and semantics
- All these will help with the interoperability of CDAs
When these minimum health data sets (ACCs) are mapped to the CDA
Sections, there is not a unique way of doing this. Yet, SET TC
specifications can be used to provide the interoperability
of different CDA schemas.
