InterOp from a Supplier perspective

This is an update to this post Sharing Consultations with primary care (GP)

I’m currently contracting for provider and have been looking at how we interface with the rest of the NHS.
Our system follows NHS Dictionary and UK SNOMED guidance so in theory we are semantically interoperable with the rest of the NHS…

We also support FHIR but this is interoperability only and the guidance we follow is UKCore the desired clinical content, we use the The NHS Digital Terminology Server - NHS Digital for UK SNOMED work (this is also used in our EPR). In addition we partly follow NHS Digital implementation guidance for NHS Data Dictionary items (this gets us the England slant to our work).

Most of the interop work we have done has been with GP system providers partner API (IM1 could have been used but we didn’t use this). We took a conscious decision to use FHIR R4 internally as this would hopefully limit the work we need to do down the line…

So ignoring the SOAP/XML interface to the GP supplier looks like, this is an example: Encounter Message · GitHub
This is an example but it roughly has

  • MessageHeader - details required for routing the payload and includes sender, destination and message type
  • Encounter - basic details on the encounter who it was for, when, type, etc.
  • Patient - patient details
  • QuestionnaireResponse - data entered by the patient in an online form. This includes some observation data the patient made.
  • Observation - weight (kg), blood pressure and body temp (also followed Clinical Observations to get correct SNOMED concept and units)
  • Condition - the problem the clinician asserted

This has been in operation for two years.

Next stage was to work on the interop to other local GP systems. This is work in progress but for local EMIS suppliers we are using the same solution as above. For other GP practices the options are listed in the first link above but we have gone for Kettering XML I wont go into details but the official route didn’t offer anything extra to Kettering and Kettering is easier to build to.

To do this (and to support moving to official route) we started onboarding to MESH API via opentest. This has been relatively easy.

As we are using kettering we are sending the above encounter as an html. For this we plan to follow PRSB headings (extracted from Outpatient letter v2.1 – PRSB).

Potentially we may need to support this encounter sharing with other local providers and as no standard exists for this we’ve come up with our own standard (which is roughly based in IHE XDS standards). This resulted in this example document message (Kettering in FHIR format)) · GitHub
This is what gets converted to Kettering XML - so GP’s get Kettering XML and we plan to use this elsewhere.

This is an example of the FHIR document message converted to kettering XML. Kettering XML ReportMsg · GitHub

This message breaks down to

  • MessageHeader - details required for routing the payload and includes sender, destination and message type
  • DocumentReference - this is the metadata attached to the document which roughly follows UK IHE XDS
  • Patient - Patient demographic details
  • Binary - contains the document

This is also roughly the same information used in GP Connect Send Document. We could probably support that if required with the addition of the Encounter details(/resource). However, there are some big differences which are around the structure of the FHIR Message.

  • We are using FHIR R4 and GP Connect is FHIR STU3. We can solve this quite easily by casting the R4 payload to STU3 and if necessary tweaking the payload … code in java is
   FhirContext stu3 =  FhirContext.forDstu3();
   FhirContext ctx =  FhirContext.forR4();
   org.hl7.fhir.dstu3.model.Bundle toc = (org.hl7.fhir.dstu3.model.Bundle) stu3.newJsonParser().parseResource(ctx.newJsonParser().encodeResourceToString(bundle));
  • We use identifiers such as GMP, GMC or ODS and not FHIR resources. So this means our examples don’t have Organization, Practitioner or PractitionerRole resources. This still matches NHS Data Dictionary requirements and matches what HL7v2 interop did. These resources don’t add anything. Instead of these resources we use a contained PractitionerRole
"resource": {
                "resourceType": "DocumentReference",
                "contained": [
                        "resourceType": "PractitionerRole",
                        "id": "author",
                        "practitioner": {
                            "identifier": {
                                "system": "",
                                "value": "G7654321"
                            "display": "Dr Gregory Townley"
                        "organization": {
                            "identifier": {
                                "system": "",
                                "value": "Y99998"
                            "display": "THE PROVIDER"
                        "healthcareService": [
                                "identifier": {
                                    "system": "",
                                    "value": "1234567"
                                "display": "Online Consultations Service"
                "author": [
                        "reference": "#author"
  • our entries are (mostly) self contained - this is a FHIR requirement. So for example our FHIR Observations can be processed on it’s own without having to do a lot of lookups. We expect most consumers to want the name of the dr/organisation and the professional/organisation codes.
  • We have tested our examples against UKCore, NHS Digital IG and the NHS Digital Ontology server. We tested using NHS Digitals GitHub - NHSDigital/validation-service-fhir-r4 and the official HL7 Validator should also work, see here for some notes on this NHS Digital FHIR Implementation Guide
1 Like

This is quite complex but we have tried to follow the doctors brief of sending structured data to GP systems.
For local GP’s we done this but external GPs we had to compromise to using KetteringXML and so sending documents.

Long term we would like to avoid sending GP’s these detailed messages. This is need of updating, sending documents just matches the paper processes or sending messages just mirrors HL7 v2.
Ideally we would like to just send events over - such as ‘John Smith has attended a consultation’ and not the entire record.
If any clinician wants to view the full record we can make it available (this is planned for other local providers using a health portal). This avoids us having to build html documents or work with detailed messaging specifications. This is also what FHIR excels at, a simple RESTful query API.