Profile Descriptions

This implementation guide documents the use of FHIR UK Core R4 profiles to support the exchange of pathology laboratory data. Each profile is documented as follows:

Summary

A brief description of the profile.

Links to the base FHIR resource and associated profile(s).

Profile Views

A formal definition of the profile presented using the following views:

  • Snapshot: a full definition of the profile
  • Differential: a description of the differences between the base FHIR resource and the associated profile
  • Hybrid: a combination of the Snapshot and Differential views; those data elements that have not been changed in the profile (i.e. are the same as the base FHIR resource) are displayed as greyed out text.

Additional Guidance

Any additional guidance that should be followed when implementing the profile. This may be specific to the Pathology FHIR Implementation Guide, a reference to applicable guidance in the UK Core Implementation Guide (STU3 Sequence) or a combination of the two.

In addition to profile specific guidance, the UK Core Implementation Guide also includes guidance on more general topics (accessible from the Guidance menu bar item). These are listed below and should be followed where appropriate:

  • UK Core Implementation Guide - Data Type Guidance
  • UK Core Implementation Guide - CodeableConcept Guidance
  • UK Core Implementation Guide - MustSupport Guidance

Conformance Language

This implementation guide uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119. The base FHIR specification uses the same terms. These are included below for reference:

  1. SHALL: an absolute requirement for all implementations.
  2. SHALL NOT: an absolute prohibition against inclusion for all implementations.
  3. SHOULD/SHOULD NOT: A best practice or recommendation to be considered by implementers within the context of their particular implementation; there may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course.
  4. MAY: This is truly optional language for an implementation; can be included or omitted as the implementer decides with no implications.