Baseline data set - Revision history

HaitemElAaouani: /* The patient or person demographic */

2023-01-16T14:47:30Z

The patient or person demographic

← Older revision		Revision as of 14:47, 16 January 2023
Line 35:		Line 35:
	{\| border="1"		{\| border="1"
	\|-		\|-
	\| colspan="5" \|'''Patient / Person'''		\| colspan="2" \|'''Patient / Person'''
	\|-		\|-
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Property'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Property'''
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''
	~~!Conformance~~
	~~!FHIR STU3 Mapping~~
	~~!Value Set~~
	\|-		\|-
	\| NHS Number		\| NHS Number
	\| An identifier of type NHS number, The NHS number allocated to the patient		\| An identifier of type NHS number, The NHS number allocated to the patient
	\|R
	~~\|Patient.identifier(nhsnumber)~~
	\|
	\|-		\|-
	\| Name		\| Name
	\| Name information and title for the patient. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”		\| Name information and title for the patient. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”
	\|
	\|
	\|
	\|-		\|-
	\| Administrative Gender		\| Administrative Gender
	\| Concept: The administrative Gender of the patient i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender		\| Concept: The administrative Gender of the patient i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender
	\|R
	\|
	\|
	\|-		\|-
	\| Date of birth		\| Date of birth
	\| Date of birth of the patient, as far as is known		\| Date of birth of the patient, as far as is known
	\|
	\|
	\|
	\|-		\|-
	\| Death indicator		\| Death indicator
	\| If a patient has died an indicator that they are now dead		\| If a patient has died an indicator that they are now dead
	\|
	\|
	\|
	\|-		\|-
	\| Date of Death		\| Date of Death
	\| If dead and if available, the date of death		\| If dead and if available, the date of death
	\|
	\|
	\|
	\|-		\|-
	\| PDS sensitive		\| PDS sensitive
	\| Flag to indicate whether the patient is marked as sensitive on the spine		\| Flag to indicate whether the patient is marked as sensitive on the spine
	\|
	\|
	\|
	\|-		\|-
	\| Ethnicity		\| Ethnicity
	\| Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of		\| Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of
	\|
	\|
	\|
	\|-		\|-
	\| Language		\| Language
	\| Concept : Held in Discovery as an observation about the patient, and qualified by whether the patient speaks the language or is their preferred language. May be several entries as language characteristics change		\| Concept : Held in Discovery as an observation about the patient, and qualified by whether the patient speaks the language or is their preferred language. May be several entries as language characteristics change
	\|
	\|
	\|
	\|-		\|-
	\| Additional identifiers		\| Additional identifiers
	\| Identifiers – qualified by identifier type		\| Identifiers – qualified by identifier type
	\|
	\|
	\|
	\|-		\|-
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \| Relationships		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \| Relationships
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''
	!
	!
	!
	\|-		\|-

	\| Main Residence current		\| Main Residence current
	\| The main residential (location identified by an address)		\| The main residential (location identified by an address)
	\|
	\|
	\|
	\|-		\|-
	\| Contact		\| Contact
	\| potentially used in contacting the patient, each contact qualified by 1) Concept : contact type e.g.... home telephone, mobile, email 1) Contact details e.g.... email address or telephone number about the patient		\| potentially used in contacting the patient, each contact qualified by 1) Concept : contact type e.g.... home telephone, mobile, email 1) Contact details e.g.... email address or telephone number about the patient
	\|
	\|
	\|
	\|-		\|-

	\| Related persons		\| Related persons
	\| Linked Related persons e.g. family members. This will be sub-typed by relationship type i.e a link table in RDB design. May be a family relationship e.g.... Father and may be qualified by genetic relationship. May be a relationship such as a carer or next of kin.		\| Linked Related persons e.g. family members. This will be sub-typed by relationship type i.e a link table in RDB design. May be a family relationship e.g.... Father and may be qualified by genetic relationship. May be a relationship such as a carer or next of kin.
	\|
	\|
	\|
	\|-		\|-
	\|Is Person		\|Is Person
	\|The person that this patient actually is (or is assumed to be)		\|The person that this patient actually is (or is assumed to be)
	\|
	\|
	\|
	\|-		\|-
	\|Residences		\|Residences
	\|Other residences (locations further identified by address) qualified by residence type (e.g. temporary) and period - start end end		\|Other residences (locations further identified by address) qualified by residence type (e.g. temporary) and period - start end end
	\|
	\|
	\|
	\|}<br />		\|}<br />

HaitemElAaouani: /* The patient or person demographic */

2023-01-13T10:42:16Z

The patient or person demographic

← Older revision		Revision as of 10:42, 13 January 2023
Line 35:		Line 35:
	{\| border="1"		{\| border="1"
	\|-		\|-
	\| colspan="2" \|'''Patient / Person'''		\| colspan="5" \|'''Patient / Person'''
	\|-		\|-
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Property'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Property'''
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''
			!Conformance
			!FHIR STU3 Mapping
			!Value Set
	\|-		\|-
	\| NHS Number		\| NHS Number
	\| An identifier of type NHS number, The NHS number allocated to the patient		\| An identifier of type NHS number, The NHS number allocated to the patient
			\|R
			\|Patient.identifier(nhsnumber)
			\|
	\|-		\|-
	\| Name		\| Name
	\| Name information and title for the patient. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”		\| Name information and title for the patient. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”
			\|
			\|
			\|
	\|-		\|-
	\| Administrative Gender		\| Administrative Gender
	\| Concept: The administrative Gender of the patient i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender		\| Concept: The administrative Gender of the patient i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender
			\|R
			\|
			\|
	\|-		\|-
	\| Date of birth		\| Date of birth
	\| Date of birth of the patient, as far as is known		\| Date of birth of the patient, as far as is known
			\|
			\|
			\|
	\|-		\|-
	\| Death indicator		\| Death indicator
	\| If a patient has died an indicator that they are now dead		\| If a patient has died an indicator that they are now dead
			\|
			\|
			\|
	\|-		\|-
	\| Date of Death		\| Date of Death
	\| If dead and if available, the date of death		\| If dead and if available, the date of death
			\|
			\|
			\|
	\|-		\|-
	\| PDS sensitive		\| PDS sensitive
	\| Flag to indicate whether the patient is marked as sensitive on the spine		\| Flag to indicate whether the patient is marked as sensitive on the spine
			\|
			\|
			\|
	\|-		\|-
	\| Ethnicity		\| Ethnicity
	\| Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of		\| Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of
			\|
			\|
			\|
	\|-		\|-
	\| Language		\| Language
	\| Concept : Held in Discovery as an observation about the patient, and qualified by whether the patient speaks the language or is their preferred language. May be several entries as language characteristics change		\| Concept : Held in Discovery as an observation about the patient, and qualified by whether the patient speaks the language or is their preferred language. May be several entries as language characteristics change
			\|
			\|
			\|
	\|-		\|-
	\| Additional identifiers		\| Additional identifiers
	\| Identifiers – qualified by identifier type		\| Identifiers – qualified by identifier type
			\|
			\|
			\|
	\|-		\|-
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \| Relationships		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \| Relationships
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''
			!
			!
			!
	\|-		\|-

	\| Main Residence current		\| Main Residence current
	\| The main residential (location identified by an address)		\| The main residential (location identified by an address)
			\|
			\|
			\|
	\|-		\|-
	\| Contact		\| Contact
	\| potentially used in contacting the patient, each contact qualified by 1) Concept : contact type e.g.... home telephone, mobile, email 1) Contact details e.g.... email address or telephone number about the patient		\| potentially used in contacting the patient, each contact qualified by 1) Concept : contact type e.g.... home telephone, mobile, email 1) Contact details e.g.... email address or telephone number about the patient
			\|
			\|
			\|
	\|-		\|-

	\| Related persons		\| Related persons
	\| Linked Related persons e.g. family members. This will be sub-typed by relationship type i.e a link table in RDB design. May be a family relationship e.g.... Father and may be qualified by genetic relationship. May be a relationship such as a carer or next of kin.		\| Linked Related persons e.g. family members. This will be sub-typed by relationship type i.e a link table in RDB design. May be a family relationship e.g.... Father and may be qualified by genetic relationship. May be a relationship such as a carer or next of kin.
			\|
			\|
			\|
	\|-		\|-
	\|Is Person		\|Is Person
	\|The person that this patient actually is (or is assumed to be)		\|The person that this patient actually is (or is assumed to be)
			\|
			\|
			\|
	\|-		\|-
	\|Residences		\|Residences
	\|Other residences (locations further identified by address) qualified by residence type (e.g. temporary) and period - start end end		\|Other residences (locations further identified by address) qualified by residence type (e.g. temporary) and period - start end end
			\|
			\|
			\|
	\|}<br />		\|}<br />

DavidStables: /* Abstract classes structural artefacts and miscalleneous */

2021-02-14T15:12:14Z

Abstract classes structural artefacts and miscalleneous

← Older revision		Revision as of 15:12, 14 February 2021
Line 1,433:		Line 1,433:

	<br />		<br />
	== Abstract ~~classes~~ structural artefacts and ~~miscalleneous~~ ==		== Abstract structural artefacts and miscallaneous ==
	Abstract classes from which most of the other record entities inherit. These are best viewed via a the information model viewer, class view as that illustrates the subclass structure of the data model. They are included here for reference.		Abstract classes from which most of the other record entities inherit. These are best viewed via a the information model viewer, class view as that illustrates the subclass structure of the data model. They are included here for reference.

DavidStables at 15:11, 14 February 2021

2021-02-14T15:11:37Z

← Older revision		Revision as of 15:11, 14 February 2021
Line 2:		Line 2:
	Discovery Data Service contains health and care-related data.		Discovery Data Service contains health and care-related data.

	These articles describe the nature of the types of data ~~processed~~ by the data service		These articles describe the nature of the types of data currently held by the data service

	In addition to reading these articles, the reader can visit the information model viewer at [x] which enables the entire information model to be explored, including the ontology, the data model, and the various ~~code sets and data sets that have been developed.~~		In addition to reading these articles, the reader can visit the information model viewer at [x] which enables the entire information model to be explored, including the ontology, the data model, and the various c

	~~In addition, from an operational perspective the status of data sets as incorporated from different supplier systems can be seen on the [[current data sets]] article.~~		<br />

	~~== Overview of the data model ==~~		== Scope of content and approach to categories ==

	The Discovery common information model includes a data model. The data model covers the structural arrangements of care record entries and related entries such as information about people and organisations.

	~~The data model is one of the main packages within the information model:[[File:Information model packages.png\|center\|600x300px\|Information model packages.png]]~~

	Only the broad categories of types of data are described in these articles. ,The information model viewer describes and defines precisely the extent of  support for types of data at a particular point in time.

	In order to understand the terms in use, it is useful to understand the basic building blocks of the model.  The article [[Concepts_classes_and_properties\|Concepts classes and properties]] describes some of the building blocks and provides access to the more specialised modelling language.

	~~ ~~

	~~ ~~

	~~=== Data model vs semantic ontology ===~~

	The data model is different to the semantic ontology. Although they both share the idea of classes and properties, the data model is configured for business purposes, whereas the semantic ontology is configured for meaning. A data model applies a [https://en.wikipedia.org/wiki/Closed-world_assumption closed world assumption], whereas the ontology applies an [https://en.wikipedia.org/wiki/Open-world_assumption open world assumption].

	Nevertheless, all concepts used in the data model are be defined by Axioms in the semantic ontology, providing a means by which data entity subtyping can take advantage of both reasoners and standard query. They are interrelated as in the following diagram with the data model entities on the left and their defning axioms in the ontology on the right.[[File:Data model ontology connection.png\|center\|750x500px\|Data model ontology connection.png]]

	~~ ~~

	Data model entities are defined by axioms in the semantic ontology They also have additional properties and relationships in the data model which are business related i.e. the data model attributes are over and above the properties needed to define the meaning of the entities.

	This presence of the data model entity in the ontology can be used to imply that a data model entry is a record of the thing that the entry is about. For example a hospital admission entry is a ''record of a hospital admission. ''This seeming tautology enables subsumption testing on data model entities and for the relevant data model attributes to be selected in query.  A user can ask the right question and get a consistent answer without any knowledge of the underlying complex relationships. The user need not care whether the concept they are looking for happens to be a value in a record, a property, or a table.

	In addition this relationship enables unlimited extensions to data models, which is something that can be used to keep a relational database schema very simple.  How the mapping to a schema is managed is a subject of specialist articles elsewhere in the Wiki.

	=== Scope of content and approach to categories ===

	The entities described here are derived from actual health records. These are not a "standard" or set of statements of what a data model ''should be'' but instead reflect the type of data that actually exists in the Discovery data service after it has been organised categorised and made ready for machine based inference and health record query.		The entities described here are derived from actual health records. These are not a "standard" or set of statements of what a data model ''should be'' but instead reflect the type of data that actually exists in the Discovery data service after it has been organised categorised and made ready for machine based inference and health record query.

	A health record consists of a set of "entries", each entry describing ~~either an event that has occurred, an event that might occur,~~ a ~~state, or~~ statement by the person making the record.  In addition, entries contain references to external things, often organised into Directories. Thus an entity is either a type of entry or a type of thing that the entry refers to.		A health record consists of a set of "entries", each entry describing the net result of a set of machine level events and is a statement by the person or device making the record entry.  In addition, entries contain references to external things, often organised into Directories. Thus an entity is either a type of entry or a type of thing that the entry refers to.

	The approach to categorising the data types has been heavily influenced by HL7 FHIR. In this approach, entities are roughly categorised according to the type of business process that the entry describes. In that sense, the categorisation is entirely pragmatic.		The approach to categorising the data types has been heavily influenced by HL7 FHIR. In this approach, entities are roughly categorised according to the type of business process that the entry describes. In that sense, the categorisation is entirely pragmatic.

	Each entity has its own article and thus the data model is described by categorising articles along the same lines as the ontological classification of the entities themselves. However, there will always be some mismatch between the articles and the model itself and it is the model itself that should be relied on at all times.		Each entity has its own article and thus the data model is described by categorising articles along the same lines as the ontological classification of the entities themselves. However, there will always be some mismatch between the articles and the model itself and it is the model itself that should be relied on at all times.

			Every entity, attribute and value in the model is defined in an ontology - an information model. This article simply tabulates a human approximation to the ontology

	==  Individuals ==		==  Individuals ==

DavidStables: DavidStables moved page Health data model content to Baseline data set

2021-02-14T15:07:59Z

DavidStables moved page Health data model content to Baseline data set

← Older revision	Revision as of 15:07, 14 February 2021
(No difference)

DavidStables: /* Abstract classes structural artefacts and miscalleneous */

2020-09-29T08:08:19Z

Abstract classes structural artefacts and miscalleneous

← Older revision		Revision as of 08:08, 29 September 2020
Line 1,588:		Line 1,588:
	\|Version of the device (e.g.... software version if the device is software)		\|Version of the device (e.g.... software version if the device is software)
	\|}		\|}
	<br /><div>		<br />
			===UPRN and addresses===
			The data model incorporates details of properties, including the address and unique property reference number and geolocations of various kinds and links user entered addresses to a set of authoritative addresses provided by the [https://www.ordnancesurvey.co.uk/business-government/products/addressbase-premium AddressBase Premium] service provided by the Ordnance survey.


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

DavidStables: /* Simple observation */

2020-09-10T14:59:49Z

Simple observation

← Older revision		Revision as of 14:59, 10 September 2020
Line 712:		Line 712:
	! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''		! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" \|'''Description'''
	\|-		\|-
	\| Observation ~~type~~		\| Observation concept
	\| Concept: Nature of the observation, ~~including whether this is a sub-type entry (described elsewhere) or categorisation within the observation type itself~~ e.g.... sign, symptom, aim, target, goal , test header, or specialist type e.g.... blood pressure. ~~Equivalent to an archetype~~<br /> It is inferred by the code within the observation, however it is modelled separately as it drives business logic		\| Concept: Nature of the observation, e.g.... sign, symptom, aim, target, goal , test header, or specialist type e.g.... blood pressure.<br /> It is inferred by the code within the observation, however it is modelled separately as it drives business logic
	\|-		\|-
	\| Prompt		\| Prompt

DavidStables: /* Device */

2020-09-08T16:02:14Z

Device

← Older revision		Revision as of 16:02, 8 September 2020
Line 1,587:		Line 1,587:
	\|Device version		\|Device version
	\|Version of the device (e.g.... software version if the device is software)		\|Version of the device (e.g.... software version if the device is software)
	\|}<br /><div>		\|}
			<br /><div>
	<br /></div>		<br /></div>

DavidStables: /* Organisations services and locations */

2020-09-08T15:41:22Z

Organisations services and locations

← Older revision		Revision as of 15:41, 8 September 2020
Line 236:		Line 236:
	Records of entities that exist independently of people, including organisations, manufactured devices, services and locations		Records of entities that exist independently of people, including organisations, manufactured devices, services and locations

	In Discovery, ~~these concepts~~ are amalgamated into a single structure and the entities are differentiated via the category and the relationships with the other entities as described below. In many cases the relationships will be inferred by ~~Discovery~~ from the nature of the information transmitted~~. There is no expectation that publishers are required to populate the relationships~~.		In Discovery, organisations are services are amalgamated into a single structure, and the entities are differentiated via the category and the relationships with the other entities as described below. In many cases the relationships will be inferred by from the nature of the information transmitted.

	~~Because Discovery is an operational service, there~~ are ~~also some related entities that provide information such as when a particular publication was updated. Organisations and related entities can be~~ illustrated as follows		The complex interrelationships between organisation locations and properties are illustrated as follows:

			<br />
	[[File:Organisations and locations - Page 1.jpg\|center\|thumb\|800x800px]]		[[File:Organisations and locations - Page 1.jpg\|center\|thumb\|800x800px]]

DavidStables: /* Context Headings or sections in encounters */

2020-09-08T15:39:21Z

Context Headings or sections in encounters

@@ Line 1,457: / Line 1,457: @@
 <br />
-== Abstract classes and structural artefacts ==
+== Abstract classes structural artefacts and miscalleneous ==
 Abstract classes from which most of the other record entities inherit. These are best viewed via a the information model viewer, class view as that illustrates the subclass structure of the data model. They are included here for reference.
@@ Line 1,552: / Line 1,552: @@
 | is subsection of
 | Link to the parent heading
 |}<br /><div>
 <br /></div>