High-level design principles related to the Open API design.
Tip: GP Connect has aligned with NHS England’s Open API Policy to support the ambition of moving to a position where significant business functionality available within systems is exposed through interfaces where the definition is open.
Important: GP Connect has adopted the FHIR® standard (DSTU2) and as such the FHIR API design principles will be followed unless a clear rationale exists to amend. When an amendment is required this decision will be logged and the rationale clearly communicated.
- FHIR API providers to provide a Conformance resource for the server
- FHIR RESTful API principles to be used by default
- synchronous endpoints using
GET,POST,PUTandDELETEHTTP verbs
- synchronous endpoints using
- FHIR Operation APIs to be used in limited “set piece” circumstances
- for example, to pull bundles of resources without using the full generic querying syntax
- Uniform Resource Identification (URI) as the resource’s Logical Identity
- business identifiers (such as NHS Number) used to resolve a resource’s Logical Identity
- resources represented as either XML or JSON as requested by the API consumer. To ensure maximum accessibility, GP Connect is expecting producers to support both formats. However since XML is on average 30% larger on the wire there is a preference towards use of JSON.
- HTML content to utilise XHTML in line with the FHIR Narrative guidance
- eTags for managing version aware updates
