Skip to end of metadata
Go to start of metadata


The official version of the OHIE workflows can be found in the OpenHIE Architecture Specification.


Description: This workflow enables aggregate data to be generated and exported to a system outside of the health information exchange. This is useful for exporting routine reporting data to an upstream HMIS systems for high level reporting. For example aggregate data could be exported from a country implementation to PEPFAR's Global DATIM instance.



Referenced Standards and APIs

Assumptions and Prerequisites

  1.  The External HMIS and the HMIS inside the OpenHIE infrastructure must use the same metadata (indicator, disaggregators, sites and mechanisms). The request metadata workflow may be used before the export takes place to ensure this is so.


Receiver - External System Actors (Actors outside this HIE)

  • External System - The system outside the HIE that will be receiving aggregate data.  Examples of this system could be an external HMIS systems or an HIE.  

Sender - Internal System Actors (Actors within this HIE)

  • IL - The Interoperability Layer (IL) is the component that enables easier interoperability between disparate information systems by connecting the infrastructure services and client applications together. An interoperability layer receives transactions from the point of service systems and coordinates interaction between components of the HIE and provides common core functions to simplify the interoperability between systems.
  • HMIS - The system that produces the aggregate data to be exported.

Technical Details

Step NumberInteractionDesign NotesDataTransaction Standard
1Initiate the transaction, aggregate months into quarters as necessary  and create the aggregate data message.In the reference implementation, the user triggers the aggregation and creation of the ADX message via the ADX adapter which is a logical component of the HMIS.ADX - Aggregate Data generated by the HMIS. ADX
2Export the Aggregate Data Message to the IL

The message will be transported via POST http(s)://<server>:<port>/<base_path>/dataset

with ADX message in the HTTP body until the ADX transport standard is developed.

3Map site codesMapping Mediator uses a CSD transaction to determine if there are local site codes that need to be translated to the Global site codes. If so, they are translated.

4Update the ADX message with the receiver's site codes
Update the ADX message with receiver's site codes


Log and secure the message


Route the message to an authenticated receiver.

5Return processing response The External system will process the aggregate data message and respond with information about the records processed and / or provide a description of errors.  May contain error messages and/or confirmation of successful processing.
6Log the processing response

7Forward aggregate data processing response


POST http://<server>:<port>/<base_path>/dataset/<submission_uuid>/response

with request body set to the string 'SUCCESSFUL' if the request was processed successfully

with request body set to the string 'UNSUCCESSFUL' with the textual error messages following on the next line if the request was not processed successfully

8Process the response

This step can be different for different implementations. The HMIS can be used to inform the user via an interface or a message. The response will contain error messages or provide information about the successful processing of the message.


Test Cases 

The following are the high-level test cases that this workflow must support:  

Test CaseDescription
  1. Sending an ADX message with required mechanisms, indicators and disaggregators

Message Examples

  • No labels


  1. Hi all, I really don't think that we should use the name 'PoS' to represent a system receiving aggregate data. It doesn't quite make sense. In our other workflows PoS systems are systems on the ground at the point of service. We wouldn't want people to get confused that the external HMIS systems is similar to those. The External HMIS system actually sits at a higher than our registry components (it acts as a registry to our entire HIE). So I think calling it something different makes more sense. 'External HMIS' or 'Upstream HMIS' make sense to me, but perhaps other could come up with a better name for this? Also moving this actor to appear on the far left in the diagram further clarifies that is it distinct from the other PoS systems in the other diagrams.