Mapping working example
Manually mapping hundreds of fields and values can be extremely laborious and prone to error.
Mapping suggestion algorithms offer machine assisted hints to manually selected mappings.
The algorithms work by starting with a context provided by the application, and via a series of iterations, narrow down the options to a small number. The algorithms are further tuned for specific patterns found in some source fields and values, and perhaps some authoring conventions when the target concepts were created.
In some cases, confidence levels are high enough to assume a single match (equivalent class axiom) and in this case it would be expected that a user validated a mapping once matched
Requesting a map via the IM mapping API
Take the following working example. In this example the client has requested information model maps for some source data. In addition the client has asked for the mapping information to the target schema. This could either be used to inform coding or to auto generate mapping code, or a combination of both.
{"Mapping": {
"Source": {
"Provider": "Barts",
"System": "CernerMillenium",
"Context": {
"id": 1,
"Table": "APC",
"Field": "PATIENT_CLASSIFICATION_CODE",
"Value": 1}},
"SchemaRequest":"Compass_Version1"}}
The context provided consists of the fact that it is Barts hospital, Cerner Millenum system, and that a file has been provided that is loaded int a Table "admitted patient care (APC)" for the purposes of further analysis. This file is a CDS file documented on the NHS Data Dictionary web site. A field with a value of 1 needs to be mapped. Until the mapping author has mapped the value, the field and value will remain as a generic extension.
There are a number of stages involved in the information model mapping server.
Mapping to the information model entities
The mapping author knows that the likely entity in the data model would be an Encounter, and on further examination a number of specialised encounter types are available for selection. In particular a hospital inpatient stay.
On further examination of the model it appears that the hospital in patient stay has a sub-component for a hospital admission entry. This appears to be a better fit.
From the NHS data dictionary specification it appears that the field "Patient classification code" is part of the admission of the patient, which is a sub encounter of the in patient encounter.
Examining the admission encounter model further reveals a property of "admission classification of patient", which has a value range that includes 'ordinary admission' which has a comment suggesting that this matches to CDS code 1 for that field.
Its beginning to look like 2 entities are involved in the model, one of which is a subcomponent of the other. There is therefore a dependency between a sub component and its container component.
In fact the mapping author did not need to know this. The M server algorithm detects the sub component dependency because the data model also includes a property of ":RM_isComponentOf", which is a subproperty of the 'dependent relationship property'.
This means that the target class is dependent on the presence of another class. This information is added by the IM mapping server also.
Consequently by simply selecting the relevant mapped field value, the following response can be generated.
{ "IMTarget": {
"Fromid": 1,
"Class": ":CM_HospitalInpAdmitEncounter",
"DependentClass": {
"Relationship": ":RM_isComponentOf",
"Class": ":DM_HospitalInpEntry"
},
"PropertyValue": {
"Property": {
"iri": ":DM_admissionPatientClassification"
},
"Value": {
"iri": ":CM_AdmClassOrdinary"
}
}
}
}
At this point, the IM server knows a fair bit about this source i.e. the table will map probably to an encounter subtype of admission and the field maps to the IM property and value and in addition there is a dependency derived from the ontology.
Nevertheless, the inbound transformer wants to go one step further and populate the actual implementation schema. Hence they used the "schema request field".
Mapping from the information model to the target schema
The mapping author has already created the IM schema map. In this case encounter subclasses all map to the table encounter and and the encounter table has an extension table - 'encounter extension', and using the entity subtype attribute method assigns the 'admission encounter' type as a value of the encounter "type" field.
The admission encounter type had previously been mapped also to encounter type but is there is a dependency in the information model between the admission and the inpatient encounter, the dependency field had also been mapped.
Thus additional information can now be added to the mapping response.
DB Target response added
{ "DBTarget": {
"Fromid": 1,
"DependentTable": {
"Relationship": "encounter_id",
"Table": {
"DependentTable": {
"Relationship": "parent_encounter",
"Table": {
"Table": "encounter",
"DependentField": {
"Field": "type",
"Value": "DM_HospitalInpEntry"}}},
"Table": "encounter",
"DependentField": {
"Field": "type",
"Value": "CM_HospitalInpAdmitEncounter" } } },
"Table": "Encoounter_extension",
"FieldValue": [
{
"Field": "property",
"Value": "DM_admissionPatientClassification"
},
{
"Field": "value",
"Value": "CM_AdmClassOrdinary" }]}}}}