Integrations & data · Practical guide

Healthcare integrations: what to check before a build

Before pricing a healthcare integration, establish whether the systems expose the access and operations your workflow needs. An API badge or a reference to an interoperability standard is a starting point for investigation, not confirmation that two products will connect.

Describe the exchange precisely

For each exchange, record the trigger, sending system, receiving system, fields and expected outcome. Identify the authoritative source for each piece of information. If both systems can edit the same value, define how a conflict is resolved.

For example, sending a booking request to a diary is different from reading availability or cancelling an appointment. A platform may support one operation and restrict another. Ask the vendor to demonstrate the required operation in a test environment using fictional records.

Request evidence from each supplier

  • Current interface documentation and the supported version.
  • Access requirements, commercial terms and any onboarding steps.
  • A test environment with examples of the required operations.
  • Limits on requests, record sizes and supported data types.
  • How identity, permissions and audit information are handled.
  • Who responds to failures and how interface changes are announced.

Design the failure path

Specify what happens after a timeout, rejected record or unavailable service. Retrying an operation should not create duplicate bookings or duplicate records. Give failures a visible queue and assign someone to resolve them.

Agree how staff can tell whether information is current. A dashboard that displays yesterday's data without saying so may be worse than an explicit unavailable message. Record the last successful exchange and define when an alert should be raised.

Treat standards and access separately

If an NHS connection is in scope, use the NHS API catalogue to identify the relevant interface and then inspect that interface's own access and onboarding requirements. Do not assume access because the documentation is public.

The discovery output should be a field map, system ownership table, dependency list, test plan and support model. Build an initial exchange only after the important access questions are answered. Kay & Co. can use this evidence to scope a connection, custom middleware or an alternative workflow.

Further reading

These primary sources provide additional context for the project decisions above.

Related decisions

Turn the brief into a working service

Kay & Co. can help you scope the work, design the experience and deliver the right solution for your organisation.

Explore integrations & data services or discuss your project.