Every health information system eventually needs to talk to another one: a national master facility list, a health information exchange, an electronic health record, a reporting platform run by a different partner. Historically, that has meant a custom integration for every pair of systems, each with its own format, its own quirks, and its own maintenance burden.
IASO’s Organization Units, the health facilities, districts, and administrative areas that structure every dataset in IASO, are now available through a FHIR R4-compliant API. FHIR (Fast Healthcare Interoperability Resources) is the interoperability standard increasingly adopted across the health data ecosystem, from electronic health records to health information exchanges to national digital health registries. FHIR defines many resource types beyond location data (patients, encounters, organizations, observations), and IASO’s implementation focuses, for now, on the resource that matters most for a georegistry: Location.
Concretely, any FHIR-aware system can query IASO’s organizational structure as standard FHIR Location resources. It can search by name, status, identifier, or organization unit type; browse a facility’s children in the hierarchy; and retrieve GPS coordinates, validation status, and source metadata in a predictable, standards-based shape, without needing to understand IASO’s internal data model first. The API is read-only and requires authentication: it does not support creating, updating, or deleting records.
In practice, this means a national health information exchange or a DHIS2 Suite instance could query IASO’s facility list directly through this standard interface, rather than through a connector built specifically for IASO.
This is a first step focused on organizational structure data specifically: read access to Organization Units as Locations. It is a foundation to build on as more of IASO’s data becomes accessible through the same standards-based approach.
FHIR did not emerge in a vacuum. It answers a problem every national health data ecosystem eventually runs into: multiple systems, each with a legitimate reason to hold facility and administrative data, drifting apart because they have no common way to describe it. The two dimensions below explain why FHIR resolves that problem, and where a facility registry fits in the broader architecture built around it.
FHIR was developed by HL7 to give health systems a common, machine-readable language for exchanging data. Its R4 release, the one IASO implements, reached normative status in 2019. That shared vocabulary changes what integration work looks like: rather than each new connection reinventing how to describe a health facility (its name, its administrative level, its parent region, its GPS position), every FHIR-compliant system already agrees on the shape of that data. The integration work shifts from negotiating a format to simply connecting to an endpoint.
This matters most for organizations running IASO alongside other systems that need to stay in sync on where things are: a national master facility list, a DHIS2 Suite instance, a broader health information exchange built on the OpenHIE architecture. In that architecture, the facility registry is a distinct component that other systems query rather than duplicate. A FHIR API positions IASO to serve that role: a source of truth for facility and administrative data that other systems can consume directly, instead of each partner maintaining its own copy.
IASO’s FHIR API does not replace the georegistry capabilities that IASO users already rely on. It complements them.
IASO’s georegistry tracks the version history of every Organization Unit and includes configurable change request workflows, so that updates to the master facility list go through a validation step rather than a direct edit.
Health geographies change over time. IASO can maintain multiple versions of a facility list in parallel, one of the georegistry features listed alongside version tracking and change request workflows.
Combined with the new FHIR API, these capabilities make IASO a strong open source georegistry option for organizations that need both rigorous version control over facility data and a standards-based way to expose that data to other systems.
For teams already running IASO, this update brings no change to daily use. What changes is what becomes possible on top of that data: national HIS teams can now connect IASO’s facility data to a health information exchange or another FHIR-compliant registry without building a custom translation layer first.
This is also a first step. Read access to Organization Units as FHIR Locations is a foundation to build on, as more of IASO’s data becomes accessible through the same standards-based approach.
If your organization is building or extending a national health data ecosystem and needs a georegistry that speaks FHIR, you can get started on IASO or contact us for more information.
