Versions Compared

Old Version 19

changes.mady.by.user Unknown User (gaelle.laurent.ext@imec.be)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (gaelle.laurent.ext@imec.be)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Used Documentation

Cookbook / MaterialsVersionLocation
Consent WS1.9https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsentSecure Token Service1.3https://www.ehealth.fgov.be/ehealthplatform/nl/service-iam-identity-access-management
MetaHub V2 Cookbook1.9https://www.ehealth.fgov.be/ehealthplatform/nl/service-verwijzingsrepertorium-hubs-metahub
Issue 13 in Jira-http://jira.ivlab.ilabt.imec.be/browse/MHEH-13?filter=-3


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


ID
AR
UC-
UC04
504-BF
NamePut Patient Consent - Professional of AR78 in a hospital
DescriptionA professional of AR78 in a hospital declares the Informed Patient Consent through the Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub. 
Actor(s)A professional of AR78 in a hospital  (! Only these 5 end-users: Physician - Nurse - Dentist - Midwife - Pharmacist)
Requirements
  • End-user is A professional of AR78 in a hospital (! Only these 5 end-users: Physician - Nurse - Dentist - Midwife - Pharmacist)
  • End-user does the request throughout the hub
  • Valid eHealth certificate of the Hub
  • Identification Hub: Hub ID, Organization category, Name (optional)
  • Identification Hospital: Hospital ID, Organization category, Name
  • Identification of the doctor: INSS, NIHII, professional category, First and family name
  • Information consent: 

         °Patient SSIN

         °Patient SSIN Support card number (optional)

         °Date of registration of consent by patient

         °Type of consent: retrospective

TriggerThe user wants to declare a Patient Consent on behalf of the patient
Preconditions
  • 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 Consent      °
  1. WS MetaHub
  2. The user does a request for Put Patient Consent 
  3. The Put Patient Consent Request is sent to the MetaHub WS
  • ° The MetaHub WS responds with a Put Patient Consent Response
    1. The Informed Patient Consent is stored in the MetaHub
    1. The request is logged 
          ° The Informed Patient Consent is stored in the MetaHub
    1. The MetaHub WS responds with a Put Patient Consent Response
    Post Conditions
    • Request is logged
    • The informed patient consent is stored in the MetaHub
    Test Data
    End point(s)

    WS MetaHub

    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 InformationAdditional information of the hub as name is optional. If provided, it will be used for audit purposes.



    Alternative

    Flow - Admin

    Flow 

    FlowSpecifications


    ID
    AR
    UC-
    UC04
    504-AF01
    NamePut Patient Consent - Administrative in a hospital
    DescriptionAn administrative in a hospital declares the Informed Patient Consent through the Hub. Certificate used to access the MetaHub WS is the eHealth Certificate of the Hub. 
    Actor(s)
    • An administrative in a hospital 
    Requirements
    • End-user is an administrative in a hospital
    • End-user does the request throughout the hub
    • Valid eHealth certificate of the Hub
    • Identification Hub: Hub ID, Organization category, Name (optional)
    • Identification Hospital: Hospital ID, Organization category, Name
    • Identification of the doctor: INSS, NIHII, professional category, First and family name
    • Identification Administrative: INSS, professional category, First and family name
    • Information consent: 

           °Patient SSIN

           °Patient SSIN Support card number (optional)

           °Date of registration of consent by patient

           °Type of consent: retrospective

    TriggerThe user wants to declare a Patient Consent on behalf of the patient
    Preconditions
    • 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 Consent      °
    1. WS MetaHub
    2. The user does a request for Put Patient Consent 
    3. The Put Patient Consent Request is sent to the MetaHub WS
  • ° The MetaHub WS responds with a Put Patient Consent Response
    1. The Informed Patient Consent is stored in the MetaHub
    Difference in flow
    1. The request is logged 

          ° The Informed Patient Consent is stored in the MetaHub

    1. The MetaHub WS responds with a Put Patient Consent Response
    Post Conditions
    • Request is logged
    • The informed patient consent is stored in the MetaHub
    Test Data
    End point(s)

    WS MetaHub

    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 InformationAdditional information of the hub as name is optional. If provided, it will be used for audit purposes.



    Exception Flow

    FlowSpecifications


    IDUC-504-EF
    NamePut Patient Consent - Professional of AR78 in a hospital - There already exists an active consent for the concerned patient
    DescriptionA professional of AR78 in a hospital declares the Informed Patient Consent through the 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)A professional of AR78 in a hospital  (! Only these 5 end-users: Physician - Nurse - Dentist - Midwife - Pharmacist)
    Requirements
    • End-user is A professional of AR78 in a hospital (! Only these 5 end-users: Physician - Nurse - Dentist - Midwife - Pharmacist)
    • End-user does the request throughout the hub
    • Valid eHealth certificate of the Hub
    • Identification Hub: Hub ID, Organization category, Name (optional)
    • Identification Hospital: Hospital ID, Organization category, Name
    • Identification of the doctor: INSS, NIHII, professional category, First and family name
    • 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
    TriggerThe 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
    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 Put Patient Consent 
    7. The Put Patient Consent Request is sent to the MetaHub WS
    8. The MetaHub WS responds with a Put Patient Consent Response: error message
    Post Condition(s)Error message
    Test Data
    End point(s)

    WS MetaHub

    To Do 

    Exception Flows