FHIR-First Standard — Ghasi EHR (Normative)
Scope: Rules for how ALL modules use HL7 FHIR as the canonical domain model and API surface.
Authority: Normative. Module specs may narrow but never contradict.
1. Definition
FHIR-first means:
- FHIR R4+ resources are the canonical clinical meaning and exchange model for in-scope data.
- A FHIR R4 server (via
fhir-gateway) is the primary interoperability surface. - Internal REST endpoints are permitted for product UX but MUST map cleanly to FHIR — no competing "shadow" clinical data model.
- Non-FHIR standards are supported only via adapters.
2. FHIR Version & Conformance
- Minimum: FHIR R4
- Platform publishes a
CapabilityStatementfor the overall server. - Profiles declared as
StructureDefinition,ValueSet,CodeSystemwhere applicable. - Write validation against base resource rules + declared profile constraints.
3. Canonical Data Rules
| Rule | Detail |
|---|---|
| Single source of truth | FHIR resources for clinical content |
| Local tables allowed for | Performance indices, workflow orchestration, adapter payloads, non-clinical config |
| References | Stable identifiers; no sequential DB IDs leaked; FHIR identifier arrays with system |
| Provenance | Clinically meaningful changes emit Provenance; corrections use versioning/status patterns |
| Terminologies | Coding with system + code + optional display |
4. Resource Ownership Map (MVP2)
| Resource Type | Owner Service | Notes |
|---|---|---|
Patient, Encounter, RelatedPerson | Registration | ADT updates via interop engine |
Appointment, Schedule, Slot | Scheduling | Portal requests write here |
Practitioner, PractitionerRole, Organization, Endpoint | Provider Directory | |
Location | Facility | |
AllergyIntolerance | Allergies | |
Condition | Problem List | |
Observation (vital-signs) | Vitals | Category vital-signs |
MedicationRequest, MedicationAdministration | Medication Management | |
ServiceRequest | Orders/CPOE | Lab/rad ordering |
DiagnosticReport | Results | Lab/imaging; category distinguishes |
Observation (laboratory) | Results via LIS | |
Specimen | Laboratory/LIS | |
ImagingStudy | Radiology/PACS (radiology-pacs serves /fhir/R4/ImagingStudy; fhir-gateway routes via RADIOLOGY_URL) | Pixel data in PACS; chart-facing filed imaging summaries use DiagnosticReport in Results per module boundary |
Immunization, ImmunizationRecommendation | Immunizations | |
CarePlan, Goal, Task | Care Plans | |
Communication | Messaging | |
DocumentReference | Document Management | PDF/scanned chart documents; metadata and links to Binary; CDA exchange maps here per §5 |
Binary | Document Management | Document bytes (e.g. application/pdf); object storage behind FHIR reference |
Composition | Document Management (optional) | Structured multi-section reports when used; otherwise narrative remains clinical-notes |
Financial (Account, ChargeItem, Invoice, Claim, Coverage, etc.) | Billing/Insurance/Claims |
5. Non-FHIR Standards (Adapter-Only)
| Standard | Handling |
|---|---|
| HL7 v2 (ADT/ORM/ORU/SIU) | Via hl7v2-interop; mapped to canonical FHIR resources |
| CDA/CCD/C-CDA | Document import/export via DocumentReference |
| DICOM/DICOMweb | Imaging payloads; metadata as FHIR ImagingStudy |
| X12 / payer exchanges | Adapter-driven; canonical via FHIR financial resources |
6. Module Conformance Requirements
Each module's spec MUST declare:
- Canonical FHIR resources for that module
- Required search parameters and write interactions
- How non-FHIR payloads map to canonical FHIR
- Any intentional non-FHIR-only areas (with justification)