Integrations & data · Practice guide

Check an API can perform the business task you need

Illustrative situation

A supplier confirms it has an API but has not shown whether it supports the clinic's required update. An API is a supported way for software to exchange information, but its existence does not promise every operation you need. Start with the task, such as creating an enquiry or updating a status, and ask for evidence.

Healthcare booking calendars on two connected screens with blue and orange appointment cards.
Make the handover between tools clear for the team using them.

What this means for your practice

Describe the exact business operation and ask for a supported demonstration. Public documentation and commercial access can differ, so resolve access prerequisites explicitly.

An example to discuss with your team

Demonstrate the required operation with fictional records in an authorised environment.

Healthcare data integration connecting two applications through a field-mapping board.
Agree what each field means and which system owns it.
Healthcare data validation separating matched records from an exception tray.
Make rejected or uncertain records visible for review.

Questions to take to your supplier

Request a demonstration of that exact operation with fictional records. Confirm the fields, access prerequisites and supported limits with the supplier. Keep unverified needs visible in the proposal so a general integration claim does not turn into an unexpected restriction after purchase.

Agree the working process

Prepare a short list of the operations the practice needs, with examples of the before-and-after record. Reading information, creating something new and updating an existing value may have different support and permission requirements. Ask the supplier to match each operation to the specific supported interface and current documentation. Keep commercial access and onboarding questions visible alongside technical capability; a documented operation may still require an account arrangement that has not been confirmed. Use fictional records in an authorised environment to demonstrate the required fields and receiving outcome.

Include a rejected request so the practice sees how exceptions will be handled. Where a capability is unavailable, ask for the proposed alternative and its ongoing support responsibilities before accepting the scope. The technical team should retain implementation details, while the business brief explains what staff will be able to do. This makes estimates and acceptance more concrete than a general statement that both products have APIs and therefore can be connected.

How to check the result

Count essential operations still supported only by an assumption.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore integrations & data services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.