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

Roadmap: The scope of the capability is under review and clinical items such as Immunisations are likely to be included at a later stage.

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

Roadmap: A RESTful model is still being considered. However, this has been removed from the short-term roadmap to allow time to evaluate the business need during the pilots.

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

Roadmap: The definition of the API filter parameters for other clinical areas is in progress.

Note: Search/filter parameters which were considered but not chosen for medications and allergies are: Fixed Date Range, SNOMED Code Cluster.