Skip to main content

Part of NHS architecture principles

Build a data layer with registers and APIs

Digital services should only store data once (usually where collected) and make it available via open application programming interfaces (APIs) whilst maintaining privacy and security.

Current Chapter

Current chapter – Build a data layer with registers and APIs


Page contents

Summary

Digital services should only store data once (usually where collected) and make it available via open application programming interfaces (APIs) whilst maintaining privacy and security.


Rationale

Storing data only once reduces costs by removing requirements for data replication/propagation when the data changes and we ensure that each individual (patient or clinician) has visibility of the same record.

Storing data once and making it available via APIs reduces the requirement for costly large databases of personal health and care data to deliver our services and meet our research aims.

Smaller, dispersed datasets mean fewer large attractive targets for hackers.


Implication

  1. Implement designs that reuse platforms and separate out disparate components, without dependency on one another. This is known as loosely coupled architecture.
  2. APIs should be made publicly available through an API management layer based upon open standards.
  3. Documentation should be published in the API catalogue
  4. APIs should also be consumed internally unless there is a reason not to do so. Note that this supports a loosely coupled architecture. 
  5. This should be shown in architecture diagrams and assessed by the Architecture Approval Group.

Last edited: 12 March 2021 1:30 pm