Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Access Record Structured design

Overview of the design decisions made in relation to the Access Record Structured capability

Access Record Structured capability scope

What is the scope of the Access Record Structured capability?

DECISION Initially the Access Record Structured capability will return a patient’s medications and allergies using the following FHIR® profiles:

  • AllergyIntolerance
  • Medication
  • Medication Statement
  • Medication Request
  • Administrative profiles to support the above, as defined by the Foundations capability pack

FHIR profiles version

DECISION Standard for Trial Use 3 (STU3) is the version of FHIR which will be adopted for the Access Record Structured clinical profiles. A decision was taken to uplift the profiles from the previous DSTU2 version for the following reasons:

  • STU3 is widely being adopted in the UK interoperability community
  • there are many breaking changes between DSTU2 and STU3
  • no supplier development had started on the previous DSTU2 versions
  • the STU3 profiles offer additional clinical value

Access Record Structured API definition

DECISION A review of the historic Access Record Structured maturity model has been completed. The following changes relating to the API have been agreed and the relevant implementation guidance applied throughout the Access Record Structured specification:

  • the Access Record Structured clinical resources will be carried in a separate API message to the Access Record HTML resources
  • API filtering will be introduced
  • further filtering at the consumer end will be advocated (appropriate to the consumer need)
  • consumers will be guided to return data for the patient in one (or few) round trips

API search/filter parameters

DECISION Each clinical area will have its own set of search/filter parameters. These parameters will only apply to their own area. For example, a data filter set for medications will have no impact on the allergy data returned.

The benefits of this approach are:

  • it is clear which search/filter parameters are applied to which clinical area
  • adding or updating a search/filter parameter will only impact its own clinical area
  • the search/filter parameters for a clinical area can be defined in parallel with their clinical area development

API search/filter parameters for medications

  • Date range based on
  • Last Issue Date
  • Effective Date where the last issue date is not available
  • Record Date where the last issue date and effect date are not available
  • Flag to include/exclude individual issues of a prescription

API search/filter parameters allergies

  • None - there will be no date range applied for allergies due to clinical safety

All content is available under the Open Government Licence v3.0, except where otherwise stated