Health Information Systems
We implement, extend and integrate DHIS2 — and we build the pipes that let it talk to everything else in the health system. Our team has worked inside national and provincial immunization registries, so we design for the vaccinator in a union council, not just the dashboard in the capital.
Fixed-scope first sprint. Working software in weeks, not a discovery deck.
Sources: DHIS2 (University of Oslo) and published peer-reviewed evaluations of Pakistan’s immunization registries. Figures describe the programmes, not Techsion contracts.
Why this page exists
Ministries and programmes rarely lack data. They have a DHIS2 instance, an Android app, a lab system, a hospital HMIS, a stock module and four spreadsheets — and none of them agree on who a patient is, what a facility is called, or when a dose was actually given.
That is the work. Not another dashboard, but the unglamorous layer underneath it: clean metadata, a Tracker programme that matches how a vaccinator actually moves through a day, an integration that survives a bad connection in the field, and an identifier strategy that lets two systems talk about the same child.
Techsion does that layer. We configure and extend DHIS2, build the mobile and web tools that sit on top of it, and connect it to the rest of the health ecosystem using HL7 FHIR and HL7 v2 — the standards WHO, Gavi and national digital health strategies are converging on.
A registry is only as good as the last mile. If the vaccinator cannot finish an enrolment in under a minute on a two-year-old phone with no signal, nothing downstream matters.
Pillar one
The world’s most widely used health information platform — open source, developed at the University of Oslo, run by ministries in more than 80 countries. We work across the whole lifecycle.
Org unit hierarchies, data elements, category combos, indicators, validation rules, user roles and sharing. We build metadata a programme manager can still understand in year three — named consistently, documented, and version-controlled rather than clicked together and forgotten.
Individual-level case tracking: enrolment, program stages, program rules, relationships and working lists. Used for immunization registries, TB and HIV cohorts, maternal and child health, nutrition and surveillance. We design the form around the encounter, then cut every field nobody will analyse.
Routine facility reporting, section forms, custom entry forms, completeness and timeliness monitoring, and the validation rules that stop bad numbers before they reach a dashboard.
Pivot tables, charts, maps, scorecards and bottleneck analysis built for a specific decision and a specific meeting. Coverage by antigen, dropout between doses, zero-dose mapping, stock-out heatmaps — with drill-down from national to union council.
DHIS2 is an application platform. We build custom web apps on the DHIS2 App Platform and dashboard plugins where the core apps stop short — programme consoles, supervisory checklists, data quality tools and role-tailored landing pages.
Android Capture configuration and custom builds on the DHIS2 Android SDK. Offline capture, conflict-safe sync, QR and barcode identifiers, GPS, low-end device performance and battery behaviour — tested on the handsets field staff actually carry.
DHIS2 Web API, Route API for secure outbound calls, Event Hooks to webhooks, Kafka or JMS, ADX and aggregate data exchange, SQL views and scheduled import/export. Middleware with OpenFn, OpenHIM or Apache Camel where the mapping deserves its own service.
Moving off Excel, Access, a legacy registry or an ageing DHIS2 version. De-duplication, identifier reconciliation, historical load, parallel-run validation, and an upgrade path that does not strand your custom apps.
Managed hosting and monitoring, database tuning, backup and DR drills, release management, and hands-on training for HMIS teams and provincial focal points — because the goal is that you stop needing us for routine changes.
DHIS2 publishes standard metadata packages built with WHO, UNICEF and Gavi — routine EPI, electronic immunization registry, immunization campaigns, the Big Catch-Up, AEFI reporting, disease surveillance and vaccine stock management. We start from the relevant package, adapt it to national guidelines and indicator definitions, and keep the standard bones intact so your data stays comparable and your upgrades still land cleanly.
Pillar two
Our team includes people who worked on both Pakistan’s National Electronic Immunization Registry and Sindh’s Zindagi Mehfooz, at IRD Pakistan. Which is why our first questions are unusual ones: how long is the vaccinator’s shift, what happens when the QR card is lost, and who is actually accountable for the defaulter list.
NEIR moves the immunization programme from counting doses to following children. Every child gets a record and an identifier; every dose is stamped with time, place, vaccinator and antigen. That single change is what makes zero-dose identification, defaulter follow-up and true dropout analysis possible — and it is also what makes the engineering hard, because the system must now handle duplicates, migration between districts, lost cards and eight different spellings of the same name.
What we bring to a national registry. Schedule and decision-support logic that mirrors the national EPI schedule exactly; offline sync that tolerates weeks without connectivity; deduplication and record-matching strategies; supervisory dashboards a district health officer can act on before the monthly review; and an export path into DHIS2 aggregate reporting so the national HMIS is fed automatically instead of re-keyed.
What registry data made visible
Daily immunization visits fell 51% during the 2020 lockdown and roughly 1.25 million children missed doses. Because every child was individually tracked, the programme could name them — and by March 2021 about 76% had been vaccinated.
Analysis of 6.2 million enrolled children showed 103 boys enrolled for every 100 girls after adjusting for population sex ratios, with about 11.6% of union councils showing a persistent male skew. Aggregate reporting had never shown this.
Once enrolled, girls reached the same coverage as boys — but later. Individual-level timestamps turned “equal coverage” into a more honest and more actionable finding.
This is the argument for individual-level registries in one line: you cannot follow up a child that your system only counted.
What we can build
Name-based child and mother registration, schedule-driven dose tracking, catch-up logic, transfers between facilities and districts, and a record that follows the child.
Encode the national schedule — minimum intervals, valid-dose rules, contraindications, catch-up pathways — so the app tells the vaccinator what is due today instead of expecting them to remember it.
Automated due and overdue lists per vaccinator and union council, SMS and IVR caregiver reminders in local languages, and outreach planning built from the actual defaulter map.
Zero-dose and under-immunized identification, dropout analysis between antigens, gender and geography equity views, and micro-plan support to union council level.
Supplementary immunization activity modules: micro-planning, real-time session monitoring, team tracking, coverage-versus-target dashboards and rapid convenience monitoring.
Facility stock and wastage tracking, stock-out visibility down the last mile, cold-chain equipment inventory, and adverse-event reporting linked back to the individual record.
Pillar three
Most real health ecosystems need FHIR, HL7 v2 and CDA at once. The integration work is mostly translation.
HL7 FHIR models health information as resources — Patient, Immunization, Encounter, Observation, Practitioner, Location — exchanged over a plain RESTful API, with profiles and Implementation Guides that pin down exactly how a country or programme uses them.
This matters for DHIS2 specifically. The emerging pattern is a FHIR gateway or façade: a translation layer that speaks FHIR outward and the DHIS2 Web API inward, driven by an Implementation Guide that defines the mappings rather than burying them in code. WHO’s SMART Guidelines and its Digital Adaptation Kits, including the DAK for immunizations, are published as FHIR Implementation Guides for exactly this reason.
Building FHIR-conformant APIs, or wrapping systems that will never be FHIR-native. Resource modelling, search parameter design, versioning, pagination, and conformance you can actually test.
Authoring profiles, extensions, value sets and IGs with FHIR Shorthand and Sushi, published as a proper IG site with capability statements — so the specification is the contract, not a slide deck.
A translation layer mapping DHIS2 tracked entities, enrolments and events to FHIR resources and back. Built on Apache Camel or equivalent, driven by StructureMaps and the FHIR Mapping Language so mappings are reviewable and swappable.
ADT feeds from hospital systems, ORU lab results, VXU immunization messages and MLLP transport. Parsing, mapping, acknowledgement handling and dead-letter queues, plus v2-to-FHIR translation where you are modernising incrementally.
Interoperability layer, client registry and master patient index, facility registry, terminology service and shared health record. We help design the architecture, then build and operate the components you actually need rather than all of them.
ICD-10/11, SNOMED CT and LOINC mapping, national vaccine and antigen code sets, and the identity strategy underneath it — national ID linkage, master patient index, probabilistic matching, and de-duplication rules a human can audit.
Turning a WHO Digital Adaptation Kit, immunization included, into working configuration: decision-support logic, indicator definitions and data dictionaries implemented in DHIS2 Tracker or a FHIR-native stack, traceable to the published IG.
OAuth2 and OpenID Connect, SMART on FHIR authorisation, role-based access, audit logging, encryption in transit and at rest, de-identification for research extracts, and data-sharing agreements that survive a privacy review.
Every arrow on this diagram is a decision about identifiers, timing and failure handling. That is where the project actually lives.
How we work
Digital health work rarely starts from zero. There is a running system, a donor timeline, a ministry team with strong opinions and a procurement window. We are built to slot into that rather than replace it.
Review the existing instance, apps and data flows. Metadata audit, data quality assessment, interoperability gap analysis, and a costed roadmap of what to fix, build and retire. You keep the document whether or not you continue with us.
2–3 weeksOne well-defined deliverable, agreed price, working software at the end. A Tracker programme piloted, a FHIR gateway for one resource type, a dashboard suite for a specific review meeting, or a migration proof-of-concept on real data.
4–6 weeksFull implementation with staged district or facility rollout, parallel running against the current process, training-of-trainers, field support during first sync cycles, and a UAT gate before each expansion wave.
StagedFHIR profiles and IGs, gateway build, HL7 v2 feeds, identity and terminology alignment, conformance testing, and documented mappings handed over as artefacts you own.
AlongsideSLA-backed support, monitoring and hosting, quarterly data quality reviews, and a deliberate capacity-transfer plan so the ministry or NGO team can run and extend the system themselves.
OngoingEngagement models: fixed-scope sprints · dedicated squad, monthly · staff augmentation into an existing ministry or programme team · advisory retainer for standards and architecture review.
Who we build for
The screens
Analytics built for a specific decision and a specific meeting, with drill-down from national to union council.
DHIS2 platform screens, shown to illustrate the analytics and capture tooling we configure, extend and integrate.
Why Techsion
We know what a zero-dose child is, why a dropout rate between Penta-1 and Penta-3 matters, and what a union council micro-plan looks like. You should not have to explain your programme to your vendor.
Offline sync, low-end Android, patchy connectivity, and forms designed for a vaccinator standing up in the sun. The dashboard is the easy part.
FHIR profiles and Implementation Guides as real, published, testable artefacts. We write the spec, conformance-test against it, and hand it over.
Data engineering, Android, web apps, design, analytics and support under one roof. No handoff gap between the people who model the data and the people who ship the app.
Experience
Our team includes people who worked on Pakistan’s two largest electronic immunization registries at IRD Pakistan: the National Electronic Immunization Registry with the Federal Directorate of Immunization, and Sindh’s Zindagi Mehfooz with the Sindh Health Department — in an ecosystem shaped by WHO, UNICEF and Gavi support to the national programme. That is first-hand experience of registries operating at national and province scale, not case studies we read.
That work covered the parts that are hard to learn from documentation: schedule and decision-support logic, offline Android capture at province scale, deduplication and record matching, defaulter tracking field staff will actually use, and analytics that hold up when a donor asks how the number was derived.
Programme figures cited on this page are drawn from public sources and published evaluations and describe the programmes themselves. They are included to show the scale and type of systems our team has experience with.
Questions
No. We are an independent implementation team with no HISP affiliation. DHIS2 is open source and its documentation, academy materials and metadata packages are public, so we build against the standard release and work directly with the ministry or programme team that owns the instance.
Almost always, and that is usually the right answer. Most instances need a metadata clean-up, better analytics and an integration layer, not a rebuild. The assessment sprint tells you which situation you are in before you commit budget.
Current supported releases, plus upgrade paths from older versions. Upgrades are scoped as their own piece of work because custom apps, program rules and integrations all need re-testing.
Not always. You need FHIR when DHIS2 has to exchange individual-level clinical data with systems outside it — an EMR, a lab, a national HIE, an identity system. If everything you need lives inside DHIS2, its own Web API and data exchange features may be enough. We will tell you which case you are in rather than selling the bigger one.
Role-based access, audit logging, encryption in transit and at rest, de-identification for research extracts, and OAuth2 or SMART on FHIR authorisation. Data-sharing agreements are drafted to survive a privacy review, not to pass one quietly.
Hi there. Tell us what you're building and we'll come straight back — Karachi and Lahore hours, usually within the hour.
Start chatOpens WhatsApp on your phone or desktop.