Perspective
Name One System of Record for Each Kind of Patient Data Before You Build an Interface
Connection is the easier half of hospital records. We settle which system owns each fact first, then connect them so that every failure raises an alert.
4-minute read5 November 2026
In Brief
- One patient can exist as several records across billing, laboratory, imaging and ward systems. Once records leave the building, the receiver cannot see the desk where the error began.
- We see four actions: name an authoritative system for each kind of data, settle identity at the front door, correct at the source, and raise an alert on any failed connection.
- Thinqmesh maps which system owns each fact, builds the connections between them, and brings your first connection to unattended running within four weeks.
A patient's history is spread across a clinic, a laboratory, a hospital, a pharmacy and an insurer, and even inside one hospital the billing, laboratory, imaging and ward systems can each hold a slightly different version of the same person. Programmes of this kind usually begin by commissioning interfaces. We see connection as the easier half. The harder half is deciding which system is authoritative for each kind of data.
An Interface Carries a Decision It Cannot Make
Records leave a hospital with the hospital's name on them, so the hospital stays answerable for what it created. A patient registered twice, an allergy typed into three notes and corrected in one, or a result returned against an order from one system and a registration from another all become more serious once the record travels, because the receiver cannot see where the error began.
We ask for one authoritative system for demographics, orders, results, medication, allergies, diagnoses and discharge summaries. Corrections are made at the source and flow outward. The integration layer enforces that decision, and an alert names any connection that fails.
Four Actions That Give Every Record an Owner
Each action settles a decision the interface cannot make for you, so the connections we build carry settled data from the first day.
Name an Authoritative System for Each Kind of Data
Demographics, orders, results, medication, allergies, diagnoses and discharge summaries each get one system that is the source.
Other systems may display or copy the data, but corrections are made at the source and flow outward. We map every system in the hospital and record which one owns each fact. That map is the first deliverable, and every connection we build afterwards follows it.
Get started
- List the systems that hold a patient's allergies today.
- Decide which one should be the source and write it down.
Settle Patient Identity at the Front Door
Duplicate registrations, a mobile number that belongs to a relative and patients with no identifier to offer all begin at admission.
A patient registered twice under two spellings, or a family of four sharing one mobile number, creates records that cannot be matched later. We review how registration works for newborns, unconscious patients and elderly patients without a phone, and agree one rule for each case with your registration team.
Get started
- Take twenty recent registrations and look for duplicates.
- Write down what the desk does when a patient cannot give an identifier.
Correct at the Source and Let the Change Flow Outward
An allergy typed into three notes and corrected in one leaves three versions of the same fact.
Once each fact has one owner, a correction made there is read by every other system. That removes the hand reconciliation of results returned against an order from one system and a registration from another, and it gives clinicians the same answer wherever they look.
Get started
- Find one fact that is stored in more than one system.
- Trace which copy was corrected the last time it changed.
Make Every Failed Connection Visible
A connection that fails quietly lets incorrect data spread for weeks.
Every connection we build raises an alert that names what failed and what it was doing, so someone can act before the error travels. Each connection comes with documentation that your own developer can pick up, which keeps the knowledge in the hospital.
Get started
- Ask who would notice today if the laboratory feed stopped for a day.
- Name who should receive the alert.
How Thinqmesh Solves This
Four weeks takes one connection to unattended operation on a defined scope. Anything touching payments or statutory records, and multi-system integration, follows its own plan with its own date.
- Week 1
A Map of Your Systems and Who Owns Each Fact
We map every system and record which one owns each fact, and we check which connections are worth building.
- Week 2
The First Connection Built
The first connection is built on a defined scope, running on a schedule or on an event, with one sign-in where the tools allow it.
- Week 3
Failures That Raise an Alert
Failures raise an alert naming what failed. If a system cannot export its history, extraction is planned as its own piece of work with its own date.
- Week 4
Running Unattended, Documented
Your first connection runs unattended, and the documentation lets your own developer pick it up.
You finish with one connection running unattended, a map of which system owns each fact, alerts on failure, and documentation your developer can use. Each further connection follows the same pattern.
