Healthcare organizations do not need another place to store information. They need a reliable way to determine what the information means, whether it still applies, and what should happen next.
By Raj Brar, Founder of Argus AI Labs
Consider a representative case.
A hospital team is reviewing a care pathway after an unexpected outcome. The patient record is available. So are the laboratory results, medication history, clinical notes, and the protocol stored in the document system.
The first question sounds simple: which protocol was in force when the decision was made?
Then the real work begins.
One version sits in a shared drive. Another appears in the clinical system. A revised document was approved, but the effective date is unclear. The note uses terminology that does not match the protocol. Access to part of the record is restricted. Nobody can tell whether the AI-generated summary used the current rule, the archived rule, or both.
The organization has the data. What it lacks is the architecture required to assemble that data into a dependable answer.
That is the job of healthcare knowledge architecture.
It is the governed layer that connects clinical information to meaning, time, authority, permissions, and decision context. Without it, a health system can exchange data successfully and still fail to use that data reliably.
Interoperability moves information. It does not finish the reasoning.
Healthcare has made real progress on data exchange.
FHIR, published by HL7, provides a standard for exchanging healthcare information electronically. Its resource model gives clinical and administrative information known identities, structured elements, versions, and defined methods of exchange. In the United States, USCDI establishes a standardized set of health data classes and elements for interoperable exchange.
Those standards matter. They give systems a common way to represent and move information.
But moving an observation from one system to another does not determine how that observation should affect a particular decision.
A laboratory result still has a collection time. A medication order may have been changed, discontinued, or entered in error. A protocol may have been approved on one date and become effective on another. A clinical note may contain a provisional assessment that was later revised.
The data can be technically interoperable while the decision context remains fragmented.
This is where many AI projects begin to break down. The model receives accessible information, but the surrounding system has not established which evidence is current, which source is authoritative, which relationships matter, or which conditions require human review.
The model is then asked to resolve an architectural problem through prediction.
That is too much authority to give a statistical component.
Meaning depends on relationships, not just fields
Clinical terminology is not a list of interchangeable labels.
SNOMED CT represents clinical meaning through concepts, descriptions, hierarchies, and formal relationships. Those relationships allow systems to recognize that two expressions may refer to related clinical ideas even when the wording differs.
That is important because real clinical information does not arrive in one vocabulary.
A physician may use an abbreviation in a note. A laboratory system may use a standardized code. A payer policy may use a broader category. A research paper may describe the same condition with a more specific term. A local protocol may use language that evolved over several revisions.
Searching those sources for identical words will miss relevant connections. Embedding them in a vector index may improve retrieval, but similarity alone still does not establish the nature of the relationship.
Is one concept a subtype of another? Did a finding occur before or after an intervention? Does a policy apply to this setting? Was the relationship asserted by a clinician, inferred by a model, imported from a terminology standard, or approved by an institutional committee?
Those distinctions belong in the architecture.
A healthcare knowledge layer should preserve not only the concepts, but also the meaning and origin of the connections between them. Otherwise, the system may retrieve related information without knowing whether that information is applicable.
Time is part of the clinical fact
Most databases can store a timestamp. That does not mean the organization can reason over time.
Healthcare knowledge changes at several levels:
- A patient’s condition changes.
- Orders and medications change.
- Clinical protocols are revised.
- Terminology releases change.
- Access permissions change.
- Regulatory and payer requirements change.
A dependable system must be able to reconstruct what was known, approved, and applicable at the moment of a decision.
That requires more than a last_updated field.
The architecture needs to distinguish when information was created, when it became valid, when it stopped being valid, who approved it, and what replaced it. It must preserve history without allowing an obsolete version to quietly enter a current workflow.
ONC’s current USCDI framework includes provenance elements describing who created data and when it was created. FHIR also includes resources for provenance and audit events. These provide important building blocks. The organization still has to connect them to its own authority model and workflow rules.
If a protocol changes on Monday, the system should not merely overwrite Friday’s version. It should know which version governs a decision made on Friday, which governs a decision made on Tuesday, and whether the change requires re-evaluation of any open cases.
That is temporal knowledge architecture in practice.
Provenance and permissions have to survive the AI pipeline
An answer is only as trustworthy as the path used to produce it.
When information moves from an EHR, document repository, imaging system, or research database into an AI workflow, the original controls cannot disappear at ingestion.
The knowledge layer should preserve:
- the originating system and record;
- the author or responsible organization;
- the version and effective period;
- the terminology or mapping applied;
- the transformations performed;
- the permissions governing access;
- the evidence retrieved for a specific output;
- the model or rule that contributed to the result;
- the person who reviewed or approved an exception.
Without that chain, the organization may know what the AI said but not why it said it.
The permission problem is just as important. A document can be properly restricted in its source system and become overexposed when copied into a retrieval index. If identity and authorization rules do not travel with the information, the AI layer creates a new access surface that the original system never intended.
This is why governance cannot be added after the application is built. Provenance, permissions, and review boundaries are part of the application architecture.
The missing distinction is relevance versus applicability
Our internal R&D at Argus exposed a failure that reaches well beyond one domain: information can be relevant to a question without being applicable to the decision.
A semantic retrieval system is good at finding material that resembles the language of a query. It is less reliable at determining whether a source governs the specific facts, time period, organization, role, or workflow in front of it.
Healthcare has the same structural problem.
A protocol from another department may be relevant but not authoritative. A research finding may be important but not incorporated into institutional guidance. A previous version of a policy may closely match the question while no longer being valid. A general clinical concept may be related to the patient record without satisfying the conditions of a specific pathway.
Relevance asks: Is this information connected to the question?
Applicability asks: Does this information govern this decision, for these facts, at this time, under this authority?
That second question cannot be left to text similarity alone.
It requires explicit relationships, temporal validity, authority, policy conditions, and a defined exception path. In higher-risk workflows, it also requires a person who is authorized to review the evidence and stop the system.
AI should operate inside the architecture
The model is a component.
It may extract concepts from notes, normalize language, summarize evidence, identify possible relationships, or help a user navigate complex records. Those capabilities are useful.
But the surrounding system must decide what the model is allowed to see, which sources it may use, what evidence it must return, when it can recommend an action, and when it must stop.
At Argus, we think about that operating layer through five controls:
- Verified knowledge — approved sources and relationships are distinguishable from model-generated suggestions.
- Bounded agents — every agent has defined tools, permissions, tasks, and escalation conditions.
- Sovereign infrastructure — sensitive information remains within the organization’s chosen boundary.
- Human review — exceptions and consequential decisions return to an authorized person.
- Continuous evaluation — the system is tested against real failure modes as sources, workflows, and models change.
This architecture does not replace clinical judgment. It protects the conditions under which people and AI use institutional knowledge.
Start with one decision loop
A health system does not need to model the entire organization before creating value.
Start with one repeated decision where fragmented information causes delay, rework, or uncertainty. Protocol change management is a practical example because it exposes the full architecture without requiring the system to make a clinical decision.
Map the loop:
- Who proposes a protocol change?
- Which evidence and institutional policies support it?
- Who has authority to approve it?
- When does the new version become effective?
- Which systems and teams must receive it?
- What happens to open workflows governed by the prior version?
- How can a user verify which version applies?
- What evidence proves that the change was distributed and acknowledged?
Then build only the knowledge required to make that loop dependable.
Connect the sources. Normalize the terminology. Represent the relationships. Encode validity dates and authority. Preserve permissions. Define the human checkpoint. Test what happens when evidence conflicts, a version is missing, or the system cannot determine applicability.
Once that loop works, the same foundation can support adjacent workflows without starting from zero.
That is how knowledge architecture compounds: not by collecting everything first, but by making one real decision dependable and extending the structure from there.
Healthcare AI needs an operating layer
Healthcare already has data standards, clinical terminologies, exchange protocols, repositories, and increasingly capable models.
The missing layer is the one that makes those components work together under real institutional constraints.
Healthcare knowledge architecture connects information to meaning, time, provenance, authority, permissions, and execution. It allows an organization to show not only what information was retrieved, but why it applied and who remained responsible for the decision.
AI becomes dependable when it operates inside that structure.
The goal is not to make every piece of clinical information available to a model. The goal is to make the right knowledge available, under the right authority, for the right decision—and to stop when the system cannot prove the difference.
Frequently Asked Questions
What is healthcare knowledge architecture?
Healthcare knowledge architecture is the governed structure that connects clinical and operational information to meaning, relationships, temporal validity, provenance, permissions, authority, and decision context. It sits above source systems and exchange standards so people and AI can determine not only what information exists, but how it may be used.
How is a healthcare knowledge architecture different from FHIR?
FHIR is a standard for representing and exchanging healthcare information electronically. A knowledge architecture can use FHIR resources while adding institution-specific relationships, authority, validity periods, workflow rules, permissions, and review boundaries. FHIR helps information move consistently; the knowledge architecture helps the organization use it consistently.
Does a healthcare knowledge architecture require a knowledge graph?
Not every component must be stored in a graph, but graph structures are useful when meaning depends on relationships among patients, observations, medications, protocols, organizations, evidence, and time. The correct design may combine graph, relational, document, vector, and event stores. The decision should follow the workflow rather than a preferred database product.
Sources
- HL7 FHIR Overview
- HL7 FHIR Resource Model
- SNOMED CT Introduction
- SNOMED CT Intended Use
- ONC United States Core Data for Interoperability
See how Argus AI Labs builds governed enterprise AI systems around your data →