Used Documentation
| Cookbook / Materials | Version | Location |
|---|---|---|
| Consent WS | 1.9 | https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsent |
| Secure Token Service | 1.3 | https://www.ehealth.fgov.be/ehealthplatform/nl/service-iam-identity-access-management |
| MetaHub V2 Cookbook | 1.9 | https://www.ehealth.fgov.be/ehealthplatform/nl/service-verwijzingsrepertorium-hubs-metahub |
| Issue 13 in Jira | - |
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.
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 | Specification | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
To Do
Exception flows