[01_FOCUS: CORE_PILLARS]
Trigonal
TRIGONAL TECHNOLOGY
Technical Blueprints

The Sovereign Library

White papers and technical documentation from 60+ years of combined engineering experience. No vendor marketing. Only implementation truth.

White Papers

Technical DNA

Standards
HL7 FHIR R4 (4.0.1)
Implementation
Java (HAPI FHIR), Python (fhir.resources)
Validation
FHIR Validator CLI, Touchstone Testing
Security
SMART on FHIR OAuth 2.0
Storage
MongoDB (FHIR Documents), PostgreSQL (Relational)
Testing
Postman Collections, FHIR Crucible

FHIR R4 Mapping Protocols

From Fragmented Data to Global Interoperability

v2.1.0📅 January 2026⏱️ 18 min

Abstract

A comprehensive technical guide to mapping fragmented clinical data sources to HL7 FHIR R4 resources. Covers Patient, Encounter, Observation, MedicationRequest, and DiagnosticReport resource mappings with real-world examples from OpenMRS, Bahmni, and proprietary EMR systems.

Key Topics Covered

1
FHIR R4 Resource Structure & Cardinality Rules
2
Mapping OpenMRS Observations to FHIR Observation Resources
3
Patient Demographics Synchronization (ADT Events)
4
CodeableConcept Mapping (ICD-10, LOINC, SNOMED CT)
5
Provenance & Audit Trail Requirements

1. FHIR Resource Fundamentals

Every FHIR resource follows a predictable structure: resourceType, id, meta (versionId, lastUpdated), and domain-specific elements. The Patient resource, for instance, contains identifiers (NID, MRN), name (HumanName), telecom (ContactPoint), gender, birthDate, and address. Understanding cardinality (0..1, 1..1, 0..*) is critical for valid resource construction.

2. OpenMRS → FHIR Observation Mapping

OpenMRS stores clinical data as key-value "observations" (concept_id → value). Mapping this to FHIR Observation requires: (1) Extracting concept_id and mapping to LOINC/SNOMED codes via ConceptMap resources. (2) Converting obs_datetime to effectiveDateTime. (3) Mapping numeric/coded/text values to valueQuantity, valueCodeableConcept, or valueString. (4) Linking to Patient (subject) and Encounter (encounter) references.

3. Handling Missing Data & Extensions

Not all local EMR data fits cleanly into FHIR's rigid structure. Use Extensions for custom fields (e.g., tribal affiliation, caste). The data-absent-reason extension indicates why a required field is missing. Custom extensions must be registered with a canonical URL and documented in a StructureDefinition.

4. Real-World Example: Lab Results

A lab analyzer sends HL7 v2.x ORU^R01 messages. The mediator parses OBX segments, creates FHIR Observation resources (status: final, category: laboratory), maps LOINC codes, and POSTs to the FHIR server. The DiagnosticReport resource bundles multiple Observations and links to the ordering ServiceRequest.

This is a condensed version. Download the full white paper (45+ pages) for code samples, architecture diagrams, and deployment checklists.

Need Custom Technical Documentation?

We provide bespoke white papers, architecture reviews, and integration blueprints tailored to your organization's specific requirements.

Request Custom Blueprint
Architecture Concierge

Ask our AI about FHIR integration, Nepal MoHP Directive 2081 compliance, or system architecture.

"How does NidanEHR ensure HL7 FHIR compliance?"

RAG-based AI integration coming in Phase 2

Ask our Architecture Concierge about FHIR integration or Directive 2081.