Mapping working example: Difference between revisions

From Discovery Data Service
Jump to navigation Jump to search
Line 8: Line 8:


=Table and field hints=
=Table and field hints=
Take the following working example
Take the following working example of a submission to the Information model mapping server as part of an inbound transform from a hospital admitted patient care table to the common model and onward to an implementation schema:
<syntaxhighlight lang="json">
<syntaxhighlight lang="json">
{"Mapping": {
{"Mapping": {
Line 16: Line 16:
         "Context": {
         "Context": {
           "id": 1,
           "id": 1,
           "Table": "AdmittedPatientCare",
           "Table": "APC",
           "Field": "PatientClassificationCode",
           "Field": "PATIENT_CLASSIFICATION_CODE",
           "Value": 1}}}}}
           "Value": 1}}}}}
</syntaxhighlight>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" for the purposes of further analysis. This is documented on the NHS Data Dictionary web site.  A field with a value of 1 needs to be mapped.
</syntaxhighlight>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.
[[File:Hospital Encounters.png|thumb]]
[[File:Hospital Encounters.png|thumb]]
At the start, the mapping knowledge base has no knowledge of the nature of the table and thus a user would be presented with the data model.  
At the start, the mapping knowledge base has no knowledge of the nature of the table and thus a mapping author would be presented with the data model.  


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 in patient stay.
The 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 in patient stay. (See right for encounter ontology).


On further examination of the model it appears that the hospital in patient stay has a sub-component for a hospital admission entry
On further examination of the model it appears that the hospital in patient stay has a sub-component for a hospital admission entry.
[[File:Admission to Inpatient.jpg|left|thumb]]
[[File:Admission to Inpatient.jpg|left|thumb]]


Its beginning to look like 2 entities are involved in the model. 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.
Its beginning to look like 2 entities are involved in the model. 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.


 
So far, no information has been provided to the application to help context. However, a picture is building up.
[[File:Admission classification.jpg|thumb]]
[[File:Admission classification.jpg|thumb]]
So far, no information has been provided to the application to help context. However, a picture is building up.


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.
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.

Revision as of 13:21, 26 May 2020

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

Table and field hints

Take the following working example of a submission to the Information model mapping server as part of an inbound transform from a hospital admitted patient care table to the common model and onward to an implementation schema:

{"Mapping": {
      "Source": {
        "Provider": "Barts",
        "System": "CernerMillenium",
        "Context": {
          "id": 1,
          "Table": "APC",
          "Field": "PATIENT_CLASSIFICATION_CODE",
          "Value": 1}}}}}

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.

Hospital Encounters.png

At the start, the mapping knowledge base has no knowledge of the nature of the table and thus a mapping author would be presented with the data model.

The 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 in patient stay. (See right for encounter ontology).

On further examination of the model it appears that the hospital in patient stay has a sub-component for a hospital admission entry.

Admission to Inpatient.jpg

Its beginning to look like 2 entities are involved in the model. 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.

So far, no information has been provided to the application to help context. However, a picture is building up.

Admission classification.jpg

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.

The mapping author then selects this resulting in the following

"Target": {
        "Provider": "Barts",
        "System": "CernerMillenium",
        "Context": {
          "id": 1,
          "Table": "AdmittedPatientCare",
          "Field": "PatientClassificationCode",
          "Value": 1
        }
      }