Used Documentation

http://jira.ivlab.ilabt.imec.be/browse/MHEH-13?filter=-3

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	-

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

ID

AR

UC-

UC02 °

502-BF
Name	Put Patient Consent - Patient through portal of a hub
Description	Patient acts as author of the Informed Patient Consent Request through the portal of a Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub.
Actor(s)	Patient through the portal a hub
Requirements	End-user is a patient Patient manages his consent through a portal provided by one of the hubs Valid eHealth certificate of the Hub Identification of the Hub: Hub ID, Organization category, Name (optional) Identification end-user: SSIN number patient Information consent: °Patient SSIN °Patient SSIN Support card number (optional) °Date of registration of consent by patient °Type of consent: retrospective
Trigger	The user wants to declare a Patient Consent on behalf of the patient
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 Put Patient Consent The Put Patient Consent Request is sent to the MetaHub WS

° The MetaHub WS responds with a Put Patient Consent Response

The Informed Patient Consent is stored in the MetaHub

The request is logged

° The Informed Patient Consent is stored in the MetaHub

The MetaHub WS responds with a Put Patient Consent Response
Post Condition(s)	Request is logged The informed patient consent is stored in the MetaHub
Test Data	Example Request Patient Example DeclarePatientConsentRequest Example Succesful DeclarePatientConsentResponse
Endpoint(s)	MetaHub WS
Remarks*	Patient SSIN Support card number is optional, if provided then the card number is ignored (INSS and support card number are not submitted to status validation)
Additional Information	Additional information of the hub as name is optional. If provided, it will be used for audit purposes.

Alternative Flow

Flow

Specifications

ID

AR

UC-

UC02 °

502-AF01
Name	Put Patient Consent - Parent of patient through portal of a hub
Description	Parent of concerned patient acts as author of the Informed Patient Consent Request through the portal of a Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub.
Actor(s)	Parent of the concerned patient through the portal a hub
Requirements	End-user is the parent of the concerned patient Parent of patient manages the consent through a portal provided by one of the hubs Valid eHealth certificate of the Hub Identification of the Hub: Hub ID, Organization category, Name (optional) Identification end-user: SSIN number parent of patient Information consent: °Patient SSIN °Patient SSIN Support card number (optional) °Date of registration of consent by patient °Type of consent: retrospective
Trigger	The user wants to declare a Patient Consent on behalf of the patient
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 Put Patient Consent The Put Patient Consent Request is sent to the MetaHub WS

° The MetaHub WS responds with a Put Patient Consent Response

The Informed Patient Consent is stored in the MetaHub

The request is logged

° The Informed Patient Consent is stored in the MetaHub

The MetaHub WS responds with a Put Patient Consent Response
Difference in flow	Identification of end-user → Parent of patient: SSIN number
Post Condition(s)	Request is logged The informed patient consent is stored in the MetaHub
Test Data	Example Request Patient Example DeclarePatientConsentRequest Example Succesful DeclarePatientConsentResponse
Endpoint(s)	MetaHub WS
Remarks*	Patient SSIN Support card number is optional, if provided then the card number is ignored (INSS and support card number are not submitted to status validation)
Additional Information	Additional information of the hub as name is optional. If provided, it will be used for audit purposes.

Alternative Flow

Flow

Specifications

ID

AR

UC-

UC02 °

502-AF02
Name	Put Patient Consent - Mandatary of patient through portal of a hub
Description	Mandatary of concerned patient acts as author of the Informed Patient Consent Request through the portal of a Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub
Actor(s)	Parent of the concerned patient through the portal a hub
Requirements	End-user is the mandatary of the concerned patient Mandatary of patient manages the consent through a portal provided by one of the hubs Valid eHealth certificate of the Hub Identification of the Hub: Hub ID, Organization category, Name (optional) Identification end-user: SSIN number mandatary of patient Information consent: °Patient SSIN °Patient SSIN Support card number (optional) °Date of registration of consent by patient °Type of consent: retrospective
Trigger	The user wants to declare a Patient Consent on behalf of the patient
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 Put Patient Consent The Put Patient Consent Request is sent to the MetaHub WS

° The MetaHub WS responds with a Put Patient Consent Response

The Informed Patient Consent is stored in the MetaHub

The request is logged

° The Informed Patient Consent is stored in the MetaHub

The MetaHub WS responds with a Put Patient Consent Response
Difference in flow	Identification of end-user → Mandatary of patient: SSIN number
Post Condition(s)	Request is logged The informed patient consent is stored in the MetaHub
Test Data	Example Request Patient Example DeclarePatientConsentRequest Example Succesful DeclarePatientConsentResponse
End Point(s)	MetaHub WS
Remarks*	Patient SSIN Support card number is optional, if provided then the card number is ignored (INSS and support card number are not submitted to status validation)
Additional Information	Additional information of the hub as name is optional. If provided, it will be used for audit purposes.

Exception Flow

Flow

Specifications

ID	UC-502-EF
Name	Put Patient Consent - Patient / Parent / Mandatary through portal of a hub - There already exists an active consent for the concerned patient
Description	Patient / parent/ mandatary acts as author of the Informed Patient Consent Request through the portal of a Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub. There already exists an active consent for the concerned patient
Actor(s)	Patient through the portal a hub
Requirements	End-user is a patient Patient manages his consent through a portal provided by one of the hubs Valid eHealth certificate of the Hub Identification of the Hub: Hub ID, Organization category, Name (optional) Identification end-user: SSIN number patient Information consent: °Patient SSIN °Patient SSIN Support card number (optional) °Date of registration of consent by patient °Type of consent: retrospective There already exists an active consent for the concerned patient
Trigger	The user wants to declare a Patient Consent
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 Put Patient Consent The Put Patient Consent Request is sent to the MetaHub WS The MetaHub WS responds with a Put Patient Consent Response: error message
Post Condition(s)	Error message
Test Data	Example Request Patient Example DeclarePatientConsentRequest Example Succesful DeclarePatientConsentResponse
End point(s)	MetaHub WS

To Do

Exception Flows

Page tree

Versions Compared

Old Version 29

New Version Current

Key

Used Documentation

General Information

MetaHub

KMEHR

Basic Flow

Alternative Flow

Alternative Flow

Exception Flow

To Do

Page tree

Page History

Versions Compared

Old Version 29

New Version Current

Key

Used Documentation

General Information

MetaHub

KMEHR

Basic Flow

Alternative Flow

Alternative Flow

Exception Flow

To Do