Mapping working example - Revision history

DavidStables: /* Mapping from the information model to the target schema */

2020-05-27T13:53:43Z

Mapping from the information model to the target schema

← Older revision		Revision as of 13:53, 27 May 2020
Line 115:		Line 115:
	"Value": "CM_AdmClassOrdinary" }]}}}} //This is the code to be placed in the value field of the extension table		"Value": "CM_AdmClassOrdinary" }]}}}} //This is the code to be placed in the value field of the extension table
	</syntaxhighlight>		</syntaxhighlight>

	~~</div>>/div>~~
	~~<br />~~

DavidStables: /* Mapping from the information model to the target schema */

2020-05-27T13:53:23Z

Mapping from the information model to the target schema

← Older revision		Revision as of 13:53, 27 May 2020
Line 88:		Line 88:
	Thus additional information can now be added to the mapping response.		Thus additional information can now be added to the mapping response.

	~~<br />~~
	~~<div class="toccolours mw-collapsible mw-collapsed">~~
	~~DB Target response added~~
	~~<div class="mw-collapsible-content">~~
	<syntaxhighlight lang="json">		<syntaxhighlight lang="json">
	{ "DBTarget": {		{ "DBTarget": {
	"Fromid": 1,		"Fromid": 1,
	"~~DependentTable~~": {		"DependentRelationship": {
	"Relationship": "encounter_id",		"Relationship": "encounter_id", the entry is dependent on the existence of the encounter table (i.e. the admission encounter)
	"Table": {		"Table": {
	"~~DependentTable~~": {		"DependentRelationship": {
	"Relationship": "parent_encounter",		"Relationship": "parent_encounter", //the encounter table is also dependent on its parent encounter (i.e. the inpatient stay encounter)
	"Table": {		"Table": {
	"Table": "encounter",		"Table": "encounter",
	"DependentField": {		"DependentField": { //Not only should the inpatient stay encounter exist it must also be assigned as type "inpatient entry"
	"Field": "type",		"Field": "type",
	"Value": "DM_HospitalInpEntry"}}},		"Value": "DM_HospitalInpEntry"}}},
Line 108:		Line 104:
	"DependentField": {		"DependentField": {
	"Field": "type",		"Field": "type",
	"Value": "CM_HospitalInpAdmitEncounter" } } },		"Value": "CM_HospitalInpAdmitEncounter" } } }, // The encounter must be of type 'Hospital inpatient admission'
	"Table": "Encoounter_extension",		"Table": "Encoounter_extension", // This is the actual table being populated
	"FieldValue": [		"FieldValue": [
	{		{
	"Field": "property",		"Field": "property",
	"Value": "DM_admissionPatientClassification"		"Value": "DM_admissionPatientClassification" //This is the code to be placed in the property field of the extension table
	},		},
	{		{
	"Field": "value",		"Field": "value",
	"Value": "CM_AdmClassOrdinary" }]}}}}		"Value": "CM_AdmClassOrdinary" }]}}}} //This is the code to be placed in the value field of the extension table
	</syntaxhighlight>		</syntaxhighlight>

	</div>>/div>		</div>>/div>
	<br />		<br />

DavidStables: /* Mapping Source to the information model */

2020-05-27T13:48:59Z

Mapping Source to the information model

← Older revision		Revision as of 13:48, 27 May 2020
Line 32:		Line 32:
	However, before considering the algorithms it is worthwhile diverging to look at maps that may have already been created		However, before considering the algorithms it is worthwhile diverging to look at maps that may have already been created

	=== Mapping Source to the information model ===		== Mapping Source to the information model ==
	[[File:Hospital Encounters.png\|thumb\|Hospital encounter ontology]]		[[File:Hospital Encounters.png\|thumb\|Hospital encounter ontology]]

Line 81:		Line 81:
	Nevertheless, the inbound transformer wants to go one step further and populate the actual implementation schema. Hence they used the "schema request field".		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 ===		== Mapping from the information model to the target schema ==
	The mapping author has already created the IM schema map as above and has authored the target DB schema resources. 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 mapping author has already created the IM schema map as above and has authored the target DB schema resources. 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.

DavidStables: /* Mapping Source to the information model */

2020-05-27T13:48:13Z

Mapping Source to the information model

← Older revision		Revision as of 13:48, 27 May 2020
Line 63:		Line 63:
	"Value": "CM_AdmClassOrdinary"}}}		"Value": "CM_AdmClassOrdinary"}}}
	}		}
	</syntaxhighlight>At an even earlier stage to this, the IM author had already generated an IM to DB map for encounters.		</syntaxhighlight>At an even earlier stage to this, the IM author had already generated an IM to DB map for encounters. In addition when the target resource was originally authored, the extension table was authored.<syntaxhighlight lang="json">
			{ "Mapping": [
			{
			"IMSource": {
			"Class": ":DM_EncounterEntry"
			},
			"TargetDBSchema": "Compass_V1",
			"DBTarget": {
			"Table": "encounter",
			"SubTypeField": "type",
			"ExtensionTable": "encounter_extension"}}}
			</syntaxhighlight>
			In other words, the IM data model class :DM_Encounter entry maps to the encounter table for compass version 1 and the encounter table has an extension table (which is dependent on the encounter table for its existence).

			At this point, the IM server knows a fair bit about this source.

	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".		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 ===		=== 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 mapping author has already created the IM schema map as above and has authored the target DB schema resources. 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.		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.		Thus additional information can now be added to the mapping response.

			<br />
	<div class="toccolours mw-collapsible mw-collapsed">		<div class="toccolours mw-collapsible mw-collapsed">
	DB Target response added		DB Target response added

DavidStables: /* Requesting a map via the IM mapping API */

2020-05-27T13:39:28Z

Requesting a map via the IM mapping API

← Older revision		Revision as of 13:39, 27 May 2020
Line 11:		Line 11:

	==Requesting a map via the IM mapping API==		==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. They wish to map directly to the DB schema, although in this case both the IM map and the DB response will be created<syntaxhighlight lang="json">		Take the following working example. In this example the client has requested information model maps for some source data. They wish to map directly to the DB schema, although in this case both the IM map and the DB response will be created
	~~syntaxhighlight lang="JSON~~">		<syntaxhighlight lang="json">
	{"Mapping":[ {		{"Mapping":[ {
	"Request": "SourcetoDB",		"Request": "SourcetoDB",

DavidStables: /* Requesting a map via the IM mapping API */

2020-05-27T13:38:58Z

Requesting a map via the IM mapping API

← Older revision		Revision as of 13:38, 27 May 2020
Line 11:		Line 11:

	==Requesting a map via the IM mapping API==		==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.<syntaxhighlight lang="json">		Take the following working example. In this example the client has requested information model maps for some source data. They wish to map directly to the DB schema, although in this case both the IM map and the DB response will be created<syntaxhighlight lang="json">
	{"Mapping": {		syntaxhighlight lang="JSON">
	"~~Source~~": {		{"Mapping":[ {
	"Provider": "Barts",		"Request": "SourcetoDB",
	"System": "CernerMillenium",		"OriginalSource": {
	"Context": {		"Provider": "Barts",
	"id": 1,		"System": "CernerMillenium",
	"Table": "~~APC~~",		"Context": {
	"Field": "~~PATIENT_CLASSIFICATION_CODE~~",		"id": 1,
	"Value": 1}},		"Table": "AdmittedPatientCare",
	"~~SchemaRequest~~":"~~Compass_Version1~~"}}		"Field": "PatientClassificationCode",
			"Value": 1
			}
			},
			"TargetDBSchema": "Compass_version1" } ] }
	</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. Until the mapping author has mapped the value, the field and value will remain as a generic extension.		</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. 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.		There are a number of stages involved in the information model mapping server.

	=== Mapping to the information model ~~entities~~ ===		However, before considering the algorithms it is worthwhile diverging to look at maps that may have already been created

			=== Mapping Source to the information model ===
	[[File:Hospital Encounters.png\|thumb\|Hospital encounter ontology]]		[[File:Hospital Encounters.png\|thumb\|Hospital encounter ontology]]

			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 appear available for selection. In particular a hospital inpatient stay. Given that the source table is "admitted patient care" this seems a good candidate.
	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.

	[[File:Admission to Inpatient.jpg\|thumb]]		[[File:Admission to Inpatient.jpg\|thumb]]

	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. On further examination of the model it appears that the hospital in patient stay has a sub-component for a 'hospital admission' and 'discharge ' entries. 'Hospital Inpatient Admission appears to be a better fit. [[File:Admission classification.jpg\|thumb]]

	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. Thus this confirms the better match being the admission sub encounter.
	[[File:Admission classification.jpg\|thumb]]

	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.

	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.		However, the admission encounter has a property of "is subcomponent of" another encounter, specifically the inpatient stay. 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'.		In fact the mapping author did not need to know this. The IM mapping algorithm detects the 'sub component' dependency because the data model includes a property of ":RM_isComponentOf", which is a subproperty of the 'dependent relationship property'. it knows it is going to generate a dependant class

	This means that the target class is dependent on the presence of another class. This information is added by the IM mapping server also.		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.~~		The mapping author then selects the appropriate property and value. Consequently by simply selecting the relevant mapped field value the mapping is stored. The API could generate the following response had the client been interested in the IM target

	<syntaxhighlight lang="json">		<syntaxhighlight lang="json">
Line 53:		Line 55:
	"Fromid": 1,		"Fromid": 1,
	"Class": ":CM_HospitalInpAdmitEncounter",		"Class": ":CM_HospitalInpAdmitEncounter",
	"~~DependentClass~~": {		"DependentRelationship": {
	"Relationship": ":RM_isComponentOf",		"Relationship": ":RM_isComponentOf",
	"Class": ":DM_HospitalInpEntry"		"Class": ":DM_HospitalInpEntry"
	},		},
	"PropertyValue": {		"PropertyValue": {
	"Property~~": {~~		"Property": ":DM_admissionPatientClassification",
	~~"iri~~": ":DM_admissionPatientClassification"		"Value": "CM_AdmClassOrdinary"}}}
	},
	"Value~~": {~~
	~~"iri~~": ":CM_AdmClassOrdinary"
	}
	}
	}
	}		}
	</syntaxhighlight>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.		</syntaxhighlight>At an even earlier stage to this, the IM author had already generated an IM to DB map for encounters.



			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".		Nevertheless, the inbound transformer wants to go one step further and populate the actual implementation schema. Hence they used the "schema request field".

DavidStables at 13:27, 27 May 2020

2020-05-27T13:27:31Z

← Older revision		Revision as of 13:27, 27 May 2020
Line 1:		Line 1:
	Manually mapping hundreds of fields and values can be extremely laborious and prone to error.		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~~.		A mapping API ensures that previously mapped resources can be repeated. Using the API achieves one of two things:

	~~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.~~		# Generates mapping information from maps already authored
			# Creation of a mapping task for future re-mapping when authored

	~~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~~		The mapping algorithms work by starting with a context provided by the application, and via a series of iterations, produce a map if present. 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.

			<br />

	==Requesting a map via the IM mapping API==		==Requesting a map via the IM mapping API==

DavidStables: DavidStables moved page Mapping hint algorithms to Mapping working example

2020-05-27T12:59:47Z

DavidStables moved page Mapping hint algorithms to Mapping working example

← Older revision	Revision as of 12:59, 27 May 2020
(No difference)

DavidStables: /* Mapping to the information model entities */

2020-05-26T22:19:53Z

Mapping to the information model entities

← Older revision		Revision as of 22:19, 26 May 2020
Line 33:		Line 33:
	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.		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.		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. Thus this confirms the better match being the admission sub encounter.
	[[File:Admission classification.jpg\|thumb]]		[[File:Admission classification.jpg\|thumb]]

DavidStables at 22:17, 26 May 2020

2020-05-26T22:17:39Z

← Older revision		Revision as of 22:17, 26 May 2020
Line 24:		Line 24:

	=== Mapping to the information model entities ===		=== Mapping to the information model entities ===
			[[File:Hospital Encounters.png\|thumb\|Hospital encounter ontology]]

	~~[[File:Admission classification.jpg\|thumb]]~~

	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.		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.
Line 34:		Line 34:

	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.		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.
			[[File:Admission classification.jpg\|thumb]]

	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.