Used Documentation

Cookbook	Version	Location
MetaHub V2 Cookbook	1.9	https://www.ehealth.fgov.be/ehealthplatform/nl/service-verwijzingsrepertorium-hubs-metahub

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.

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

ID	UC-1001-BF
Name	Get Metahub Delta - Hub as author of the request - ALL
Description	Get MetaHub Delta allows a hub to obtain all requests that have been registered in the metahub regarding consents, exclusions and/or hub hub-patient link data, for a certain period.
Actor(s)	Authorized end-user through a hub: Professional of AR78 ( Physician, Dentist, Nurse, Midwife) Professional of AR78 in a hospital ( Physician, Dentist, Nurse, Midwife) Administrative in a hospital Citizen: Patient - Parent of patient - Mandatary of patient
Requirements	Authorized end-user through a Hub (mentioned in "Actors") Valid eHealth cerificate of the hub Identification Hub: Hub ID, Organization category, Hub name (optional) Period: begin & end Delta type: all
Trigger	User wants to Get MetaHub Delta
Precondition(s)	The user has an account for the application The user is logged out
Flow	The user attempts to access to the eHealth MetaHub WS The user needs to request a SAML Token by using the eHealth Certificate of the Hub A request for a SAML Token is sent to the Secure Token Service (STS) The STS responds with a SAML Token The user has access to the eHealth WS MetaHub The user does a request for Get MetaHub Delta The Get MetaHub Delta Request is sent to the MetaHub WS The list of recorded delta elements that fulfill the provided criteria The request is logged The MetaHub WS responds with a Get MetaHub Delta Response
Post Condition(s)	The request is logged The list of recorded delta elements that fulfill the provided criteria °The occurrence time is contained in the period (Begin-End) °Type of Delta element corresponds to timeperiod
Test Data	Example Get MetaHub Delta Request Example Successful Get Metahub Delta Response with delta p122 Example Successful Get MetaHub Delta Response without delta Example Unsuccessful Get MetaHub Delta Response
End point(s)	WS MetaHub
Additional Information	If the end of the interval is not provided, the interval is considered to be (Begin-Present Date Time) We strongly recommend minimizing the period by using the request criteria ‘begindate’,’ begintime’, ‘enddate’ and ‘endtime’. Indeed, the maximum of the records returned in the result set by the service is currently 1500. A ‘Warning' is returned when there are more results than supported by the service.
Remarks	If there is no delta element that fulfills the provided criteria, the returned list is empty.
Comments	Due to technical limitations, the availability of the delta elements throughout the service is limited in time. The size of the response is also limited. The hubs are expected to update their systems with the metahub deltas once in a certain period, as to assure to their patients that their application information is up to date.

Page tree

UC-1001-MH-Get MetaHub Delta-All

Used Documentation

General Information

KMEHR

Basic Flow