Problems and fixes

We have discovered that the HealthcareService.type attribute is being returned as a singular object by the eRS endpoints. As per the FHIR standard, this attribute should be an array.

Expected result 

HealthcareService.type is returned as an array

"type": [ { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/eRS-AppointmentType", "code": "DAY_CASE", "display": "Day Case" } ] }, ],

Actual result

As per the documentation under:

• Retrieve healthcare service (A033)
• Search for healthcare services (A035)

 HealthcareService.type is instead returned as a singular coding object

"type": { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/eRS-AppointmentType", "code": "DAY_CASE", "display": "Day Case" } ] },

What we’re doing to fix this

The HealthcareService.type attribute will be updated so that it is returned as an array rather than a singular object. This will bring the endpoints in line with the FHIR R4 specification.

Please note that while similar defects have been identified in both STU3 and R4 endpoints, we will only be fixing the defect in the R4 endpoints. This is because the STU3 endpoints are widely used. Introducing a fix may break these endpoints for a significant number of partners.

As R4 is the normative standard we need to ensure e-RS compliance to the specification.

What you need to do

Review any implementation of these endpoints you may be using in our test environments.

We have discovered that the Participant.type attribute is being mapped as a single type.

As per the Appointment FHIR profile, this attribute should be an array.

This impacts any endpoint which returns either the Appointment or ReferralRequest resource:

• Retrieve referral request (A005)
• Create referral (A011)
• Maintain referral letter (A012)
• Accept referral (A013)
• Reject referral (A014)
• Book or defer appointment (A016)
• Create referral and send for triage (A021)
• Cancel appointment, action later (A022)
• Convert A&G to request to referral (A027)
• Record triage outcome (A028)
• Change shortlist (A031)
• Change shortlist and send for triage (A032)
• Update appointment (A034)
• Cancel referral (A036)
• Retrieve appointment (A038)

What we’re doing to fix this

We are not planning to fix this issue in our STU3 endpoints. This is because existing partner integrations make use of this property and fixing the issue may break their software.

We are planning to fix the issue as part of our uplift of all endpoints to FHIR R4 version. This forms part of our strategic direction for the e-RS FHIR API.

What you need to do

Follow the e-RS specification which indicates the atribute to be a single value.

We have found that one of the search parameters on the Retrieve appointment slots (A015) endpoint is not FHIR compliant.

As the Schedule.actor is defined as an Identifier it is necessary to use the :identifier modifier when searching to indicate that an Identifer is used rather than a literal, relative, internal or absolute reference.

This issue impacts the schedule.actor search parameter in this endpoint.

Expected usage

Using the :identifier modifier on the search parameter:

GET /STU3/v1/Slot?schedule.actor:identifier=http://fhir.nhs.net/Id/ers-service|11008
&schedule.actor:identifier=http://fhir.nhs.net/Id/sds-user-id|021600556514
&appointmentType=ROUTINE
&_count=20
&page=1
&status=free
&_include=Slot:schedule

Actual usage

Without :identifier modifier on the search parameter (using :Practitioner incorrectly):

GET /STU3/v1/Slot?schedule.actor:HealthcareService=11008
&schedule.actor:Practitioner=021600556514
&appointmentType=ROUTINE
&_count=20
&page=1
&status=free
&_include=Slot:schedule

What we're doing to fix this

We are not planning to fix this compliancy issue. This is because there is no functional impact and switching to use the :identifier modifier on the search parameter would be a breaking change for existing partner integrations.

We are planning to fix the issue as part of our uplift of all endpoints to FHIR R4 version. This forms part of our strategic direction for the e-RS FHIR API.

What you need to do

Continue to follow the e-RS specification when building the search parameter.

Our regression tests have highlighted FHIR violations for our coding resource.

The issue impacts the participant of an Appointment which references a value set, not a coding system.

This affects any endpoint which returns either the Appointment or ReferralRequest resource.

What we’re doing to fix this

We are not planning to fix this issue in our STU3 endpoints. This is because existing partner integrations make use of this property and fixing the issue may break their software.

We are planning to fix the issue as part of our uplift of all endpoints to FHIR R4 version. This forms part of our strategic direction for the e-RS FHIR API.

What you need to do

Follow the e-RS specification which indicates the participant of an Appointment to be a value set.

Our tests have highlighted a bug in the Change shortlist (A031) endpoint.

When changing a shortlist it is possible to change the Commissioning Rule Organisation (CRO) parameter. The CRO parameter determines a referring user's service availability and rights when conducting a service search. When a referral is created, the CRO is set and is used throughout the lifespan of a referral.

It is possible that after the creation of a referral, the patient changes their registered GP practice. This has no effect on the determination of the CRO parameter.

Expected usage

The CRO parameter is not recalculated if the patients registered GP practice changes, and the shortlist is amended.

Actual usage

The CRO parameter is being recalculated if the patients registered GP practice changes, each time the shortlist is amended.

What we’re doing to fix this

We're adding an optional CRO parameter into the Patient service search (A010) endpoint.

This is not a breaking change. However, it will require partners who intend to use Change shortlist (A031) to incorporate the new CRO parameter.

What you need to do

According to our data, there is no usage of A031 in production yet. However, if you’re working on A031, please note the following.

Once the above mentioned fix is available, your product must incorporate the CRO parameter.

This will:

• ensure that services retrieved from the patient service search endpoint will match the CRO for the referral
• enable you to provide a valid shortlist when attempting to re-shortlist

Subject to final testing, the bug fix will be available in the:

• integration environment on 28 October 2024
• production environment on 05 November 2024