HL7v2 API
This document specifies the technical details for accessing and using the Discovery Data Service HL7v2 API, for the use by interoperability system suppliers developing integrations against the service.
The Discovery Data Service (DDS) is an NHS owned service that provides low cost access to personal health and care data from combined primary, secondary, unscheduled and community health care data sets (https://discoverydataservice.org/Content/Overview.htm)
All data that is published or subscribed to and from DDS is governed by strict information governance rules and underpinned by Data Sharing Agreements, Sharing Flows and Subscriber Extract Projects (https://discoverydataservice.org/Content/Governance.htm)
DDS receives data from multiple source publishing systems in multiple formats and normalises the data into a common structure based on national care record standards.
DDS can receive HL7v2 structured ADT and ORU messages from Secondary Care systems, and transform them into the Discovery FHIR store, from where the data gets transformed into subscriber databases for reporting.
The Discovery HL7v2 API uses a secure authentication and authorisation service. This uses recommended standards for identity and access management, using OpenID Connect and OAuth 2.0 methods, and also includes an additional security layer, where DDS checks it’s internal User Management service to ensure that each user is authorised with the necessary role based access profiles to use each particular application. This allows for tokens and user access to be centrally managed and revoked within the DDS User Manager application.
Two API calls are used for the HL7v2 API:
- Authenticate
- Authorise/ProcessMessage
Authenticate
Authenticate the client identity by passing in client credentials to receive an access token for the API.
The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user.
The authorization server MUST authenticate the client.
https://devauthentication.discoverydataservice.net/authenticate/$gettoken
Passing this JSON POST body (no header required)
{
"grantType": "client_credentials",
"clientId": "hl7v2-api",
"clientSecret": "888b4f03-3264-4d89-b6a8-9c9a502ad0d0"
}
The grantType parameter must be set to client_credentials.
(the client secret is unique to each client application and can be acquired by contacting the Discovery Data Service Helpdesk at info@discoverydataservice.org )
If the access token request is valid and authorized, the authorization server issues an access token in this JSON reply, or a 404 HTTP Not Found (Unauthorized Client) response if the request failed client authentication or is invalid.
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}
NOTE: A refresh token SHOULD NOT and is not included, as specified in the OAuth 2.0 standards.
https://tools.ietf.org/html/rfc6749#section-4.4
Authorise/ProcessMessage
Post HL7v2 messages to a REST API.
This call uses the access token from the authentication API to authorise the client's access to the API, which will then post the HL7v2 message to DDS if the client is recognised and authorised to use this service.
https://devhl7.discoverydataservice.net/hl7/$process-message
Passing this JSON POST body
{
"meta": {
"profile": [
"https://hl7.org.uk/V2/OperationDefinition/ProcessMessage-Operation-1"
],
"tag": [
{
"system": "https://hl7.nhs.uk/Id/ODS-Code",
"code": "RYJ",
"display": "IMPERIAL COLLEGE HEALTHCARE NHS TRUST"
}
]
},
"resourceType": "HL7v2",
"messageType": "LaboratoryResult",
"id": "4847653a-7b39-4d7e-928f-a9fa6d833dd4",
"identifier": [
{
"system": "https://hl7.org.uk/Id/dds",
"value": "1716"
}
],
"creationTime": "2012-10-23T00:00:00+00:00",
"messageEventType": [
{
"valueCodeableConcept": {
"coding": [
{
"system": "https://hl7.nhs.uk/V2/CodeSystem/EMS-MessageEventType-1",
"code": "new",
"display": "New event message"
}
]
},
"url": "https://hl7.nhs.uk/V2/StructureDefinition/Extension-EMS-MessageEventType-1"
}
],
"body": "MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4 PID|||07827717281||JANET^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^
^TESTVILLE^EL4^35292||(01)33452232|(01)348439949||||AC555444444||67-A4335^LONDON^20030520 OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||
0283829292^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||02992888292^SMITH^HOWARD H^^^^MD OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F"
}
Note: The body elements contains the HL7v2 message. The rest of the JSON is the wrapper specification for the message.
Set the Authorization header in the REST POST call to the value of the access_token returned from the authentication API.
Note: Access tokens expire if they are not used according to the value set in the expires_in attribute of the Client Credentials authentication method response.
If this API fails to authorise the access token against the Discovery identity and access management service, then an Unauthorised return value will be sent with a 401 HTTP Status (Unauthorized).
Success will return a 200 OK HTTP status, after the message is filed into DDS.
Workflow
HL7 V2 Publisher message specifications
See main article HL7 ADT and ORU and FHIR which provides an overview of the messages and segments supported by DDS specific to two publishers
See main article Publisher HL7 V2 API Messages which specifies the evolving common preferred approach to the content of HL7 V2 messages when these are selected by publishers as the way of sending some data to Discovery, where FHIR capability does not yet exist
HL7 -V2 FHIR profile maps
See main article HL7 V2 to FHIR Store mappings which provides an overview of the conceptual map between HL7V2 segments, FHIR resources and FHIR elements