NHS STU3 Capability Statement Profile Design

Similar documents
FHIR Packages and Versioning

Assessment, Discharge and Withdrawal Notices between Hospitals and Social Services

FHIR Overview. HL7 FHIR Connectathon20 January 12, 2019

ITK2.2 Distribution Envelope Requirements

IHE IT Infrastructure Technical Framework Supplement. Patient Identifier Cross-reference for Mobile (PIXm) Rev. 1.4 Trial Implementation

IHE IT Infrastructure Technical Framework Supplement. Non-patient File Sharing (NPFSm) Rev. 1.1 Trial Implementation

IHE IT Infrastructure Technical Framework Supplement. Patient Identifier Cross-reference PIX for Mobile (PIXm) Draft for Public Comment

IHE IT Infrastructure Technical Framework Supplement. Patient Demographics Query for Mobile (PDQm) Rev. 1.4 Trial Implementation

MESH General Practice Clinical System Changes and Impacts on Addressing

IHE IT Infrastructure Technical Framework Supplement. Mobile access to Health Documents (MHD) With XDS on FHIR. Rev. 2.3 Trial Implementation

How to use the MESH Certificate Enrolment Tool

FHIR Testing and Touchstone

Data Security and Protection Toolkit - Start guide (all users)

Cervical Screening System DMS User Guide April 2015

ExtraHop 7.3 ExtraHop Trace REST API Guide

FHIR Interface Specification

Guide to ITK Compliant Output Based Specification

HL7 FHIR. Rik Smithies, HL7 UK Technical Committee Chair September 28 th 2016

WebEx Management. GP Connect. WebEx Interactions

ISO INTERNATIONAL STANDARD. Health informatics Harmonized data types for information interchange

Social care: local sponsorship model application process guidance

Getting Started with Clinical Quality Language: Technical Implementation for Vendors

Health Information Exchange Content Model Architecture Building Block HISO

Developing A Semantic Web-based Framework for Executing the Clinical Quality Language Using FHIR

Boubacar Sow Miyagi University

Test Assertions for the SCA Web Service Binding Version 1.1 Specification

Working Group Charter: Web Services Basic Profile

Oracle Revenue Management and Billing. File Upload Interface (FUI) - User Guide. Version Revision 1.1

Developing A Semantic Web-based Framework for Executing the Clinical Quality Language Using FHIR

ITK2.2 TMS Transport Requirements

edelivery SMP Profile Test Assertions Description

Information Architecture. It s utility with the NHS landscape. Presented by Richard Kavanagh, Head of

Working Group Charter: Basic Profile 1.2 and 2.0

W3C WoT call CONTEXT INFORMATION MANAGEMENT - NGSI-LD API AS BRIDGE TO SEMANTIC WEB Contact: Lindsay Frost at

SimplifierDocs Documentation

[MS-ADFSOAL]: Active Directory Federation Services OAuth Authorization Code Lookup Protocol

Integration Architecture Of SDMS

Guidance for Creation of an NHS 111 Repeat Caller Query

The Dublin Core Metadata Element Set

Health Information Exchange Clinical Data Repository Utility Services Architecture Building Block HISO

ISO CTS2 and Value Set Binding. Harold Solbrig Mayo Clinic

Cancer Waiting Times. Getting Started with Beta Testing. Beta Testing period: 01 February May Copyright 2018 NHS Digital

SimplifierDocs Documentation

API Security Management SENTINET

OCF Core Specification Extension

Alternate Data Submission Users Guide

Chapter One: Overview

IHE IT Infrastructure Technical Framework Supplement. Patient Demographics Query for Mobile (PDQm) Trial Implementation

Chapter Two: Conformance Clause

IHE Radiology Technical Framework Supplement. Web-based Image Access (WIA) Rev. 1.1 Trial Implementation

Integration Guide. SafeNet Authentication Manager. Using SAM as an Identity Provider for PingFederate

Composer Help. Web Request Common Block

HL7 s Vision for 2016 & Beyond

ISO/IEC INTERNATIONAL STANDARD. Information technology Metadata registries (MDR) Part 3: Registry metamodel and basic attributes

HITSP/T16. October 15, 2007 Version 1.1. Healthcare Information Technology Standards Panel. Security and Privacy Technical Committee.

This document is a preview generated by EVS

Electronic Transmission of Prescriptions Message Signing Requirements

REST API Operations. 8.0 Release. 12/1/2015 Version 8.0.0

Informatica Cloud Spring REST API Connector Guide

How to use an EPR certificate with the MESH client

not use this documentation except in compliance with the License.

Deliverable Final Data Management Plan

D. Crocker, Ed. Updates: RFC4871 June 10, 2009 (if approved) Intended status: Standards Track Expires: December 12, 2009

OCF Specification Overview Core Technology Specification. OCF 2.0 Release June 2018

MarkLogic Server. REST Application Developer s Guide. MarkLogic 9 May, Copyright 2017 MarkLogic Corporation. All rights reserved.

HSCN Internet Protocol (IP) addressing policy

Deployment Profile Template Version 1.0 for WS-Reliability 1.1

How to complete the NHSmail Social Care Provider Registration Portal

IHE IT Infrastructure Technical Framework Supplement. Patient Demographics Query for Mobile (PDQm) Draft for Public Comment

Identification and Authentication

OMA-ETS-DL-OTA-v1_ a Page 1 (24)

File Type Specification

Frequently Asked Questions (FAQ):

Inland Revenue. Build Pack. Identity and Access Services. Date: 04/09/2017 Version: 1.5 IN CONFIDENCE

WhamTech SmartData Fabric Healthcare Configurable FHIR REST APIs

FHIR Interface Specification

Test Assertions Part 1 - Test Assertions Model Version 1.0

Interoperability Specifications and Conformance Testing Services Made Available on the Tukan Platform

Usage of "OAuth2" policy action in CentraSite and Mediator

REDCap under FHIR Enhancing electronic data capture with FHIR capability

Automatic Test Markup Language <ATML/> Sept 28, 2004

Generic Profiles V 1.0

RealMe. SAML v2.0 Messaging Introduction. Richard Bergquist Datacom Systems (Wellington) Ltd. Date: 15 November 2012

<Name of the project> Software Requirement Specification

ISO/IEC INTERNATIONAL STANDARD. Information technology Multimedia service platform technologies Part 3: Conformance and reference software

Consents Service - SMBC NextGenPSD2

ISO/IEC INTERNATIONAL STANDARD. Information technology Multimedia service platform technologies Part 2: MPEG extensible middleware (MXM) API

Simple Object Access Protocol (SOAP) Reference: 1. Web Services, Gustavo Alonso et. al., Springer

This document is a preview generated by EVS

Taverna I Assignment

Health Level 7 (HL7) Implementation Guide

Graphic technology Extensible metadata platform (XMP) Part 2: Description of XMP schemas using RELAX NG

IHE IT Infrastructure Technical Framework Supplement. Mobile Care Services Discovery (mcsd) Rev. 1.0 Draft for Public Comment

Standard CIP 007 3a Cyber Security Systems Security Management

API Migration Guide. Migrating from v1.syndication.nhschoices.nhs.uk (v1) to api.nhs.uk (Content API) Published August 2017

QRDA Category I Conformance Statement Resource CY 2016 ecqm Reporting

FHIR for specifiers. Michel Rutten. HL7 WGM San Antonio, Jan. 2017

This document is a preview generated by EVS

Advancing HL7 v2 to New Heights: A Platform for Developing Specifications, Test Plans, and Testing Tools

C-DAC s Medical Informatics Software Development Kit (SDK) for DICOM PS Conformance Statement

Transcription:

Document filename: NHS STU3 Capability Statement Profile Design.docx Project / Programme Programme 14 Interoperability & Architecture Project <insert> Document Reference <insert> Project Manager Richard Kavanagh Status Draft Owner Simon Knee Version 0.4 Author Simon Knee Version issue date 10/01/2018 NHS STU3 Capability Statement Profile Design Copyright 2017 Health and Social Care Information Centre Page 1 of 15 The Health and Social Care Information Centre is a non-departmental body created by statute, also known as NHS Digital.

Document management Revision History Version Date Summary of Changes 0.1 2017-09-19 Initial comments 0.2 2017-10-03 P14 Review comments 0.3 2017-12-13 0.4 2018-01-02 Multiple capabilitystatement-expectation extensions added to represent complete REST conformance context. HL7 capabilitystatement-expectation replaced by Extension- CapabilityStatement-Expectation-1 extension. Reviewers This document must be reviewed by the following people: Reviewer name Title / Responsibility Date Version Richard Kavanagh Head of Interoperability Standards Development 0.1 Programme 14 Interoperability & Architecture 0.2 Approved by This document must be approved by the following people: Name Signature Title Date Version Glossary of Terms Term / Abbreviation What it stands for Document Control: The controlled copy of this document is maintained in the NHS Digital corporate network. Any copies of this document held outside of that area, in whatever format (e.g. paper, email attachment), are considered to have passed out of control and should be checked for currency and validity. Copyright 2017 Health and Social Care Information Centre. Page 2 of 15

Contents 1. Introduction 4 1.1. Purpose of Document 4 1.2. Background 4 1.3. In Scope 4 1.4. Out of Scope 4 1.5. Target Audience 5 1.6. References 5 2. CapabilityStatement 5 2.1. Design Principles 5 2.2. NHSDigital-CapabilityStatement-1 Profile Design 6 Copyright 2017 Health and Social Care Information Centre. Page 3 of 15

1. Introduction 1.1. Purpose of Document This document defines the best practice rules that must be followed by technical and interoperability architects when profiling NHS Digital national FHIR Capability Statements. It is published as a 'work in progress' version and as such is subject to change. It has been published to show the direction of travel and to serve as a discussion document for parties involved in the creation of NHS Digital national API Capability Statements and how these Capability Statements will be used in national NHS FHIR API Implementation Guides. 1.2. Background The conformance layer 1 is used within FHIR implementation guides to provide a computable statement about how FHIR resources and FHIR exchange paradigms are used to solve particular healthcare interoperability use cases. The conformance layer is implemented using a number of key resources including StructureDefinition, CapabilityStatement and ImplementationGuide. This document is only concerned with profiling the STU3 CapabilityStatement resource. The long term objective of this document is to ensure a consistency in design of NHS Digital Capability Statements for use within NHS Digital FHIR API Implementation Guides. 1.3. In Scope For this version of the NHS STU3 Capability Statement Profile Design the following is considered in scope: NHS Digital FHIR API projects delivered on Spine Capability Statement resource Metadata FHIR RESTful mode FHIR query mechanism 1.4. Out of Scope For this version of the NHS STU3 Capability Statement Profile Design out of scope items include: Peer to Peer FHIR API projects e.g. CareConnect API Capability Statement elements: o CapabilityStatement.rest.mode Client o CapabilityStatement.rest.interaction o CapabilityStatement.rest.operation o CapabilityStatement.rest.compartment o CapablityStatement.messaging o CapabilityStatement.document 1 http://hl7.org/fhir/stu3/profiling.html Copyright 2017 Health and Social Care Information Centre. Page 4 of 15

1.5. Target Audience This document is intended for NHS Digital technical teams involved in the development of FHIR API Implementation Guides using the STU3 FHIR standard. It is assumed that the reader is familiar with the FHIR standard and all of technologies detailed within this document. 1.6. References # Name Version 1 https://nhsconnect.github.io/fhir-policy/index.html 1.2.0-alpha 2 http://hl7.org/fhir/stu3/capabilitystatement.html FHIR Release 3 (STU) 2. CapabilityStatement A FHIR STU3 Capability Statement documents a set of capabilities (behaviours) of a FHIR Server that may be used as a statement of actual server functionality or a statement of required or desired server implementation. The context of FHIR Server capability MUST not be confused with technical architecture solution capability. 2.1. Design Principles A Capability Statement is a key part of the FHIR conformance framework. It is used as a statement of actual software capability features or as a set of conformance rules that a system should adhere to. For NHS Digital there are 2 relevant ways to profile the Capability Statement: 1. A specification of requirements profile - describes a desired solution 2. An implementation instance profile - describes an actual implementation NOTE An instance profile is a statement of conformance to a requirements profile. FHIR restful solutions are expected to make available an instance profile on invocation of the capabilities operation. It is also the type of statement that forms a basis for the testing, certification or commissioning of specific software installations. The Capability Statement profile detailed in this section applies to all NHS Digital FHIR API development projects delivered on Spine. The only way to provide consistent and standard Copyright 2017 Health and Social Care Information Centre. Page 5 of 15

FHIR API Definitions is if all FHIR API Implementation Guides abide by these common Capability Statement design principles. 2.2. NHSDigital-CapabilityStatement-1 Profile Design The following table shows the NHSDigital-CapabilityStatement-1 StructureDefinition profile, which constrains the CapabilityStatement resource. Constraints applied to the CapabilityStatement base resource by this profile are shown in bold. For some CapabilityStatement elements, the comments column details the expected instance statement of conformance to a requirements profile. Name Card. Description & Constraints Comments CapabilityStatement A statement of system capabilities CapabilityStatement.url 1..1 URL that is used to identify this capability statement when it is referenced in a specification, model, design or an instance. MUST be globally unique, and MUST be an address at which this capability statement is (or will be) published. The URL MAY [TBC] include the major version of the capability statement. CapabilityStatement.version 0..1 The identifier that is used to identify this version of the capability statement when it is referenced in a specification, model, design or instance. NB: This is a business versionid, not a resource version id. This version of the profile requires a URL element. FHIR-CONF-01: All FHIR ReST endpoints MUST publish their conformance FHIR-VER-02: HL7 FHIR version in FHIR Endpoint URL FHIR-VER-04: Major Profile Version in Resource ID Capability statements of kind 'requirements' example [TBC]: https://fhir.nhs.uk/stu3/capab ilitystatement/odsapi- CapabilityStatement-1 Capability statements of kind 'instance' example [TBC]: https://directory.spineservices. nhs.uk /STU3/SpineDirectory- CapabilityStatement-1 FHIR-VER-05: Minor and Patch Profile Version will use FHIR versioning The version element within the resource will contain the full semantic version of the resource, and will look like this: <version value= 1.1.3 /> CapabilityStatement.name 1..1 Name for this capability statement (computer friendly) This version of the profile requires a name element. FHIR-VER-04: Major Profile Version in Resource ID FHIR-NAME-01: FHIR Profile names MUST follow an agreed format National NHS Digital capability statements MUST support the Copyright 2017 Health and Social Care Information Centre. Page 6 of 15

naming conventions for nationally defined FHIR profiles. Refer to: https://nhsconnect.githu b.io/fhirpolicy/naming.html CapabilityStatement.title 0..1 Name for this capability statement (human friendly) CapabilityStatement.status 1..1 draft active retired unknown PublicationStatus (Required) For all under development CapabilityStatement profiles the status MUST be 'draft'. CapabilityStatement.experimental 0..1 For testing purposes, not real usage CapabilityStatement.date 1..1 Date this was last changed CapabilityStatement.publisher 1..1 Name of the publisher (organization or individual) This version of the profile requires a publisher element. National Spine capability statements MUST populate this element with NHS Digital. CapabilityStatement.contact 1..* Contact details for the publisher This version of the profile requires a contact details element. CapabilityStatement.contact.name 1..1 Name of a service that would provide first line support. This version of the profile requires a contact name element. National capability statements of kind requirements MUST populate this element with Interoperability Team. Capability statements of kind instance SHOULD populate this element with relevant service desk details. CapabilityStatement.contact.teleco m 1..* Contact details of the service This version of the profile requires at least one telecom element. Capability statements of kind 'requirements' MUST populate the telecom child elements as follows: System: email Value: interoperabilityteam@nhs.net Use: work Capability statements of kind 'instance' MUST populate the telecom child elements with relevant service desk contact details. CapabilityStatement.description 0..1 Natural language description of the capability statement Capability statements of kind requirements MUST support Copyright 2017 Health and Social Care Information Centre. Page 7 of 15

CapabilityStatement.useContext 0..* Context the content is intended to support CapabilityStatement.jurisdiction 0.. * Intended jurisdiction for capability statement (if applicable) Jurisdiction ValueSet (Extensible) CapabilityStatement.purpose 0..1 Why this capability statement is defined the description element. The description of the capability statement will be described and published within the NHS Digital Jekyll API Implementation Guide publication. CapabilityStatement.copyright 1..1 Use and/or publishing restrictions All NHS Digital national capability statements of kind 'instances' MUST support the copyright element. Example: Copyright 2017 NHS Digital. CapabilityStatement.kind 1..1 instance capability requirements CapabilityStatementKind (Required) CapabilityStatement.instantiates 0.. * Canonical URL of another capability statement this implements CapabilityStatement.software 0..1 Software that is covered by this capability statement The 'requirements' code MUST be used for all capability statements profiles defined by national API IGs - it sets out what systems should do rather than what a particular system does do. A server implementation MUST use the code instance. It describes what a particular system does do. A server 'instance' of a national Capability Statement MUST reference the requirements CapabilityStatement. [TBC] cpb-2: Capability statements of kind 'requirements' do not have software or implementation elements. CapabilityStatement.implementatio n 0..1 If this describes a specific instance cpb-2: Capability statements of kind 'requirements' do not have software or implementation elements. CapabilityStatement.fhirversion 1..1 FHIR Version the system uses STU3 Capability Statements MUST support 3.0.1". CapabilityStatement.acceptUnknow n 1..1 no extensions elements both UnknownContentCode (Required) For this version of the profile both national 'requirements' profiles and server 'instance' profiles MUST use the code no. CapabilityStatement.format 1.. * formats supported (xml json ttl mime type) National REST APIs MUST support one of JSON, XML or both formats. Copyright 2017 Health and Social Care Information Centre. Page 8 of 15

MimeType (Required) This element MUST be populated to meet this requirement. Spine mime-type conformance: Spine SHALL support the formal mime-type for STU3 XML + JSON FHIR resources: application/fhir+xml or application/fhir+json Spine MAY support the formal mime-types for DSTU2 XML +JSON FHIR resources: application/xml+fhir or application/json+fhir Spine MAY support generic mimetypes e.g. text/html, xml, text/xml, applicat ion/xml, json and application/json Spine SHOULD support the FHIR STU3 implementation note: https://www.hl7.org/fhir/http.html #mime-type CapabilityStatement.patchFormat 0.. * Patch formats supported MimeType (Required) CapabilityStatement.Implementatio nguide 0.. * Implementation guides supported A national 'requirements' profile MUST link to the NHS Developer site for FINAL releases of national Implementation Guides. A server 'instance' MUST list the implementation guides that the server does (or should) support in their entirety. Publication URLs should be assigned before Implementation Guides released. CapabilityStatement.profile 0.. * Profiles for use cases supported. This could include: Extensions Data types ValueSets A national 'requirements' profile MAY specify a list of profiles that represent different use cases that are required to be supported by a system. A server 'instance' MAY list all profiles that represent different use cases that are required to be supported by a system. CapabilityStatement.profile.profil e-link 0..* Extension-NHSDigital-Profile-Link- 1 extension. A code that references a resource listed in CapabilityStatement.rest.resource. The Extension-NHSDigital- Profile-Link-1 extension links profiles to the resources they are based upon for the purpose of describing profile specific capabilities such as Copyright 2017 Health and Social Care Information Centre. Page 9 of 15

specific search criteria or operations which are supported on a profile by profile bases. The Extension-NHSDigital- Profile-Link-1 extension binds to the HL7 resource-types value set. This value set includes codes from the following code systems: http://hl7.org/fhir/resourcetypes CapabilityStatement.rest 0.. * A definition of the restful capabilities of the solution. MUST be supported for all national Spine RESTful APIs Multiple repetitions allow definition of both client and/or server behaviours. + A given resource can only be described once per RESTful mode. CapabilityStatement.rest.mode 1..1 client server RestfulCapabilityMode (Required) Identifies whether this portion of the statement is describing the ability to initiate or receive restful operations. This version of the profile MUST support 'server' mode. The Client mode is out of scope for this version of the profile. CapabilityStatement.rest.document ation 0..1 General description of implementation CapabilityStatement.rest.security 0..1 Information about security of implementation CapabilityStatement.rest.security.c ors CapabilityStatement.rest.security.s ervice CapabilityStatement.rest.security.d escription CapabilityStatement.rest.security.c ertificate CapabilityStatement.rest.security.c ertificate.type CapabilityStatement.rest.security.c ertificate.blob 1..1 Adds CORS Headers (http://enablecors.org/) MUST Mandate boolean value. [TBC] 0.. * OAuth SMART-on-FHIR NTLM Basic Kerberos Certificates RestfulSecurityService (Extensible) 0..1 General description of how security works 0.. * Certificates associated with security profiles 0..1 Mime type for certificates MimeType (Required) 0..1 Actual certificate This version of the profile MUST support 'cors' Boolean element. All National API FHIR servers SHOULD support CORS. CORS support is highly recommended - mandatory if using SMART on FHIR. CapabilityStatement.rest.resource 0.. * Resource served on the REST interface Max of one repetition per resource type. A national 'requirements' profile MUST specify the restful capabilities of the solution for a specific resource type. A server 'instance' MUST Copyright 2017 Health and Social Care Information Centre. Page 10 of 15

support all resources served on the REST interface. CapabilityStatement.rest.resourc e.capabilitystatement-searchparameter-combination CapabilityStatement.rest.resource.t ype CapabilityStatement.rest.resource.p rofile CapabilityStatement.rest.resource.d ocumentation CapabilityStatement.rest.resource.i nteraction CapabilityStatement.rest.resourc e.interaction. capabilitystatementexpectation CapabilityStatement.rest.resource.i nteraction.code CapabilityStatement.rest.resource.i nteraction.documentation 0.. * CapabilityStatement resource search combinations MUST be specified using the HL7 maintained capabilitystatement-searchparameter-combination common extension which is a container for a single allowable parameter combination. The extension supports required and optional parameter combinations. http://hl7.org/fhir/stu3/extensioncapabilitystatement-searchparameter-combination.html 1..1 A type of resource exposed via the restful interface e.g. CarePlan ResourceType (Required) 0..1 Base System profile for all uses of resource The profile applies to all resources of this type - i.e. it is the superset of what is supported by the system. 0..1 Additional information about the use of the resource type 1..* What operations are supported? 0..1 FHIR endpoint conformance must be specified within the CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi nition/extension-capabilitystatement- Expectation-1 1..1 read vread update patch delete history-instance history-type create search-type TypeRestfulInteraction (Required) 0..1 Anything special about operation behaviour If a search combination is specified, clients should expect that they must submit that required combination or the search will be unsuccessful. If multiple search parameter combinations are specified, a client may pick between them, and supply the minimal required parameters for any of the combinations. A national 'requirements' profile MUST specify the profile that describes the solution's overall support for the resource. A server 'instance' MUST support the profile that describes the solution's overall support for the resource. The Extension- CapabilityStatement- Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: http://hl7.org/fhir/stu3/valuesetconformance-expectation.html A national 'requirements' profile MUST specify coded identifiers of the interaction codes supported by the national system. A server 'instance' MUST support coded identifiers of the interaction codes supported by the national system. Copyright 2017 Health and Social Care Information Centre. Page 11 of 15

CapabilityStatement.rest.resource.v ersioning CapabilityStatement.rest.resource.r eadhistory 0..1 no-version versioned versionedupdate ResourceVersionPolicy (Required) 0..1 Whether vread can return past versions NHS Digital national REST API Capability Statements of kind 'instances' MAY support versioning for a resource type. If the capability statement does not explicitly support this field the default code = noversion. This indicates that the server does not support versioning for a resource type. NHS Digital national REST API Capability Statements of kind 'instances' MAY support returning past versions of a resource as part of the vread operation. If the capability statement does not explicitly support this field the default flag = false. This indicates that the server is NOT able to return past versions of the resource as part of the vread operation. CapabilityStatement.rest.resource.u pdatecreate CapabilityStatement.rest.resource.c onditionalcreate 0..1 If update can commit to a new identity NHS Digital national REST API Capability Statements of kind 'instances' MAY allow clients to create new identities on the server using the updatecreate operation for a resource type. If the capability statement does not explicitly support this field the default flag = false. This indicates that the server does NOT allow clients to create new identities on the server. 0..1 If allows/uses conditional create NHS Digital national REST API Capability Statements of kind 'instances' MAY support the conditionalcreate operation for a resource type. If the capability statement does not explicitly support this field the default flag = false. This indicates that the server does NOT support conditional create. CapabilityStatement.rest.resource.c onditionalread 0..1 not-supported modified-since notmatch full-support ConditionalReadStatus (Required) NHS Digital national REST API Capability Statements of kind 'instances' MAY support the conditionalread operation for a resource type. If the capability statement does not explicitly support this field the default code = notsupported. This indicates that the server does not support conditional read for a resource Copyright 2017 Health and Social Care Information Centre. Page 12 of 15

type. CapabilityStatement.rest.resource.c onditionalupdate 0..1 If allows/uses conditional update NHS Digital national REST API Capability Statements of kind 'instances' MAY support the conditionalupdate operation for a resource type. If the capability statement does not explicitly support this field the default flag = false. This indicates that the server does NOT support conditional update. CapabilityStatement.rest.resource.c onditionaldelete CapabilityStatement.rest.resource.r eferencepolicy CapabilityStatement.rest.resource.s earchinclude CapabilityStatement.rest.resourc e.interaction. capabilitystatementexpectation CapabilityStatement.rest.resource.s earchrevinclude CapabilityStatement.rest.resourc e.interaction. 0..1 not-supported single multiple - how conditional delete is supported ConditionalDeleteStatus (Required) 0.. * literal logical resolves enforced local ReferenceHandlingPolicy (Required) 0.. * _include values supported by the server 0..1 FHIR endpoint conformance must be specified within the CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi nition/extension-capabilitystatement- Expectation-1 0.. * _revinclude values supported by the server 0..1 FHIR endpoint conformance must be specified within the NHS Digital national REST API Capability Statements of kind 'instances' MAY support the conditionaldelete operation for a resource type. If the capability statement does not explicitly support this field the default code = notsupported. This indicates that the server does not support conditional delete for a resource type. A national 'requirements' profile MUST specify the list of _include values supported by the system. A server 'instance' MUST support the list of _include values supported by the system. The Extension- CapabilityStatement- Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: http://hl7.org/fhir/stu3/valuesetconformance-expectation.html A national 'requirements' profile MUST specify the list of _revinclude values supported by the system. A server 'instance' MUST support the list of _revinclude values supported by the system. The Extension- CapabilityStatement- Copyright 2017 Health and Social Care Information Centre. Page 13 of 15

capabilitystatementexpectationc apabilitystatement.rest.resource. searchrevinclude. capabilitystatement-expectation CapabilityStatement.rest.resource.s earchparam CapabilityStatement.rest.resourc e.interaction. capabilitystatementexpectation CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi nition/extension-capabilitystatement- Expectation-1 0.. * Search parameters supported by implementation 0..1 FHIR endpoint conformance must be specified within the CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi nition/extension-capabilitystatement- Expectation-1 Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: http://hl7.org/fhir/stu3/valuesetconformance-expectation.html MUST reference either search parameters defined in the specification, or additional ones defined for/by the implementation. MAY reference search parameters for all resources or search result parameters. The Extension- CapabilityStatement- Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: http://hl7.org/fhir/stu3/valuesetconformance-expectation.html CapabilityStatement.rest.resource.s earchparam.name CapabilityStatement.rest.resource.s earchparam.definition CapabilityStatement.rest.resource.s earchparam.type CapabilityStatement.rest.resource.s earchparam.documentation 1..1 Name of search parameter When specified, MUST match Name of search parameter in STU3 Resource definitions. 0..1 Source of definition for parameter MUST be URI that is a formal reference to where this parameter was first defined. 1..1 number date string token reference composite quantity uri SearchParamType (Required) 0..1 Server-specific usage Definition SHOULD be present in both 'requirements' and'instance' capability statements. CapabilityStatement.rest.interaction 0.. * What system operations are supported? Out of scope for this version CapabilityStatement.rest.resourc e.interaction. capabilitystatementexpectation 0..1 FHIR endpoint conformance must be specified within the CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi The Extension- CapabilityStatement- Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: Copyright 2017 Health and Social Care Information Centre. Page 14 of 15

CapabilityStatement.rest.interaction.code CapabilityStatement.rest.interaction.documentation CapabilityStatement.rest.searchPar am nition/extension-capabilitystatement- Expectation-1 1..1 transaction batch search-system history-system SystemRestfulInteraction (Required) 0..1 Anything special about operation behaviour 0.. * Search parameters for searching all resources http://hl7.org/fhir/stu3/valuesetconformance-expectation.html Out of scope for this version Out of scope for this version MUST reference search parameters that apply to all resources - tags, profiles, text search etc. CapabilityStatement.rest.operation 0.. * Definition of an operation or a custom query Out of scope for this version CapabilityStatement.rest.resourc e.interaction. capabilitystatementexpectation CapabilityStatement.rest.operation. name 0..1 FHIR endpoint conformance must be specified within the CapabilityStatement resource using the NHSDigital maintained Extension-CapabilityStatement- Expectation-1 extension. It defines the level of expectation associated with a given system capability. https://fhir.nhs.uk/stu3/structuredefi nition/extension-capabilitystatement- Expectation-1 1..1 Name by which the operation/query is invoked The Extension- CapabilityStatement- Expectation-1 extension is bound to the HL7 conformance-expectation value set. This value set defines the following codes which must be used when publishing a FHIR capability statement: http://hl7.org/fhir/stu3/valuesetconformance-expectation.html Out of scope for this version CapabilityStatement.rest.operation. definition 1..1 The defined operation/query Out of scope for this version CapabilityStatement.rest.compartm ent 0.. * Compartments served/used by system Out of scope for this version CapabilityStatement.messaging 0.. * A description of the messaging capabilities of the solution. Out of scope for this version CapabilityStatement.document 0.. * A document definition. Out of scope for this version Copyright 2017 Health and Social Care Information Centre. Page 15 of 15