惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
B
Blog
Stack Overflow Blog
Stack Overflow Blog
量子位
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tailwind CSS Blog
MongoDB | Blog
MongoDB | Blog
小众软件
小众软件
博客园 - 三生石上(FineUI控件)
Recent Announcements
Recent Announcements
U
Unit 42
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
腾讯CDC
D
DataBreaches.Net
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
M
MIT News - Artificial intelligence
P
Proofpoint News Feed
罗磊的独立博客
L
LangChain Blog
V
Visual Studio Blog
雷峰网
雷峰网
aimingoo的专栏
aimingoo的专栏
宝玉的分享
宝玉的分享

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Building a FHIR-Compliant ADT Database: Encounters, Polym...
Yusdirman Lu · 2026-05-07 · via DEV Community

Building a FHIR-Compliant ADT Database: Encounters, Polymorphism, and Facades

If you are a software engineer building a healthcare application today, you're inevitably going to cross paths with HL7 FHIR (Fast Healthcare Interoperability Resources). FHIR is fantastic as a standardized API format for exchanging healthcare data. But when it comes time to actually store that data in a traditional relational database (SQL), things get complicated fast.

Today, we're going to look at how to design a database architecture for a core hospital workflow: ADT (Admission, Discharge, Transfer). We'll explore why standard SQL design patterns don't always apply, the headache of polymorphic relationships, and how real-world systems handle these challenges.

1. The End of Fragmented Visit Tables

In a legacy hospital system, you might expect to see a database schema that looks like this:

  • table_outpatient_visits
  • table_inpatient_admissions
  • table_er_logs

FHIR completely rejects this pattern. In FHIR, every type of patient visit is centralized into a single resource called an Encounter. To distinguish between an emergency visit and a routine checkup, we don't use different tables; we use state definitions—specifically, the class attribute (mapped to v3-ActEncounterCode) and the status attribute.

Here is how a single Encounter table handles the whole ADT spectrum:

  1. Walk-in (Service Undecided): class = AMB (Ambulatory), status = arrived. It's linked to a Patient and maybe a generic waiting room location, but no doctor is assigned yet.
  2. Outpatient: class = AMB. The encounter is linked to a specific Practitioner (doctor) and a consultation room.
  3. Inpatient: class = IMP (Inpatient), status = in-progress. This involves a complex history of Location relationships as the patient transfers from the Admission Ward -> Surgery -> Recovery Bed.
  4. Emergency: class = EMER. Often transitions into an IMP encounter if the patient is admitted (linked via Encounter.partOf).
  5. Daycare: class = SS (Short Stay). Mapped to a specific infusion chair or recovery bed for < 24 hours.

The ADT Entity-Relationship Diagram

Here is a simplified view of how these FHIR resources translate into relational tables:

erDiagram  
    PATIENT {  
        string id PK  
        string identifier  
        string name  
        date birthDate  
    }  

    ENCOUNTER {  
        string id PK  
        string patient\_id FK "Wait, is this a standard FK? See below\!"  
        string class\_code "AMB, IMP, EMER"  
        string status   
        datetime period\_start  
    }  

    LOCATION {  
        string id PK  
        string physical\_type "room, bed, ward"  
    }  

    ENCOUNTER\_LOCATION {  
        string encounter\_id FK  
        string location\_id FK  
        string status "planned, active, completed"  
    }

    PRACTITIONER {  
        string id PK  
    }

    ENCOUNTER\_PARTICIPANT {  
        string encounter\_id FK  
        string practitioner\_id FK   
        string type\_code "admitter, attender"  
    }

    PATIENT ||--o{ ENCOUNTER : "has"  
    ENCOUNTER ||--o{ ENCOUNTER\_LOCATION : "occupies"  
    LOCATION ||--o{ ENCOUNTER\_LOCATION : "houses"  
    ENCOUNTER ||--o{ ENCOUNTER\_PARTICIPANT : "involves"  
    PRACTITIONER ||--o{ ENCOUNTER\_PARTICIPANT : "acts as"

Enter fullscreen mode Exit fullscreen mode

2. The Elephant in the DB: Polymorphic Relationships

If you looked closely at the ERD above, you might have noticed a problem. I mapped patient_id as a standard Foreign Key on the ENCOUNTER table.

If you are building a strict, 100% compliant FHIR backend, that Foreign Key is illegal.

Why? Because FHIR relies heavily on a data type called a Reference. A Reference doesn't strictly point to a single table.

  • Look at the spec for Encounter.subject. It can be a reference to a Patient, OR a Group (e.g., for group therapy).
  • Look at Encounter.participant.individual. It can point to a Practitioner, a PractitionerRole, or a RelatedPerson.

How do you implement this in SQL?

Standard Foreign Keys (e.g., CONSTRAINT fk_patient FOREIGN KEY (subject_id) REFERENCES patients(id)) strictly enforce a link to one target table. To support FHIR, you must abandon strict DB-level referential integrity and embrace Polymorphic Associations.

Instead of a patient_id column, your schema needs two columns:

  1. subject_type (VARCHAR) - e.g., "Patient" or "Group"
  2. subject_id (VARCHAR) - e.g., "12345"

The Trade-off: Polymorphism gives you the flexibility FHIR demands, but you lose database-level Foreign Key constraints. Your application layer (or complex database triggers) is now solely responsible for ensuring that if subject_type="Patient" and subject_id="123", Patient 123 actually exists.

3. Real-World Case Study: The Frappe/Marley Healthcare Approach

Building a native FHIR document store from scratch is hard. Let's look at how a real-world system handles this using standard SQL.

Marley Healthcare (built on the Frappe/ERPNext framework using MariaDB) takes a very pragmatic approach. Rather than forcing MariaDB to act like a native FHIR document database, it uses a FHIR Facade pattern.

1. Operational ERP Tables First

Frappe prioritizes hospital operations (billing, inventory, UI). So, under the hood, MariaDB holds highly normalized, flat tables generated by Frappe's "DocTypes". You will actually find separate tables like tabPatient_Encounter (for OPD) and tabInpatient_Record (for IPD) because they trigger different billing and HR workflows.

2. The API Adapter

When a system requests FHIR data, Frappe's Python backend queries these disparate operational tables, merges them, and dynamically serializes the data into a compliant FHIR Encounter JSON payload. It’s an adapter pattern at the API boundary.

3. Solving Polymorphism with "Dynamic Links"

How does Frappe handle the FHIR Reference polymorphism in MariaDB? By using a built-in framework feature called Dynamic Links. Frappe uses exact two-column pairs:

  • link_doctype: Stores the target table name (e.g., "Patient").
  • link_name: Stores the target record ID.

This allows Marley Healthcare to support FHIR's polymorphic data structures perfectly within a standard MariaDB relational database without hardcoded schema limitations.

Conclusion

When building for FHIR on SQL, you have a choice to make. Do you build a strict, normalized schema that acts as a FHIR Facade (like Frappe), or do you build a native FHIR data store utilizing heavy polymorphism?

Understanding the unified Encounter paradigm and the necessity of polymorphic references is the first step to making the right architectural choice for your healthcare app.