Chapter 7 Mapping from an existing relational EPR database to the HL7 CDA
7.3 Methodology for mapping
There are 4 main steps involved in the mapping methodology which is outlined below. Methodology for mapping a relational EPR physical data model to the CDA
Standard
Step 1 Define Requirements and Use Cases for semantic interoperability
Step 1.1 Establish a stakeholder group to include clinical, domain experts and technical personnel.
Step 1.2 Define business requirements or examine existing business requirements regarding interoperability.
Step 1.3 Refine the business requirements to include business rules where required. Step 1.4 Develop user requirements from the business requirements.
Step 1.5 Define use cases and scenarios based on the user requirements. Based on the use case defined, a corresponding CDA document is identified e.g. a CDA Referral, Discharge Summary document.
139
Step 2 Identify appropriate CDA Implementation Guide (IG)
Step 2.1 Analyse CDA implementation guides in order to select the most suitable one to use. A CDA implementation guide needs to satisfy the use case and align with the business and user requirements that were identified in Step 1. This step involves input from the stakeholder group including domain and technical experts.
Step 2.2 Examine the CDA implementation guide to assess the alignment with overall requirements. This involves the stakeholder group deciding on what is in scope or out of scope. The type of decisions that need to be made are outlined in the following sub-steps:
Step 2.2.1 Decide on IDs - this involves identifying the OIDS required to identify clinical documents
Step 2.2.2 Decide on CDA Levels: CDA can be defined with three different levels (1 to 3) and the richness of the data increases, starting with lowest level 1 to highest 3.
Step 2.2.3 Decide on the terminology or classification systems and code sets that best suit the use case.
Step 2.2.4 Identify each mandatory element of the CDA header. Decide on CDA optional header elements – optional elements are not required but it is best practise to use these elements if a suitable mapping candidate is identified at the mapping stage in step 4 below.
Step 2.2.5 Review the mandatory sections and decide on the optional sections of the CDA body. This includes the required section level templates and the optional entry level templates.
Step 2.2.6 Examine the CDA RMIM model concepts including classes, class attributes and associations.
Step 3 Identify existing Relational EPR Database Extract
Step 3.1 Select the appropriate existing relational EPR database (extracts which match the CDA IG requirements and scope decided upon in Step 2.2 (such as demographics and medication tables)
Step 3.2 Derive a logical data model and physical data model from the selected database. The scope of each data model is driven by the scope of the CDA IG identified in step 3.
Step 3.3 Derive a data dictionary from the selected database model which provides a comprehensive record of all fields in the database. The data dictionary should contain the field name, field size, data type, data format, description and example for every field which in each table defined in the physical data model.
140
Step 4 Perform mapping from a relational EPR physical data model to a CDA IG schema
Step 4.1 Map using a table-by-table approach from tables in the relational EPR database to the RMIM class attributes.(225)
Step 4.2 Establish mappings using the matching techniques outline in section 6.6: Step 4.2.1 Perform Exact matching-For example, if the table field patient name is defined as nameand if a class attribute patient name found is name then this will be the an exact match .(214)
Step 4.2.2 Perform Pattern matching-For example the pattern match “gender” is used to match PATIENT_DEMOGRAPHIC table field “gender” to the CDA PATIENTROLE class attribute “administativeGenderCode”.
Step 4.2.3 Perform Structure-based matching-For example the PATIENT_DEMOGRAPHIC table has a field called “dateOfBirth” and the CDA PATIENT class has an attribute called “birthtime”. The structure similarities of the database field “dateOfBirth” (Patient demographic table) and the CDA class field “birthtime” (patient/birthtime) indicate the same thing which is a patient’s date of birth.
Step 4.2.4 Perform Synonym matching-For example the
PATIENT_DEMOGRAPHIC table field “title” can be matched to the PATIENT class attribute “prefix” because both are synonymous.
Step 4.2.5 Perform Variation matching – this technique is applicable to person name as person naming conventions vary in different parts of the world. Once the table PATIENT_DEMOGRPAHIC person name fields are identified each name field can be mapped to the associated HL7 standard person name parts (e.g. “family name”, “given name”, “prefix”).
Step 4.2.6 Perform Constraint matching – this technique is applicable to complex data types like demographic address data type (AD) which contain multiple address part components such as “streetAddressLine”, “city” and “country”. These address parts can be mapped from the database address data
141
type (VARCHAR). In addition this technique can also apply the HL7 nullFlavor value set for matches which may contain nulls.
Step 4.3 Map codes from clinical classifications or terminology systems in the source system to the clinical classifications or terminology systems
Step 4.4 Represent mappings from steps 4.1 to 4.3 in a mapping table and use the headings and rows as illustrated in table 7-1 below.
Table 7-1 Example of the Mapping Table and Headings
The headings in the mapping table have three sections:
Source Database Heading: The headings describe the matching criteria of the mapping source which is the physical database model. The headings are
database table, field and data type.
Destination RMIM Heading: The headings describe the mapping criteria of the destination including the RMIM element path (using an example from the epSOS IG XPATH), RMIM class, Optionality of each element, Cardinality of each element and Data Type.
Source Database Headings Destination CDA IG (RMIM) Headings Matching Outcome Database
Field DB Data Type Database Table IG Schema XPath (example epSOS IG) CDA RMIM Class
Optionality /Cardinalit y
Data
Type Matched Inconsistency
LastName varchar Patient_ Demogra phic
recordTarget/patientRol
e/patient/name/family Patient R/[1..*] PN TRUE FALSE
Title varchar Patient_
Demogra phic
recordTarget/patientRol
e/patient/name/prefix/ Patient O/[0..*] PN TRUE FALSE
FirstName varchar Patient_ Demogra phic
recordTarget/patientRol
e/patient/name/given Patient R/[1..*] PN TRUE FALSE
Gender varchar Patient_
Demogra phic recordTarget/patientRol e/patient/administrative GenderCode Patient R, use nullFlavour/ [1..1] CE TRUE FALSE
142
Mapping Outcome Heading: The mapping outcome is either TRUE (represents a match) or FALSE (highlighting an inconsistency). The ‘Matched’ heading
indicates if a match between the source and destination criteria was successful. The ‘Inconsistency’ heading indicates if the destination RMIM class attributes have a mapping inconsistency.