Voror_Wiki - User contributions [en-gb]

Record Viewer/Immunisations

2021-04-30T11:50:29Z

DarrenS: record viewer image

[[Category:Help]]
Immunisations displays current and historical administration of vaccines.

Use this section to help you to:

*[[Record Viewer/Immunisations#Immunisations|View Immunisations]]


== View Immunisations ==

#[[File:Screenshot 2021-04-30 at 12.40.33.png|alt=|thumb|800x800px|Example Immunisations screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Immunisations''' .
#:Immunisations displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Immunisations'''
#:*'''Effective date'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Integrated Patient Care Record Viewer/Family history|Family history]]

File:Screenshot 2021-04-30 at 12.40.33.png

2021-04-30T11:50:24Z

DarrenS:

record viewer image

Record Viewer/Family history

2021-04-30T11:49:56Z

DarrenS: record viewer image

[[Category:Help]]
Family history displays significant health conditions for a person related to the patient relevant in the context of care for the selected patient.

Use this section to help you to:

*[[Record Viewer/Family history#Family history|View Family history]]


== View Family history ==

#[[File:Screenshot 2021-04-30 at 12.40.10.png|alt=|thumb|800x800px|Example Family history screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Family history''' .
#:Family history displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Family history'''
#:*'''Effective date'''
#:*'''Practitioner'''
#:*'''Date of encounter'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.40.10.png

2021-04-30T11:49:50Z

DarrenS:

record viewer image

Record Viewer/Referral requests

2021-04-30T11:49:24Z

DarrenS: record viewer image

[[Category:Help]]
Referral requests displays records of requests for a referral service or transfer of the selected patient to the care of another provider or provider organisation.

Use this section to help you to:

*[[Record Viewer/Referral requests#Referral requests|View Referral requests]]


== View Referral requests ==

#[[File:Screenshot 2021-04-30 at 12.40.00.png|alt=|thumb|800x800px|Example Referral requests screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Referral requests''' .
#:Referral requests displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Recipient'''
#:*'''Priority'''
#:*'''Type'''
#:*'''Mode'''
#:*'''Speciality'''
#:*'''Date of referral
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.40.00.png

2021-04-30T11:49:17Z

DarrenS:

record viewer image

Record Viewer/Procedures

2021-04-30T11:48:38Z

DarrenS: record viewer image

[[Category:Help]]
Procedures displays the details of procedures performed on the selected patient.

Use this section to help you to:

*[[Record Viewer/Procedures#Procedures|View Procedures]]


== View Procedures ==

#[[File:Screenshot 2021-04-30 at 12.39.49.png|alt=|thumb|800x800px|Example Procedures screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Procedures''' .
#:Procedures displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Procedures'''
#:*'''Effective date'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.39.49.png

2021-04-30T11:48:30Z

DarrenS:

record viewer image

Record Viewer/Procedure requests

2021-04-30T11:48:04Z

DarrenS: record viewer image

[[Category:Help]]
Procedure requests displays records of requests for a procedure to be performed.

Use this section to help you to:

*[[Integrated Patient Care Record Viewer/Procedure requests#Procedure requests|View Procedure requests]]


== View Procedure requests ==

#[[File:Screenshot 2021-04-30 at 12.39.35.png|alt=|thumb|800x800px|Example Procedure requests screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Procedure requests''' .
#:Procedure requests displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Procedure requests'''
#:*'''Status'''
#:*'''Effective date'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.39.35.png

2021-04-30T11:47:57Z

DarrenS:

record viewer image

Record Viewer/Diagnostic reports

2021-04-30T11:47:12Z

DarrenS: record viewer image

[[Category:Help]]
Diagnostic reports displays the findings and interpretation of diagnostic tests performed on the selected patient.

Use this section to help you to:

*[[Record Viewer/Diagnostic reports#diagnostic reports|View Diagnostic reports]]
*[[Record Viewer/Diagnostic reports#trend charts|View trend charts]]


== View Diagnostic reports ==

#[[File:Screenshot 2021-04-30 at 12.39.25.png|alt=|thumb|700x700px|Example Diagnostics reports screen]][[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Diagnostic reports''' .
#:Diagnostic reports displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Battery'''
#:*'''Diagnostic report'''
#:*'''Result'''
#:*'''Effective date'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner
{{Filter}}

 
== View trend charts ==
#[[File:Trend chart.jpg|thumb|700x700px|Example Trend chart|alt=]][[Access Record Viewer]].
#[[Record Viewer/Diagnostic reports#diagnostic reports|View Diagnostic reports]].
#Select the required diagnostic item check box(es), and then click to display a trend chart.
#If required, in the '''Date from''' and '''Date to''' fields, type the dates that you want the chart to cover, or click to use the calendar functions.
#If required, in the '''Select series''' field, select the items that you want to display on the chart.
#If required, select one or more of the following options to format the trend chart:
#:*Show gridlines
#:*Show area chart
#:*Gradient fill
#:*Logarithmic
#:{{Tip| Hover over the chart to show details of individual items: date, diagnostic test, and value.}}

'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.39.25.png

2021-04-30T11:47:03Z

DarrenS:

record viewer image

Record Viewer/Observations

2021-04-30T11:45:46Z

DarrenS: record viewer image

[[Category:Help]]
Observations displays measurements and simple assertions made about the selected patient.

Use this section to help you to:

*[[Record Viewer/Observations#observations|View Observations]]


== View Observations ==

#[[Accessing Record Viewer|Access Record Viewer]].
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Observations''' .
#:Observations displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed">{{Demographic}}</div>
#:*'''Observations'''
#:*'''Category'''
#:*'''Effective date'''
# Click to expand specific conditions and display the following details:
#:*Source of data
#:*Practitioner

{{Filter}}
'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

Record Viewer/Allergies

2021-04-30T11:43:27Z

DarrenS: record viewer image

[[Category:Help]]
Allergies & intolerances displays the clinical assessment of the selected patient's allergies or intolerances.

Use this section to help you to:

*[[Record Viewer/Allergies#allergies|View Allergies & intolerances]]


== View Allergies & intolerances==

#[[Accessing Record Viewer|Access Record Viewer]].
#[[File:Screenshot 2021-04-30 at 12.37.18.png|alt=|thumb|800x800px|Example Allergies & intolerances screen]]If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Allergies''' .
#:Allergies displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Allergies & intolerances'''
#:*'''Effective date'''
# Click to expand specific allergies and display the following details:
#:*Source of data
#:*Onset date
#:*Practitioner

{{Filter}}

'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.37.18.png

2021-04-30T11:43:20Z

DarrenS:

record viewer image

Record Viewer/Medication

2021-04-30T11:42:46Z

DarrenS: record viewer image

Medication displays a record of acute and repeat medication that has been prescribed for the selected patient, including past medication.

Use this section to help you to:

*[[Record Viewer/Medication#medication|View Medication]]


== View Medication ==

#[[Accessing Record Viewer|Access Record Viewer]].[[File:Screenshot 2021-04-30 at 12.37.08.png|alt=|thumb|800x800px|Example Medication screen]]
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Medication''' .
#:Medication displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Current medication'''
#:*'''Dose'''
#:*'''Status'''
#:*'''Date prescribed'''
#Click to expand specific medications and display the following details:
#:*Type
#:*Last issued
#:*Source of data
#:*Dosage
#:*Quantity
#:*Start date
#:*Status
#:*Practitioner

{{Filter}}

'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.37.08.png

2021-04-30T11:42:39Z

DarrenS:

record viewer image

Record Viewer/Conditions

2021-04-30T11:41:47Z

DarrenS: record viewer image

[[Category:Help]]
Conditions displays the selected patient's clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept, that has risen to a level of concern.

Use this section to help you to:

*[[Record Viewer/Conditions#conditions|View Conditions]]


== View Conditions ==

#[[Accessing Record Viewer|Access Record Viewer]].[[File:Screenshot 2021-04-30 at 12.36.56.png|alt=|thumb|800x800px|Example Conditions screen]]
#If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Conditions''' .
#:Conditions displays the following details for the '''selected patient''':
#:<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-demographic">{{Demographic}}</div>
#:*'''Condition'''
#:*'''Status'''
#:*'''Onset date'''
# Click to expand specific conditions and display the following details:
#:*Status
#:*Source of data
#:*Onset date
#:*Problem end date
#:*Practitioner

{{Filter}}

'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.36.56.png

2021-04-30T11:41:39Z

DarrenS:

record viewer image

Record Viewer/Care record summary

2021-04-30T11:36:17Z

DarrenS: /* View Care record summary */

[[Category:Help]]
Care record summary displays a summary of the selected patient's key care record events.

Use this section to help you to:

*[[Record Viewer/Care record summary#care record summary|View Care record summary]]


== View Care record summary ==

#[[Accessing Record Viewer|Access Record Viewer]].
#[[File:Screenshot 2021-04-30 at 12.35.52.png|alt=|thumb|800x800px|Example Care Record Summary screen]]If required, in the [[Record Viewer/Patient demographics/RV navigation side menu|Record Viewer navigation side menu]], click '''Care record summary''' .
#:{{Info| Care record summary is the default view.}}The Care record summary displays the following key care events for the selected patient:
#:*'''Active conditions/problems'''
#:*'''Allergies & intolerances'''
#:*'''Health status'''
#:*'''Current medication'''
#:*'''Recent encounters'''
#:*'''Warnings & flags'''
# Click to expand specific care record events and display the following details:
#:*'''Active conditions/problems''':
#:**Status
#:**Onset date
#:**Source of data
#:**Practitioner
#:***
#:*'''Allergies & intolerances''':
#:** Effective date
#:** Source of data
#:** Practitioner
#:*'''Health status''':
#:**Source of data
#:**Practitioner
#:*'''Current medication''':
#:**Type
#:**Dosage
#:**Status
#:**Last issued
#:**Quantity
#:**Practitioner
#:**Source of data
#:**Start date
#:*'''Recent encounters''':
#:**Source of data
#:**Practitioner
#:*'''Warnings & flags''':
#:**Status
#:**Source of data
#:**Onset date

{{Demographic}}

'''See also:'''

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic orders|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.35.52.png

2021-04-30T11:36:07Z

DarrenS:

record viewer image

Record Viewer

2021-04-30T11:32:05Z

DarrenS: record viewer image

[[File:Screenshot 2021-04-30 at 12.30.34.png|alt=|thumb|777x777px|Example Record Viewer screen showing the default Care Record Summary view]]
{{Help}}

The Discovery Data Service (DDS) receives data from source organisations (publishers), transforms the data into a common model, stores the data, and then distributes the data to organisations (subscribers), subject to data sharing agreements, consent and satisfactory security arrangements.

Record Viewer shows a combined view of an individual's patient records, using data from different source organisations.

* [[Accessing Record Viewer]]

Use Record Viewer to view:

*[[Record Viewer/Patient demographics|Patient demographics]]
*[[Record Viewer/Care record summary|Care record summary]]
*[[Record Viewer/Conditions|Conditions]]
*[[Record Viewer/Medication|Medication]]
*[[Record Viewer/Allergies|Allergies]]
*[[Record Viewer/Warnings & flags|Warnings & flags]]
*[[Record Viewer/Registries|Registries]]
*[[Record Viewer/Appointments|Appointments]]
*[[Record Viewer/Encounters|Encounters]]
*[[Record Viewer/Observations|Observations]]
*[[Record Viewer/Diagnostic reports|Diagnostic orders]]
*[[Record Viewer/Diagnostic reports|Diagnostic reports]]
*[[Record Viewer/Procedure requests|Procedure requests]]
*[[Record Viewer/Procedures|Procedures]]
*[[Record Viewer/Referral requests|Referral requests]]
*[[Record Viewer/Family history|Family history]]
*[[Record Viewer/Immunisations|Immunisations]]

File:Screenshot 2021-04-30 at 12.30.34.png

2021-04-30T11:31:23Z

DarrenS:

record viewer

Secure publication to the DDS

2020-06-22T09:39:31Z

DarrenS:

Data is transferred, via HSCN, into the DDS HSCN connected AWS instance in one of the four following ways:

* SFTP Pull
* SFTP Push
* HTTPS Post
* MLLP Send

=== SFTP Pull ===

GPSoC IM1 pairing directly with the publisher’s system supplier. The data is pulled by the DDS from the suppliers SFTP and then onto a publisher specific SFTP folder structure in Discovery’s AWS instance over a TLS 1.2 encrypted link. Data from EMIS is pgp encrypted at source.

=== SFTP Push ===

The data is pushed from the publisher's SFTP into the DDS and then onto a publisher specific SFTP folder structure in Discovery’s AWS instance over a TLS 1.2 encrypted link.

=== HTTPS REST Post ===

The data is posted to the DDS and then onto a publisher specific data structure in Discovery’s AWS instance over a TLS 1.2 encrypted link.

=== MLLP Send ===

Messages are posted over VPN TLS 1.2 encrypted links into the DDS HL7 receiver and then onto Discovery’s AWS instance.

===AWS Security===

As a hosting organisation, AWS has in place over 50 security and compliance certifications including ISO 27001, 27017, 27018; PCI DSS; SOC 1/2/3; and Cyber Essentials Plus.

The DDS is built on this platform and makes use of multiple enhanced features to secure the data; these include encrypting all networks to at least TLS 1.2 with high strength ciphers, ensuring all data at rest (such as in databases) or data in transit (such processing queues) is encrypted, administrative access is controlled using VPN with 2FA, access controls, and all access to the systems is logged & audited.

The system has been designed to exceed the requirements set out in the NHS Data Security Protection Toolkit.

===HSCN Certification===

The Discovery platform has an HSCN to AWS connection that has been certified.

The connection is provided through our IG agreement with Tower Hamlets CCG ODS code 08V.

HL7v2 API

2020-06-10T17:24:46Z

DarrenS:

==Introduction==
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)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "hl7v2-api",
"clientSecret": "888b4f03-3264-4d89-b6a8-9c9a502ad0d0"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:23:47Z

DarrenS:

==Introduction==
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)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:23:29Z

DarrenS:

==Introduction==
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)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:22:08Z

DarrenS:

==Introduction==
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.

<nowiki>https://devauthentication.discoverydataservice.net/authenticate/$gettoken</nowiki>

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:21:01Z

DarrenS:

==Introduction==
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.

<nowiki>https://devauthentication.discoverydataservice.net/authenticate/$gettoken</nowiki>

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:18:02Z

DarrenS:

==Introduction==
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.

<nowiki>https://devauthentication.discoverydataservice.net/authenticate/$gettoken</nowiki>

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:16:22Z

DarrenS:

==Introduction==
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.

<nowiki>https://devauthentication.discoverydataservice.net/authenticate/$gettoken</nowiki>

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"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.

<nowiki>https://tools.ietf.org/html/rfc6749#section-4.4</nowiki>

===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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-10T17:14:29Z

DarrenS:

==Introduction==
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.

<nowiki>https://devauthentication.discoverydataservice.net/authenticate/$gettoken</nowiki>

Passing this JSON POST body (no header required)
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at <nowiki>https://learning-health.co.uk/</nowiki>)

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.

<nowiki>https://tools.ietf.org/html/rfc6749#section-4.4</nowiki>

===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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

FHIR Get Structured Record API

2020-06-10T17:11:51Z

DarrenS:

{{DISPLAYTITLE:FHIR Get Structured Record API}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== 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)<syntaxhighlight lang="json">
{
"grantType": "client_credentials",
"clientId": "fhir-api",
"clientSecret": "6d8e1310-5e9c-4b62-b314-79fbd9c735d5"
}
</syntaxhighlight>The <code>grantType</code> parameter must be set to <code>client_credentials</code>.

(the client secret is unique to each client application and can be acquired by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/)

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.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxxxxxxxxxxxxx",
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "97260f48-23c4-408d-8af2-d528fc17390c",
"expires_in": 60
}

</syntaxhighlight>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/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

FHIR Get Structured Record API

2020-06-07T10:04:29Z

DarrenS:

{{DISPLAYTITLE:FHIR Get Structured Record API}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== Authenticate ===
Authenticate the client identity by passing in client credentials to receive an access token for the API.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/).

This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call.

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>Note: this will return as updated refresh token along with each new access token request, and retrieves the access token based on updated refresh token.

=== Authorise/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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 within 60 seconds.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

HL7v2 API

2020-06-07T10:03:50Z

DarrenS:

==Introduction==
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.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/). This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call. Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>Note: this will return as updated refresh token along with each new access token request, and retrieves the access token based on updated refresh token.

===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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

Voror Health Platform

2020-06-05T09:52:41Z

DarrenS:

DRAFT: These pages are at an early stage of development, with many articles to be lifted from the Discovery document repository.

The articles describe and define Discovery Data Service functionality and technology; the architecture that underpins the data service software, the components that make up the service, the testing and assurance processes, and the resources, technologies, and software that are used to host, develop, and support the service.

= 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.

= Information model related topics =

These articles provide information about the services, structure, and functionality that operate using the Discovery Common Information Model; 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:

*[[Common_information_model|Discovery common information model]] - an overview of the components of the common model, leading to details of each component.
*[[Health_data_model_content|Discovery health data model ]] - a very high level overview of the types of data held within the Discovery data stores.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[Data modelling language|Discovery information modelling language]] - describes the machine and human readable language used to build the information model and for computers to process or manipulate data

= Operational and interoperability topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

*[[Secure_publication_to_the_DDS|Secure publication to the DDS]] - lists the technical interfaces in place for receiving data from publishers.
*[[Remote_Subscriber_Database_(RSD)_SQL_guide|Remote Subscriber Database (RSD) SQL guide]] - provides information for subscribers that wish to host their own copy of data supplied by Discovery.
*[[Remote_Subscriber_Database_(RSD)_AWS_hosting_setup_guide|Remote Subscriber Database (RSD) AWS hosting setup guide]] - provides information for subscribers who want to set up their data in AWS.
*[[Generic_publisher_system_data_requirements|Generic publisher system data requirements]] - provides a set of guides for systems that are publishing data through the Discovery Data Service.
*[[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_mapping_to_the_commmon_model|Publishers and mapping to the common model]] - provides the specification for how supplier system information is mapped to the common model, using FHIR as the intermediary.

= Services =

These articles provide information about the services provided by the Discovery Data Service and the underlying functionality.

*[[Simple_generic_query_service|Simple Generic query Service]] - a service that provides data on request for data that might be conceptually very complex, but falls into simple common patterns.
*[[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]]

= Technologies =

These articles provide information about the technologies used in the Discovery Data services, including summaries of considerations and tests that have been undertaken when selecting technologies.

*[[Graph_or_relational_databases|Graph versus relational database ]] - considers two of the approaches for storing the main health care record stores.

= Publisher system known issues =

This section documents the known long standing problems relating to systems that publish data to Discovery. The issues as categorised by supplier and system. These issues need to be taken into account when configuring the services to process the data. The issues do not include short term glitches or errors.

*[[EMIS_known_issues|EMIS]]
*[[TPP_known_issues|TPP]]

= 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.

FHIR GetStructuredRecord API

2020-06-05T09:49:54Z

DarrenS: DarrenS moved page FHIR GetStructuredRecord API to FHIR Get Structured Record API

#REDIRECT [[FHIR Get Structured Record API]]

FHIR Get Structured Record API

2020-06-05T09:49:53Z

DarrenS: DarrenS moved page FHIR GetStructuredRecord API to FHIR Get Structured Record API

{{DISPLAYTITLE:FHIR Get Structured Record API}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== Authenticate ===
Authenticate the client identity by passing in client credentials to receive an access token for the API.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/).

This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call.

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
=== Authorise/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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 within 60 seconds.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

Template:DISPLAYTITLE

2020-06-05T09:45:15Z

DarrenS: Created page with "{{DISPLAYTITLE:FHIR Get Structured Record API}}"

FHIR Get Structured Record API

2020-06-05T09:38:41Z

DarrenS:

{{DISPLAYTITLE:FHIR Get Structured Record API}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== Authenticate ===
Authenticate the client identity by passing in client credentials to receive an access token for the API.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/).

This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call.

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
=== Authorise/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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 within 60 seconds.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

FHIR Get Structured Record API

2020-06-05T09:37:30Z

DarrenS:

{{DISPLAYTITLE:FHIR}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== Authenticate ===
Authenticate the client identity by passing in client credentials to receive an access token for the API.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/).

This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call.

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
=== Authorise/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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 within 60 seconds.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

FHIR Get Structured Record API

2020-06-05T09:35:20Z

DarrenS:

{{DISPLAYTITLE:FHIR Get Structured Record API}}

== Introduction ==
This document specifies the technical details for accessing and using the Discovery Data Service FHIR® Care Connect 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 makes the data available to multiple subscribers in standardised formats, one of the common formats being FHIR®.

The Discovery FHIR CareConnect $getstructuredrecord 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.

The following FHIR CareConnect FHIR STU3 resources are currently supported by the API.

AllergyIntolerance, Condition, MedicationStatement, Medication, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Encounter, EpisodeOfCare, DiagnosticReport, FamilyMemberHistory, Immunization, Location, Procedure, ProcedureRequest, ReferralRequest, RelatedPerson, Appointment.

Two API calls are used for the FHIR CareConnect $getstructuredrecord API:

* Authenticate
* Authorise/GetRecord

=== Authenticate ===
Authenticate the client identity by passing in client credentials to receive an access token for the API.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/).

This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call.

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
=== Authorise/GetRecord ===
Retrieve a patient's structured care record as a FHIR bundle in the FHIR CareConnect STU3 format. See https://fhir.hl7.org.uk/

This call uses the access token from the authentication API to authorise the client's access to the API, which will return the FHIR bundle if the client is recognised and authorised to use this service.

https://devfhir.discoverydataservice.net/patient/$getstructuredrecord

Passing this JSON POST body<syntaxhighlight lang="json">

{
"meta": {
"profile": [
"https://fhir.hl7.org.uk/STU3/OperationDefinition/CareConnect-GetStructuredRecord-Operation-1"
]
},
"resourceType": "Parameters",
"parameter": [
{
"name": "patientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/nhs-number",
"value": "5558526785"
}
},
{
"name": "patientDOB",
"valueIdentifier": {
"system": "https://fhir.hl7.org.uk/Id/dob",
"value": "1970-01-01"
}
}
]
}

</syntaxhighlight>'''Note:''' The patientDOB parameter is optional.

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 within 60 seconds.

[[File:Options.png|border|600x600px]]

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 the FHIR bundle for the patient specified in the query parameters.

=== Workflow ===
[[File:Workflow.png|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

Voror Health Platform

2020-06-05T09:30:57Z

DarrenS:

DRAFT: These pages are at an early stage of development, with many articles to be lifted from the Discovery document repository.

The articles describe and define Discovery Data Service functionality and technology; the architecture that underpins the data service software, the components that make up the service, the testing and assurance processes, and the resources, technologies, and software that are used to host, develop, and support the service.

= 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.

= Information model related topics =

These articles provide information about the services, structure, and functionality that operate using the Discovery Common Information Model; 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:

*[[Common_information_model|Discovery common information model]] - an overview of the components of the common model, leading to details of each component.
*[[Health_data_model_content|Discovery health data model ]] - a very high level overview of the types of data held within the Discovery data stores.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[Data modelling language|Discovery information modelling language]] - describes the machine and human readable language used to build the information model and for computers to process or manipulate data

= Operational and interoperability topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

*[[Secure_publication_to_the_DDS|Secure publication to the DDS]] - lists the technical interfaces in place for receiving data from publishers.
*[[Remote_Subscriber_Database_(RSD)_SQL_guide|Remote Subscriber Database (RSD) SQL guide]] - provides information for subscribers that wish to host their own copy of data supplied by Discovery.
*[[Remote_Subscriber_Database_(RSD)_AWS_hosting_setup_guide|Remote Subscriber Database (RSD) AWS hosting setup guide]] - provides information for subscribers who want to set up their data in AWS.
*[[Generic_publisher_system_data_requirements|Generic publisher system data requirements]] - provides a set of guides for systems that are publishing data through the Discovery Data Service.
*[[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_mapping_to_the_commmon_model|Publishers and mapping to the common model]] - provides the specification for how supplier system information is mapped to the common model, using FHIR as the intermediary.

= Services =

These articles provide information about the services provided by the Discovery Data Service and the underlying functionality.

*[[Simple_generic_query_service|Simple Generic query Service]] - a service that provides data on request for data that might be conceptually very complex, but falls into simple common patterns.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR GetStructuredRecord API|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]]

= Technologies =

These articles provide information about the technologies used in the Discovery Data services, including summaries of considerations and tests that have been undertaken when selecting technologies.

*[[Graph_or_relational_databases|Graph versus relational database ]] - considers two of the approaches for storing the main health care record stores.

= Publisher system known issues =

This section documents the known long standing problems relating to systems that publish data to Discovery. The issues as categorised by supplier and system. These issues need to be taken into account when configuring the services to process the data. The issues do not include short term glitches or errors.

*[[EMIS_known_issues|EMIS]]
*[[TPP_known_issues|TPP]]

= 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.

HL7v2 API

2020-06-04T20:06:08Z

DarrenS: /* Workflow */

==Introduction==
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.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/). This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call. Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
===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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:HL7v2 workflow.png|alt=|600x600px]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

File:HL7v2 workflow.png

2020-06-04T20:04:52Z

DarrenS:

HL7v2 workflow

HL7v2 API

2020-06-04T19:56:36Z

DarrenS:

==Introduction==
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.

https://devauthentication.discoverydataservice.net/authenticate/$gettoken

Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "password",
"clientId": "information-manager",
"userName": "XXXXXXXXXXX",
"password": "XXXXXXXXXXXX"
}

</syntaxhighlight>(userName and password can be requested by contacting the Learning Health Solutions Helpdesk at https://learning-health.co.uk/). This API call returns an authorisation access_token in this JSON reply, or a 404 HTTP Not Found response if the user is not recognised.<syntaxhighlight lang="json">
{
"access_token": "xxxxxxxx",
"refresh_token": "xxxxxxxxx",
"refresh_expires_in": 1800,
"not-before-policy": 1548863201,
"scope": "profile email",
"token_type": "bearer",
"session_state": "79b125f5-f062-4a4c-a5a6-b2fa4519e8ad",
"expires_in": 60
}

</syntaxhighlight>An access token can also be retrieved using the refresh_token value, once the user's identity has been authenticated using the above call. Passing this JSON POST body (no header required)<syntaxhighlight lang="json">
{
"grantType": "refresh_token",
"clientId": "information-manager",
"userName": "",
"password": "<refresh_token_value>"
}

</syntaxhighlight>
===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<syntaxhighlight lang="json">
{
"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"
}
</syntaxhighlight>'''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 within 60 seconds.

[[File:Options.png|border|600x600px|link=https://wiki.discoverydataservice.org/File:Options.png]]

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===
[[File:Workflow.png|600x600px|link=https://wiki.discoverydataservice.org/File:Workflow.png]]

The Discovery Data Service is powered by Learning Health Solutions Ltd. https://learning-health.co.uk/

Voror Health Platform

2020-06-04T19:46:29Z

DarrenS:

DRAFT: These pages are at an early stage of development, with many articles to be lifted from the Discovery document repository.

The articles describe and define Discovery Data Service functionality and technology; the architecture that underpins the data service software, the components that make up the service, the testing and assurance processes, and the resources, technologies, and software that are used to host, develop, and support the service.

= 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.

= Information model related topics =

These articles provide information about the services, structure, and functionality that operate using the Discovery Common Information Model; 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:

*[[Common_information_model|Discovery common information model]] - an overview of the components of the common model, leading to details of each component.
*[[Health_data_model_content|Discovery health data model ]] - a very high level overview of the types of data held within the Discovery data stores.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[Data modelling language|Discovery information modelling language]] - describes the machine and human readable language used to build the information model and for computers to process or manipulate data

= Operational and interoperability topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

*[[Secure_publication_to_the_DDS|Secure publication to the DDS]] - lists the technical interfaces in place for receiving data from publishers.
*[[Remote_Subscriber_Database_(RSD)_SQL_guide|Remote Subscriber Database (RSD) SQL guide]] - provides information for subscribers that wish to host their own copy of data supplied by Discovery.
*[[Remote_Subscriber_Database_(RSD)_AWS_hosting_setup_guide|Remote Subscriber Database (RSD) AWS hosting setup guide]] - provides information for subscribers who want to set up their data in AWS.
*[[Generic_publisher_system_data_requirements|Generic publisher system data requirements]] - provides a set of guides for systems that are publishing data through the Discovery Data Service.
*[[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_mapping_to_the_commmon_model|Publishers and mapping to the common model]] - provides the specification for how supplier system information is mapped to the common model, using FHIR as the intermediary.

= Services =

These articles provide information about the services provided by the Discovery Data Service and the underlying functionality.

*[[Simple_generic_query_service|Simple Generic query Service]] - a service that provides data on request for data that might be conceptually very complex, but falls into simple common patterns.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR GetStructuredRecord 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]]

= Technologies =

These articles provide information about the technologies used in the Discovery Data services, including summaries of considerations and tests that have been undertaken when selecting technologies.

*[[Graph_or_relational_databases|Graph versus relational database ]] - considers two of the approaches for storing the main health care record stores.

= Publisher system known issues =

This section documents the known long standing problems relating to systems that publish data to Discovery. The issues as categorised by supplier and system. These issues need to be taken into account when configuring the services to process the data. The issues do not include short term glitches or errors.

*[[EMIS_known_issues|EMIS]]
*[[TPP_known_issues|TPP]]

= 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.

HL7v2 API

2020-06-04T19:44:46Z

DarrenS: Created page with "aaa"

aaa

Voror Health Platform

2020-06-04T19:42:53Z

DarrenS:

DRAFT: These pages are at an early stage of development, with many articles to be lifted from the Discovery document repository.

The articles describe and define Discovery Data Service functionality and technology; the architecture that underpins the data service software, the components that make up the service, the testing and assurance processes, and the resources, technologies, and software that are used to host, develop, and support the service.

= 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.

= Information model related topics =

These articles provide information about the services, structure, and functionality that operate using the Discovery Common Information Model; 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:

*[[Common_information_model|Discovery common information model]] - an overview of the components of the common model, leading to details of each component.
*[[Health_data_model_content|Discovery health data model ]] - a very high level overview of the types of data held within the Discovery data stores.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[Data modelling language|Discovery information modelling language]] - describes the machine and human readable language used to build the information model and for computers to process or manipulate data

= Operational and interoperability topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

*[[Secure_publication_to_the_DDS|Secure publication to the DDS]] - lists the technical interfaces in place for receiving data from publishers.
*[[Remote_Subscriber_Database_(RSD)_SQL_guide|Remote Subscriber Database (RSD) SQL guide]] - provides information for subscribers that wish to host their own copy of data supplied by Discovery.
*[[Remote_Subscriber_Database_(RSD)_AWS_hosting_setup_guide|Remote Subscriber Database (RSD) AWS hosting setup guide]] - provides information for subscribers who want to set up their data in AWS.
*[[Generic_publisher_system_data_requirements|Generic publisher system data requirements]] - provides a set of guides for systems that are publishing data through the Discovery Data Service.
*[[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_mapping_to_the_commmon_model|Publishers and mapping to the common model]] - provides the specification for how supplier system information is mapped to the common model, using FHIR as the intermediary.

= Services =

These articles provide information about the services provided by the Discovery Data Service and the underlying functionality.

*[[Simple_generic_query_service|Simple Generic query Service]] - a service that provides data on request for data that might be conceptually very complex, but falls into simple common patterns.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR GetStructuredRecord API]] - Returns a complete patient record in a structured format following GP and Care Connect standards.
*[[HL7v2 API|FHIR GetStructuredRecord 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]]

= Technologies =

These articles provide information about the technologies used in the Discovery Data services, including summaries of considerations and tests that have been undertaken when selecting technologies.

*[[Graph_or_relational_databases|Graph versus relational database ]] - considers two of the approaches for storing the main health care record stores.

= Publisher system known issues =

This section documents the known long standing problems relating to systems that publish data to Discovery. The issues as categorised by supplier and system. These issues need to be taken into account when configuring the services to process the data. The issues do not include short term glitches or errors.

*[[EMIS_known_issues|EMIS]]
*[[TPP_known_issues|TPP]]

= 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.

Voror Health Platform

2020-06-04T19:38:42Z

DarrenS: /* Services */

DRAFT: These pages are at an early stage of development, with many articles to be lifted from the Discovery document repository.

The articles describe and define Discovery Data Service functionality and technology; the architecture that underpins the data service software, the components that make up the service, the testing and assurance processes, and the resources, technologies, and software that are used to host, develop, and support the service.

= 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.

= Information model related topics =

These articles provide information about the services, structure, and functionality that operate using the Discovery Common Information Model; 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:

*[[Common_information_model|Discovery common information model]] - an overview of the components of the common model, leading to details of each component.
*[[Health_data_model_content|Discovery health data model ]] - a very high level overview of the types of data held within the Discovery data stores.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[Data modelling language|Discovery information modelling language]] - describes the machine and human readable language used to build the information model and for computers to process or manipulate data

= Operational and interoperability topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

*[[Secure_publication_to_the_DDS|Secure publication to the DDS]] - lists the technical interfaces in place for receiving data from publishers.
*[[Remote_Subscriber_Database_(RSD)_SQL_guide|Remote Subscriber Database (RSD) SQL guide]] - provides information for subscribers that wish to host their own copy of data supplied by Discovery.
*[[Remote_Subscriber_Database_(RSD)_AWS_hosting_setup_guide|Remote Subscriber Database (RSD) AWS hosting setup guide]] - provides information for subscribers who want to set up their data in AWS.
*[[Generic_publisher_system_data_requirements|Generic publisher system data requirements]] - provides a set of guides for systems that are publishing data through the Discovery Data Service.
*[[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_mapping_to_the_commmon_model|Publishers and mapping to the common model]] - provides the specification for how supplier system information is mapped to the common model, using FHIR as the intermediary.

= Services =

These articles provide information about the services provided by the Discovery Data Service and the underlying functionality.

*[[Simple_generic_query_service|Simple Generic query Service]] - a service that provides data on request for data that might be conceptually very complex, but falls into simple common patterns.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR GetStructuredRecord API]] - Returns a complete patient record in a structured format following GP and Care Connect standards.
*[[FHIR GetStructuredRecord 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]]

= Technologies =

These articles provide information about the technologies used in the Discovery Data services, including summaries of considerations and tests that have been undertaken when selecting technologies.

*[[Graph_or_relational_databases|Graph versus relational database ]] - considers two of the approaches for storing the main health care record stores.

= Publisher system known issues =

This section documents the known long standing problems relating to systems that publish data to Discovery. The issues as categorised by supplier and system. These issues need to be taken into account when configuring the services to process the data. The issues do not include short term glitches or errors.

*[[EMIS_known_issues|EMIS]]
*[[TPP_known_issues|TPP]]

= 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.