What Healthcare Architecture and Database Diagrams Need to Show

Nitin Sharma • Aug 18, 2026 • 15 min read

Information governance teams, clinical safety officers, security reviewers and procurement assessors evaluate healthcare software, even though they did not build it. Each of them asks a version of the same question: how does data move through this system, and where does a human intervene?

Architecture and database diagrams are how a team answers that question consistently. They are not compliance artefacts in themselves, and they do not make a product safe or lawful. What they do is make the system legible enough that the people responsible for those assessments have something concrete to evaluate.

This article covers what healthcare diagrams need to show that general software diagrams usually do not.

Key takeaways

Four healthcare-specific things belong on an architecture diagram: data classification on flows rather than only on stores, processing locations, human decision points, and failure behaviour on external dependencies.
The MHRA states that its July 2026 ambient voice technology guidance “does not change the law” — it sets out how existing medical device regulations are applied. Guidance clarifies; it does not create new obligations.
The MHRA describes products that “take automated action such as placing orders without clinician review” as regulated medical devices. Whether such a path exists is visible on an architecture diagram.
NHS England describes DCB0129 as defining clinical risk management requirements for manufacturers, and DCB0160 as covering organisations deploying and using health IT.
Both standards are under review. NHS England opened a consultation on 29 June 2026 which closes 11 September 2026.
The ICO describes a DPIA as required where processing is likely to result in high risk, and identifies large-scale processing of special category data as a trigger.
HHS identifies five technical safeguards under the HIPAA Security Rule — access control, audit controls, integrity, authentication and transmission security. Each corresponds to a boundary on a diagram.
FHIR provides Provenance and AuditEvent resources, which is a signal that traceability is a data modelling concern rather than only a logging one.
Source-of-truth ambiguity is the modelling decision teams most often defer and most often regret in EHR-integrated products.

Why healthcare diagrams differ

The usual argument for architecture diagrams applies everywhere: they help developers think, align teams and expose dependencies.

Healthcare adds a specific pressure. During an assessment, reviewers who did not build the system will evaluate written descriptions of it, so those descriptions must be accurate rather than approximate.

The questions that recur across those assessments are consistent. Where does patient data enter? Where is it stored, and where is it processed? Which third parties receive it? Which system is authoritative when two disagree? Does automated output reach a clinical record directly, or does a clinician review it first? What happens when an external system is unavailable? Can you reconstruct who changed what?

A team that has drawn these things can answer quickly. A team that has not tends to reconstruct the answer from memory and code-reading, which is slower and less reliable.

Four things a healthcare architecture diagram should show

1. Data classification on the flows

Label the movement of information, not only the stores:

Consultation audio → identifiable health data

Transcript → identifiable health data

Model prompt → health data

Analytics event → no patient data

This is the single most useful addition, because it exposes cases where a service nobody thought of as clinical is receiving clinical information. Analytics, error reporting, logging and support tooling are the usual culprits.

2. Processing locations

Where data is stored and where it is processed are separate questions, and a diagram showing a cloud provider as one box answers neither.

This matters commercially as well as technically. For teams selling into the UK or EU, buyers often ask first where the system processes and stores data, and those decisions become difficult to change later.

3. Human decision points

Represent review explicitly:

AI draft → clinician review → approved note

rather than AI service → EHR, if review is genuinely part of the intended workflow.

The MHRA’s guidance published on 29 July 2026 is relevant here. GOV.UK’s announcement says that the current framework does not regulate AVT products as medical devices when they only transcribe clinical conversations, summarise them, draft letters, or suggest clinical codes for clinician review. However, the framework regulates products that support diagnosis, treatment or prevention, or that take automated actions such as placing orders without clinician review, and requires them to meet the relevant safety and performance requirements.

The MHRA is explicit that this guidance does not change the law; it sets out how existing medical device regulations are applied.

For an engineering team, the practical reading is narrow and useful: whether a review step exists is a design property, and it is one that regulators have described as significant. If your diagram shows automated output reaching a clinical record or triggering a clinical action without review, raise this with the person responsible for your regulatory assessment before the team builds that workflow.

4. Failure behaviour on external dependencies

Healthcare systems depend on EHRs, FHIR servers, HL7 interfaces, identity providers, terminology services and laboratory systems. The diagram should state what happens when each is unavailable: queue, retry, block, degrade, show stale data, or proceed without it.

Failing safely usually matters more than failing rarely, and the answer is a product decision rather than a default that should emerge from a library’s retry configuration.

Interoperability needs a boundary

FHIR provides standardised resources and APIs for exchanging healthcare information. “Supports FHIR” nonetheless conceals real variation — vendors differ on capabilities, versions, implementation guides, extensions and operational constraints.

A useful architecture introduces an integration boundary:

Application → EHR adapter → FHIR or HL7 interface → EHR

Vendor-specific behaviour belongs in the adapter. Without that boundary, EHR-specific assumptions spread into business logic, and each new integration requires changes in many places rather than one.

What the database diagram needs to establish

The architecture diagram explains how the system behaves. The database diagram explains how information is structured, related and owned.

Source of truth

This is the modelling decision most often deferred and most often regretted.

If your application receives patient demographics, medications, problems, allergies and identifiers from an EHR, the model has to state whether you copy those fields, cache them, hold references only, permit local edits, or write changes back — and which system prevails when values differ.

If the model does not answer these questions, the code answers them implicitly, and different parts of the code may answer differently. The result is two systems holding different versions of the same fact with no defined authority.

A useful model labels each major category: EHR-owned, application-owned, derived, cached, generated, and audit or provenance data. That classification usually matters more than the table names.

Auditability is a schema decision

Healthcare systems are frequently asked who created a record, who changed it, what changed, when, which system produced it, which version was involved, and who approved it.

FHIR reflects this structurally rather than treating it as logging. HL7’s specification describes Provenance as covering the entities, agents and activities involved in producing or influencing a resource, and AuditEvent as recording events relevant to security, privacy and operations.

HHS identifies audit controls as one of the technical safeguards under the HIPAA Security Rule, describing them as mechanisms that record and examine activity in information systems containing or using ePHI.

The design consequences are concrete. Do you overwrite records or version them? Is the previous value retained? Do you overwrite records or version them? Is the previous value retained? Are audit entries themselves immutable? Every action should be attributable to a specific actor, and you should be able to reproduce a record’s state at an earlier point in time.

Those are schema questions, and retrofitting them onto a mutable schema means either losing history or migrating everything.

Tenant boundaries

Many products start with one clinic, then a second, then a group, then separate legal entities.

If tenancy was not modelled early, a query as simple as GET /patients/123 becomes a place where isolation can fail. Tenant boundaries affect authorisation, query construction, indexing, identifiers, API design, logging and administrative access simultaneously — which is why retrofitting is expensive.

This does not mean every early-stage product needs an elaborate multi-tenant platform. It means the team should decide whether tenancy is part of the intended product before the data structures decide for them.

Security boundaries

HHS describes five technical safeguards under the HIPAA Security Rule: access control, audit controls, integrity, person or entity authentication, and transmission security.

A diagram can show where teams enforce authentication and authorisation, which services can access patient data, which communications cross trust boundaries, where encryption applies, and which activities require auditing.

NIST’s Zero Trust Architecture requires teams to verify authentication and authorisation explicitly whenever a user or system requests access to a resource, rather than trusting access based on network location. A diagram with explicit trust boundaries is easier to review against that model than one that assumes a trusted perimeter.

Clinical safety analysis is structural

NHS England describes DCB0129 as defining clinical risk management requirements for manufacturers of health IT systems, and DCB0160 as covering organisations that deploy and use them. Both are published as information standards under section 250 of the Health and Social Care Act 2012.

Clinical safety work involves identifying hazards and documenting how they are managed. The hazards that are easiest to miss are not application bugs — they are interactions between components. An EHR write that fails partway. An identifier matched incorrectly. A cached medication list older than the source. An audit service that stops recording without alerting. A queue that retries a clinical write twice. A clinician approving content belonging to a different encounter.

A diagram makes those interactions visible, which supports a straightforward exercise: take each component and each arrow, and ask what happens if it fails, delays, duplicates, returns the wrong information, or becomes unavailable.

Data protection assessments need an accurate description

The ICO describes a data protection impact assessment as required where processing is likely to result in a high risk to people’s rights and freedoms, and identifies large-scale processing of special category data as one situation requiring one. Health information is special category data.

Whether a DPIA is required in a given case depends on the specific processing rather than on the sector, and that determination is a matter for your data protection adviser rather than for an engineering article.

What is relevant here is what the ICO says a DPIA should contain. Its guidance describes a systematic description of the processing — covering how data is collected and stored, who has access, who it is shared with, whether processors are used, retention periods and security measures.

Those are the same facts an architecture diagram records. A team that has drawn them has done part of the work already; a team that has not will assemble it later under time pressure.

What diagrams do not do

Being clear about the limits is what makes the rest of the argument credible.

They do not make a product compliant or safe. Both depend on the controls, processes and behaviour that actually exist.

They do not determine regulatory status. Classification depends on intended purpose and claims. A diagram can surface a question worth asking; it cannot answer it.

Clinical validation, security testing and professional advice remain necessary. Diagrams simply make each of those activities better targeted.

Accuracy also depends on maintenance. Once a diagram no longer matches the production system, it can mislead reviewers and create false confidence. Assign an owner and update it whenever the architecture changes, rather than relying only on a calendar-based review.

How KastHunt approaches this

Our sequence is clinical workflow, then data boundaries, then integration requirements, then architecture and data model, then implementation.

The reason is practical rather than philosophical: these decisions get progressively more expensive to reverse. Teams can decide early where to process data, which information the EHR remains authoritative for, where clinicians review output, and what the system must audit. Changing those decisions becomes far more expensive once real records exist.

This is what we mean by Clarity Before Code. A discovery engagement should produce artefacts a founder, clinician, security lead and engineer can all inspect, because the diagram is what lets them disagree with each other while disagreement is still inexpensive.

Pre-build checklist

Your diagrams should let the team answer:

Where does patient-identifiable information enter the system?
Which components process it, and which third parties receive it?
Where is data stored, and where is it processed?
Which system is the source of truth for each major data category?
Which data is cached or duplicated, and for how long?
Where are authentication and authorisation enforced?
Which actions require clinician review before taking effect?
Can any automated component write to a clinical record or trigger a clinical action without review?
What happens when the EHR or another external dependency fails?
How are consequential actions audited, and can output be traced to its source?
How are organisations and tenants separated?
Which architectural changes should prompt a review of your assurance documentation?

The last item is the one most often missing, and it is what keeps the others true over time.

Where this leaves healthcare software design

Healthcare software raises questions that cannot be answered from screenshots or a feature list. Where does the data go, who controls it, what happens when systems disagree, where does automation stop, and can you reconstruct events afterwards?

Those are architecture and data model questions before they become anything else. Answering them early is cheaper, and it means that when someone does ask formally, the answer already exists.

The diagram is not the assurance programme. It is the map that lets everyone involved confirm they are discussing the same system — which, in healthcare, is worth establishing before the first production record exists.

Deciding what to design before you build?

Healthcare teams should decide these critical product questions before implementation: where to process data, who owns it, who reviews it, what the system must audit, and how clinical systems should integrate.

That is what the Discovery Workshop establishes. Sometimes the output is an architecture ready to build. Sometimes it is the finding that the scope should change first. The second is cheaper to discover early.

Book a Discovery Workshop

FAQs

What should a healthcare architecture diagram show that a general one does not?

Four things: data classification on the flows rather than only on the stores, where processing and storage physically occur, where a human reviews or approves automated output, and what the system does when an external dependency such as an EHR is unavailable.

Can an architecture diagram tell us whether our product is a medical device?

No. Classification depends on intended purpose and claims. A diagram can, however, surface functionality worth reviewing — the MHRA has described products that take automated action such as placing orders without clinician review as regulated medical devices, and whether such a path exists is visible on a diagram. That is a question to raise with a qualified adviser, not one the diagram settles.

Does the MHRA’s ambient voice technology guidance change the law?

The MHRA states that it does not. GOV.UK’s announcement describes the guidance, published on 29 July 2026, as setting out how the MHRA applies existing medical device regulations to the technology.

What do DCB0129 and DCB0160 cover?

Are those standards changing?

NHS England opened a public consultation on DCB0129 and DCB0160 on 29 June 2026, stated to close on 11 September 2026. Check the current position with NHS England, as timelines and outcomes may have moved since this article was written.

Does every healthcare application need a DPIA?

Not automatically. The ICO describes a DPIA as required where processing is likely to result in a high risk to people’s rights and freedoms, and identifies large-scale processing of special category data as a trigger. Whether it applies to a specific product depends on the processing involved and is a question for your data protection adviser.

Which HIPAA safeguards are visible in architecture?

HHS identifies five technical safeguards under the Security Rule: access control, audit controls, integrity, person or entity authentication, and transmission security. Each corresponds to a boundary or control point a diagram can show.

Why is source of truth the critical database decision in EHR integration?

Because if the model does not state which system owns each category of patient information, the application code decides implicitly — and often inconsistently across different parts of the code base. That produces conflicting versions of the same fact with no defined authority.

Why model auditability at the start?

Because it determines whether records are versioned or overwritten, whether previous values are retained, and whether actions can be attributed to an actor. Retrofitting onto a mutable schema means either losing history or migrating everything. HL7 reflects this structurally in FHIR through the Provenance and AuditEvent resources.

Can multi-tenancy be added later?

It can, but expensively. Tenant boundaries affect authorisation, queries, indexes, identifiers, API design and logging at once, so retrofitting touches most of the application.

How often should diagrams be updated?

On architectural change rather than on a schedule. A diagram that has diverged from the deployed system is worse than none, because reviewers may confidently assess an architecture that no longer exists.

Do diagrams make a product compliant?

No. They provide context and evidence for assessment. Compliance and safety depend on the controls and processes that actually exist, and on advice specific to your product and jurisdiction.

About the author

Nitin Sharma is a Backend Engineer at KastHunt Consulting LLP, working on AI-native healthcare software and real-time backend systems. His work focuses on Agentic AI, Node.js development, conversational AI, WhatsApp and SMS automation, and real-time AI systems, with an emphasis on building reliable and scalable healthcare technology.
He writes about backend engineering, healthcare technology, AI systems and the practical challenges involved in designing and deploying intelligent software products.

Questions or corrections: info@kasthunt.com