Data Model - Revision history

DavidStables at 10:33, 29 September 2020

2020-09-29T10:33:59Z

DavidStables: /* Data model properties */

2020-09-29T10:16:48Z

Data model properties

← Older revision		Revision as of 10:16, 29 September 2020
Line 58:		Line 58:
	b) Use a triple extension table on the encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.		b) Use a triple extension table on the encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.

			==== Types of data model properties ====
			Whether core or extended, properties fall into 3 main types:

	~~<br />~~		# Object properties, whose range is an instance of a class, this either being a class or a value set with class members
			# Data properties, whose range is a literal e.g. an integer or string
			# Relationships, a type of object property whose range is another data model class

			==== Property Cardinality ====
			Within the data model cardinality modelling is implied in the following way:

			# A core property is stated within the class expression as either having an exact cardinality, maximum cardinality or one or more (or any combination). Minimum cardinality (of 1) is implied.
			# An extended property is either a functional property (Cardinality of 1) or unstated in which case it is assumed there may be zero or more than one. Explicit cardinality of extended properties is not supported directly and such a property would be modelled as core. Minimum cardinality of zero is implied as an extended property.

	===Model content===		===Model content===

DavidStables: /* Core data model properties */

2020-09-29T10:08:38Z

Core data model properties

← Older revision		Revision as of 10:08, 29 September 2020
Line 9:		Line 9:
	The data model is built using the same OWL2 information modelling language as the semantic ontology. A major difference is the way in which the two are used. In the case of a data model, an application would use a [[wikipedia:Closed-world_assumption\|'closed world assumption']] with the use of query language to filter and sort, whereas in the semantic ontology an application would use the [[wikipedia:Open-world_assumption\|'open world assumption]]' with the use of reasoners to enable [https://wiki.discoverydataservice.org/Subsumption_test subsumption testing.]		The data model is built using the same OWL2 information modelling language as the semantic ontology. A major difference is the way in which the two are used. In the case of a data model, an application would use a [[wikipedia:Closed-world_assumption\|'closed world assumption']] with the use of query language to filter and sort, whereas in the semantic ontology an application would use the [[wikipedia:Open-world_assumption\|'open world assumption]]' with the use of reasoners to enable [https://wiki.discoverydataservice.org/Subsumption_test subsumption testing.]

	=== Data model ~~classes~~ and semantic definition ===		=== Data model and semantic definition ===
	Data model classes often use terms that appear to have meaning that ''should'' be semantically defined, therefore a convention used is to name the different concepts by the use of a () qualifier.		Data model classes often use terms that appear to have meaning that ''should'' be semantically defined, therefore a convention used is to name the different concepts by the use of a () qualifier.

Line 21:		Line 21:

	For example, an implementer may elect to have a single Encounter table for all encounters (including the 20,000 or so encounter sub types). To record a telephone triage an entry into the encounter table : 'Encounter' -> is of type-> Telephone triage consultation' may be all that is required.		For example, an implementer may elect to have a single Encounter table for all encounters (including the 20,000 or so encounter sub types). To record a telephone triage an entry into the encounter table : 'Encounter' -> is of type-> Telephone triage consultation' may be all that is required.

			=== Data model class inheritance ===
			Data model classes inherit explicit in the same way as semantic ontology classes i.e. may be subclasses. In doing so the following inheritance rules apply:

			# All properties of the super class are available to the subclass (standard inheritance)
			# Where the subclass has a redeclared property which is the same as a superclass, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class. For example if an encounter (data model) -> is type of-> Encounter type, then a consultation (data model) which is a subclass of encounter -> is type of-> must be a subclass of encounter type
			# Where the subclass has a property which is a subproperty of a property of the super class, then likewise, the range of the property of the subclass ust be the same as, or a subclass of, or derived data type of, the range of the super class.

	=== Data model properties ===		=== Data model properties ===
Line 30:		Line 37:
	For example, a patient health event would have a property of 'has subject' the value being the patient to whom the event referred. Being an event it would also have a start date and time.		For example, a patient health event would have a property of 'has subject' the value being the patient to whom the event referred. Being an event it would also have a start date and time.

	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example:		The "is of type" property is an example of a core property for those objects that are subtyped by the value of this property.

			In the modelling language these are modelled as OWL class expressions with the maximum cardinality defined where necessary. For example:

	<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p style="margin-left:9%"> and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p style="margin-left:9%"> and 'has date of birth' exactly 1 'Date Time'</p></span>

	On the ~~other hand~~, if there ~~was~~ a business purpose ~~to record~~ the 'quality of the call' ~~in a telephone triage consultation, then a~~ 'Telephone triage consultation (data model)' concept ~~would~~ be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		==== Extended data model properties ====
			Extended data model properties are those properties that are deemed to be 'available' for a particular class but not always expected. Depending on the business these may also be used to constrain allowable properties of a class.

			For example, a record of an 'accident and emergency encounter' may record a 'treatment function for which the patient was admitted'. But if the patient was never admitted the encounter would not have this property. This property is therefore modelled as an extended property. (These may also be referred to as optional properties).

			in the modelling language these are modelled as OWL property domains. As such, applications may use the closed world assumption to determine that properties of an object must either be core properties or extended properties and use a reasoner to determine that when a user is querying on a property then the object must be a member of the property domain class.

			Extended properties are of value when considering implementation design. Using the example of the 'telephone triage consultation' there may be a business purpose for recording the 'quality of the call' .

			Firstly The 'Telephone triage consultation (data model)' concept could be created as a subclass of 'Consultation (data model)'. An implementer who used a single 'encounter table' has a choice of:

	a) Create a table for telephone triage with the additional field of 'quality of call'		a) Create a table for telephone triage with the additional field of 'quality of call'

	b) Use a triple extension table on the encounter table with field 1= Encounter id/ value =12345, field 2= Property/ value quality of call, field 3 = Object / value = 'good'.		b) Use a triple extension table on the encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.

	~~And because the info~~

	<br />		<br />

DavidStables: /* Core data model properties */

2020-09-29T08:58:53Z

Core data model properties

← Older revision		Revision as of 08:58, 29 September 2020
Line 30:		Line 30:
	For example, a patient health event would have a property of 'has subject' the value being the patient to whom the event referred. Being an event it would also have a start date and time.		For example, a patient health event would have a property of 'has subject' the value being the patient to whom the event referred. Being an event it would also have a start date and time.

			In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example:
	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

	<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p style="margin-left:9%"> and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p style="margin-left:9%"> and 'has date of birth' exactly 1 'Date Time'</p></span>

DavidStables: /* Core data model properties */

2020-09-29T08:58:25Z

Core data model properties

← Older revision		Revision as of 08:58, 29 September 2020
Line 33:		Line 33:
	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example		In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

	<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p style="margin-left:9%"> and 'has date of birth' exactly 1 'Date Time'</p></span>

	On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

DavidStables: /* Core data model properties */

2020-09-29T08:58:01Z

Core data model properties

← Older revision		Revision as of 08:58, 29 September 2020
Line 33:		Line 33:
	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example		In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

	<span style="color:#0000ff"> Person (record of): Subclass of:<p~~><tab~~>Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p style="margin-left:10%">Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>

	On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

DavidStables: /* Core data model properties */

2020-09-29T08:55:44Z

Core data model properties

← Older revision		Revision as of 08:55, 29 September 2020
Line 33:		Line 33:
	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example		In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

	<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p><tab>Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>

	On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

DavidStables: /* Core data model properties */

2020-09-29T08:55:12Z

Core data model properties

← Older revision		Revision as of 08:55, 29 September 2020
Line 33:		Line 33:
	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example		In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

	<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p>and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p> and 'has date of birth' exactly 1 'Date Time'</p></span>

	On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

DavidStables: /* Core data model properties */

2020-09-29T08:55:00Z

Core data model properties

← Older revision		Revision as of 08:55, 29 September 2020
Line 32:		Line 32:

	In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example		In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example


	<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p>and 'has date of birth' exactly 1 'Date Time'</p></span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p>and 'has date of birth' exactly 1 'Date Time'</p></span>


	On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:		On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

DavidStables: /* Core data model properties */

2020-09-29T08:54:44Z

Core data model properties

← Older revision		Revision as of 08:54, 29 September 2020
Line 34:		Line 34:


	<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p>and 'has date of birth' exactly 1 'Date Time'</span>		<span style="color:#0000ff"> Person (record of): Subclass of:<p> Individual (record of)<p>and 'has date of birth' exactly 1 'Date Time'</p></span>

← Older revision		Revision as of 10:33, 29 September 2020
Line 1:		Line 1:
	~~The~~ data model is the part of the ontology that defines classes required for particular business purposes.		A data model is the part of the common information model ontology that defines classes required for particular business purposes.

	Business purposes vary from the need to store particular items of data through the need to display items in a certain way. This is the model that defines the ever evolving structure of health records held within multi-domain health records, varying from common high level classes through to specialised classes. An example of the former is an 'observation', and an example of the latter is a 'histological/immunological report on a breast carcinoma'.		Business purposes vary from the need to store particular items of data through the need to display items in a certain way. This is the model that defines the ever evolving structure of health records held within multi-domain health records, varying from common high level classes through to specialised classes. An example of the former is an 'observation', and an example of the latter is a 'histological/immunological report on a breast carcinoma'.
Line 5:		Line 5:
	N.B. in IS013606 these are called archetypes and their derivative templates. In HL7 FHIR, from a messaging and API perspective, they are referred to as resources and profiles.		N.B. in IS013606 these are called archetypes and their derivative templates. In HL7 FHIR, from a messaging and API perspective, they are referred to as resources and profiles.

	Whilst ~~the~~ data model supports inheritance (in the ways described below), unlike the semantic ontology, the data model classes are not inherently semantically defined in relation to other concepts. In order to semantically define a data model class, a special property 'is of type' is used to link the semantic definition to the data model. This is described below.		Whilst a data model supports inheritance (in the ways described below), unlike the semantic ontology, the data model classes are not inherently semantically defined in relation to other concepts. In order to semantically define a data model class, a special property 'is of type' is used to link the class's semantic definition to the data model class This is described further below.

	~~The~~ data model is built using the same OWL2 information modelling language as the semantic ontology. A major difference is the way in which the two are used. In the case of a data model, an application would use a [[wikipedia:Closed-world_assumption\|'closed world assumption']] with the use of query language to filter and sort, whereas in the semantic ontology an application would use the [[wikipedia:Open-world_assumption\|'open world assumption]]' with the use of reasoners to enable [https://wiki.discoverydataservice.org/Subsumption_test subsumption testing.]		A data model is built using the same OWL2 information modelling language as the semantic ontology. A major difference is the way in which the two are used. In the case of a data model, an application would use a [[wikipedia:Closed-world_assumption\|'closed world assumption']] with the use of query language to filter and sort, whereas in the semantic ontology an application would use the [[wikipedia:Open-world_assumption\|'open world assumption]]' with the use of reasoners to enable [https://wiki.discoverydataservice.org/Subsumption_test subsumption testing.]

	=== Data model and semantic definition ===		=== Data model and semantic definition ===
	Data model classes often use terms that appear to have meaning that ''should'' be semantically defined, ~~therefore~~ a ~~convention used~~ is ~~to name~~ the ~~different concepts~~ by the use of a () qualifier.		Data model classes often use terms that appear to have meaning that ''should'' be semantically defined. As described above, a separate concept is normally created in the semantic ontology and linked by the 'is of type' property. The potential ambiguity is resolved using a naming convention by the use of a () qualifier.

	For example a data model class of 'Encounter' would be named 'Encounter (data model)' whereas the encounter class that holds it's semantic definition may be called 'Encounter (type)'. (The qualifier 'type' is often omitted for brevity).		For example a data model class of 'Encounter' would be named 'Encounter (data model)' whereas the encounter class that holds it's semantic definition may be called 'Encounter (type)'. (The qualifier 'type' is often omitted for brevity).
Line 18:		Line 18:
	For example, An 'Encounter (data model)' -> is of type -> 'Encounter (type)'.		For example, An 'Encounter (data model)' -> is of type -> 'Encounter (type)'.

	The separation allows for many more 'subtypes' than there are data model entities. This enables implementers who use a relational design to have far fewer tables than there are types.		The separation allows for many more 'subtypes' than there are data model entities. This enables implementers who use a relational design to have far fewer tables than there are types and use a type field to differentiate.

	For example, an implementer may elect to have a single Encounter table for all encounters (including the 20,000 or so encounter sub types). To record a telephone triage an entry into the encounter table : 'Encounter' -> is of type-> Telephone triage consultation' may be all that is required.		For example, an implementer may elect to have a single 'Encounter' table for all encounters (including the 40,000 or so encounter sub types held in real records). To record a telephone triage an entry into the encounter table : 'Encounter' -> is of type-> Telephone triage consultation' may be all that is required.

	=== Data model class inheritance ===		=== Data model class inheritance ===
	Data model classes inherit ~~explicit~~ in the same way as semantic ontology classes i.e. may be subclasses. In doing so the following inheritance rules apply:		Data model classes inherit explicitly in the same way as semantic ontology classes i.e. may be subclasses. In doing so the following inheritance rules apply:

	# All properties of the super class are available to the subclass (standard inheritance)		# All properties of the super class are available to the subclass (standard inheritance) and the subclass appears to extend the superclass.
	# Where ~~the~~ subclass has a redeclared property which is the same as a superclass, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class. For example if an encounter (data model) -> is type of-> Encounter type, then a consultation (data model) which is a subclass of encounter -> is type of-> must be a subclass of ~~encounter~~ type		# Where a subclass has a redeclared property which is the same as its superclass, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class. For example if an encounter (data model) -> is type of-> Encounter type, then a consultation (data model) (which is a subclass of encounter) -> is type of-> X, and X must be a subclass of 'Encounter type'
	# Where the subclass has a property which is a subproperty of a property of the super class, then likewise, the range of the property of the subclass ~~ust~~ be the same as, or a subclass of, or derived data type of, the range of the super class.		# Where the subclass has a property which is a subproperty of a property of the super class, then likewise, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class.

	=== Data model properties ===		=== Data model properties ===
Line 33:		Line 33:

	==== Core data model properties ====		==== Core data model properties ====
	Core data model properties are properties that would be expected to be populated in most circumstances and form part of the "business definition" of the class. Another way of describing them would be to say they are mandatory. However, the data model does not itself mandate the presence of value of the property with the handling of 'unknown' as nulls or or proxy values delegated to a business decision.		Core data model properties are properties that would be expected to be populated in most circumstances and form part of the "business definition" of the class. Another way of describing them would be to say they are mandatory. However, the data model does not itself mandate the presence of value of the property with the handling of 'unknown' as nulls or or proxy values delegated to a business decision. Nevertheless, an implementer using a relational model may create fields for these as could implementers using code classes.

	For example, a patient health event would have a property of 'has subject' the ~~value~~ being the patient to whom the event referred. Being an event it would also have a start date and time.		For example, a patient health event class would have a property of 'has subject' the range being the patient to whom the event referred. Being an event it would also have a start date and time. There would be little point in having an entry for an observation (subclass of patient health event) unless it was linked to a patient.

	The "is of type" property is an example of a core property for those objects that are subtyped by the value of this property.		The "is of type" property is an example of a core property for those objects that are subtyped by the value of this property.
Line 44:		Line 44:

	==== Extended data model properties ====		==== Extended data model properties ====
	Extended data model properties are those properties that are deemed to be 'available' for a particular class but not always expected. Depending on the business these may also be used to constrain allowable properties of a class.		Extended data model properties are those properties that are deemed to be 'available' for a particular class but not always expected. Depending on the business these may also be used to constrain 'allowable' properties of a class. An example of the latter is the Snomed-CT concept model which constrains attributes of a subclass to a defined list.

	For example, a record of an 'accident and emergency encounter' may record a 'treatment function for which the patient was admitted'. But if the patient was never admitted the encounter would not have this property. This property is therefore modelled as an extended property. (These may also be referred to as optional properties).		For example, a record of an 'accident and emergency encounter' may record a 'treatment function' (for which the patient was admitted). But if the patient was never admitted the encounter would not have this property. This property is therefore modelled as an extended property. (These may also be referred to as optional properties).

	in the modelling language these are modelled as OWL property domains. As such, ~~applications~~ may use the closed world assumption to determine ~~that~~ properties of an ~~object must~~ either be core ~~properties~~ or extended ~~properties and use a~~ reasoner to determine that when a user is querying on a property then the object must be a member of the property domain class.		in the modelling language these are modelled as OWL property domains. As such, an information model application may use the closed world assumption to determine the properties of an class as either core or extended. A reasoner can determine that when a user is querying on a property then the object must be a member of the property domain class.

	Extended properties are of value when considering implementation design. ~~Using~~ the example of the 'telephone triage consultation' there may be a business purpose for recording the 'quality of the call' .		Extended properties are of value when considering implementation design. For example, using the example of the 'telephone triage consultation' there may be a business purpose for recording the 'quality of the call' .

	Firstly The 'Telephone triage consultation (data model)' concept ~~could~~ be created as a subclass of 'Consultation (data model)'. An implementer who used a single 'encounter table' has a choice of:		Firstly The 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Telephone Consultation (data model)'. An extended property would be created 'quality of call' with a domain of telephone consultation.

			An implementer who used a single 'encounter table' has a choice of:

	a) Create a table for telephone triage with the additional field of 'quality of call'		a) Create a table for telephone triage with the additional field of 'quality of call'

	b) Use a triple extension table on ~~the~~ encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.		b) Use a triple extension table on an encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.

	==== Types of data model properties ====		==== Types of data model properties ====
	Whether core or extended, properties fall into 3 main types:		Whether core or extended, properties fall into 3 main types:

	# Object properties, whose range is an instance of a class, this either being a class or a value set with class members		# Object properties, whose range is an instance of a class, this either being a class or a value set with class members.
	# Data properties, whose range is a literal e.g. an integer or string		# Data properties, whose range is a literal e.g. an integer or string.
	# Relationships, a type of object property whose range is another data model class		# Relationships, a type of object property whose range is another data model class