Voror_Wiki - User contributions [en-gb]

Voror Health Platform

2022-02-27T17:04:14Z

Sophie: Undo revision 5905 by Sophie (talk)

__TOC__
These articles describe the Discovery Data Service; the architecture that underpins the data service, the components that make up the service, the testing and assurance processes, and the resources, open source technologies, and software that are used to host, develop, and support the service.

=Discovery Data Service status=

* The data service is live.
* It currently stores and processes the data from 28 million linked organisational patient records in the UK.
* It contains long term records on 14 million unique UK citizens who have been resident in London at some point in the last 30 years (including people who have left or died).
* Data on individuals are held in a single common data model with data values represented by a super ontology composed of the world's leading health ontologies.
* Data in Discovery is submitted by health providers who provide primary, secondary, and urgent care services to patients or clients.
* Data is kept up to date in close to real time - at worst within 24 hours; see [[Latency of extract data feeds]] for more details.

= Discovery overview =

These articles provide background to the ideas, philosophies and approaches that have resulted in the Discovery Data Service. They cover the original objectives, the approach to collaboration and shared tenancy, and the information governance rules that underpin the way privacy and sharing are balanced.

*[[What_is_Discovery|What is Discovery]]? - This article describes what Discovery is and how it is conceptualised at a very high level.
*[[Case studies]] - An overview of some initial projects that access and utilise data from Discovery; information includes the applicant, project summary, and the latest status (Development/Live).
*[[Latest news]] - The latest information for all Discovery Data Service releases and changes, plus known issues and updates from system suppliers and other third parties.
*[[Current_data_sets|Current data sets]] - the broad types of data received from various systems.
*[[Current published data]] - provides the latest data publisher information by sector, geographical area, service, and system provider.

= Information model topics =

These articles provide information about the services, structure, and functionality that operate using the Information Models; one of the fundamental tenets of the Discovery Data Service. This is the starting point for those interested in health data and the information derived from it, and why Discovery may be different from other approaches:

*[[Discovery health information model|Health Information model]] - An overview of the approach to the Discovery information model, the purpose, and type of content.
*[[Health Information modelling language|Modelling language]] - The W3C standard languages used to build the various components of the information model
*[[Health_data_model_content|Basic health data set ]] - a very high level overview of the types of data mapped from data held within the Discovery data stores.
*[[Information model reference data|Reference data -]] an overview of additional data held in the information model.
*[[Mapping and matching concepts|Mapping and matching concepts and structures]] - Introduces the approaches to matching and mapping concepts and the structural mappings in the model
*[[Information_model_service|Information model services]] - the technical services , such as APIs and apps that enable an model instance to be used or to implement an EHR based on the model or particular data model

= Publishers and subscribers =
These articles provide some brief high level information for organisations that send data to Discovery and those that use that data.

* [[Publishers]] - includes technical interface information, FHIR mapping, system requirements, and how to make changes to publishing services.
* [[Subscribers]] - includes set up, data mapping, and schema information.

= Services and applications =

These articles provide information about the services and applications provided by the Discovery information services.

* [[Discovery Query|Sextant]] - A data set distribution service with an option to post the data directly into the recipients database.
*[[Monitoring and alerting]] - provides an overview of the monitoring and alert systems in place.

*[[Data Sharing Manager|Data Sharing manager]]- DSM provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.

*[[UPRN address match application|ASSIGN- UPRN address matching application -]] a web based application that matches single or batches of hand entered address to authoritative addresses and assigns a unique property reference number.
*[[Information model manager]] - an application designed to provide a view of the common information model, and support the authoring of the content of the model.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR Get Structured Record API]] - returns a complete patient record in a structured format following GP and Care Connect standards.
*[[HL7v2 API]] - Send HL7v2 ADT and ORU (clinical events) data to Discovery.
*Get health record - the service that obtains a fully structured health record about a person, in real time via a standards based API.
*Record publication service - the service that publishes data from health records for specific purposes, often immediately on receipt.
*Data set distribution service - the service that distributes sets of data for populations of patients where the definition is complex or where the subscriber is hosting a copy of the data permanently.
*[[NHS 111 Discovery frailty flagging]] / [[Frailty algorithm]]
*[[GitHub repositories]] - descriptions and information relating to the application source code.

= Architectures =
These articles provide information about the overall high level software architecture models providing a descriptions and visualisations of the Discovery Data Service and information service components and how they interact.

* The [[Data Storage Architecture]] illustrates how data is stored within the service and the various implementation options available for organisations that wish to use some or parts of the services.
*[[Identity Authentication Authorisation|Identity, authentication and authorisation]] specifies the approach taken by Discovery for accessing utilities and controlling some aspects of access to application functionality and some data resources, after all of the other locks have been opened.
*[[Application zone architecture]] illustrates how the data is accessed in different places and in different ways according to different use cases
*[[Pseudonymisation]] describes how Discovery generates pseudonymised data.
*[[Data linking]] describes how Discovery links several patient records into a single person/citizen record.

= Application help =

*[[Data_Sharing_Manager|Data Sharing Manager]] - Data Sharing Manager provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.
*:You can also amend or cancel data sharing and processing agreements in real time.
*[[Record Viewer]] - Record Viewer shows a combined view of an individual's patient records, using data from different source organisations.
*[[Jira]] - Jira is an effective way to share and track information and helps to make sure that tasks and issues are completed, and signed off, by all relevant teams.

= Wiki tips =

*[[Adding a new page to the wiki]]
*[[Adding tables from word documents]]
*[https://www.mediawiki.org/wiki/Help:Tables Mediawiki Help:Tables]
*[[Creating a DDS wiki watchlist]]
*[[Creating a new user]]
*[https://en.wikipedia.org/wiki/Help:List Wikipedia Help:Lists]
*[[Test page]]

Voror Health Platform

2022-02-27T17:03:37Z

Sophie: /* Information model topics */ IM sectction removed at request of Endeavour.

__TOC__
These articles describe the Discovery Data Service; the architecture that underpins the data service, the components that make up the service, the testing and assurance processes, and the resources, open source technologies, and software that are used to host, develop, and support the service.

=Discovery Data Service status=

* The data service is live.
* It currently stores and processes the data from 28 million linked organisational patient records in the UK.
* It contains long term records on 14 million unique UK citizens who have been resident in London at some point in the last 30 years (including people who have left or died).
* Data on individuals are held in a single common data model with data values represented by a super ontology composed of the world's leading health ontologies.
* Data in Discovery is submitted by health providers who provide primary, secondary, and urgent care services to patients or clients.
* Data is kept up to date in close to real time - at worst within 24 hours; see [[Latency of extract data feeds]] for more details.

= Discovery overview =

These articles provide background to the ideas, philosophies and approaches that have resulted in the Discovery Data Service. They cover the original objectives, the approach to collaboration and shared tenancy, and the information governance rules that underpin the way privacy and sharing are balanced.

*[[What_is_Discovery|What is Discovery]]? - This article describes what Discovery is and how it is conceptualised at a very high level.
*[[Case studies]] - An overview of some initial projects that access and utilise data from Discovery; information includes the applicant, project summary, and the latest status (Development/Live).
*[[Latest news]] - The latest information for all Discovery Data Service releases and changes, plus known issues and updates from system suppliers and other third parties.
*[[Current_data_sets|Current data sets]] - the broad types of data received from various systems.
*[[Current published data]] - provides the latest data publisher information by sector, geographical area, service, and system provider.

= Publishers and subscribers =
These articles provide some brief high level information for organisations that send data to Discovery and those that use that data.

* [[Publishers]] - includes technical interface information, FHIR mapping, system requirements, and how to make changes to publishing services.
* [[Subscribers]] - includes set up, data mapping, and schema information.

= Services and applications =

These articles provide information about the services and applications provided by the Discovery information services.

* [[Discovery Query|Sextant]] - A data set distribution service with an option to post the data directly into the recipients database.
*[[Monitoring and alerting]] - provides an overview of the monitoring and alert systems in place.

*[[Data Sharing Manager|Data Sharing manager]]- DSM provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.

*[[UPRN address match application|ASSIGN- UPRN address matching application -]] a web based application that matches single or batches of hand entered address to authoritative addresses and assigns a unique property reference number.
*[[Information model manager]] - an application designed to provide a view of the common information model, and support the authoring of the content of the model.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR Get Structured Record API]] - returns a complete patient record in a structured format following GP and Care Connect standards.
*[[HL7v2 API]] - Send HL7v2 ADT and ORU (clinical events) data to Discovery.
*Get health record - the service that obtains a fully structured health record about a person, in real time via a standards based API.
*Record publication service - the service that publishes data from health records for specific purposes, often immediately on receipt.
*Data set distribution service - the service that distributes sets of data for populations of patients where the definition is complex or where the subscriber is hosting a copy of the data permanently.
*[[NHS 111 Discovery frailty flagging]] / [[Frailty algorithm]]
*[[GitHub repositories]] - descriptions and information relating to the application source code.

= Architectures =
These articles provide information about the overall high level software architecture models providing a descriptions and visualisations of the Discovery Data Service and information service components and how they interact.

* The [[Data Storage Architecture]] illustrates how data is stored within the service and the various implementation options available for organisations that wish to use some or parts of the services.
*[[Identity Authentication Authorisation|Identity, authentication and authorisation]] specifies the approach taken by Discovery for accessing utilities and controlling some aspects of access to application functionality and some data resources, after all of the other locks have been opened.
*[[Application zone architecture]] illustrates how the data is accessed in different places and in different ways according to different use cases
*[[Pseudonymisation]] describes how Discovery generates pseudonymised data.
*[[Data linking]] describes how Discovery links several patient records into a single person/citizen record.

= Application help =

*[[Data_Sharing_Manager|Data Sharing Manager]] - Data Sharing Manager provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.
*:You can also amend or cancel data sharing and processing agreements in real time.
*[[Record Viewer]] - Record Viewer shows a combined view of an individual's patient records, using data from different source organisations.
*[[Jira]] - Jira is an effective way to share and track information and helps to make sure that tasks and issues are completed, and signed off, by all relevant teams.

= Wiki tips =

*[[Adding a new page to the wiki]]
*[[Adding tables from word documents]]
*[https://www.mediawiki.org/wiki/Help:Tables Mediawiki Help:Tables]
*[[Creating a DDS wiki watchlist]]
*[[Creating a new user]]
*[https://en.wikipedia.org/wiki/Help:List Wikipedia Help:Lists]
*[[Test page]]

Publisher API Code Sets

2022-01-10T13:40:42Z

Sophie: Latest Version

This page details the various code sets that are supported by the DDS Publisher API. The majority of these code sets have previously been published by NHS Digital as part of the [https://isd.digital.nhs.uk/trud3/user/guest/group/41/pack/34 ITK HL7 V2 standard] (version 1.1)

=== AdministrativeSex ===
{| class="wikitable"
!Code
!Description
|-
|U
|Unknown
|-
|M
|Male
|-
|F
|Female
|-
|I
|Other
|}
=== PatientClass ===
{| class="wikitable"
!Code
!Description
|-
|E
|Emergency
|-
|I
|Inpatient
|-
|O
|Outpatient
|}
=== 0136-Yes/noIndicator ===
{| class="wikitable"
!Code
!Description
|-
|Y
|Yes
|}
=== 0399-CountryCode ===
{| class="wikitable"
!Code
!Description
|-
|1
|England
|-
|10
|Channel Islands
|-
|2
|Scotland
|-
|3
|Wales
|-
|4
|Northern Ireland
|-
|7
|Sark
|-
|9
|Alderney
|-
|ABW
|Aruba
|-
|AFG
|Afghanistan
|-
|AGO
|Angola
|-
|AIA
|Anguilla
|-
|ALA
|Ã…land Islands
|-
|ALB
|Albania
|-
|AND
|Andorra
|-
|ARE
|United Arab Emirates
|-
|ARG
|Argentina
|-
|ARM
|Armenia
|-
|ASM
|American Samoa
|-
|ATA
|Antarctica
|-
|ATF
|French Southern Territories
|-
|ATG
|Antigua and Barbuda
|-
|AUS
|Australia
|-
|AUT
|Austria
|-
|AZE
|Azerbaijan
|-
|BDI
|Burundi
|-
|BEL
|Belgium
|-
|BEN
|Benin
|-
|BES
|Bonaire, Sint Eustatius and Saba
|-
|BFA
|Burkina Faso
|-
|BGD
|Bangladesh
|-
|BGR
|Bulgaria
|-
|BHR
|Bahrain
|-
|BHS
|Bahamas
|-
|BIH
|Bosnia and Herzegovina
|-
|BLM
|Saint BarthÃ©lemy
|-
|BLR
|Belarus
|-
|BLZ
|Belize
|-
|BMU
|Bermuda
|-
|BOL
|Bolivia, Plurinational State of
|-
|BRA
|Brazil
|-
|BRB
|Barbados
|-
|BRN
|Brunei Darussalam
|-
|BTN
|Bhutan
|-
|BVT
|Bouvet Island
|-
|BWA
|Botswana
|-
|CAF
|Central African Republic
|-
|CAN
|Canada
|-
|CCK
|Cocos (Keeling) Islands
|-
|CHE
|Switzerland
|-
|CHL
|Chile
|-
|CHN
|China
|-
|CIV
|CÃ´te d'Ivoire
|-
|CMR
|Cameroon
|-
|COD
|Congo, the Democratic Republic of the
|-
|COG
|Congo
|-
|COK
|Cook Islands
|-
|COL
|Colombia
|-
|COM
|Comoros
|-
|CPV
|Cape Verde
|-
|CRI
|Costa Rica
|-
|CUB
|Cuba
|-
|CUW
|CuraÃ§ao
|-
|CXR
|Christmas Island
|-
|CYM
|Cayman Islands
|-
|CYP
|Cyprus
|-
|CZE
|Czech Republic
|-
|DEU
|Germany
|-
|DJI
|Djibouti
|-
|DMA
|Dominica
|-
|DNK
|Denmark
|-
|DOM
|Dominican Republic
|-
|DZA
|Algeria
|-
|ECU
|Ecuador
|-
|EGY
|Egypt
|-
|ERI
|Eritrea
|-
|ESH
|Western Sahara
|-
|ESP
|Spain
|-
|EST
|Estonia
|-
|ETH
|Ethiopia
|-
|FIN
|Finland
|-
|FJI
|Fiji
|-
|FLK
|Falkland Islands (Malvinas)
|-
|FRA
|France
|-
|FRO
|Faroe Islands
|-
|FSM
|Micronesia, Federated States of
|-
|GAB
|Gabon
|-
|GBR
|United Kingdom
|-
|GEO
|Georgia
|-
|GGY
|Guernsey
|-
|GHA
|Ghana
|-
|GIB
|Gibraltar
|-
|GIN
|Guinea
|-
|GLP
|Guadeloupe
|-
|GMB
|Gambia
|-
|GNB
|Guinea-Bissau
|-
|GNQ
|Equatorial Guinea
|-
|GRC
|Greece
|-
|GRD
|Grenada
|-
|GRL
|Greenland
|-
|GTM
|Guatemala
|-
|GUF
|French Guiana
|-
|GUM
|Guam
|-
|GUY
|Guyana
|-
|HKG
|Hong Kong
|-
|HMD
|Heard Island and McDonald Islands
|-
|HND
|Honduras
|-
|HRV
|Croatia
|-
|HTI
|Haiti
|-
|HUN
|Hungary
|-
|IDN
|Indonesia
|-
|IMN
|Isle of Man
|-
|IND
|India
|-
|IOT
|British Indian Ocean Territory
|-
|IRL
|Ireland
|-
|IRN
|Iran, Islamic Republic of
|-
|IRQ
|Iraq
|-
|ISL
|Iceland
|-
|ISR
|Israel
|-
|ITA
|Italy
|-
|JAM
|Jamaica
|-
|JEY
|Jersey
|-
|JOR
|Jordan
|-
|JPN
|Japan
|-
|KAZ
|Kazakhstan
|-
|KEN
|Kenya
|-
|KGZ
|Kyrgyzstan
|-
|KHM
|Cambodia
|-
|KIR
|Kiribati
|-
|KNA
|Saint Kitts and Nevis
|-
|KOR
|Korea, Republic of
|-
|KWT
|Kuwait
|-
|LAO
|Lao People's Democratic Republic
|-
|LBN
|Lebanon
|-
|LBR
|Liberia
|-
|LBY
|Libya
|-
|LCA
|Saint Lucia
|-
|LIE
|Liechtenstein
|-
|LKA
|Sri Lanka
|-
|LSO
|Lesotho
|-
|LTU
|Lithuania
|-
|LUX
|Luxembourg
|-
|LVA
|Latvia
|-
|MAC
|Macao
|-
|MAF
|Saint Martin (French part)
|-
|MAR
|Morocco
|-
|MCO
|Monaco
|-
|MDA
|Moldova, Republic of
|-
|MDG
|Madagascar
|-
|MDV
|Maldives
|-
|MEX
|Mexico
|-
|MHL
|Marshall Islands
|-
|MKD
|Macedonia, the former Yugoslav Republic of
|-
|MLI
|Mali
|-
|MLT
|Malta
|-
|MMR
|Myanmar
|-
|MNE
|Montenegro
|-
|MNG
|Mongolia
|-
|MNP
|Northern Mariana Islands
|-
|MOZ
|Mozambique
|-
|MRT
|Mauritania
|-
|MSR
|Montserrat
|-
|MTQ
|Martinique
|-
|MUS
|Mauritius
|-
|MWI
|Malawi
|-
|MYS
|Malaysia
|-
|MYT
|Mayotte
|-
|NAM
|Namibia
|-
|NCL
|New Caledonia
|-
|NER
|Niger
|-
|NFK
|Norfolk Island
|-
|NGA
|Nigeria
|-
|NIC
|Nicaragua
|-
|NIU
|Niue
|-
|NLD
|Netherlands
|-
|NOR
|Norway
|-
|NPL
|Nepal
|-
|NRU
|Nauru
|-
|NZL
|New Zealand
|-
|OMN
|Oman
|-
|PAK
|Pakistan
|-
|PAN
|Panama
|-
|PCN
|Pitcairn
|-
|PER
|Peru
|-
|PHL
|Philippines
|-
|PLW
|Palau
|-
|PNG
|Papua New Guinea
|-
|POL
|Poland
|-
|PRI
|Puerto Rico
|-
|PRK
|Korea, Democratic People's Republic of
|-
|PRT
|Portugal
|-
|PRY
|Paraguay
|-
|PSE
|Palestinian Territory, Occupied
|-
|PYF
|French Polynesia
|-
|QAT
|Qatar
|-
|REU
|RÃ©union
|-
|ROU
|Romania
|-
|RUS
|Russian Federation
|-
|RWA
|Rwanda
|-
|SAU
|Saudi Arabia
|-
|SDN
|Sudan
|-
|SEN
|Senegal
|-
|SGP
|Singapore
|-
|SGS
|South Georgia and the South Sandwich Islands
|-
|SHN
|Saint Helena, Ascension and Tristan da Cunha
|-
|SJM
|Svalbard and Jan Mayen
|-
|SLB
|Solomon Islands
|-
|SLE
|Sierra Leone
|-
|SLV
|El Salvador
|-
|SMR
|San Marino
|-
|SOM
|Somalia
|-
|SPM
|Saint Pierre and Miquelon
|-
|SRB
|Serbia
|-
|SSD
|South Sudan
|-
|STP
|Sao Tome and Principe
|-
|SUR
|Suriname
|-
|SVK
|Slovakia
|-
|SVN
|Slovenia
|-
|SWE
|Sweden
|-
|SWZ
|Swaziland
|-
|SXM
|Sint Maarten (Dutch part)
|-
|SYC
|Seychelles
|-
|SYR
|Syrian Arab Republic
|-
|TCA
|Turks and Caicos Islands
|-
|TCD
|Chad
|-
|TGO
|Togo
|-
|THA
|Thailand
|-
|TJK
|Tajikistan
|-
|TKL
|Tokelau
|-
|TKM
|Turkmenistan
|-
|TLS
|Timor-Leste
|-
|TON
|Tonga
|-
|TTO
|Trinidad and Tobago
|-
|TUN
|Tunisia
|-
|TUR
|Turkey
|-
|TUV
|Tuvalu
|-
|TWN
|Taiwan, Province of China
|-
|TZA
|Tanzania, United Republic of
|-
|UGA
|Uganda
|-
|UKR
|Ukraine
|-
|UMI
|United States Minor Outlying Islands
|-
|URY
|Uruguay
|-
|USA
|United States
|-
|UZB
|Uzbekistan
|-
|VAT
|Holy See (Vatican City State)
|-
|VCT
|Saint Vincent and the Grenadines
|-
|VEN
|Venezuela, Bolivarian Republic of
|-
|VGB
|Virgin Islands, British
|-
|VIR
|Virgin Islands, U.S.
|-
|VNM
|Viet Nam
|-
|VUT
|Vanuatu
|-
|WLF
|Wallis and Futuna
|-
|WSM
|Samoa
|-
|YEM
|Yemen
|-
|ZAF
|South Africa
|-
|ZMB
|Zambia
|-
|ZWE
|Zimbabwe
|}
=== 0092-Re-AdmissionIndicator ===
{| class="wikitable"
!Code
!Description
|-
|R
|Re-admission
|}
=== 0125-ValueType ===
{| class="wikitable"
!Code
!Description
|-
|CE
|Coded Entry
|-
|ED
|Encapsulated Data
|-
|FT
|Formatted Text (Display)
|-
|NM
|Numeric
|-
|SN
|Structured Numeric
|-
|ST
|String Data.
|-
|TX
|Text Data (Display)
|}
=== 0127-AllergenType ===
{| class="wikitable"
!Code
!Description
|-
|AA
|Animal Allergy
|-
|DA
|Drug allergy
|-
|EA
|Environmental Allergy
|-
|FA
|Food allergy
|-
|IC
|Inorganic Chemicals
|-
|IN
|Insects
|-
|IO
|Iodine
|-
|LA
|Pollen Allergy
|-
|MA
|Miscellaneous allergy
|-
|MC
|Miscellaneous contraindication
|-
|OC
|Organic Chemicals
|-
|PA
|Plant Allergy
|}
=== 0128-AllergySeverity ===
{| class="wikitable"
!Code
!Description
|-
|0
|Unknown
|-
|1
|Insignificant/Minimal
|-
|3
|Mild
|-
|5
|Moderate
|-
|7
|Moderate-Severe
|-
|9
|Very Severe
|}
=== 0228-DiagnosisClassification ===
{| class="wikitable"
!Code
!Description
|-
|C
|Consultation
|-
|D
|Diagnosis
|-
|I
|Invasive procedure not classified elsewhere (I.V., catheter, etc.)
|-
|M
|Medication (antibiotic)
|-
|O
|Other
|-
|R
|Radiological scheduling (not using ICDA codes)
|-
|S
|Sign and symptom
|-
|T
|Tissue diagnosis
|}
=== DDS-HL7v2-EventType ===
{| class="wikitable"
!Code
!Description
|-
|A28
|ADT A28 - create patient record
|-
|A31
|ADT A31 - update patient record
|-
|A40
|ADT A40 - merge patient records
|-
|A05
|ADT A05 - pre-admit a patient
|-
|A38
|ADT A38 - cancel a pre-admit
|-
|A01
|ADT A01 - admit a patient
|-
|A11
|ADT A11 - cancel admit
|-
|A02
|ADT A02 - transfer a patient
|-
|A12
|ADT A12 - cancel transfer
|-
|A03
|ADT A03 - discharge a patient
|-
|A13
|ADT A13 - cancel discharge
|-
|R01
|ORU R01 - send observations
|}
=== DDS-HL7v2-MessageType ===
{| class="wikitable"
!Code
!Description
|-
|ADT
|ADT message
|-
|ORU
|ORU message
|-
|ACK
|General acknowledgment message
|}

=== DDS-HL7v2-AckCode ===
{| class="wikitable"
!Code
!Description
|-
|AA
|Application Accept
|-
|AE
|Application Error
|-
|AR
|Application Reject
|}
=== 0062-EventReason ===
{| class="wikitable"
!Code
!Description
|-
|01
|Patient request
|-
|02
|Physician/health practitioner order
|-
|03
|Census management
|}
=== DDS-ResultStatus ===
{| class="wikitable"
!Code
!Description
|-
|C
|Correction to results
|-
|F
|Final results; results stored and verified. Can only be changed with a corrected result.
|}

=== NHSEOrganisationRole ===

* URL - https://directory.spineservices.nhs.uk/STU3/CodeSystem/ODSAPI-OrganizationRole-1
* Version - 1.24.0

=== 0074-DiagnosticServiceSectionID ===

* URL - http://terminology.hl7.org/CodeSystem/v2-0074
* Version - 2.9

=== HL7v3-EncounterType ===

* URL - http://terminology.hl7.org/ValueSet/v3-ActEncounterCode
* Version - 2014-03-26

=== FHIR-ProcedureCode ===
[TODO - is this the right valueset to use?]

* URL - http://hl7.org/fhir/ValueSet/procedure-code
* Version - 4.0.1

Publisher API HL7 Messages

2022-01-10T13:35:54Z

Sophie: Latest Version

__NOTOC__

This page summarises the messages that are currently supported by DDS

'''Acknowledgement'''

*[[Publisher API HL7 Messages#ACK: General acknowledgement|ACK]] - general acknowledgement

'''Records'''

*[[Publisher API HL7 Messages#ADT A28: Create patient record|ADT A28]] - create patient record
*[[Publisher API HL7 Messages#ADT A31: Update patient record|ADT A31]] - update patient record
*[[Publisher API HL7 Messages#ADT A34: Merge Patient Information - Patient ID Only|ADT A34]] - merge patient records

'''Encounters'''

*[[Publisher API HL7 Messages#ADT A01: Admit Patient|ADT A01]] - admit a patient
*[[Publisher API HL7 Messages#ADT A11: Cancel admit|ADT A11]] - cancel admit
*[[Publisher API HL7 Messages#ADT 02: Transfer a Patient|ADT A02]] - transfer a patient
*[[Publisher API HL7 Messages#ADT A12: Cancel transfer|ADT A12]] - cancel transfer
*[[Publisher API HL7 Messages#ADT A03: Discharge Patient|ADT A03]] - discharge a patient
*[[Publisher API HL7 Messages#ADT A13: Cancel discharge|ADT A13]] - cancel discharge
*[[Publisher API HL7 Messages#ADT A08: Update Patient Information|ADT A08]] - update patient information

'''Observations'''

*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation|ORU R01]] - send observations

'''Not currently defined'''

*[[Publisher API HL7 Messages#Not currently defined|Not currently defined]]

== Standard segments ==
See [[Publisher API HL7 Segments]] for definitions of the segments that are used across the DDS message set. Note that in many cases individual messages refine the standard definitions. Where this is the case it is made clear in the definition of each message below.

== Coded field mapping ==
DDS has a core set of codes for various concepts. A scheme must be defined that maps your local codes on to their DDS core equivalents

As a publisher you have two options open to you in terms of how coded values are mapped -

# Map at source
# Map in DDS

'''Map at source'''

Here the data that is published already contains the core DDS codes i.e. the mapping scheme is applied in ''your'' system. The onus is on you to maintain the mapping schemes within your local estate.

'''Map in DDS'''

Here the mapping scheme is applied when your data reaches the DDS i.e. local codes leave your system and are pushed in to DDS. The mapping scheme is maintained within DDS and DDS applies that scheme to the messages it receives.

Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core DDS codes. The distinction is around when and where the mapping is applied.

== ACK: General acknowledgement ==
This message is used to indicate whether or not DDS has successfully received an inbound message or not.

The value of MSH:9.2 (trigger event) is always the same as the trigger event in the inbound message that is being acknowledged.
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#MSA - Message acknowledgement|MSA - Message acknowledgement]]
|R
|N
|}
== ADT A28: Create patient record ==

=== Overview ===
This message will create a new patient record within DDS. [TODO - what happens if the record exists - will this act as A31?]

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|[[Publisher API HL7 Segments#PD1 - Patient Additional Demographic|PD1 - Patient Additional Demographics]]
|O
|N
|}
===Example===

== ADT A31: Update patient record ==

=== Overview ===
This message will update an existing patient record within DDS. [TODO - what happens if the record does not exist - will this act as A28?]

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|[[Publisher API HL7 Segments#PD1 - Patient Additional Demographic|PD1 - Patient Additional Demographics]]
|O
|N
|}
===Example===

== ADT A34: Merge Patient Information - Patient ID Only ==

=== Overview ===
This message is used when two patient records are merged at the patient identifier list level.

The "incorrect" identifier from MRG:4 is to be merged with the "correct" identifier from PID:3 where both identifiers have the same identifier type code.

In theory the identifier from MRG:4 should not be used in future transactions when referring to the patient.

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|[[Publisher API HL7 Segments#MRG - Merge Patient Information|MRG - Merge Patient Information]]
|R
|N
|}
===Example===
== ADT A01: Admit Patient ==

=== Overview ===
This will create an Encounter for the specified patient

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|R
|If not known please provide "UNKNOWN" for PV1:6.9
|^^^^^^^^UNKNOWN
|-
|PV1:4 - Admission Type
|R
|
|
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:14 - Admit source
|R
|
|
|-
|PV1:36 - Discharge Disposition
|X
|Ignored if supplied
|
|-
|PV1:37 - Discharged to Location
|X
|Ignored if supplied
|
|-
|PV1:44 - Admit Date/TIme
|R
|
|202105250824
|-
|PV1:45 - Discharge Date/Time
| X
|Ignored if supplied
|
|}

===Example===

== ADT A11: Cancel admit ==

=== Overview ===
The A11 is sent following the cancellation of an admission event (A01). The reason for cancellation could be that the original admission (A01) was created in error or that a decision was taken to not admit the patient.

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|X
|Ignored if supplied
|
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:36 - Discharge Disposition
|X
|Ignored if supplied
|
|-
|PV1:37 - Discharged to Location
|X
|Ignored if supplied
|
|-
|PV1:44 - Admit Date/TIme
|X
|Ignored if supplied
|
|-
|PV1:45 - Discharge Date/Time
| X
|Ignored if supplied
|
|}

===Example===

== ADT 02: Transfer a Patient ==

=== Overview ===
Records a patient transfer. Note that there can be three kinds of transfer -

# location transfer
# clinician transfer
# location and clinician transfer

In the case of a location transfer PV1:6 (prior patient location) will be populated along with PV1:3 (assigned patient location). In the case of clinician transfer PV1:9 (consulting doctor) will be updated. Note also that EVN:2 (recorded date/time) is used to track the actual time of transfer.

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|R
|If not known please provide "UNKNOWN" for PV1:6.9. If this is not a location transfer then provide the existing location. If this is a location transfer then provide the new location
|^^^^^^^^UNKNOWN
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name. If this is not a clinician transfer then provide the existing clinician. If this is a location transfer then provide the new clinician
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:36 - Discharge Disposition
|X
|Ignored if supplied
|
|-
|PV1:37 - Discharged to Location
|X
|Ignored if supplied
|
|-
|PV1:44 - Admit Date/TIme
|X
|Ignored if supplied. Instead see EVN:3.2 where the transfer time will be recorded
|
|-
|PV1:45 - Discharge Date/Time
| X
|Ignored if supplied
|
|}

===Example===

== ADT A12: Cancel transfer ==

=== Overview ===
The A12 is sent following the cancellation of a transfer event (A02). The reason for cancellation could be that the original transfer (A02) was created in error or that a decision was taken to not transfer the patient.

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|X
|Ignored if supplied
|
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:36 - Discharge Disposition
|X
|Ignored if supplied
|
|-
|PV1:37 - Discharged to Location
|X
|Ignored if supplied
|
|-
|PV1:44 - Admit Date/TIme
|X
|Ignored if supplied
|
|-
|PV1:45 - Discharge Date/Time
| X
|Ignored if supplied
|
|}

===Example===

== ADT A03: Discharge Patient ==

=== Overview ===
This message signals that the patient's stay in the healthcare facility has ended.

=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|X
|Ignored if supplied
|
|-
|PV1:6 - Prior Patient Location
|O
|If not known please provide "UNKNOWN" for PV1:6.9
|^^^^^^^^UNKNOWN
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:36 - Discharge Disposition
|R
|If not known please provide "UNKNOWN"
|UNKNOWN
|-
|PV1:37 - Discharged to Location
|R
|If not known please provide "UNKNOWN"
|19
|-
|PV1:44 - Admit Date/TIme
|R
|
|
|-
|PV1:45 - Discharge Date/Time
| R
|
|202105250824
|}

===Example===

== ADT A13: Cancel discharge ==

=== Overview ===
The A13 is sent following the cancellation of a discharge event (A03). The reason for cancellation could be that the discharge transfer (A03) was created in error or that a decision was taken to not discharge the patient.
=== Definition ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Optionality
!Notes
!Example
|-
|PV1:3 - Assigned Patient Location
|R
|Assigned Patient Location should record the location of the patient following the cancellation. In the case of a discharge created in error the location could be different from the patient’s location prior to the erroneous discharge. In this scenario the prior Location could be used to show the location before the erroneous A03 was sent. If Assigned Patient Location is not known please provide "UNKNOWN" for PV1:6.9
|^^^^^^^^UNKNOWN
|-
|PV1:9 - Consulting Doctor
|R
|If not known please provide "UNKNOWN" for the family name
|^UNKNOWN^^^^^^^^^^^^^^
|-
|PV1:36 - Discharge Disposition
|X
|Ignored if supplied
|
|-
|PV1:37 - Discharged to Location
|X
|Ignored if supplied
|
|-
|PV1:44 - Admit Date/TIme
|X
|Ignored if supplied
|
|-
|PV1:45 - Discharge Date/Time
| X
|Ignored if supplied
|
|}

===Example===

== ADT A08: Update Patient Information ==

=== '''Overview''' ===
An A08 message is used to update existing encounter information. Note that it is important to supply a value for PV1:19 (Visit number) in order to match the encounter to update.

[TODO] -

* confirm behaviour if A08 is sent an no encounter exists
* confirm what happens to the previous version of the updated data (is it retained and retrievable?)
* What are the rules around triggered an update, for example if a field is left blank in PV1 does that mean that the existing data in DDS will not be updated?
* is it only the PV1 segment that is used as a source data to update i.e. the PID segment is ignored?

=== '''Definition''' ===
'''Segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|R
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|PV1 - Patient Visit
|R
|N
|}
'''Fields'''

PV1 - Patient Visit

Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit|DDS standard definition of PV1]] -
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|PV1:2 - Patient Class
|PV1:2.1
|ID
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0004-PatientClass|0004-PatientClass]]
|
|-
|PV1:3 - Assigned Patient Location
|PV1:3.1
|IS
|O
|N
|General patient location
|
|-
|PV1:4 - Admission Type
|PV1:4.1
|ID
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0007-AdmissionType|0007-AdmissionType]]
|
|-
|PV1:6 - Prior Patient Location
|PV1:6.9
|ST
|O
|N
|Free text description of the location
|
|-
| rowspan="5" |PV1:7 - Attending Doctor
| -
| -
|O
|N
|Attending doctor. If provided, at least the family name must be given.
|
|-
|PV1:7.2
|ST
|R
|N
|Family Name
|
|-
|PV1:7.3
|ST
|O
|N
|Given Name
|
|-
|PV1:7.4
|ST
|O
|N
|Middle Names
|
|-
|PV1:7.6
|ST
|O
|N
|Prefix
|
|-
| rowspan="5" |PV1:8 - Referring Doctor
| -
| -
|O
|N
|Referring doctor. If provided, at least the family name must be given.
|
|-
|PV1:8.2
|ST
|R
|N
|Family Name
|
|-
|PV1:8.3
|ST
|O
|N
|Given Name
|
|-
|PV1:8.4
|ST
|O
|N
|Middle Names
|
|-
|PV1:8.6
|ST
|O
|N
|Prefix
|
|-
| rowspan="6" |PV1:9 - Consulting Doctor
| -
| -
|O
|N
|Consulting doctor. If provided, at least the family name must be given.
|
|-
|PV1:9.1
|ST
|R
|N
|ID number
|
|-
|PV1:9.2
|ST
|R
|N
|Family Name
|
|-
|PV1:9.3
|ST
|O
|N
|Given Name
|
|-
|PV1:9.4
|ST
|O
|N
|Middle Names
|
|-
|PV1:9.6
|ST
|O
|N
|Prefix
|
|-
|PV1:10 - Hospital Service
|PV1:10.1
|IS
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0069-HospitalService|0069-HospitalService]]
|
|-
|PV1:13 - Re-admission Indicator
|PV1:13.1
|IS
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0092-Re-AdmissionIndicator|0092-Re-AdmissionIndicator]]
|
|-
|PV1:14 - Admit source
|PV1:14.1
|IS
|O
|N
|Allowed values are from table [[Publisher API Code Sets#DDS-AdmissionSource|DDS-AdmissionSource]]
|
|-
|PV1:18 - Patient Type
|PV1:18.1
|IS
|O
|N
|Allowed values are from table [[Publisher API Code Sets#HL7v3-EncounterType|HL7v3-EncounterType]]
|
|-
|PV1:36 - Discharge Disposition
|PV1:36.1
|IS
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0112-DischargeDisposition|0112-DischargeDisposition]]
|
|-
|PV1:37 - Discharged to Location
|PV1:37.1
|ID
|O
|N
|Allowed values are from table [[Publisher API Code Sets#0113-DischargedToLocation|0113-DischargedToLocation]]
|
|-
|PV1:44 - Admit Date/Time
|PV1:44.1
|TS
|O
|N
|Admit timestamp
|
|-
|PV1:45 - Discharge Date/Time
|PV1:45.1
|TS
|O
|N
|Discharge timestamp
|}

== ORU R01: Unsolicited Observation ==

=== Overview ===
DDS supports two kinds of Observation -

*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Laboratory.29|Laboratory observation]]
*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Radiology.29|Radiology Observation]]

DDS differentiates these by examining the value of MSH:3.1. For Radiology observations that value MUST be "RADIOLOGY". Any other value is interpreted as a Laboratory observation.

==== Payload size constraints ====
The specification does allow for binary payloads to be carried within the R01 message however it should be noted that publishers should verify that the inbound (to DDS) interface that is being integrated with is capable of receiving that type of payload.

At the time of writing (Oct 2021) the DDS has a limit on the size of message that can be processed. This limitation is as a result of the queuing technology ([https://www.rabbitmq.com/ RabbitMQ]) that underpins the inbound message processing pipeline. There is a limit to the size of an individual message that can be processed hence it might be that binary payloads are not supported by the implementation at the time of integration.

'''Formatting of textual results'''

Both Laboratory and Radiology observations can carry results in the form of text. The way that the text is formatted in the publisher's source system can be important from a clinical safety perspective. This is because formatting can impact the way a clinician interprets the information in the text. At the moment the specification does not attempt to cater for formatting rules that should be applied by consuming systems. This is an area that requires further elaboration. Potentially the Formatted Text (FT) data type could be used to convey this information. More detail can be found in the HL7 v2 standard - http://www.hl7.eu/HL7v2x/v27/std27/ch02.html#Heading44 (retrieved on 27 Oct 2021).

==== Schema ====

[[File:ORU Schema.png]]

Note - In the diagram above the grey boxes are logical groupings of segments

=== Definition ===
'''segments'''
{| class="wikitable"
!Segment
!Optionality
!Repeating
|-
|[[Publisher API HL7 Segments#MSH - Message Header|MSH - Message Header]]
|R
|N
|-
|[[Publisher API HL7 Segments#EVN - Event Type|EVN - Event Type]]
|O
|N
|-
|[[Publisher API HL7 Segments#PID - Patient Identification|PID - Patient Identification]]
|R
|N
|-
|[[Publisher API HL7 Segments#PV1 - Patient Visit|PV1 - Patient Visit]]
|O
|N
|-
|[[Publisher API HL7 Segments#ORC - Common Order|ORC - Common Order]]
|O
|Y
|-
|[[Publisher API HL7 Segments#OBR - Observation Request|OBR - Observation Request]]
|C
|Y
|-
|[[Publisher API HL7 Segments#OBX - Observation or result|OBX - Observation or result]]
|C
|Y
|-
|[[Publisher API HL7 Segments#NTE - Notes and Comments|NTE - Notes and Comments]]
|O
|Y
|}

== ORU R01: Unsolicited Observation (Laboratory) ==

=== Overview ===
This message is used to transmit unsolicited laboratory results into DDS. [TODO - how to differentiate path from rad results?]

==== Interpretation of observations ====
Depending upon the structure of the R01, DDS will interpret the message in one of three ways.

===== Single textual laboratory report =====
The following criteria are used to determine if an OBR contains a single textual laboratory report -

* There are one or more OBX segments which when combined hold at least two lines of text
* Each OBX segment has a textual data type (TX, FT or ST)
* Each OBX segment has the same test ID as the others (OBX:3)

The OBX segments are interpreted as lines of a report as are any NTE segments directly associated with the OBR.

It's worth noting that OBX:13 can be used to carry details of any delay that is to be applied before the patient should see the results. If there is a delay associated with the report then this should be included on the first OBX segment.

===== Collection of individual test results =====
If an OBR group does not meet the criteria for a single textual laboratory report then DDS assumes it to contain a collection of individual test results. DDS considers the comments for a given test result (OBX) to be the combination of the comments (NTE segments) associated directly with the OBR plus the comments (NTE segments) associated directly with the test result.

'''Embedded PDF result'''

If OBX.2.1 (Value Type) contains "ED" then it is expected that the OBX segments contains an embedded, Base64-encoded PDF document

===== NTE - Notes and Comments =====
DDS will interpret comments differently depending on where in the R01 message an NTE segment is found -

* NTE segments that immediately follow the OBR segment are considered by DDS to apply to all results in the R01 message
* NTE segments immediately following an OBX segment are considered by DDS to apply only to the immediately preceding result

=== Definition ===
'''Fields'''

OBX - Observation

Refines the [[Publisher API HL7 Segments#OBX%20-%20Observation%20or%20result|DDS standard definition of OBX]] -
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|OBX:3 - Observation Identifier
|OBX:3.3
|ST
|R
|N
|DDS will only accept a measurement if this value is "SNOMED-CT"
|<nowiki>26604007 | Complete blood count (procedure)</nowiki>
|-
| rowspan="6" |OBX:5 - Observation value
| -
|VARIES
|
|N
|The number of sub-fields varies depending upon the value of OBX:2.1
|
|-
|OBX:5.1
|ST
|R
|N
|If OBX:2.1 = "ED" then this must be the source application
Otherwise the raw observation value
|
|-
|OBX:5.2
|ID
|C
|N
|Required if OBX:2.1 = "ED" and MUST be "document"
|document
|-
|OBX:5.3
|ID
|C
|N
|Required if OBX:2.1 = "ED" and MUST be "pdf"
|pdf
|-
|OBX:5.4
|ID
|C
|N
|Required if OBX:2.1 = "ED" and MUST be "Base64"
|Base64
|-
|OBX:5.5
|ST
|C
|N
|Required if OBX:2.1 = "ED" and must be Base64 encoded PDF document
|
|}
ORC - Common Order

Refines the [[Publisher API HL7 Segments#ORC - Common Order|DDS standard definition of ORC]] -
{| class="wikitable"
!Field
! Component
! Data Type
!Optionality
!Repeating
!Description
!Example
|-
|ORC:3 - Filler Order number
|ORC:3.1
|ST
|C
|N
|This string is required if OBR:3.1 is not provided
|
|}
=== Example ===

== ORU R01: Unsolicited Observation (Radiology) ==

=== Overview ===

==== Interpretation of observations ====
DDS can interpret a radiology observation in three different ways -

# as a single textual report with multiple image attachments
# as carrying an embedded PDF report

It's worth noting that OBX:13 can be used to carry details of any delay that is to be applied before the patient should see the results. If there is a delay associated with the report then this should be included on the first OBX segment.

Single textual report with multiple image attachments

If an OBX segments contains an image (OBX:2.1 = "ED" and OBX:5.2 = "image") then the image will be extracted and added as an attachment to the textual report. The ordering of the OBX segments containing images is not meaningful to DDS.

An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by DDS and it will concatenate them to form a single textual report. Note that each segment will be delineated by a UNIX line feed character (escape sequence - \n Unicode character - U+000A).

Embedded PDF report

DDS interprets a radiology observation in this way if the following is true -
OBX:2.1 = "ED" and OBX:5.2 = "document" and OBX:5.3 = "pdf"
An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by DDS and it will concatenate them to form a narrative block that will be associated with the PDF element of the observation.

=== Definition ===
'''Fields'''

OBX - Observation

Refines the [[Publisher API HL7 Segments#OBX - Observation or result|DDS standard definition of OBX]] -
{| class="wikitable"
!Field
! Component
! Data Type
!Optionality
!Repeating
!Description
!Example
|-
|OBX:2 - Value Type
|OBX:2.1
|ID
|R
|N
|Radiology messages only support FT, TX or ED
|ED
|-
|OBX:3 - Observation Identifier
|OBX:3.2
|ST
|O
|N
|Needed to allow consumers to understand the type of radiology study that this observation represents. Note that if this is not specified then the OBR:4.2 value must be present. In this case the OBR:4.2 value is interpreted as the test code
|X-ray pelvis
|-
| rowspan="6" |OBX:5 - Observation value
| -
|VARIES
|
|N
|The number of sub-fields varies depending upon the value of OBX:2.1
|
|-
|OBX:5.1
|ST
|R
|N
|If OBX:2.1 = "ED" then this must be the source application
Otherwise the raw observation value
|
|-
|OBX:5.2
|ID
|C
|N
|Required if OBX:2.1 = "ED" and MUST be "image" or "document"
|image
|-
|OBX:5.3
|ID
|C
|N
|Required if OBX:2.1 = "ED"
if OBX:5.2 = "image" then MUST be "TIFF"

else if OBX:5.2 = "document" then must be "pdf"
|TIFF
|-
|OBX:5.4
|ID
|C
|N
|Required if OBX:2.1 = "ED" and MUST be "Base64"
|Base64
|-
|OBX:5.5
|ST
|C
|N
|Required if OBX:2.1 = "ED" and must be Base64 encoded image or PDF document
|
|}

== Not currently defined ==
The following types of message are not currently in scope or need further elaboration
{| class="wikitable"
!Use case
!Messaging type
!Status
|-
|DICOM
|ORU - Unsolicited Results
|NOT IN SCOPE
|-
|Microbiology - discrete results
|ORU - Unsolicited Results
|REQUIRES ELABORATION (see https://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_LRI_R1_STU3_2018JUN.pdf section 8.9.1)
|-
|Virology - discrete results
|ORU - Unsolicited Results
|REQUIRES ELABORATION (see https://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_LRI_R1_STU3_2018JUN.pdf section 8.9.1)
|-
|Display formatting of text results
|ORU - Unsolicited Results
|REQUIRES ELABORATION (see [[Publisher API HL7 Messages#ORU%20R01:%20Unsolicited%20Observation|Formatting of textual results]])
|}

Publisher API HL7 Segments

2022-01-10T13:34:50Z

Sophie: Latest Version

== Introduction ==
Below are all of the segments that a DDS Publisher using the HL7 API can send. The definitions below are generic and hence are relatively permissive. In the context of a specific message the segment various segment definitions may be refined to take account of the data needed to complete the business function associated with the message. More detail can be found on the [[Publisher API HL7 Messages|HL7 API messages page]]

== Coded fields ==
Note that currently only a subset of the coded fields that are specified in the segments below are interpreted by DDS (see below). The remainder are left as-is once ingested in to DDS are are not processed further. In this latter case it is recommended that publishers take note of the suggested code sets as in the future it might be that these fields are interpreted by DDS and therefore a mapping exercise will need to be undertaken to map from publisher local codes to a core DDS code set.

* Primary Language - PID:15
* Religion - PID:17
* Ethnic Group - PID:22
* Admission Type - PV1:4
* Hospital Service - PV1:10
* Admit Source - PV1:14
* Patient Type - PV1:18
* Discharge Disposition - PV1:36
* Discharged to Location - PV1:37

== MSA - Message acknowledgement ==

=== Overview ===
The MSA segment contains information sent whilst acknowledging an inbound message. The following rules govern the nature of the acknowledgement -

* If the message could not be saved to the DDS message store then an AR (failure occurred, retry) acknowledgement code is returned.
* If the message is malformed, or fails sender, recipient or message type checks, or is missing a message control ID, or fails for an unexpected reason, an AE (failure occurred, move to next message) acknowledgement code is returned.
* If the message passes the above checks and is saved to the message store, an AA (success) acknowledgement code is returned.
* If the message receiver fails to send an acknowledgement (e.g. network outage, hardware failure etc), it is expected the sender will automatically re attempt to send the message.

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|MSA:1 - Acknowledgement code
|MSH:1.1
|ID
|R
|N
|Message type. Allowed values are from table [[Publisher API Code Sets#DDS-HL7v2-AckCode|DDS-HL7v2-AckCode]]
|
|-
|MSA:2 - Message control ID
|MSH:1.1
|ST
|R
|N
|Unique (to DDS) identifier assigned by DDS
|
|-
|-
|MSA:3 - Text message
|MSA:3.1
|ST
|O
|N
|Further describes an error condition (may not always be provided by DDS)
|
|}

== MSH - Message Header ==

=== Overview ===
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|MSH.1 - Field Separator
|MSH:1.1
|ST
|R
|N
|Defines the character to be used as the separator in the message
|
|-
|MSH.2 - Encoding characters
|MSH:2.1
|ST
|R
|N
|Contains (in the following order) component separator, repetition separator, escape character, and subcomponent separator
|
|-
|MSH:3 - Sending application
|MSH:3.1
|ST
|R
|N
|Sending application name
|
|-
|MSH:4 - Sending facility
|MSH:4.1
|ST
|R
|N
|Sending facility name
|
|-
|MSH:5 - Receiving application
|MSH:5.1
|ST
|R
|N
|Receiving application name
|
|-
|MSH:6 - Receiving facility
|MSH:6.1
|ST
|R
|N
|Receiving facility name
|
|-
|MSH:7 - Message timestamp
|MSH:7.1
|DT
|R
|N
|Datetime that the sending system created the message
|
|-
|-
| rowspan="3" |MSH:9 - Message type
| -
| -
|R
|N
|
|
|-
|MSH:9.1
|ID
|R
|N
|Message type. Values SHOULD be from table [[Publisher API Code Sets#DDS-HL7v2-MessageType|DDS-HL7v2-MessageType]]
|
|-
|MSH:9.2
|ID
|R
|N
|Trigger event. Values SHOULD be from table [[Publisher API Code Sets#DDS-HL7v2-EventType|DDS-HL7v2-EventType]]
|
|-
|MSH:10 - Message control ID.
|MSH:10.1
|ST
|R
|N
|This must be unique for all messages sent to DDS by each publisher. However, DDS does not currently detect or reject duplicate messages based on this value, so it is important that each publisher enforces this themselves.
|
|-
|MSH:11 - Processing ID
|MSH:11.1
|PT
|O
|N
|In production MUST be "P"
|
|-
|MSH:12 - Message version
|MSH:12.1
|ID
|R
|N
|The version of HL7 that this message conforms to. MUST be "2.3"
|
|}

== EVN - Event Type ==

=== Overview ===
The EVN segment is used to communicate trigger event information to receiving applications

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|EVN:1 - Event Type Code
|EVN:1.1
|ID
|O
|N
|The value should be the same as theMSH:9.2 (trigger event)
|
|-
|EVN:2 - Recorded Date/Time
|EVN:2.1
|TS
|R
|N
|Timestamp of when the transaction was entered
|
|-
|EVN:3 - Date/Time planned event
|EVN:3.1
|TS
|O
|N
|Avoid populating this field. Instead use PV2 expected admit date and PV2 expected discharge date whenever possible.
|
|-
|EVN:4 - Event reason code
|EVN:4.1
|CWE
|O
|N
|The reason for this event. Allowed values are from table [[Publisher API Code Sets#0062-EventReason|0062-EventReason]]
|
|-
| rowspan="5" |EVN:5 - Operator ID
| -
| -
|O
|N
|Operator ID. If provided, at least the family name must be given.
|
|-
|EVN:5.2
|ST
|R
|N
|Family Name
|
|-
|EVN:5.3
|ST
|O
|N
|Given Name
|
|-
|EVN:5.4
|ST
|O
|N
|Middle Names
|
|-
|EVN:5.6
|ST
|O
|N
|Prefix
|
|-
|EVN:6 - Event occured
|EVN:6.1
|TS
|O
|N
|This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient)), this field would contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being canceled occurred.
|
|}

== PID - Patient Identification ==

=== Overview ===
The PID segment is used as the main way of communicating patient identification information. The majority of patient identifying and demographic information held within the PID segment is not subject to frequent changes

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|PID:2 - Patient ID
| -
| -
|X
|N
|Not used. Instead please populate PID.3 Patient Identifier List
|
|-
| rowspan="3" |PID:3 - Patient Identifier List
| -
| -
|R
|N
|Patient Identifier List. This list must include at least both of the following (in order) -

* the patient's local (to the publisher) identifier. In this instance the assigning authority (PID:3.4) must be "MRN"
*the patient's NHS number. In this instance the assigning authority (PID:3.4) must be "NHS"
|
|-
|PID:3.1
|ST
|R
|Y
|Patient ID
|
|-
|PID:3.4
|ST
|R
|N
|Assigning authority
|
|-
| rowspan="5" |PID:5 - Patient Name
| -
| -
|R
|N
|
|
|-
|PID:5.1
|ST
|R
|N
|Family name
|
|-
|PID:5.2
|ST
|O
|N
|Given name
|
|-
|PID:5.3
|ST
|O
|N
|Middle names
|
|-
|PID:5.5
|ST
|O
|N
|Title
|
|-
|PID:7
|PID:7.1
|TS
|R
|N
|Date of birth
|
|-
|PID:8
|PID:8.1
|IS
|R
|N
|Administrative sex. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#AdministrativeSex|AdministrativeSex]]
|
|-
| rowspan="8" |PID:11 - Patient Address
| -
| -
|O
|N
|
|
|-
|PID:11.1
|ST
|O
|N
|Address line 1
|
|-
|PID:11.2
|ST
|O
|N
|Address line 2
|
|-
|PID:11.3
|ST
|O
|N
|City
|
|-
|PID:11.5
|ST
|O
|N
|Post code
|
|-
|PID:11.6
|ID
|O
|N
|Country. Values SHOULD be from table [[Publisher API Code Sets#0399-CountryCode|0399-CountryCode]]
|
|-
|PID:11.7
|ID
|O
|N
|Address usage eg temporary address
|
|-
|PID:11.9
|IS
|O
|N
|County
|
|-
| rowspan="3" |PID:13 - Home contact information
| -
| -
|O
|N
|
|
|-
|PID:13.1
|TN
|O
|N
|Contact value
|
|-
|PID:13.2
|ID
|O
|N
|Contact use code. Allowed values are "home" or "mobile"
|
|-
| rowspan="3" |PID:14 - Work contact information
| -
| -
|O
|N
|
|
|-
|PID:14.1
|TN
|O
|N
|Contact value
|
|-
|PID:14.2
|ID
|O
|N
|Contact use code. Allowed values is "work"
|
|-
| rowspan="2" |PID:15 - Primary language
| -
| -
|O
|N
|Primary language. This should be the ISO 639-1 code or one of the five communication method extensions defined in the NHS Data Dictionary code set.
|
|-
|PID:15.1
|ST
|O
|N
|Primary language. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source]<nowiki> then allowed values are child concepts of the SNOMED CT World Languages concept - 297289008 | World languages (qualifier value) |</nowiki>
|
|-
|PID:17 - Religion
|PID:17.1
|IS
|O
|N
|Religion. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/religious_or_other_belief_system_affiliation_code.html RELIGIOUS OR OTHER BELIEF SYSTEM AFFILIATION CODE]
|
|-
|PID:18 - Patient Account Number
|PID:18.1
|ST
|C
|N
|Though officially this field is intended to capture account number it has been repurposed in DDS. It is used to carry the identifier for the episode of care. Simplistically an episode of care encapsulates all of the encounters that a patient may have with a healthcare organisation from the point of referral to the point of discharge.
If the publisher does not have the concept of episode of care then instead this MUST be the same value as that found in PV1.19 - Visit number.

If no PV1 segment accompanies this PID segment then PID:18 should not be populated
|
|-
|PID:22 - Ethnic group
| -
| -
|O
|N
|
|
|-
|
|PID:22.1
|ST
|O
|N
|Ethnicity identifier. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/data_elements/ethnic_category.html?hl=ethnicity ETHNIC CATEGORY]
|
|-
|PID:29 - Patient Death Date and Time
|PID:29.1
|TS
|C
|N
|If PID.30:1 is not empty and PID:30.1 == "Y" then PID:29 is mandatory
|
|-
|PID:30 - Patient Death Indicator
|PID:30.1
|ID
|O
|N
|"Y" or "N"
|
|}

== PD1 - Patient Additional Demographic ==

=== Overview ===
The PD1 segment contains demographic information about a patient that is likely to change. In the case of DDS is it used to carry GP data.

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
| rowspan="3" |PD1:3 - Patient Primary Facility
| -
| -
|R
|N
|
|
|-
|PD1:3.1
|ST
|R
|N
|name
|
|-
|PD1:3.3
|ST
|R
|N
|ODS code
|
|-
| rowspan="5" |PD1:4 - Patient Primary Care Provider Name and ID No
| -
| -
|R
|N
|
|
|-
|PD1:4.1
|ST
|R
|N
|GMC code
|
|-
|PD1:4.2
|FN
|R
|N
|Family name
|
|-
|PD1:4.3
|ST
|R
|N
|Given name
|
|-
|PD1:4.6
|ST
|O
|N
|Prefix
|
|}
== MRG - Merge Patient Information ==

=== Overview ===
The MRG segment is used by DDS to support merging of patient identifiers

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|MRG:1 - Prior Patient Identifier List
|MRG:1.1
| CX
|R
|N
|MUST only contain one value - the patient's local (to the publisher) identifier.
|
|-
|MRG:2 - Prior Alternate Patient ID
|
|CX
|X
|N
|Ignored if supplied
|
|-
|MRG:3 - Prior Alternate Account Number
|
|CX
|X
|N
|Ignored if supplied
|
|-
|MRG:4 - Prior Patient ID
|
| -
|X
|N
|Ignored if supplied
|
|-
|MRG:5 - Prior Visit Number
|
|CX
|X
|N
|Ignored if supplied
|
|-
|MRG:6 - Prior Alternate Visit ID
|
|CX
|X
|N
|Ignored if supplied
|
|-
|MRG:7 - Prior Patient Name
| -
| XPN
|X
|N
|Ignored if supplied
|
|} 

== PV1 - Patient Visit ==

=== Overview ===
The PV1 segment is used by Registration/Patient Administration applications to communicate information on a visit-specific basis.

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|PV1:2 - Patient Class
|PV1:2.1
|ID
|R
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#PatientClass|PatientClass]]
|
|-
|PV1:3 - Assigned Patient Location
|PV1:3.1
|IS
|R
|N
|General patient location
|
|-
|PV1:4 - Admission Type
|PV1:4.1
|ID
|O
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/admission_method.html ADMISSION METHOD]
|
|-
| rowspan="5" |PV1:8 - Referring Doctor
| -
| -
|O
|N
|Referring doctor. If provided, at least the family name must be given.
|
|-
|PV1:8.1
|ST
|O
|N
|ID number
|
|-
|PV1:8.2
|ST
|O
|N
|Family Name
|
|-
|PV1:8.3
|ST
|O
|N
|Given Name
|
|-
|PV1:8.6
|ST
|O
|N
|Prefix
|
|-
| rowspan="5" |PV1:9 - Consulting Doctor
| -
| -
|R
|N
|Consulting doctor. If provided, at least the family name must be given.
|
|-
|PV1:9.1
|ST
|R
|N
|ID number
|
|-
|PV1:9.2
|ST
|R
|N
|Family Name
|
|-
|PV1:9.3
|ST
|O
|N
|Given Name
|
|-
|PV1:9.6
|ST
|O
|N
|Prefix
|
|-
|PV1:10 - Hospital Service
|PV1:10.1
|IS
|R
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/treatment_function_code.html TREATMENT FUNCTION CODE]
|
|-
|PV1:14 - Admit source
|PV1:14.1
|IS
|O
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/source_of_admission.html SOURCE OF ADMISSION]
|
|-
|PV1:18 - Patient Type
|PV1:18.1
|IS
|R
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#HL7v3-EncounterType|HL7v3-EncounterType]]
|
|-
|PV1:19 - Visit Number
|PV1:19.1
|CX
|R
|N
|Visit ID. Should uniquely identify an Encounter from the DDS publisher.
|
|-
|PV1:36 - Discharge Disposition
|PV1:36.1
|IS
|O
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/discharge_method.html DISCHARGE METHOD]
|
|-
|PV1:37 - Discharged to Location
|PV1:37.1
|ID
|O
|N
|If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/discharge_destination.html DISCHARGE DESTINATION]
|
|-
|PV1:44 - Admit Date/Time
|PV1:44.1
|TS
|C
|N
|Admit timestamp
|
|-
|PV1:45 - Discharge Date/Time
|PV1:45.1
|TS
|O
|N
|Discharge timestamp
|
|}

== NTE - Notes and Comments ==

=== Overview ===
The NTE segment is used to hold comments [TODO - are there any constraints on the size of an individual comment]

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|NTE:3 - Comment
|NTE:3.1
|FT
|R
|Y
|Comment
|
|}

== ORC - Common Order ==

=== Overview ===
The ORC segment is used to carry information that is common across an order

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|ORC:3 - Filler Order number
|ORC:3.1
|ST
|O
|N
|This string must uniquely identify an order from other orders in the filling system
|
|-
| rowspan="4" |ORC:21 - Ordering Facility name
| -
| -
|R
|N
|Used to differentiate between different sources of result data (eg GP vs acute settings)
|
|-
|ORC:21.1
|ST
|O
|N
|Facility name
|
|-
|ORC:21.3
|ST
|R
|N
|Facility ID. Note that this MUST be the ODS code of the ordering facility
|
|-
|ORC:21.7
|ID
|R
|N
|Facility ID type. Values SHOULD be from table [[Publisher API Code Sets#0074-DiagnosticServiceSectionID|0074-DiagnosticServiceSectionID]]
|
|}

== OBR - Observation Request ==

=== Overview ===
DDS interprets an OBR as either representing a single textual laboratory report or a collection of individual test results. More information can be found in the [[Publisher API HL7 Messages#ORU_R01:_Unsolicited_Observation_.28Laboratory.29|ORU R01]] - Unsolicited Observation definition.
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|OBR:3 - Filler Order number
|OBR:3.1
|ST
|C
|N
|OBR:3-filler order number is identical to ORC:3-filler order number.
If the filler order number is not present in the ORC, it must be present in the associated OBR
|
|-
| rowspan="5" |OBR:4 - Universal Service Identifier
| -
| -
|R
|N
|
|
|-
|OBR:4.1
|ST
|R
|N
|Service Identifier
|
|-
|OBR:4.2
|ST
|R
|N
|Service name
|
|-
|OBR:4.3
|ID
|R
|N
|Service coding system. Allowed values are [TODO]
|
|-
|OBR:4.5
|ST
|O
|N
|Alternative service name
|
|-
|OBR:7 - Observation date/time
|ORC:7.1
|TS
|C
|N
|Observation timestamp. If this is not present, OBX:14 is used instead. It is an error for neither to be provided.
|
|-
| rowspan="5" |OBR:16 - Ordered by
|
|
|O
|N
|If provided, at least the family name must be given.
|
|-
|OBR:16.2
|ST
|R
|N
|Family Name
|
|-
|OBR:16.3
|ST
|O
|N
|Given Name
|
|-
|OBR:16.4
|ST
|O
|N
|Middle Names
|
|-
|OBR:16.6
|ST
|O
|N
|Prefix
|
|-
|OBR:24 - Discipline
|OBR:24.1
|ID
|O
|N
|This field is the section of the diagnostic service where the observation was performed.
If the study was performed by an outside service, the identification of that service should be recorded here. Values SHOULD be from table [[Publisher API Code Sets#0074-DiagnosticServiceSectionID|0074-DiagnosticServiceSectionID]]
|
|-
|OBR:25 - Result status
|OBR:25.1
|ID
|O
|N
|Only values of F and C will be processed. Values of I, O, P or X (which indicate pending or no results) are silently ignored, whilst any other values will cause an error. Values SHOULD be from table [[Publisher API Code Sets#DDS-ResultStatus|DDS-ResultStatus]]
|
|}

=== Definition ===

== OBX - Observation or result ==

=== Overview ===
The OBX segment can carry an observation about the patient or it can also be used to carry test results.

=== Definition ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|OBX:1 - Set ID
|OBX:1.1
|SI
|R
|N
|Sequence number for OBX. Must be unique under its associated OBR segment
|
|-
|OBX:2 - Value Type
|OBX:2.1
|ID
|R
|N
|Values SHOULD be from table [[Publisher API Code Sets#0125-ValueType|0125-ValueType]]
|
|-
| rowspan="4" |OBX:3 - Observation Identifier
| -
| CWE
|R
|Y
|If this is a textual report, this value will be overridden by OBR:4. Otherwise this value must be provided.
|
|-
|OBX:3.1
|ST
|R
|N
|Test ID. If this is a textual report, this value will be overridden by OBR:4.1. Otherwise this value must be provided. If a measurement is being provided, this ID must match one of the predefined values which DDS can accept. At the time of writing the acceptable code systems are still being defined though there is an aspiration to adopt the [https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-data-and-technology-standards/clinical-information-standards#unified-test-list National Unified Test List] where appropriate. Note that this does not exclude the adoption of more appropriate code systems depending upon the nature of the observation
|
|-
|OBX:3.2
|ST
|O
|N
|Test Name
|
|-
|OBX:3.3
|ST
|C
|N
|Test coding system. If this is a textual report, this value will be overridden by OBR:4.3.
|
|-
|OBX:5 - Observation Value
| OBX:5.1
| VARIES
|R
|N
|Value. Type MUST match OBX:2.1
|
|-
| rowspan="4" |OBX:6 - Observation Units
| -
| -
|O
|N
|
|
|-
|OBX:6.1
|ST
|R
|N
|Unit ID
|
|-
|OBX:6.2
|ST
|O
|N
|Unit Name
|
|-
|OBX:6.3
|ST
|R
|N
|Unit coding system
|
|-
|OBX:7
|OBX:7.1
|ST
|O
|N
|Reference range. Can be used to convey low value, high value and normal value. DDS will parse the data into one or more of these categories depending upon how the reference range value is formatted 

* [low value]"-"[high value]
* "<"[Number] (i.e. "less than number")
* ">"[Number] (i.e. "greater than number")
* "<="[Number] (i.e. "less than or equal to number")
* ">="[Number] (i.e. "greater than or equal to number")
* [Alphabetic value indicating normal value]
|See table below for examples
|-
| rowspan="4" |OBX:8 - Abnormal flag
| -
| -
|C
|N
|To flag the result as abnormal (e.g., High, Low) this flag MUST be sent in the message
|
|-
|OBX:8.1
|
|R
|N
|Flag ID - Values SHOULD be from table <nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki>
|
|-
|OBX:8.2
|
|O
|
|Flag name
|
|-
|OBX:8.3
|
|O
|N
|Flag coding system - If present then SHOULD be "<nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki>"
|
|-
|OBX:11
|ST
|O
|N
|Result status
|Result status. Only values of F and C will be processed. Values of I, O, P or X (which indicate pending or no results) are silently ignored, whilst any other values will cause an error. Values SHOULD be from table [[Publisher API Code Sets#DDS-ResultStatus|DDS-ResultStatus]]
|
|-
|OBX:13
|ST
|O
|N
|Custom access rules
|Custom access rules for lab results. Currently supported: "{patientDelay:NUMBERdays}" with any whole number in place of "NUMBER" (no spaces). The patient will see that a lab result has arrived, but the result value will not be revealed until the set number of days past the date/time of observation have passed. If this field is not specified the patient will be able to see their results immediately. Note: if this OBR group is a textual report spanning multiple OBX segments, the delay must be provided in the first.
|{patientDelay:3days}
|-
|OBX:14
|ST
|C
|N
|Date/Time of the Observation
|Observation timestamp. If this is not present, OBR:7 is used instead. It is an error for neither to be provided.
|
|
|-
| rowspan="5" |OBX:16 - Responsible Observer
|
|
|O
|N
|If provided, at least the family name must be given.
|
|-
|OBX:16.2
|ST
|R
|N
|Family Name
|
|-
|OBX:16.3
|ST
|O
|N
|Given Name
|
|-
|OBX:16.4
|ST
|O
|N
|Middle Names
|
|-
|OBX:16.6
|ST
|O
|N
|Prefix
|}

=== Reference range ===
{| class="wikitable"
!OBX:7 value
!Low value
!High value
!Normal value
|-
|"3-4"
|3
|4
| -
|-
|"3--4"
|3
| -4
| -
|-
|"-3-4"
| -3
|4
| -
|-
|"3 - 4"
|3
|4
| -
|-
|" 5"
| -
| -
|5
|-
|">5"
| -
| -
|">5"
|-
|"POS"
| -
| -
|"POS"
|}