Recipe 13.10: Federated Clinical Knowledge Network

Effort: 5 of 5

The Problem

Here's a scenario that plays out every day in healthcare: a patient with a rare autoimmune condition moves from a research hospital in Boston to a community health system in rural Tennessee. The Boston hospital has a rich knowledge graph connecting that patient's condition to experimental treatments, genetic markers, and clinical trial outcomes. The Tennessee system has never seen this condition. Their local knowledge base has nothing useful.

Now multiply that by every rare disease, every novel drug interaction, every emerging treatment protocol. Each health system builds its own clinical knowledge in isolation. Academic medical centers accumulate deep expertise in their research specialties. Community hospitals develop practical knowledge about managing chronic conditions in underserved populations. Payers build claims-derived insights about treatment effectiveness at scale. None of this knowledge flows between organizations.

The result is a healthcare system where the collective clinical intelligence is fragmented across thousands of institutional silos. A researcher at one institution discovers that a particular drug combination shows promise for treatment-resistant depression. That knowledge lives in their local graph. Meanwhile, three other institutions have patients who could benefit, but they'll never know unless someone happens to publish a paper and someone else happens to read it. That cycle takes years.

The obvious solution is "just put everything in one big graph." But that's a non-starter. Patient data is governed by HIPAA. Institutional knowledge represents competitive advantage. Research data has IP implications. No hospital is going to dump their clinical knowledge into a shared database controlled by someone else. The governance, legal, and competitive barriers are real and legitimate.

What you actually need is a way to query across distributed knowledge graphs without centralizing the data. Each institution keeps control of their own graph, their own governance policies, their own access rules. But when a clinician at Institution A asks "what do we know about treatment options for condition X?", the system can reach across institutional boundaries and bring back relevant knowledge from Institutions B, C, and D, filtered through each institution's sharing policies.

This is federated knowledge graph querying. It's architecturally hard, politically harder, and genuinely important.

The Technology: Federated Knowledge Graphs

Knowledge Graphs: Quick Refresher

A knowledge graph represents information as entities (nodes) connected by relationships (edges). In healthcare, entities might be diseases, drugs, genes, procedures, or clinical concepts. Relationships encode things like "treats," "causes," "interacts_with," or "is_subtype_of." The power of a graph representation is that you can traverse relationships to discover non-obvious connections: Drug A treats Disease B, which shares a genetic pathway with Disease C, which responds to Drug D. That traversal is a query.

Most clinical knowledge graphs use RDF (Resource Description Framework) or property graph models. RDF represents everything as subject-predicate-object triples: (Metformin, treats, Type2Diabetes). Property graphs allow richer attributes on both nodes and edges. Both work for federation, but the query languages differ: SPARQL for RDF, Cypher or Gremlin for property graphs.

What Makes Federation Different from Replication

Replication means copying data from multiple sources into one central store. You get a single unified graph, but you lose governance control. The source institutions can't revoke access to specific knowledge after it's been copied. They can't enforce fine-grained sharing policies. And the central store becomes a single point of failure and a massive compliance liability.

Federation means the data stays where it is. Queries are decomposed and routed to the relevant source graphs, executed locally, and results are assembled back at the requesting node. Each source graph applies its own access control before returning results. No data moves permanently. The federation layer is a query router, not a data store.

This distinction matters enormously in healthcare. A federated architecture lets Institution A share drug interaction knowledge broadly while keeping patient-derived insights restricted to approved research collaborators. That granularity is impossible with replication.

The Query Federation Problem

Federated querying sounds simple until you try to build it. Here's what makes it hard:

Schema heterogeneity. Each institution models their knowledge differently. One uses SNOMED codes for diseases. Another uses ICD-10. One represents drug interactions as edges between drug nodes. Another represents them as intermediate "interaction" nodes with severity properties. Before you can query across graphs, you need a shared understanding of what the entities and relationships mean. This is the ontology alignment problem, and nobody has cracked it for the general case.

Query decomposition. A federated query like "find all known treatments for condition X with evidence level A or B" needs to be broken into sub-queries that each source graph can answer. The federation layer needs to know which graphs might have relevant data (query routing), how to translate the query into each graph's local schema (query rewriting), and how to combine partial results (result merging). Each of these is a research problem in its own right.

Performance. A local graph query returns in milliseconds. A federated query that touches five remote graphs, each with network latency, authentication overhead, and local query execution time, might take seconds. For interactive clinical decision support, that's too slow. Caching, pre-computation, and intelligent query planning become essential.

Trust and provenance. When results come back from multiple sources, the clinician needs to know where each piece of knowledge originated, what evidence supports it, and how current it is. A drug interaction flagged by an academic research graph based on a 2024 clinical trial carries different weight than one flagged by a payer's claims analysis. Provenance metadata must travel with the results.

Privacy-preserving queries. Some queries might inadvertently reveal information about the querying institution's patients. If Institution A asks "what treatments exist for [extremely rare condition]?", that query itself reveals that they have a patient with that condition. Differential privacy techniques and query obfuscation can help, but they add complexity and reduce result quality.

Emerging Standards

The healthcare industry is slowly converging on standards that make federation more tractable:

Fast Healthcare Interoperability Resources (FHIR) provides a common data model for clinical concepts. While FHIR is primarily designed for patient data exchange, its resource types and terminology bindings provide a shared vocabulary that knowledge graphs can align to.

Clinical ontologies like Logical Observation Identifiers Names and Codes (LOINC), SNOMED CT, RxNorm, and ICD provide canonical identifiers for clinical concepts. If every participating graph maps their local concepts to SNOMED codes, you have a shared key space for federation, even if local schemas differ.

W3C standards for linked data (RDF, SPARQL, SPARQL Federation extensions) provide a technical foundation for distributed graph querying. The SPARQL 1.1 Federated Query extension (SERVICE keyword) allows a query to explicitly delegate sub-patterns to remote endpoints.

TEFCA (Trusted Exchange Framework and Common Agreement) establishes governance principles for health information exchange in the US. While focused on patient data, its trust framework concepts (qualified health information networks, data use agreements) apply to knowledge federation as well.

None of these fully solve the problem. But they provide building blocks that make federation architecturally feasible rather than purely theoretical.

The General Architecture Pattern

A federated clinical knowledge network has these logical components:

[Local Knowledge Graphs] → [Federation Layer] → [Query Router] → [Result Assembler] → [Consumer Applications]
         ↑                        ↑                    ↑
    [Ontology Alignment]    [Access Control]    [Provenance Tracking]

Local Knowledge Graphs. Each participating institution maintains their own graph database with their own schema, their own data governance, and their own access policies. These are the source of truth. They expose a query endpoint (SPARQL endpoint, GraphQL API, or custom protocol) that the federation layer can call.

Ontology Alignment Layer. A shared mapping between local schemas and a common federated schema. This doesn't require every institution to change their local model. It requires a translation layer that can convert between local representations and the federated query language. Think of it as a Rosetta Stone for clinical knowledge models.

Federation Layer. The orchestrator. It receives a query in the federated schema, determines which source graphs might have relevant data (catalog lookup), rewrites the query into each source's local schema (query translation), dispatches sub-queries in parallel, and assembles results.

Access Control. Each source graph enforces its own sharing policies. The federation layer passes authentication context (who is asking, from which institution, for what purpose) to each source. Sources return only what the requester is authorized to see. This is attribute-based access control (ABAC) at the knowledge level.

Provenance Tracking. Every result carries metadata: which source provided it, what evidence supports it, when it was last updated, and what confidence level the source assigns. This lets consumers make informed decisions about which knowledge to trust.

Result Assembly. Partial results from multiple sources are merged, deduplicated, ranked, and presented as a unified response. Deduplication is non-trivial: two sources might report the same drug interaction with different severity ratings. The assembler needs conflict resolution strategies. For safety-critical knowledge (drug interactions rated "high" severity), the assembler should surface all perspectives with their provenance rather than silently picking a winner. A clinician needs to see that two sources disagree on severity, not just the "winning" answer.

The AWS build lives in a companion page. This recipe covers the problem, the underlying technology, and the vendor-agnostic architecture. For the AWS services, architecture diagram, prerequisites, and the step-by-step pseudocode walkthrough, see the Architecture and Implementation companion. The Python example is linked from there.

Recipe 13.8 (Medical Concept Normalization and Mapping): Provides the ontology alignment foundation that federation depends on. Build 13.8 first.
Recipe 13.9 (Literature-Derived Knowledge Graph): One of the source graph types that participates in federation. Literature-derived knowledge is often the most shareable.
Recipe 13.4 (Drug-Drug Interaction Knowledge Base): The classic first use case for federation. Start here for your pilot.
Recipe 5.8 (Privacy-Preserving Record Linkage): Shares privacy-preserving computation techniques applicable to query obfuscation.
Recipe 5.9 (National-Scale Patient Matching): Addresses similar cross-institutional trust and governance challenges at the patient data level.