UKCore Hackathon Supporting Guide

Traditional Document Exchange

Pattern

• Send Document

The document and document metadata is sent directly to the recipient.

Pros

• Simple to establish
• Mimics traditional transfer of care processes
• Like for like replacement of fax and email with more automation support.
• Independent of http or MESH transports
• Compatibility with NHS England projects including Virtual Wards, Transfer of Care and GP Connect Send Document

Cons

• Concurrency Issues (document is correct at point of creation, corrections or updates can make interaction complex)
• No UK standards. Future work on UKCore-DocumentReference (document metadata) should answer part of this.
• Document duplication, which one is correct?
• Suited for point to point sharing only

FHIR Technical Framework Options

This pattern may be sent in several ways in FHIR. They overlap especially around the content of the FHIR resources. They should have low technical overhead with only minor amendments required.

RESTful API

The document metadata and document are individually to the recipient. This would involve the following interactions.

• POST /Binary to store the document. See demonstration POST /Binary
• POST /DocumentReference to store the document metadata. See demonstration POST /DocumentReference

It is likely this would need to be complemented with patient demographic interactions, such as searching for an existing patient record or adding a new record.

Transactions

This contains the same interactions listed in the previous section and is sent in a single interaction using the FHIR Bundle resource.

• POST / to send a collection of the RESTful interactions. See demonstration POST /

This is the recommended option in IHE-MHD ITI-65

Messaging

This has a defined set of resources and for Sending Documents, this is likely to include FHIR DocumentReference, Binary and Patient. In FHIR this is defined in a FHIR MessageDefinition i.e. documents

It is sent via the following interaction.

• POST /$process-message See demonstration example Provide Document Message example on POST /$process-message

Share Clinical Documents

Pattern

• Sharing Clinical Documents

Builds on Traditional Document Exchange with the documents being sent to a document repository instead of individual recipients.

Document and Document Metadata are shared via open api’s. The document metadata is used to query for patient patient documents

Pros

• Repositories can either be in NHS Wales (DHCW), NHS England (Waystation) or in English Trusts
• Potential compatibility for English Trusts with NHS England projects e.g. NRLF and Waystation
• Documents can easily be shared with other care providers (not just Wales)
• Has more standardisation e.g. IHE XDS and/or MHD which existing systems may already support.
• Builds on common patterns of handling documents in NHS providers
• English NHS Trusts can control access to documents if documents are shared from English repositories.

Cons

• Lack of notification support. Documents are now going to repository not a user. Recipients are not informed of clinical events
• No UK standards/patterns. Future work on UKCore-DocumentReference (document metadata) should answer part of this.

FHIR Technical Framework Options

The extra interactions added by this option are all RESTful API based.

They are likely follow all of the following: UKCore FHIR Access, and IHE-MHD.

The interactions are:

• GET /DocumentReference Find Documents. See demonstration GET /DocumentReference
• GET /Binary This can be any url (and so not a FHIR endpoint) to retrieve the document. See demonstration GET /Binary

Share Clinical Document plus Notifications

Pattern

• Event Notifications

Builds on both Traditional Document Exchange and Share Clinical Documents and adds event notification feeds to interested parties.

Document and Document Metadata are shared via open api’s. The document metadata is used to query for patient patient documents

Pros

• Builds on widespread existing support for patient admissions and discharges in acute trusts.
• Can be extended to feed a Master Patient Index (MPI)
• Extends patient admission and discharge notifications from acute only to primary, mental health and social care.
• Can be used to send practitioner or patient notifications using Alerts

Cons

• Makes use HL7 v2 standard, however it is believed this can be converted to FHIR
• HL7 v2 ADT standardisation is not widespread. If HL7 v2 is chosen, it is recommended HSCIC ITK - HL7v2 Interoperability Message Specification is used as this has similar data model to UKCore-Patient and UKCore-Encounter.

FHIR Technical Framework Options

This is a topic for discussion. It is likely suggestions here include FHIR Message and FHIR RESTful. HL7 mappings of HL7 v2 to FHIR favour the use of FHIR Messaging or Transactions.

However the use of identifiers (NHS Number, ODS Codes, GMP/GMC codes, etc) in the UK would also allow a mapping to single FHIR Resource. E.g. a HL7 v2 ADT_A03/A03/A04 would map to a FHIR Encounter, HL7 v2 ADT_A28/A31 would map to a FHIR Patient.

This leads to the following interactions:

• POST /Encounter See demonstration POST /Encounter
• POST /Patient See demonstration POST /Patient