Overview of Core API Conformance expectations

1. FHIR Resource Conformance Requirements

  • Where Care Connect profiles exist for resources they MUST be used.
    • The Care Connect profiles MUST be used within the API and implementation and feedback is encouraged.
  • The Core API can be extended to use resources for which no Care Connect profiles currently exist.
    • If no Care Connect profile exists then engagement with INTEROPen is encouraged so that profiles can be considered for later product releases.
  • When using Care Connect profiles and extensions are required, Care Connect extensions SHOULD be used.
    • Care Connect profile extensions should be the first option when extending profiles. If a local use case requires further extension then this should be initially a “non” Care Connect extension. Engagement with the INTEROPen community is encouraged to validate the extension.
  • When using the Care Connect Core API the implementer can choose which resource types to support.
    • All resource types are optional (even Patient). The implementer can choose the resources that meets the use cases being catered for.
  • Resources MUST identify the CareConnect profile supported as part of the FHIR Base Resource i.e. populate the FHIR meta.profile attribute for each instance.

2. Server Conformance Requirements

This section outlines conformance requirements for Care Connect Core API Servers, identifying FHIR profiles, content types, RESTful operations and the search parameters to be supported.

2.1 Conformance Requirements for Care Connect Core Server

  • MUST support HL7 FHIR STU3 version 3.0.1.
  • MUST Implement REST behavior according to the FHIR specification
  • MUST support JSON format for all CareConnect API interactions and SHOULD support XML format.
  • MUST declare a CapabilityStatement identifying the list of profiles, operations and search parameters supported.

2.2 Profile Interaction Summary

All servers MUST make available the read and search interactions for the resources the server chooses to support.

Summary of the Care Connect Core API search criteria

Specific server search capabilities are described in detail in each of the resource sections.

Resource Profile Supported Searches Supported Includes
AllergyIntolerance patient, patient + code, patient + clinical-status, patient + verification-status
Condition patient, patient + clinical-status, patient + category
Encounter patient, patient + date, patient + type, patient + type + date
Immunization patient, patient + vaccination-procedure-code, patient + notgiven, patient + status
Location identifier, name, address, address-city, address-postalcode
Medication
MedicationRequest patient, patient + status MedicationRequest.medication
MedicationStatement patient, patient + status MedicationStatement.medication
Observation patient, patient + date, patient + code, patient + date + code
Organization identifier, name, address, address-city, address-postalcode
Patient identifier, given, family, birthdate, gender, name, name + gender, name + birthdate, family + gender, given + gender
Practitioner identifier, name
PractitionerRole organization, practitioner
Procedure patient, patient + date

For date type search requests, servers SHOULD support the following modifier prefixes to the parameter value:

  • greater than or equal to ge
  • less than or equal to le
  • greater than gt
  • less than lt

2.3 Capability Statement

FHIR Servers MUST support the Care Connect Core API Requirements Capability Statement

2.4 Content Types

This section details FHIR Server content type conformance requirements:

MIME Type Rationale Conformance
application/fhir+xml Server supports formal MIME-type for FHIR resources SHOULD
application/fhir+json Server supports formal MIME-type for FHIR resources MUST
application/xml+fhir Server supports DSTU2 MIME-type for backwards compatibility SHOULD
application/json+fhir Server supports DSTU2 MIME-type for backwards compatibility MUST
application/xml Server to gracefully handle generic MIME types SHOULD
application/json Server to gracefully handle generic MIME types MUST
text/json Server to gracefully handle generic MIME types MUST
  • The server MUST support the optional _format parameter in order to allow the client to specify the response format by its MIME-type. If both are present, the _format parameter overrides the Accept header value in the request.

3. Client Conformance Requirements

This section outlines conformance requirements for Care Connect Core API Client applications:

  • When using the Care Connect Core API to access clinical data, a verified NHS number SHOULD be used.

4. Security Conformance Considerations

All Core API transactions must be secured appropriately with access limited to authorized individuals, data protected in transit and appropriate audit measures taken.

Implementers should be aware of the security considerations associated with FHIR transactions.

For the purpose of the Core API, minimum security conformance requirements are as follows:

  • Systems MUST support Transport Layer Security Version 1.2 (TLS v1.2) or higher for all transmissions
  • For authentication, systems SHOULD support Authentication Types as used within the NHS Identity Service.
  • For authorisation systems SHOULD support the OAuth 2.0 standard. See the NHS Identity Service Authorisation Service Overview
  • Systems SHOULD use ID & Access Tokens as specified here
  • Systems MUST implement consent requirements as per local policies.

5. NHS Number

NHS Number SHOULD be used with the Care Connect Core API. If the NHS Number is used, this MUST be a verified NHS Number. This can be achieved using a spine accredited system, a Demographics Batch Service (DBS) batch-traced record (CSV), or using a Spine Mini Services Provider (HL7v3) to verify the NHS Number.

Tags: conformance