1. A consent handling API endpoint.
Analysis of back-end implementation of consent checking revealed that it was no longer necessary to impose upon consumers a requirement to check consent because this was already being performed by the back-end service during the handling of an SCR request. Now, this API endpoint simply updates consent status by translating the FHIR R4 based standard into the HL7 V3 SOAP request required to integrate with the existing back-end consent service.
2. An update handling API endpoint.
As the back-end of the SCR service was built natively to handle updates asynchronously, the ability to change this was limited to enabling a new back-end API endpoint which the client could poll for the result. This would remove the need for SCR API consumers to stand up a web server to listen for incoming results – in itself an important step forward.
From a consumer perspective, 2 options were available to us:
- expose the two back-end endpoints to consumers, and require consumers to poll for results
- implement an intermediary layer in order to present a simple synchronous API to consumers
We chose the second option, even though it represented more complexity in the API itself, because the consumer first viewpoint seeks to move complexity from API consumers to API providers where possible.
3. Alerts client endpoint
Initial analysis suggested that the SCR service raised privacy alerts on behalf the API client where necessary, and therefore this component was excluded from the initial design.