Mapping and matching concepts - Revision history

DavidStables at 11:30, 27 September 2021

2021-09-27T11:30:23Z

← Older revision		Revision as of 11:30, 27 September 2021
Line 1:		Line 1:
			== Mapping API ==
			The information model mapping API is used, when given contextual data, to return both a property concept (representing the context) and a value concept (representing the value within that context). The structure of the mapping module allows multiple contexts to reference a common mapping node (for example when the same type of value is received from multiple sources) and also multiple value types to be referenced from a common mapping node.

			The logic of the version 1 live mapping is described more fully in the [[Information Model Mapping (v1)\|model mapping article]].

	== Managing codes and taxonomies ==		== Managing codes and taxonomies ==
	Information consists of ideas. Another word for an idea is a 'concept' . A concept may be named,( in which case the meaning of the concept can usually be understood), or they may be an unnamed expression, which is made up of a set of interrelated named or unnamed concepts.		Information consists of ideas. Another word for an idea is a 'concept' . A concept may be named,( in which case the meaning of the concept can usually be understood), or they may be an unnamed expression, which is made up of a set of interrelated named or unnamed concepts.

DavidStables: /* Legacy codes, terms and term codes */

2021-08-04T14:46:46Z

Legacy codes, terms and term codes

← Older revision		Revision as of 14:46, 4 August 2021
Line 106:		Line 106:
	}		}

	</pre>~~<br />~~		</pre>

			== Enumerated values ==
			The NHS Data dictionary employs enumerated numeric values for many of its field contents.

			These are treated as local codes using the context to create a field specific code scheme. In many cases local trusts have extended the national scheme (or even changed the scheme), and as a result mapping nodes are used for the common codes.

	==Decision process for handling codes and terms==		==Decision process for handling codes and terms==
	When incorporating codes and terms into the ontology, there are 2 categories of approach, the selected approach being dependent on the semantic relationship between the legacy and core concept. The categories are:		When incorporating codes and terms into the ontology, there are 4 categories of approach, the selected approach being dependent on the semantic relationship between the legacy and core concept. The categories are:

	#Creation of a simple "matched to" map between a core concept and a legacy concept. This implies that the legacy concept is a subtype of, or equivalent to the core concept. Examples of these are supplier local codes, Read 2, TPP		#Creation of a local concept and creation of a simple "matched to" map between a core concept and a legacy concept. This implies that the legacy concept is a subtype of, or equivalent to the core concept. Examples of these are supplier local codes, Read 2, TPP
	#Creation of a complex "mapped to" between a core concept and a legacy concept. This implies a more nuanced relationship meaning that the user may elect how to use the maps when querying records.		#Creation of a local or legacy concept and a complex "combination of" + some of or one of "mapped to" between a core concept and a legacy concept. This implies a more nuanced relationship meaning that the user may elect how to use the maps when querying records.
			#Mapping of the local context object to a mapping node which maps to a core concept i.e. the core concept is used throughout the data store and the local context is replaced.
			#Mapping of the local context object to a mapping node which maps to a legacy concept which may or may not map from a core concept

	<br />		<br />

DavidStables at 14:41, 4 August 2021

2021-08-04T14:41:27Z

← Older revision		Revision as of 14:41, 4 August 2021
Line 1:		Line 1:
	== Managing codes and taxonomies ==		== Managing codes and taxonomies ==
	''Main article'' [[Management of code based taxonomies.]] Describes how codes such as EMIS local codes, Read 2, OPCS4 etc are handled in the information model applying the maps as described in this article.

	~~== Concepts - background ==~~
	Information consists of ideas. Another word for an idea is a 'concept' . A concept may be named,( in which case the meaning of the concept can usually be understood), or they may be an unnamed expression, which is made up of a set of interrelated named or unnamed concepts.		Information consists of ideas. Another word for an idea is a 'concept' . A concept may be named,( in which case the meaning of the concept can usually be understood), or they may be an unnamed expression, which is made up of a set of interrelated named or unnamed concepts.

Line 10:		Line 7:

	A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.		A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.

			These types of concepts are referred to as "Core concepts"

	The idea of codes originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.		The idea of codes originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.
Line 15:		Line 14:
	Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.		Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.

	There are two strategies to link ~~codes~~ to concepts.		These types of concepts are referred to as "legacy concepts"

			There are two strategies to link legacy code concepts to core concepts.

	1. A coded term may be stated confidently to be the same as, or a variation on, a concept. Typically code systems like Read2 or CTV3 can be dealt with in this way because they are designed to try and capture the idea in the clinicians mind, and they have been incorporated as concepts anyway. Likewise many system supplier codes have been created in this way. In this case the term code can be said to be a term code of the concept. Read2 G33 - Angina pectoris is a term code for the concept of angina pectoris.		1. A coded term may be stated confidently to be the same as, or a variation on, a concept. Typically code systems like Read2 or CTV3 can be dealt with in this way because they are designed to try and capture the idea in the clinicians mind, and they have been incorporated as concepts anyway. Likewise many system supplier codes have been created in this way. In this case the term code can be said to be a term code of the concept. Read2 G33 - Angina pectoris is a term code for the concept of angina pectoris.
Line 56:		Line 57:
	:oneOf icd10:O24.3 icd10:O24.9 O24.4]		:oneOf icd10:O24.3 icd10:O24.9 O24.4]
	</pre><br />		</pre><br />
	== Mapping ~~resources properties and local codes~~ ==		== Mapping source fields ==
			It is equally common to need to map source fields to core data model properties. In the information model a property is considered just another concept.

			However, to use mappings for source fields it is necessary to use the context in which the source fields exist.

	In the above examples, coded concepts were considered as context independent in the sense that the same code used by many providers and many systems would generally mean the same thing and can be treated the same way.		In the above examples, coded concepts were considered as context independent in the sense that the same code used by many providers and many systems would generally mean the same thing and can be treated the same way.

	It is equally common to find provider and system specific constructs, including coded items whose meaning depends on the table or field within the source system. A similar approach to mapping of standard code schemes can be taken except that the source properties of the source concept must be explicitly described in order to provide context.

	In the same way that codes can be mapped, so can source resource types such as tables or fields, message types or message segments. Mapping may involve functional transformation		In the same way that codes can be mapped, so can source resource types such as tables or fields, message types or message segments. Mapping may involve functional transformation
Line 92:		Line 96:
	<br />		<br />
	== Legacy codes, terms and term codes==		== Legacy codes, terms and term codes==
	~~Health records tend to hold 3 types of items when describing~~ a ~~clinical or administrative concept:~~ A code~~, a term,~~ or ~~a term~~ code (i.e. a code ~~with a term(~~		Legacy or local codes also require context and the same approach is used as described above. In this case a local code 12345655 mat have different meaning in a ddifferent system. A local code may or may not have any sort of code scheme (the scheme then being implied by the context). In the following example, Barts trust has its own local cerner code scheme.<pre>
			{
			"organisation": "Barts",
			"system" : "CernerMillenium",
			"message" :"cds_type_130",
			"field" :"admin_cat_code",
			"codeScheme" :"BartsLocalCodes",
			"code" :123445556
			}

	The information model's ontology uses the idea of concepts (which are ideas). Concepts categorise into those that are considered core concepts, which mean they are concepts intended to be used in the future, and legacy concepts i.e. those that may deprecate over time.		</pre><br />

	~~All purely code based concepts are considered legacy whereas ontologically defined concepts (that may have codes) are considered core. Snomed-CT is an example of core concepts that have codes.~~

	The healthcare ontology Snomed-CT consists of a set of codes which reference concepts and hence Snomed refers to the codes as concept identifiers. For example the code for 'Chest pain (finding) ' (29857009) references the concept of chest pain ([http://~~snomed.info/sct#29857009 http://snomed.info/sct#29857009) ,], which itself has a label of "Chest pain (finding)".~~

	Snomed also contains a list of terms that are similar or synonymous with the meaning of a concept and these reference the concept. This article refers to these as 'term codes' . For example the term 'Chest Pain' (49966017) also references the same concept of chest pain ([http://snomed.info/sct#29857009 http://snomed.info/sct#29857009) ,]

	~~Legacy classifications such as Read2 and CTV3 have term codes also. For example H33..11 Bronchial asthma is a term code of asthma which is itself a code that is NOT semantically defined.~~
	==Decision process for handling codes and terms==		==Decision process for handling codes and terms==
	When incorporating codes and terms into the ontology, there are 2 categories of approach, the selected approach being dependent on the semantic relationship between the legacy and core concept. The categories are:		When incorporating codes and terms into the ontology, there are 2 categories of approach, the selected approach being dependent on the semantic relationship between the legacy and core concept. The categories are:

	#Creation of a simple "matched to" map between a core concept and a legacy concept. This implies that the legacy concept is a subtype of, or equivalent to the core concept. Examples of these are supplier local codes, Read 2, TPP		#Creation of a simple "matched to" map between a core concept and a legacy concept. This implies that the legacy concept is a subtype of, or equivalent to the core concept. Examples of these are supplier local codes, Read 2, TPP
	#Creation of a complex "mapped to" between a core concept and a legacy concept. This implies a more nuanced relationship meaning that the user may elect how to use the maps when ~~qureying~~ records.		#Creation of a complex "mapped to" between a core concept and a legacy concept. This implies a more nuanced relationship meaning that the user may elect how to use the maps when querying records.

	~~When creating a forward relationship, 2 outcomes are possible:~~



	<br />		<br />

DavidStables at 14:28, 4 August 2021

2021-08-04T14:28:52Z

@@ Line 25: / Line 25: @@
 Legacy Code based concepts can be mapped to Core concepts , and this enables the use of the vast volumes of data already recorded in systems. Maps must be used with care as it is almost always the case that the use of a mapped code in a query is dependent on the purpose of the query. This means that mappings are more of a guide to the things to include rather than a confident statement of meaning. When querying records the query author may need to determine which codes to include or exclude on a case by case basis.
-== Code relationships to term based concepts ==
+== Maps between core concepts and legacy concepts ==
 As mentioned above the relationships are managed as mappings which state the type or degree of match.
-Maps generally fall into 4 patterns. These are illustrated in the context of code based concepts as follows:
+Maps generally fall into 2 patterns. These are illustrated in the context of code based concepts as follows:
 === Simple match ===
@@ Line 56: / Line 56: @@
                             :oneOf  icd10:O24.3 icd10:O24.9 O24.4]
 </pre><br />
-== Source resources properties and local codes ==
+== Mapping resources properties and local codes ==
 In the above examples, coded concepts were considered as context independent in the sense that the same code used by many providers and many systems would generally mean the same thing and can be treated the same way.
@@ Line 90: / Line 90: @@
 </pre>The information model has fully defined the administrative category property as a property of a subclass of encounter dealing with hospital stays. Consequently the source system's table and field can be fully mapped to the common model field.

DavidStables: /* Code relationships to term based concepts */

2021-08-04T14:18:18Z

Code relationships to term based concepts

← Older revision		Revision as of 14:18, 4 August 2021
Line 36:		Line 36:
	:matchedTo emis:G33 \|Angina Pectoris\|.		:matchedTo emis:G33 \|Angina Pectoris\|.
	</pre>		</pre>
	=== Complex ~~option~~ match ===		=== Complex optional match ===
	A concept may be matched to a number of alternative concepts and it is expected that a query author may wish to select ~~thise~~		A concept may be matched to a number of alternative concepts and it is expected that a query author may wish to select these.
	~~<pre>~~
	sn:~~26298008~~		In this example, the concept ''':''' "Ketoacidotic coma due to diabetes mellitus (disorder)" has a complex map which is selection of either
	~~:hasMap [~~
	~~:oneOf~~

	]
	~~</pre>~~

	~~=== Complex source match ===~~		a) Coma unspecified
	~~A combination of concepts may be matched to~~ a ~~single target concept (e.g. A and B matches C~~) ~~implying that the meaning of C should include all of the source concepts.<pre>~~
	~~sn:6025007 \|Laparoscopic appendectomy (procedure)]~~
	~~:hasMap [~~
	~~:combinationOf [~~
	~~:oneOf opcs:H029\| Unspecified other excision of appendix (OPCS49 H02),~~
	~~opcs:H021 \| Interval appendicectomy (opcs49 H02.1),~~
	~~opcs:H028 Other specified other excision of appendix(opcs49 H02)~~
	],
	[
	~~opcs:Y752 \| Laparoscopic approach to abdominal cavity NEC (opcs49 Y75.2),~~
	~~opcs: Y755 \|Laparoscopic ultrasonic approach to abdominal cavity (opcs49 Y75.5)]~~
	]
	]
	]
	]
	</pre>In other words a combination of one of the appendix excision OPCS codes and laparoscopic codes matches to the Snomed-CT concept of laparoscopic appendectomy. The matching objects also contain advice.

	~~=== Axiom based target match. ===~~		and
	~~A concept may be matched with a high level of confidence to an intersection of target concepts i.e. a concept expression. If the level of confidence is high enough~~ and ~~the context known, this could also be asserted as an axiom.~~

	~~It should be noted that in this case, in the knowledge that the original code was authored with an ontological definition in mind that the above could be represented as an equivalent i.e.<pre>~~
	~~emis:ALLERGY6183BRIDL \| Adverse reaction to Mercilon~~
	~~owl:equivalentClass~~
	~~[owl:intersectionOf~~
	~~[rdf:type sn:281647001 \|Adverse reaction (disorder)],~~
	~~[rdf:type : owl:Restriction;~~
	~~owl:onProperty sn:246075003 \| Causative agent (attribute);~~
	~~owl:someValuesFrom sn:9491701000001106\|Mercilon (product)~~
	]
	]

	.		b) one of either Diabetes mellitus in pregnancy: Pre-existing diabetes mellitus, unspecified, or Diabetes mellitus in pregnancy, unspecified, or Diabetes mellitus arising in pregnancy
	~~</pre>~~

			In effect meaning that the compound entry in the record would need to have 2 icd 10 codes to fulfill the criteria.
			<pre>
			sn:26298008
			:hasMap [
			:combinationOf [
			:oneOf icd10:R402 ]
			[
			:oneOf icd10:O24.3 icd10:O24.9 O24.4]
			</pre><br />
	== Source resources properties and local codes ==		== Source resources properties and local codes ==
	In the above examples, coded concepts were considered as context independent in the sense that the same code used by many providers and many systems would generally mean the same thing and can be treated the same way.		In the above examples, coded concepts were considered as context independent in the sense that the same code used by many providers and many systems would generally mean the same thing and can be treated the same way.
Line 89:		Line 64:

	=== Defining source context ===		=== Defining source context ===
	The first step in managing source concepts is to define the concept in the context of the originator of the data. This employs the use of a context object.<pre>		The first step in managing source concepts is to define the concept in the context of the originator of the data. This employs the use of a context object usually sent as parameters through the REST API. For example the following<pre>
	~~Barts_cds_type_130_admin~~
	~~:hasSourceContext~~		{
	[:organisation :~~organisation/12345\|~~Barts ~~NHS Foundation Trust;~~		"organisation": "Barts",
	:system :~~system/92223 \| Cerner Millenium ;~~		"system" : "CernerMillenium",
	:~~resource :table/~~cds_type_130;		"message" :"cds_type_130",
	:field :~~field/~~admin_cat_code~~\| administrative category code on admission~~		"field" :"admin_cat_code"
	];		}
	~~owl:equivalentClass nhsdm:administrative_category_code_on_admission.~~
	</pre>		</pre>

	=== Mapping nodes ===		=== Mapping nodes ===
	A second step is to identify whether the source ~~concept~~ is equivalent to another source ~~concept~~. This is done in order to rationalise the number of mappings steps needed between a source concept and the final target concept. ~~For~~ example:<pre>		A second step is for the mapping author to identify whether the source context is equivalent to another source contexts. This is done in order to rationalise the number of mappings steps needed between a source concept and the final target concept.
	~~Barts_cds_type_130_admin~~		=== Matching to concept ===
	~~:hasSourceContext~~		The third step involves creation of a source concept and a core concept. In the above example the source is concept has been mapped to a core concept and the core concept is returned<pre>
	~~[:organisation :organisation/12345\|Barts NHS Foundation Trust;~~		bc:BC_xyz
	:~~system :system/92223 \| Cerner Millenium ;~~		rdfs:label "admin_cat_code"
	:~~resource :table/cds_type_130;~~
	~~:field :field/~~admin_cat_code~~\| administrative category code on admission~~		and potential core map
	];
	~~owl:equivalentClass nhsdm:administrative_category_code_on_admission.~~
	~~</pre>~~

	~~=== Matching to ontological concept ===~~		im:administrative_category_code_on_admission
	In the above example we may have a number of different providers each providing different files or concepts, whose context suggests a match with the NHS Data model. As the Discovery data service includes the NHS data model attributes as part of its core model, the NHS datamodel is then mapped to the Discovery model.<pre>
	~~nhsdm~~:administrative_category_code_on_admission
	:matchedTo		:matchedTo
	~~[rdf~~:~~type im:administrativeCategory\| administrative category on admission]~~		bc:BC_xysdasdasd.


	</pre>The information model has fully defined the administrative category property as a property of a subclass of encounter dealing with hospital stays. Consequently the source system's table and field can be fully mapped to the common model field.		</pre>The information model has fully defined the administrative category property as a property of a subclass of encounter dealing with hospital stays. Consequently the source system's table and field can be fully mapped to the common model field.

DavidStables: /* Simple match */

2021-08-04T11:55:12Z

Simple match

← Older revision		Revision as of 11:55, 4 August 2021
Line 11:		Line 11:
	A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.		A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.

	~~Codes~~ originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.		The idea of codes originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.

	Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.		Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.
Line 21:		Line 21:
	2. A coded term might be the same term as a concept but may have been entered without the assertion that is a true representation of a state. Typically code systems such as ICD10 and OPCS fall into this category. E11 - Diabetes type 2, seems to be the same as the concept of diabetes type 2, but was entered without clinician attestation and may have been approximated for payment purposes. In this case a legacy concept is produced and a map between this concept and the similar clinical concept is generated.		2. A coded term might be the same term as a concept but may have been entered without the assertion that is a true representation of a state. Typically code systems such as ICD10 and OPCS fall into this category. E11 - Diabetes type 2, seems to be the same as the concept of diabetes type 2, but was entered without clinician attestation and may have been approximated for payment purposes. In this case a legacy concept is produced and a map between this concept and the similar clinical concept is generated.

	A map is just another form of relationship, but unlike an ontological equivalent or subclass axiom it implies that the relationship is an approximation. It is a sort of statement that something is ~~possibly~~ or probably similar to ~~something~~ else and thus has much less weight than an asserted relationship.		A map is just another form of relationship, but unlike an ontological equivalent or subclass axiom it implies that the relationship is an approximation. It is a sort of statement that something is p''ossibly or probably similar to s''omething else and thus has much less weight than an asserted relationship.

	Legacy Code based concepts can be mapped to Core concepts , and this enables the use of the vast volumes of data already recorded in systems. Maps must be used with care as it is almost always the case that the use of a mapped code in a query is dependent on the purpose of the query. This means that mappings are more of a guide to the things to include rather than a confident statement of meaning. When querying records the query author may need to determine which codes to include or exclude on a case by case basis.		Legacy Code based concepts can be mapped to Core concepts , and this enables the use of the vast volumes of data already recorded in systems. Maps must be used with care as it is almost always the case that the use of a mapped code in a query is dependent on the purpose of the query. This means that mappings are more of a guide to the things to include rather than a confident statement of meaning. When querying records the query author may need to determine which codes to include or exclude on a case by case basis.
Line 31:		Line 31:

	=== Simple match ===		=== Simple match ===
	A concept may be matched to ~~one other concept, the match having a certain weighting or category. For example the ICD10~~ code ~~for Angina may have a map which maps to the single term~~ based ~~Snomed-CT concept of angina, with~~ a ~~category indicating that~~ the ~~source~~ concept is ~~properly classified. Note that many coded concepts may~~ be ~~mapped~~ to ~~one single term based concept~~. ~~The map is viewed from~~ the ~~perspective of the coded~~ concept.		A core concept may be matched to many code based concepts. In a simple match the legacy concept is deemed to be probably equivalent to, or a subclass of. the code concept<pre>

			sn:194828000 \|Angina (disorder)
			:matchedTo emis:G33 \|Angina Pectoris\|.
	~~N.B. In line with use of the health information modelling language based on RDF, Turtle syntax is used with the IRIs expanded by use of their name.<pre>~~
	~~icd10~~:~~I209~~ \|Angina ~~Pectoris~~ (~~ICD10 I20.9~~)\|
	~~:hasMap [~~
	:matchedTo [
	~~rdf:type sn~~:~~194828000~~ \|Angina ~~(disorder);~~
	~~:mapCategory sn:447637006~~ \|~~Map source concept is properly classified;~~
	~~im:assuranceLevel im:NationallyAssuredUK~~
	]
	]
	</pre>		</pre>

	~~i.e. The ICD10 code I20.9 is matched to a single Snomed-CT concept.~~

	=== Complex option match ===		=== Complex option match ===
	A concept may be matched to a number of alternative concepts		A concept may be matched to a number of alternative concepts and it is expected that a query author may wish to select thise
	<pre>		<pre>
			sn:26298008
	~~icd10~~:~~E140\| Unspecified diabetes mellitus with coma~~
	~~//This maps to a number of potential target concepts~~
	:hasMap [		:hasMap [
	:oneOf		:oneOf
	~~sn:26298008\|Ketoacidotic coma due to.....,~~
	~~sn:421725003\|Hypoglycemic coma due to...,~~
	~~sn:267384006 \|Coma due to hypoglycemia]~~
	]		]
	</pre>		</pre>

DavidStables: /* Managing codes and taxonomies */

2021-05-09T15:54:55Z

Managing codes and taxonomies

← Older revision		Revision as of 15:54, 9 May 2021
Line 1:		Line 1:
	== Managing codes and taxonomies ==		== Managing codes and taxonomies ==
	''Main article'' [[Management of code based taxonomies.]] Describes how codes such as EMIS local codes, Read 2, OPCS4 etc are handled in the information model.		''Main article'' [[Management of code based taxonomies.]] Describes how codes such as EMIS local codes, Read 2, OPCS4 etc are handled in the information model applying the maps as described in this article.

	== Concepts - background ==		== Concepts - background ==

DavidStables: /* Concepts - background */

2021-05-09T15:41:01Z

Concepts - background

← Older revision		Revision as of 15:41, 9 May 2021
Line 11:		Line 11:
	A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.		A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using DL. A collection of concepts defined in this way constitute an "Ontology" and there is a standard language OWL that is used to represent the definitions.

	~~Coded~~ originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.		Codes originated from a different starting point. The intention of a coded entry is to ''pre-classify'' an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.

	Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.		Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.

DavidStables: /* Complex intersection target match. */

2021-05-03T14:09:07Z

Complex intersection target match.

← Older revision		Revision as of 14:09, 3 May 2021
Line 80:		Line 80:
	</pre>In other words a combination of one of the appendix excision OPCS codes and laparoscopic codes matches to the Snomed-CT concept of laparoscopic appendectomy. The matching objects also contain advice.		</pre>In other words a combination of one of the appendix excision OPCS codes and laparoscopic codes matches to the Snomed-CT concept of laparoscopic appendectomy. The matching objects also contain advice.

	=== ~~Complex intersection~~ target match. ===		=== Axiom based target match. ===
	A concept may be matched with a high level of confidence to an intersection of target concepts i.e. a concept expression. If the level of confidence is high enough and the context known, this could also be asserted as an axiom.		A concept may be matched with a high level of confidence to an intersection of target concepts i.e. a concept expression. If the level of confidence is high enough and the context known, this could also be asserted as an axiom.

DavidStables: /* Complex intersection target match. */

2021-05-03T14:08:28Z

Complex intersection target match.

← Older revision		Revision as of 14:08, 3 May 2021
Line 81:		Line 81:

	=== Complex intersection target match. ===		=== Complex intersection target match. ===
	A concept may be matched with a high level of confidence to an intersection of target concepts i.e. a concept expression. If the level of confidence is high enough and the context known, this could also be asserted as an axiom.~~<pre>~~		A concept may be matched with a high level of confidence to an intersection of target concepts i.e. a concept expression. If the level of confidence is high enough and the context known, this could also be asserted as an axiom.
	~~emis:ALLERGY6183BRIDL \| Adverse reaction to Mercilon~~
	~~:hasMap [~~
	~~:matchedTo [owl:intersectionOf~~
	~~[rdf:type sn:281647001 \|Adverse reaction (disorder)],~~
	~~[rdf:type : owl:Restriction;~~
	~~owl:onProperty sn:246075003 \| Causative agent (attribute);~~
	~~owl:someValuesFrom sn:9491701000001106\|Mercilon (product)~~
	]
	]
	.
	]

	~~</pre>~~It should be noted that in this case, in the knowledge that the original code was authored with an ontological definition in mind that the above could be represented as an equivalent i.e.<pre>		It should be noted that in this case, in the knowledge that the original code was authored with an ontological definition in mind that the above could be represented as an equivalent i.e.<pre>
	emis:ALLERGY6183BRIDL \| Adverse reaction to Mercilon		emis:ALLERGY6183BRIDL \| Adverse reaction to Mercilon
	owl:equivalentClass		owl:equivalentClass