KPI Objectives. Ensure that the specific interactive web service is available on the eHealth platform. The service is considered as available when it provides a successful response at each access. Successful responses are all Front Web Service responses which do not mention the unavailability of a component needed to route a request from its reception at a Front Web Service till the answer is delivered. Poor request formulations (e.g. bad NISS) which provide an error message, are considered as successful transactions when this error message is not related to a component failure.
KPI Objectives. Ensure the availability of the SOA infrastructure to ensure the availability of the different services proposed on the eHealth Service Bus.
KPI Objectives. Ensure that each ConsultRN web service request handled through the eHealth platform is being processed within the response time limit (see Table 1). It ensures the follow-up of the web service performance.
KPI Objectives. Ensure that each request to the Timestamping Base Service handled through the eHealth platform is being processed within the response time limit (see Table 1). It ensures the follow-up of the web service performance.
KPI Objectives. Ensure that each request for authorisation handled through the eHealth platform is being processed within the response time limit (see Table 1). It ensures the follow-up of the authorisation service performance. The eHealth Platform identifies 2 distinct scenario’s type with 2 distinct service level expectations: scenarios integrating the new UAM components, scenarios still needing to be adapted3 or complex scenarios of Orthopride, Medic-e, e-Birth, Safe, Quermid, ZNA Elimzo, Vesta.
KPI Objectives. Ensure that the time stamping web service is available every day, around the clock, on the eHealth platform, for requests coming from the Client Application over the Internet and reaching the Reverse Proxy. The service is considered as available when it provides a successful response at each access. Successful responses are all Web Service responses which do not mention the unavailability of a component needed. Requests poorly formulated (e.g. bad TS Bag) which generate an error message, are considered as successful transactions whenever this error message is not related to a component failure.
KPI Objectives. Ensure that the specific components involved in the Checking of qualities and relationships steps are available on the eHealth platform.
KPI Objectives. Ensure that each request for checking of qualities and relationships steps is being processed within the response time limit (see Table 1). It ensures the follow-up of the checking of qualities and relationships service performance.
KPI Objectives. Ensure that the specific components involved in the authorisation service are available on the eHealth platform. The service is considered as available when a successful response is provided at each monitoring request for authorisation. Successful responses are all web service and other components responses which are not blocked by the unavailability of a specific component needed to route a request from its reception at the PEP till an application screen is provided, with either authorisation or denial of access.
KPI Objectives. Ensure that each eH2eBox web service request handled through the eHealth platform is being processed within the response time limit (see Table 1). It ensures the follow-up of the web service performance.
