A Simple Guide to OpenFn, OpenHIM, and X-Road

This overview was co-authored by Open Function Group (OpenFn), Jembi (OpenHIM), and Aktors (X-Road) to help organizations disambiguate between the different platforms.

The Big Picture

At OpenFn, Jembi, and Aktors we are often asked how different tools across the ecosystem can and should be used together. In the context of creating and maintaining high quality integrated systems, equipped with data exchanges and workflow automation, we need to consider how and when to use tools like OpenFn, with other tools operating in a similar space like OpenHIM and X-Road. To illustrate this, we have created a fairly non-technical document to consider the different roles that each tool might play.

To help us conceptualise, imagine a busy city where information needs to flow between different buildings and organisations. Banks need to talk to insurance companies. Hospitals need to share data with laboratories. Government offices need to exchange information with service providers. All this information needs to move securely and efficiently between different digital systems.

In healthcare particularly, this flow of information can be critical. The timely, reliable and secure exchange of patient records, lab results, and supply chain data between systems saves lives.

All three systems (OpenFn, OpenHIM, and X-Road) can be used in concert, or independently, and are specialized to excel in different roles despite having some overlapping functionality.

Meet the Tools

So, what roles might OpenFn, OpenHIM and X-Road play in this busy city?

OpenFn: The Intelligent Courier Service

(a “workflow engine” in the OpenHIE Interoperability Layer [IOL] and Govstack Building Block specifications)

Think of OpenFn as an intelligent courier service. As well as moving packages (data) from one place to another - it can also:

• Translate documents into different languages (transform data formats)
• Sort, organise, and repackage before delivery (clean and structure data)
• Follow complex multi-step routing or delivery instructions (“if this lab result is positive, send alerts to these three people or systems”)
• Keep records of every delivery (full audit trail)
• Perform tasks/deliveries in real-time or “on demand” (e.g., “do X every time a message is received”)
• Perform tasks/deliveries on a schedule (e.g., “do X every Thursday at 8am”)

Note that the whole ‘city’ may use a single instance of OpenFn or have several instances ‘owned’ by different groups. One might be run by the MoH, another by a specific hospital or clinic, and another by an entirely different ministry.

OpenFn in action:

At early stages of maturity, software ecosystems may use OpenFn for moving data between systems as shown above without any additional governance layers.

OpenHIM: The Regional Command Center

(a centralized “information mediator” in the OpenHIE Interoperability Layer [IOL] and Govstack Building Block specifications)

OpenHIM acts like a particular jurisdiction’s central command centre. It:

• Ensures that all traffic heading to a destination within its jurisdiction (eg, a health ministry) passes through a single security point (centralised architecture)
• Checks ID badges before letting information pass (security)
• Keeps track of all information flows (monitoring)
• Ensures messages get to the right destination (routing)
• Maintains a complete log of all activity (audit trail - ATNA compliant)

Note that with OpenHIM, you can also develop and deploy custom microservices. When built to follow a specific set of requirements, they’re known as “mediators”. These applications can do absolutely anything—it’s entirely up to you. Common tasks for microservices in an OpenHIM implementation are transforming data or chaining together a series of requests.

OpenHIM in action, with OpenFn serving some workflows:

X-Road: The Secure Public Transportation Network

(a decentralized “information mediator” in the OpenHIE Interoperability Layer [IOL] and Govstack Building Block specifications)

X-Road is like a broad network of roads, bridges, traffic signs, and police checkpoints that:

• Verifies all travellers but doesn’t force them through one central station (decentralized security protocols)
• Allows transit between points directly (decentralised architecture, no single point of failure)
• Has security checkpoints at each location which follow the same security protocols (distributed security)
• Allows different jurisdictions to communicate under the same security standards, but maintain their own lists of ‘who can access what’ by implementing those same security protocols (distributed ownership via a federated architecture)
• Maintains a complete log of all activity (full audit trail)

Note that if a city implements X-Road, people still may use private roads within a specific area (all traffic within the MoH might run on private roads organized by OpenHIM) but for traffic across jurisdictions, there will usually only be one X-Road implementation.

X-Road facilitating inter-departmental data exchange protocols:

Key Differences

Control Style

• OpenHIM: Like a region within a city with one main postal hub
  • Everything goes through it, you can also define post pathways using OpenHIM mediators.
• X-Road: Like a city with well policed streets, clear rules-of-the-road, and where every building has its own secure mailroom
  • Direct building-to-building delivery.
• OpenFn: Like the postal service itself
  • Sorts, processes, and delivers mail, complying with and notifying whichever security system is in use. OpenFn also provides visual representation of the flows of post, and when it is not delivered.

Who’s in Charge

• OpenHIM: One organisation (or Ministry—usually the MoH) runs the central command centre
• X-Road: Each organisation runs their own security checkpoint based on a shared protocol or set of rules, a “central server” and ‘certification authority’ are used to keep those different checkpoints aligned to the same rules. That server is often hosted within a more neutral authority.
• OpenFn: Focuses on processing and delivering the packages, works with either approach and multiple OpenFn instances might be hosted within the same city, owned by different authorities and complying with different security protocols.

Where they’re used

• OpenFn can be used in any domain to support any integrations
• OpenHIM specializes in the health domain (implementing the IHE’s ATNA profile) but could be adapted for non-health domains as well
• X-Road has been designed for national (and international)-level implementation and data exchange, specifically for cross-ministry/agency work

When to Use What

Stages of Maturity

The product you choose to adopt may depend on the maturity of your digital ecosystem. OpenFn can be used to automate processes or integrate systems at any phase of maturity, and may also serve as a lightweight “central command centre” until the organisation is ready to grow into something bigger. OpenHIM may become relevant at a point when you are building and maintaining a a data exchange within a single jurisdiction or ministry, such as health. Similarly, X-Road may only become relevant for cross-sectoral data exchange. Different digital ecosystems are ‘ready’ for different tools, depending on their system maturity.

Use OpenFn When:

• You need a smart courier service that can:
  • Pick up data from one system and deliver it to another
  • Translate between different data formats
  • Follow complex delivery rules
  • Work on a regular schedule
  • Work on-demand, based on real-time notifications
  • Can comply with security requirements and protocols
• Example: Automatically processing patient records from clinics and updating the national health database

Use OpenHIM When:

• You want a central command centre that:
  • Monitors all system communications
  • Controls access through one point
  • Provides complete visibility
  • Works especially well for national health systems
• Example: Managing data exchange within a national digital health ecosystem

Use X-Road When:

• You need a secure transport network where:
  • Organisations are independent and loosely coupled
  • Organisations maintain their own security
  • Direct communication between systems is important
  • Scale and independence are priorities for data sharing
• Example: Connecting multiple data systems that each need to maintain control and ownership of their data

Use Them Together When:

You *might *combine all 3 of these tools:

• Using OpenHIM as an interoperability layer or information mediator for exchanging data through, _within your Digital Health Ecosystem _
• Using X-Road as an interoperability layer or information mediator for exchanging data through, between your health ministries and other ministries
• Using OpenFn to execute the workflows required to send data between those system, via OpenHIM and / X-Road as is appropriate for each workflow

Diagram Explained

This scenario might represent a blueprint of a digital architecture using OpenFn, X-Road and OpenHIM within the same digital ecosystem.

Several software products are deployed within the Ministry of Health (MoH)‘s servers. In this case, the data sharing agreements between those systems stipulate that data must be shared via OpenHIM’s central ‘command centre’, where an ATNA compliant audit trail is generated.

To execute the sharing of data between those systems, some workflows may use OpenFn as their workflow engine and move data via an OpenHIM ‘channel’. Others may use an OpenHIM ‘mediator’ and others may develop bespoke extensions to send data (also via an OpenHIM channel).

When data is shared outside of the MoH servers to other systems, it may operate under a different data sharing agreement. In this case, inter-Ministry data sharing is policed by X-Road. MoH and Ministry of XYZ are both ‘members’ of this ecosystem’s X-Road data exchange. They each maintain their own security servers, which are under their own control and approved by the X-Road’s Central Server.

All data being shared between the two Ministries must pass through the security servers maintained by each, but does not need to travel via the Central Server. Again, such workflows could be executed by OpenFn or by some other means, but would need to be validated by X-Road security servers.

When data is being shared within Ministry XYZ’s own servers, there may be different data sharing protocols again, and the execution of data flows could be completed by OpenFn or otherwise. Ministry XYZ may not have any central data exchange and may share data between its different systems as required.

This approach could be replicated across any number of different Ministries or organisations, allowing for the safe and efficient passing of data between different systems.

A Note on Feature Overlap

It should be noted that while these tools can be used together, there is some feature overlap.

Building & Managing Complex Workflows

OpenFn provides a simple user interface for designing, building, running, and monitoring complex, multi-step workflows. OpenHIM also allows users to create and register microservices (known as “mediators”) which might be programmed to perform and report on complex tasks but it’s not designed specifically for this type of visual, multi-step workflow.

Generating an Audit Trail

OpenHIM provides a fully ATNA compliant audit trail for all data exchange in a health information ecosystem. Both OpenFn and X-Road provide full auditability for all transactions processed via their platforms also, but their audit trails are not fully ATNA compliant.

A Note on Healthcare

While these tools can be used in any sector, OpenHIM was specifically designed for healthcare systems and X-Road was designed for cross-governmental data sharing. Health Information Exchanges following OpenHIE specifications may use OpenHIM, with other tools (like X-Road and OpenFn) to complement it or provide alternatives, depending on specific requirements. OpenFn was designed to be applicable to all sectors. It has several adaptors which are popular in the health space, but these adaptors and use cases are always changing rapidly.

Choosing which tools to implement

Consider:

• Do you need more security or more integration?
• Do you need central or distributed control over security?
• How important is direct communication?
• Do you need automated workflows?
• What’s your preferred security model?

Remember: Start with what you need most. You can add other tools as your requirements grow.