Publishers and mapping to the common model: Difference between revisions

Latest revision as of 10:28, 5 February 2026

Publishers are defined as any provider system, or provider/ system/version combination that sends data to the Voror Health Platform (VHP) or provides an API for the VHP to use to obtain data.

Some providers have systems that have a common mechanism of publishing data. Typical examples of this are GP system suppliers such as EMIS, TPP or Vision. In this case, the transformation and mapping can be standardised and used for any publisher.

Some providers have systems that do not have a mechanism of publishing data, or where they do, a particular provider may not have purchased it. In this case, a transformation and mapping exercise has to be undertaken specifically for that provider. In many cases that also means a variety of source systems are involved.

These articles summarise the necessary transformations and mappings needed for each provider system.

General approach

The initial transformation in the VHP is to an extended FHIR format i.e. a FHIR model with extensions, the extensions to accommodate the many dozens of properties and data types for specialist systems or specialties within providers. From the interim FHIR format, a further structural and semantic mapping occurs to a relational data model, stored in a form that can be efficiently queried and retrieved. This can be illustrated as follows:

High level (non-technical) overview

The data is received from the publisher (various different publishers, systems, and versions) and is sent, in various different formats by various different mechanisms, into the VHP.
The gateway controls the IG and flow of data into the VHP file store and inbound/publisher queue.
The inbound queue reader (transform) is notified, by the inbound publisher queue, that there is new data.
The inbound queue reader (transform) takes that new data and uses the FHIR maps to transform it, stores it in the FHIR store, and then puts a notification on the outbound/subscriber queue.
The outbound queue reader (subscriber) is notified, by the outbound subscriber queue, that there is new FHIR data.
The outbound queue reader (subscriber) takes that new data and uses the ontology, maps, and data models to make it available in a relational data store.

New publisher data standards

Acute

Main article: Publisher API HL7 Messages

CDS Data

Main article: CDS Data

Community Data

Main article: Community data FHIR mapping

Live data feeds

Adastra

Main article: Adastra Extract FHIR Mapping

BHRUT Medway

Main article: BHRUT Medway Extract FHIR Mapping

Cerner Imperial

Historic data feeds

Barts Health ADT

Main article: HL7 ADT (Draft)

Barts Health CDS

Main article: Barts Health CDS FHIR Mapping

Barts Health Cerner

Homerton ADT

Main article: Homerton ADT FHIR Mapping

Vision

Main article: Vision GP Extract FHIR Mapping

@@ Line 1: / Line 1: @@
-Publishers are defined as any provider system, or provider/ system/version combination that &nbsp;sends&nbsp;data to Discovery or provides&nbsp;an API for Discovery to use to obtain data.
+Publishers are defined as any provider system, or provider/ system/version combination that sends data to the Voror Health Platform (VHP) or provides an API for the VHP to use to obtain data.
-Some providers have systems that have a common mechanism of publishing data. Typical examples of this are GP system suppliers such as EMIS, TPP or Vision. In this case the transformation and mapping can be standardised and used for any publisher.
+Some providers have systems that have a common mechanism of publishing data. Typical examples of this are GP system suppliers such as EMIS, TPP or Vision. In this case, the transformation and mapping can be standardised and used for any publisher.
-Some providers have systems that do not have a mechanism of publishing data, or where they do, a particular provider may not have purchased it. In this case a transformation and mapping exercise has to be undertaken specificlly for that provider. In many cases that also means a variety of source systems are involved.
+Some providers have systems that do not have a mechanism of publishing data, or where they do, a particular provider may not have purchased it. In this case, a transformation and mapping exercise has to be undertaken specifically for that provider. In many cases that also means a variety of source systems are involved.
-These articles summarise the necessary transformations and mappings needed for each provider system.&nbsp;
+These articles summarise the necessary transformations and mappings needed for each provider system.
 == General approach ==
-The initial transformation in Discovery is to an extended FHIR format i.e. a FHIR model with extensions, the extensions&nbsp; to accomodate the many dozens of properties and data types for particular specialist systems or specialties within providers.&nbsp;&nbsp;From the interim&nbsp;FHIR format, a further structural and semantic mapping occurs to the common model and the data is stored in a form that can be efficiently queried and retrieved. This can be illustrated as follows:
+The initial transformation in the VHP is to an extended FHIR format i.e. a FHIR model with extensions, the extensions to accommodate the many dozens of properties and data types for specialist systems or specialties within providers. From the interim FHIR format, a further structural and semantic mapping occurs to a relational data model, stored in a form that can be efficiently queried and retrieved. This can be illustrated as follows:
-[[File:Inbound.png|center|800x250px|Inbound.png]]
+[[File:Inbound.png|center|1600x500px|Inbound.png]]
-== EMIS ==
+=== High level (non-technical) overview ===
+# The data is received from the publisher (various different publishers, systems, and versions) and is sent, in various different formats by various different mechanisms, into the VHP.
+# The gateway controls the IG and flow of data into the VHP file store and inbound/publisher queue.
+#The inbound queue reader (transform) is notified, by the inbound publisher queue, that there is new data.
+#The inbound queue reader (transform) takes that new data and uses the FHIR maps to transform it, stores it in the FHIR store, and then puts a notification on the outbound/subscriber queue.
+#The outbound queue reader (subscriber) is notified, by the outbound subscriber queue, that there is new FHIR data.
+#The outbound queue reader (subscriber) takes that new data and uses the ontology, maps, and data models to make it available in a relational data store.
-=== ''Main Article :&nbsp;''[[EMIS_published_data_transformation_and_mapping]] ===
+== New publisher data standards ==
-== TPP ==
+=== Acute ===
+''Main article:'' [[Publisher API HL7 Messages]]
-== Vision ==
+=== CDS Data ===
+''Main article:'' [[CDS Data]]
-== Adastra ==
+=== Community Data ===
+''Main article:'' [[Community data FHIR mapping]]
-== Cerner Barts ==
+== Live data feeds ==
-== Cerner Imperial ==
+=== Adastra ===
+''Main article:'' [[Adastra Extract FHIR Mapping]]
-== &nbsp; ==
+=== BHRUT Medway ===
+''Main article:'' [[BHRUT Medway Extract FHIR Mapping]]
+=== Cerner Imperial ===
+=== EMIS ===
+''Main article:'' [[EMIS GP published data transformation and mapping]]
+===NEMS===
+''Main article:'' [[NEMS Extract FHIR Mapping]]
+=== TPP ===
+''Main article:'' [[TPP Extract FHIR Mapping]]
+== Historic data feeds ==
+=== Barts Health ADT ===
+''Main article:'' [[HL7 ADT]] (Draft)
+=== Barts Health CDS ===
+''Main article'': [[Barts Health CDS FHIR Mapping]]
+=== Barts Health Cerner ===
+=== Homerton ADT ===
+''Main article:'' [[Homerton ADT FHIR Mapping]]
+=== Vision ===
+''Main article:'' [[Vision GP Extract FHIR Mapping]]

AdminJo (talk | contribs)