Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Supported resource types. Remember to check the capabilities of the Aggregated FHIR endpoint to confirm that the aggregator supports the relevant resource type(s).

    • Searches over unsupported resource types will return an empty search result; you should not assume a “successful” response implies the corresponding resource type has been added to the aggregation logic

    • Additionally, Customers must not provide a reference from a supported resource type to an unsupported resource type, since this is not supported by our aggregation logic

  • Business rules that define whether a resource will be included in the Aggregated FHIR endpoint. The rules are outlined below.

    • Resources which do not meet these rules will be silently excluded from the data in the Aggregated FHIR endpoint

  • Relevant merge logic. The aggregator will attempt to merge some resources together. There are resource type-specific rules about if/how this is down, which are outlined below.

    • Please also take note of the implications of the merge logic for corrective workflows

...

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

Example of a correct Patient reference

Rule

Description

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. Additionally, 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

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

Examples of incorrect Patient references

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

Code Block
{
  "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:

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

Example of a correct Patient reference

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

Examples of incorrect Patient references

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

Code Block
{
  "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:

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

Examples of incorrect Patient references

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

Code Block
{
  "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:

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

Identifier/code systems

When providing a resource of a type that is merged during aggregation:

  • If the merging is based on the identifier element, then at least one identifier must be provided.

  • The relevant identifier or coding element which is used to group those resources together must contain a system for every identifier or coding provided.

Example of a correct Patient identifier

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

Examples of incorrect Patient identifiers

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

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

Person.link

If providing a Person resource, a link to a target Patient must be provided.

PractitionerRole.practitioner/organization

If providing a PractitionerRole resource, a link to a target Practitioner and Organization must be provided.

...