Integrations & data · Practice guide

Explain the practical purpose of a FHIR connection

Illustrative situation

A project brief asks for a FHIR integration without explaining what information needs to move or why. FHIR is a standard for exchanging healthcare information. Its name is a starting point for a supplier discussion, not a description of what the practice will receive. Explain the sender, recipient, required information and useful result first.

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 information handover and the result your team needs. Ask the implementation specialists to identify the relevant FHIR components and any limits of the specific connection.

An example to discuss with your team

Explain the proposed handover to the receiving team without using the standard's name. They should be able to recognise the result being requested.

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

Ask the receiving team to describe the proposed handover without using the standard's name. The implementation team can then identify the relevant technical parts. Keep unresolved assumptions written down. The official HL7 introduction linked below explains the standard and its implementation context.

Agree the working process

Write a one-page description of the exchange in ordinary terms: what happens in the sending system, what information the recipient needs and what useful action should become possible. Include the circumstances in which the exchange should not proceed or should wait for review. This gives the implementation team a concrete task to translate into the relevant standard and local requirements. Ask both organisations to review the same fictional example and agree its meaning before focusing on format.

A technically valid exchange can still be unhelpful if the receiving team expects different information or has no process for it. Keep a named owner for business questions and separate technical assumptions awaiting supplier confirmation. During acceptance, return to the original description and ask the receiving team to demonstrate the intended result. You do not need to become an expert in the standard to recognise whether the agreed administrative handover works, whether exceptions are owned and whether the delivered outcome matches the reason for the project.

How to check the result

Count unresolved business requirements behind the technical label.

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.