Date: Fri, 29 Mar 2024 05:58:47 +0000 (UTC) Message-ID: <636601794.278.1711691927031@9b64b402ade9> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_277_274419737.1711691927031" ------=_Part_277_274419737.1711691927031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
An interoperability layer is a system= that enables simpler interoperability between disparate information system= s. In an OpenHIE context, these are Health Information Systems (HISs) such = as a client registry, provider registry, facility registry and shared healt= h record.
An Interoperability Layer receives tr= ansactions from client systems, coordinates interaction between the differe= nt components of the HIE and provides common core functionality to simplify= the data exchange between systems.
The interoperability layer enables in= teroperability between the disparate system within an HIE. Its main functio= n is to allow disparate health information systems to share information mor= e easily. This means that it should handle the common, mundane tasks such a= s logging and security and performs message transformations such that syste= ms may communicate with it in a native messaging format.
<=
/span>At its core the Interoperability L=
ayer should provide a single point of entry into the services of the HIE. I=
t should centralise the logging/auditing of messages; the handling of authe=
ntication and authorization and the routing of message to the correct servi=
ce provider. In addition it MAY provide additional mediation functions for =
transactions within the HIE in an attempt to simplify the business logic re=
quired by service consumer systems to interact with the HIE. These function=
may include mediation tasks such as transformation of messages and message=
orchestration.
It is important to consider who will = make us of a HIE to guide our thinking of what an interoperability layer ne= eds to do. Below are some descriptions of the types of stakeholders that wo= uld be interested in an interoperability layer. Note, that may be more wide= ly applicable than to just the stakeholders listed here.
a population of ~40 million
> 5 official languages
potential international donor support for eHealth programs
a health system where NGOs and private institutions complement= government facilities
internal software development and hosting capability
a presence in multiple countries in a region
many long-term projects aimed at producing positive health out= comes
various software applications, developed in-house
= li>a population of ~10 million
2 official languages
a centralised health system
little in-house software development or hosting capability
These three "customers" types might w= ant to interact with OpenHIE in different ways:
The medium-sized country might want to significantly customise= OpenHIE, discarding the default orchestration for their own software that = might implement workflows very specific to that government and incorporate = data from other systems. This means that the Interoperability layer should = support customization and extension to perform new use cases.
The NGO wish to use a subset of OpenHIE components to track he= alth outcomes over time e.g. the provider registry and the SHR but not the = facility registry. The Interoperability Layer should be able to be included= transparently without changing the existing interaction between components= if it is desired at a later stage. This will allow it to add value by prov= iding common core services.
The small country might want to adopt OpenHIE wholesale, witho= ut customisation. The Interoperability Layer should be able to support some= key transaction that enable OpenHIE to be useful out of the box.
Core functions
FR02 - Provides a central point of access for the services of = the HIE. For example this interface will provide access to the CR, PR, FR a= nd SHR. This central point of access simplifies security management and pro= vides a single entry point into the HIE.
FR12 - Provides routing functions that allow messages to be ro= uted to the correct service provider systems within the HIE
FR01 - Provides a central logging mechanism for the messages s= ent through the exchange. This function should log copies of the messages t= hat travel through the interoperability layer for audit and reporting purpo= ses.
Mediation functions (See Transaction Mediation section for add= itional information)
FR03 - Should support transformation of messages that travel t= o the interoperability layer from service consumer systems and vice versa i= f the service consumer is not able communicate in the required format, i.e.= the interoperability layer should provide implementation specific adapters= to transform message from the interoperability layer=E2=80=99s internal fo= rm to a form that the service consumer expects (e.g. A clinic=E2=80=99s EMR= )
FR04 - Should support transformation of messages that travel f= rom the interoperability layer to service provider systems and vice versa i= f the service provider is not able communicate in the required format, i.e.= provides implementation specific adapters to transform messages from the i= nteroperability layer=E2=80=99s internal form to a form that the service pr= ovider expects (eg. SHR, CR, PR etc.)
FR07 - Is able to perform orchestration tasks for complex tran= sactions to take the burden off client systems. This orchestration may cont= act multiple service provider within the HIE on a client=E2=80=99s behalf a= nd compile an appropriate response to return to the client. Examples of orc= hestration could be the execution of a care plan or the validation of eleme= nts (such as identifiers or codes) in a message against other service provi= ders within the HIE (e.g. PR, CR, FR, TS). Orchestration tasks are those th= at are required to complete the current transaction and therefore must be e= xecuted timeously as the transaction cannot continue without these steps.= span>
FR14 - The systems must include an interface into which a work= flow engine can be connected. This workflow engine could be able to keep tr= ack of long running state of a patient care and it would be able to perform= action based on this context (such as sending alerts) to improve a patient= care. This workflow engine is out of scope for an Interoperability Layer, = however, the Interoperability Layer is expected to expose an interface to a= llow this sort of systems to be implemented.
FR08 - The system can be extended by allowing additional media= tion functions to be added or remove as they are needed
Error Management functions
FR05 - Must provide a mechanism for error management and track= ing, e.g. a console for viewing failed transactions
FR11 - Must allow for failed transactions to be grouped by err= or type and reason so errors can be rectified efficiently by finding the ro= ot cause of the error, fixing the problem and re-running those transactions=
FR06 - Allows the user to re-run errored transactions through = the HIE once the reason for their failure has been rectified.
FR13 - Must provide a view of metrics for monitoring the flow = of messages through the HIE
NR01 - Must have acceptable performance at a district level an= d the ability to scale to a national level.
Is secure:
NR02: Supports Authentication and Authorization
NR07: Supports encryption of data in flight (when not on a physically secured network= ) and at rest (whenever data is stored, e.g. when transaction are sto= red for logging (FR01))
NR03 - Adheres to= standards: makes use of current accepted standards where appropriate
NR04 - Takes into= account the IT infrastructure of low resource settings, see =E2=80=9Clow r= esource setting=E2=80=9D section below
NR05 - Services should be durable. This means the services sho= uld be able to recover from failures or interruption by automatically resum= ing or restarting the service.
NR06 - Reliably delivers messages e.g. messages effects cannot= be executed more than once, messages can therefore be retried as needed.= span>
Transaction mediation function are ne= eded to simplify and enable existing systems to connect to the HIE through = the use of transformation services. However, it is recognised that the need= for normalization and de-normalization of messages should be minimised. Ra= ther, the use of standard messaging formats should be encouraged within ser= vices consumers and service providers so that this functionality is not nee= ded. However, in real world terms transformations from customs format to st= andard format as well as transformations to remove the imperfections from s= tandards message formats will be required to some degree. Thus, this functi= onality should be supported for these cases.
In this section we identify some of t= he key transactions that an Interoperability Layer could support to facilitate the sharing of health information. These item= s are to assist in showing the main transactions of focus for an interopera= bility layer, however this list is not exhaustive= and we can expect actual services to be required will vary depending on th= e implementation needs.
The actual services will be provide b= y service providers such as a client registry, provider registry, facility = or shared health record, however the interoperability layer will facilitate= these sorts of transaction through mediation.
Transactions to save a patient's clinical encounter to a share= d health record
Transactions to receive reporting information and send this to= an aggregate datastore
Transactions to manage health providers
Transactions to manage health facilities
Transactions to manage patient demographics and identity
Transactions that retrieve relevant information about patient = encounters and care
Transactions to notify providers/physicians with clinical aler= ts related to a patient
The following is a summary of the key= capabilities that an Interoperability Layer should provide. These some of = these relate to the services mentioned above and describe if they are envis= ioned to touch single or multiple registries. Cross-registry capabilities h= ave a good chance of requiring orchestration.
Authorise - Ensure that the service requester is authorized to= perform the request
Decrypt - Be able to decrypt incoming messages to pass on to s= ervice providers
Route - Be able to route messages to the correct service provi= der system
Normalise - Transform messages into a well understood intermed= iate form (canonical form)
Orchestration - Execute a set of steps to perform a business f= unction, this often can include requesting services from multiple service p= roviders
De-normalise - Transform messages into a form that a specific = service provider can understand
Orchestrate of transaction
Workflow management
Register encounter
Lookup health record
Lookup patient
Register patient
Lookup provider
Lookup facility
Lookup terminology
We define low resource settings, when= applied to information systems, as geographical areas where there is poor = infrastructure due to limited funds dedicated to this area.
When looking at low resource setting = from a technological perspective this could mean that one or more of the fo= llowing is true: electrical power may be inconsistent and unpredictable; ac= cess to the Internet may be poor both in latency and in speed while also be= ing inconsistent and unpredictable; users of systems are not sufficiently c= omputer literate; and hardware is poorly maintained and fails more frequent= ly. In systems terms the key issue for us to solve is that the system must = be fault tolerant. This system would also be installed a datacenter where t= hese problem are minimised, however, can still likely occur.