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

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"

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.