Skip to content

PharmaNet Technical Architecture: OpenHIE Framework (v3.2)

The PharmaNet system acts as the digital nervous system for Nepal's primary care and pharmacy sector. It connects edge devices (pharmacy POS tablets) to national regulators, distributors, and logistics providers via an OpenHIE-compliant interoperability layer.

1. System Landscape

graph TD
    subgraph Edge ["Pharmacy Edge Layer"]
        direction LR
        App[Android App<br/><small>POS & Stock UI</small>]
        LocalDB[(WatermelonDB<br/><small>Local Cache</small>)]
        App --- LocalDB
    end

    subgraph Interop ["Interoperability Layer"]
        direction TB
        Mediator{{"Mediator / Gateway"}}
        Auth[[OIDC / OAuth2]]
    end

    subgraph Registries ["Core Registries (Master Data)"]
        direction LR
        CR[(Client Registry)]
        FR[(Facility Registry)]
        DR[(Distributor Registry)]
        LOG[(Logistics Registry)]
        HWR[(Worker Registry)]
        TS[(Terminology Service)]
    end

    subgraph Services ["Domain Services (Transactional)"]
        direction LR
        PR[Product Registry]
        INV[Inventory Service]
        SUB[Subscription Svc<br/><small>Chronic Care</small>]
        SCH[Scheduling Svc<br/><small>Doctor Booking</small>]
        SHR[Shared Health Record]
        FIS[Finance Service]
    end

    subgraph National ["National Ecosystem & Regulators"]
        direction LR
        OpenIMIS[openIMIS]
        NID[National ID]
        NMC[Medical Council]
        NPC[Pharmacy Council]
        3PL[Logistics Channels<br/><small>Pathao / Couriers</small>]
        Pay[Digital Payments]
    end

    App ==>|FHIR Bundle| Mediator
    Mediator <--> Auth
    Mediator <--> Registries
    Mediator <--> Services

    FIS <==>|FHIR Claim| OpenIMIS
    FIS <==>|Payment API| Pay
    Mediator -.->|ID Verification| NID
    Mediator -.->|License Check| NMC
    Mediator -.->|License Check| NPC
    INV <--> LOG
    SUB <--> LOG
    LOG <--> 3PL
    SCH <--> HWR

    style App fill:#3b82f6,color:#fff
    style Mediator fill:#1e3a8a,color:#fff
    style LOG fill:#fbbf24,color:#000
    style SUB fill:#34d399,color:#000
    style SCH fill:#34d399,color:#000
    style NMC fill:#ef4444,color:#fff
    style NPC fill:#ef4444,color:#fff

2. Core Registries

  • CR (Client Registry): The Master Patient Index (MPI). Uniquely identifies patients via National ID (NID) and phone. Foundational for preventing record fragmentation.

  • FR (Facility Registry): Canonical index of all physical pharmacies and clinics. Includes GPS coordinates necessary for 3PL routing and regulatory license status.

  • DR (Distributor Registry): Directory of suppliers. Contains B2B integration endpoints, lead times, and negotiated GPO contract pricing for automated procurement.

  • LOG (Logistics Registry): Master data for delivery partners (e.g., Pathao, local 3PLs). Standardizes tasks for inbound tracking and outbound patient deliveries.

  • HWR (Worker Registry): Index of verified health practitioners. Stores license numbers that MUST be validated by the NMC (Doctors) or NPC (Pharmacists).

  • TS (Terminology Service): The clinical source of truth for code sets (ICD-10, SNOMED, RxNorm). Ensures semantic interoperability.

3. Domain Services (Transactional)

  • Inventory Service: Transactional engine tracking live stock counts, batches, and expiries. Linked to LOG to track "In-Transit" stock.

  • Subscription Service: Manages medication adherence for chronic patients. Tracks recurring cycles and triggers FHIR Subscription resources to coordinate dispatch.

  • Scheduling Service: FHIR-compliant booking engine. Manages doctor availability slots and patient appointment history at registered pharmacies.

  • Shared Health Record (SHR): The clinical vault. Stores encounters, observations, and prescriptions in a portable International Patient Summary (IPS) format.

  • Finance Service (FIS): Financial orchestrator. Manages GPO margins, routes insurance claims to openIMIS, and requests dynamic payment QR codes.

  • Product Registry (PR): Commercial SKU catalog. Maps physical local drug barcodes to standardized clinical entries and GPO Master SKUs.

4. Data Analytics & Pipeline

Transitioning from operational throughput (OLTP) to analytical insights (OLAP) requires a decoupled architecture so reporting does not burden the transactional databases.

graph TD
    subgraph OLTP ["Operational DBs"]
        SHR_DB[(SHR Clinical)]
        INV_DB[(Inventory DB)]
        FIS_DB[(Finance DB)]
    end

    subgraph Pipe ["Pipelines"]
        direction LR
        CDC{{"CDC (Debezium)"}}
        Kafka[[Kafka Bus]]
        Airflow{{"Airflow (ETL)"}}
        Anon[[Anonymizer]]
    end

    subgraph OLAP ["Analytics Lakehouse"]
        Lake[(Data Lake)]
        DWH[(ClickHouse)]
        BI[Metabase BI]
    end

    SHR_DB -.-> CDC
    INV_DB -.-> CDC
    FIS_DB -.-> CDC
    CDC --> Kafka
    Kafka --> DWH
    SHR_DB -->|Nightly| Airflow
    INV_DB --> Airflow
    Airflow --> Anon
    Anon --> Lake
    Lake --> DWH
    DWH --> BI

    style Lake fill:#8b5cf6,color:#fff
    style DWH fill:#8b5cf6,color:#fff
    style BI fill:#8b5cf6,color:#fff

  • CDC (Debezium): Streams DB transaction logs into Kafka to decouple analytics from operations in real-time.

  • Kafka Bus: High-throughput event bus routing data changes to downstream consumers without delay.

  • Airflow & Anonymizer: Orchestrates nightly ETL pipelines, strictly stripping PII (Name, NID) from clinical records before ingestion into the data lake.

  • ClickHouse & Metabase: The analytics backend and BI presentation layer for generating national disease surveillance reports and supply chain analytics.

5. Security & Regulatory Guardrails

  • Encryption: TLS 1.3 for all transit; AES-256 for data-at-rest in the Shared Health Record (SHR).

  • Professional Verification: All clinical authorship in the SHR is blocked until the Practitioner resource carries a true value in the Council-Verified extension, validated via NMC or NPC.

  • Identity: Deterministic matching via the National ID (NID) system prevents duplicate records.

  • Audit: Every read/write operation generates a FHIR AuditEvent containing the Practitioner ID and Facility ID.