THIS SPACE IS UNDER CONSTRUCTION

Used Documentation

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.

Basic Flow

FlowSpecifications

IDUC-805-BF
NameGet Patient Audit Trail - Hub - All criteria
DescriptionGet Patient Audit Trail allows a hub to audit the MetaHub operations on a given patient (audit list of consent, exclusions and link operations) for a certain period. All criteria in input.
Actor(s)Hub
Requirements
  • Identification of the hub: Hub ID, Organization category, Hub name (optional)
  • INSS patient
  • Period (Begin-End)
  • Operation list
  • Completion status (all, success, failed)
  • Maximum number of allowed results
TriggerUser wants to Get Patient Audit Trail
Precondition(s)
  • The user has an account for the application
  • The user is logged out
Flow
  1. The user attempts to access to the eHealth MetaHub WS
  2. The user needs to request a SAML Token by using the eHealth Certificate of the Hub
  3. A request for a SAML Token is sent to the Secure Token Service (STS)
  4. The STS responds with a SAML Token
  5. The user has access to the eHealth WS MetaHub
  6. The user does a request for Get Patient Audit Trail
  7. The Get Patient Audit Trail Request is sent to the MetaHub WS
  8. The list of recorded audit elements that fulfill the provided criteria
  9. The request is logged
  10. ° The MetaHub WS responds with a Get Patient Audit Trail Response
Post Condition(s)
  • The request is logged 
  • The list of recorded audit elements that fulfill the provided criteria

      °The audit element is related to the patient

      °The occurrence time is contained in the period (Begin-End)

      °The requested operation

      °The completion status of the requested operations

Test Data
End point(s)WS MetaHub
Remarks
  • if there is no audit element that fulfills the provided criteria, the returned list is
      empty.
  • only successful Put (Declare) and Revoke operations audit are returned. Failed
     operations are not returned
  • the successful or failed Get operations are not returned
  • if the maximum number of allowed results is exceeded, the service returns the more

      recent access audits that fulfill the provided criteria.

  • Completion status: if omitted, the status is by default 'success'
CommentsThe availability of the audit elements throughout the service is limited in time. The hub
can always contact eHealth Platform in order to retrieve the archived access audits.
  • No labels