Customer Interface Requirements

Customer Interface Requirements

Overview

Provides an overview of the mandatory interface requirements that customers sending data to an upstream FHIR server must conform to.

General interface requirements

Rule

Description

Rule

Description

Logical ids

See https://wiki.hub.patientsknowbest.com/wiki/spaces/api/pages/5003673621

References

When populating a Reference, Customer integrations must ensure that they…

  • populate the “reference” element of a Reference. Business identifiers provided in the “identifier” element of a reference will not be resolved by PKB.

  • are not contained references; they must refer to a resource with a persistent identity

  • do not refer to resources on a different server (absolute references are discouraged, but if provided will never be followed and will always be treated as if the server component had not been provided - see below)

  • do not refer to an unsupported resource type from a supported resource type (our aggregation logic does not support this)

Resources that do not provide correct references will normally be skipped during the aggregation process, and will therefore not be returned from the Aggregated FHIR endpoint. Some errors might lead to an error state that will need support from PKB helpdesk to resolve.

Additionally, absolute references are strongly discouraged. The aggregator will assume any absolute reference is an artefact of upstream data construction and will remove the server component. For example, if a reference is provided to http://example.com/Patient/123, then the aggregator will assume this is equivalent to a local reference of Patient/123, and that is the reference value that will be returned from the Aggregated FHIR endpoint.

Example of a correct Patient reference

{ "resourceType": "MedicationStatement", "subject" : { "reference" : "Patient/123" } ... }

Examples of incorrect Patient references

The following is incorrect because the patient is referenced by business identifier:

{ "resourceType": "MedicationStatement", "subject" : { "identifier" : { "system": "https://fhir.nhs.uk/Id/nhs-number", "value": "9999999999" } } ... }

The following is incorrect because the patient referenced is a contained resource:

{ "resourceType": "MedicationStatement", "contained": [ { "resourceType": "Patient", "id": "patient-123", ... } ], "subject" : { "reference" : "#patient-123" } ... }

Business identifiers

All Identifier elements must contain both a system and value. This applies to Identifier elements on the root of the resource, as well as those in sub-elements.

Example of a correct Patient identifier

{ "resourceType": "Patient", "identifier": [ { "system": "https://fhir.nhs.uk/Id/nhs-number", "value": "9999999999" } ] ... }

Example of an incorrect Patient identifier

The following is incorrect because the Patient identifier does not contain a system element.

{ "resourceType": "Patient", "identifier": [ { "value": "9999999999" } ] ... }

Coding

All Coding elements must contain both a system and value, or neither.

Examples of a correct Coding

Both code and system are present

"coding": [ { "code": "Cardiology", "system": "http://hospital-specialty.com" } ]

Neither code nor system are present

"coding": [ { "display": "Coding display text" } ]

Example of an incorrect Coding

The following is incorrect because the coding does not contain a system element.

"coding": [ { "code": "Cardiology" } ]

Modifier extensions/elements

Modifier extensions or elements, which alter the interpretation of a resource or sub-element in an unbounded way, are not observed or utilised in any way.

In a future versions of the API the intention is to programmatically prohibit these from being sent into the upstream endpoint.

See https://www.hl7.org/fhir/R4/extensibility.html#isModifier for more details.

Contained resources

It is a requirement that all resources are written to their specific API endpoint. If one resource must reference another, this should be done through the use of logical id references as described above.

Contained references are therefore not permitted as the break the model of being able to retrieve all the relevant data via the specific API endpoint. In a future versions of the API the intention is to programmatically prohibit these extensions from being sent into the upstream endpoint.

Multi-patient resources

Some resources may be syntactically valid to belong to more than one Patient, for example a multi-patient group Appointment.

While there is currently no validation preventing resources of this form from being sent in, please note that these are not currently supported for extraction via the aggregated endpoint due to authorization limitations.

Resource specific interface requirements

Please see subpages to this page for any additional requirements which are specific to particular resource types.

These are generally required for merged resources. For more information as to the distinction of merged resources, please read https://wiki.hub.patientsknowbest.com/wiki/spaces/api/pages/5001904159

 

Patients Know Best Wiki Hub | Deploy | Developer | Trust Centre | Manual | Research | Education | Release Notes

© Patients Know Best, Ltd. Registered in England and Wales Number: 6517382. VAT Number: GB 944 9739 67.

This API specification and design is licensed under a Creative Commons Attribution 4.0 International License.