General Information
MetaHub
The ‘MetaHub’ component is introduced to support the interconnection between ‘Hubs’. This component is accessible to ‘recognized’ hubs. The word ‘hub’ denotes the kernel of a ‘recognized’ regional or sub regional health network.
The main purpose of the MetaHub is to allow a hub to know where it can find information about a patient outside of its network. More precisely, the MetaHub simply provides the list of hubs that have information about a patient. It is not the MetaHub’s role to know where, within a (sub)regional health network, the information is stored.
The MetaHub is thus more a ‘locator service’ than a ‘routing component’: there are no ‘document’ exchanges transiting throughout the component. MetaHub v2 also allows the hubs to consult and manage the registration of patient consents and exclusions1. A major feature is that the hubs themselves feed the MetaHub. See figure below.
Therapeutic Link
It is not the task of the MetaHub to store or to manage any data regarding ‘therapeutic links’ nor is it the purpose of the MetaHub to register or verify the therapeutic links.
However, for some types of therapeutic links for which an authentic source is defined and available, the MetaHub will offer a ‘relay’ service to the hubs to check the existence of such a therapeutic link.
Again, the interface of the services is more ‘generic’ (in order to be aligned with the specifications defined at the hub level and to potentially support other kinds of therapeutic links if required). For more information on
the methods to use, please refer to the WS TherapeuticLink cookbook.
| PutTherapeuticLink | Allows a hub to declare the therapeutic links. Its main purpose is to allow one to declare a therapeutic link. |
| RevokeTherapeuticLink | Allows a hub to revoke the therapeutic links. Its main purpose is to allow one to “end” the (declaration of a) therapeutic link. |
| GetTherapeuticLink | Allows a hub to consult therapeutic links according to basic search parameters. Its main purpose is to allow one to check the existence of the therapeutic links when executing a consultation process. |
KMEHR
This service is a ‘KMEHR-based’ WS. We thus strongly recommend consulting the documentation related to the KMEHR normative elements. The KMEHR site aims to offer a central point for the documentation of the KMEHR normative elements.
https://www.ehealth.fgov.be/standards/kmehr/en
The three following generic elements are, in particular, essentials to build the request and the reply of eHealth MetaHub WS.
cd : This is the key element used to code information: this section is completely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/key-elements#cd
id: This element is used to uniquely identify key elements like request, response of the WS, patient, HCParty. It can also be used to specify any unique identifier: this section is completely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/key-elements#id
HC Party: The hcparty element is a generic element that aims to represent any kind of healthcare party: organization, physician, medical specialty, or even IT systems: this section is entirely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/hcparty
Basic Flow
| Flow | Specifications | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternative Flow
| Flow | Specifications | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternative Flow
| Flow | Specifications | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|