4 Key Digital Functionalities
At a high level, these are the key functionalities that must or should be provided by any software implementation that plays the role of an Information Mediator. These key digital functionalities have been cross-checked and validated with those provided by the OpenHIE community (see below for details) and the “OpenHIE” column in the yellow table provides a cross-reference to the corresponding OpenHIE specification.
In a nutshell, the Information Mediator building block is responsible for providing (1) a managed facility through which different GovStack BBs and applications may communicate securely with each other and (2) a facility through which applications may publish and subscribe to different events identified by unique message types, enabling more efficient and resilient communication and application design.
Note that the IM is not responsible for manipulating the payloads sent to and from various applications—in a sense, it is both the postal service and the roads/bridges/train tracks—but it does not read the contents of your mail.
GovStack facilitates creation of an ecosystem of applications meant to fulfill different e-governance tasks. Applications are software solutions consisting of some specific part which is actually implementation of some user journeys and a set of standard Building Blocks implementing predefined standardized parts of the job. Different parts of the application interact with each other preferably by means of REST based API. This interaction is built around the API Gateway of the application.
Interaction between applications which are participants of the GovStack ecosystem is implemented by Mediator BB Security Servers. Interaction with software solutions outside of GovStack goes in inward direction through firewall/load balancer/reverse proxy and in outward direction through API Gateway.
Draw.io source in github: https://github.com/aleksander-reitsakas/InformationMediatorAPI/blob/main/IM/diagrams/global-picture.drawio.png
Please note that the source/master-copy of these tables are maintained on this Google sheet and may be updated by clicking the “refresh” button below.
GovStack provided an initial set of key digital functionalities as recommendations for the IM building block. The following table provides updated KDFs, striking-out and refining those that are no longer required and/or in scope.
ID | Explanation | Status | Bucket | OpenHIE? | Comments |
|---|---|---|---|---|---|
KDF1 | Routes requests to the correct provider after necessary message transformation functionalities and protocol conversion | REQUIRED | Service Access | IOLF-2 | The IM does not do message transformation or protocol conversion. |
KDF2 | Connects the service requestor to the service provider and its underlying solution platforms, realizing the requested service | REQUIRED | Service Access | IOLF-2 | Maybe IOLF-6, but not orchestration |
KDF3 | Discovers services and, at runtime, to support the virtualization of services, so that changes to end-points can occur without impact to service consumers and service provider | REQUIRED | Service Access | --- | |
KDF4 | Supports the handling of transactions and associated communication errors and exceptions | n/a | Workflow | IOLF-10 | |
KDF5 | Enforces access privileges and other security policies | REQUIRED | Service Access | IOLF-1/15 | |
KDF6 | Maintains service invocation history and monitors and tracks service invocations | REQUIRED | Service Access | IOLF-3 | |
KDF7 | Provides broadcast/multicast capabilities to facilitate faster, more resilient application design | RECOMMENDED | PubSub | | Note that "caching" has been REMOVED from this requirement. |
KDF8 | Translates data from one format to another, and interoperates with handshake protocols to enable interoperability between different ICT Building Blocks duplications | REQUIRED | Workflow | IOLF-5 | Note that this has been shifted to the Workflow BB. |
Initially, the following table of high-level functional requirements was provided to the Information Mediation working group, but all have since been identified as “out of scope” because they fall into the realm of the Workflow BB or the Security BB.
ID | Explanation | Status | Bucket | OpenHIE? | Comments |
|---|---|---|---|---|---|
F1 | Map data structures and fields from the identification system to the registration system and vice versa. | NOT REQUIRED | Workflow | IOLF-5 | Moved to workflow. |
F2 | Hold authentication and credentials for each system | NOT REQUIRED | Workflow | IOLF-1/13/14 | Moved to workflow. |
F3 | Allow the definition of steps for a particular transaction | NOT REQUIRED | Workflow | IOLF-6 | Moved to workflow. |
F4 | Provide an API for both systems to access – and execute all necessary steps for that transaction (including error handling, retries, and notifications) | NOT REQUIRED | Workflow | IOLF-4/5/9/10/11 | Moved to workflow. This is a number of features lumped together. |
F5 | Provide an API for external systems to access Gov-stack BBs | NOT REQUIRED | API Gateway+IAM | IOLF-4/5/9/10/11 | Moved to Security BB. |
For comparison with existing specifications, we have engaged with OpenHIE — a global community focused on health systems interoperability. While the remit of the Information Mediator is domain independent, we have drawn from OpenHIE because (a) a number of the initial use cases are health-related and (b) the OpenHIE community has developed a mature, well-thought-through, multi-stakeholder specification which can serve as an example (though limited) for GovStack’s purposes.
Below are the key Information mediation requirements from their OHIE architecture specification. Note that the “GovStack?” column provides a cross-reference back to the above GovStack specifications.
ID | Explanation | Status | GovStack? | Comments |
|---|---|---|---|---|
IOLF-1 | The system should provide a central point of access for the services of the HIE. For example, this interface will provide access to the CR, PR, FR and SHR. This central point of access simplifies security management and provides a single entry point into the HIE. | Recommended | KDF2 | |
IOLF-2 | The system shall provide routing functions that allow messages to be routed to the correct service provider systems within the HIE. | Requirement | KDF1 | |
IOLF-3 | The system shall provide a central logging mechanism for the messages sent through the exchange. This function should log copies of the messages that travel through the interoperability layer for audit and reporting purposes. | Requirement | KDF8 | |
IOLF-4 | The system should allow for the rerunning of failed transactions at a central level, alleviating the need for Point-of-Service systems to resend data, for example, in the event of a problem with an infrastructure component. | Recommended | F4 | |
IOLF-5 | Should support transformation of messages that travel from the interoperability layer to service provider systems and vice versa if the service provider is not able to communicate in the required format, i.e. provides implementation specific adapters to transform messages from the interoperability layer’s internal form to a form that the service provider expects (e.g., SHR, CR, PR). | Recommended | F1/F4 | |
IOLF-6 | The system should allow for the routing of messages to the appropriate architecture component or external Point-of-Service system. ● Performs orchestration tasks for complex transactions to take the burden off client systems. This orchestration may contact multiple service providers within the HIE on a client’s behalf and compile an appropriate response to return to the client. ● Examples of orchestration could be the execution of a care plan or the validation of elements (such as identifiers or codes) in a message against other service providers within the HIE (e.g., PR, CR, FR, TS). ● Orchestration tasks are those that are required to complete the current transaction and therefore must be executed timeously as the transaction cannot continue without these steps. | Recommended | KDF2 | |
IOLF-7 | The systems shall include an interface into which a workflow engine can be connected. ● This workflow engine should be able to keep track of the long running state of a patient's care and would be able to perform actions based on this context (such as sending alerts) to improve patient care. ● This workflow engine is out of scope for an Interoperability Layer. However, the Interoperability Layer is expected to expose an interface to allow this sort of systems to be implemented. | Requirement | n/a | Note that this has been shifted to the Workflow BB. |
IOLF-8 | The system should support the ability to be extended by allowing additional mediation functions to be added or removed as they are needed. | Recommendation | | |
IOLF-9 | The system shall support a mechanism for error management and tracking, e.g. a console for viewing failed transactions. | Requirement | F4 | |
IOLF-10 | The system shall allow for failed transactions to be grouped by error type and reason so that errors can be rectified efficiently by finding the root cause of the error, fixing the problem, and re-running those transactions. | Requirement | F4 | |
IOLF-11 | The system should support the ability for a user to re-run errored transactions through the HIE once the reason for their failure has been rectified. | Recommendation | F4 | |
IOLF-12 | The system shall provide authorized users with a view of metrics for monitoring the flow of messages through the HIE. | Requirement | | |
IOLF-13 | The system shall manage the security of the HIE through authentication (identity verification), authorization (permission to interact with specified HIE components) and encryption and decryption of messages. | Requirement | F2/KDF5 | |
IOLF-14 | The system shall support Authentication and Authorization of systems trying to send data to the HIE. | Requirement | F2/KDF5 | |
IOLF-15 | The system should support the encryption of data in flight (when not on a physically secure network) and at rest (whenever data is stored, e.g. when transactions are stored for logging). | Recommendation | | |
IOLF-16 | The system should capture monitoring statistics, such as transaction loads and performance metrics, and provides a view of these for monitoring the flow of messages through the HIE. | Recommendation | | |
| | | | |
In future iterations of this specification, we may take into consideration more broad API-management standards which include multiple domains, such as those proposed by the UK Government in their https://www.gov.uk/guidance/defining-an-api-management-strategy document. ****
Last modified 9mo ago