Table of Contents

Background

In the implemented workflows, such as Patient Service, the XCPD profile is used to obtain a match for a given Patient, concerning his identifiers.

The HCP will ask the Patient for a set of Patient Demographics (or identity traits), that can be a Single Identifier or even a Combination of Identifiers (that are able to uniquely identify a single patient) and this data will be submitted, using XCPD, to the Patient's home country NCP. This NCP will return, in case of success, a match for the Patient, returning the identifier to be used in the subsequent transactions (such as the XCA profile transactions).

The combination will vary from country to country, and the following table shows all the identity traits supported by epSOS (only the following traits or a subset of them can be used):

In order to determine which identity traits are required for a given country, the current implementations of the portal in OpenNCP make use of a set of search-masks files, one for each country, containing the definition of the required fields (to be filled). These fields will be presented to the HCP in the portal interface. Bellow you can see an example of that file for Austria:

<?xml version="1.0" encoding="UTF-8"?>
<patientSearch>
   <!-- min and max -1 means no length check -->
   <!-- id format="LLLLLLNNLNNLNNNL" means 'L'etter 'N'umber -->
   <!-- validation contains the fields which are mandatory -->
   <!-- more then one validation means or -->
   <!-- only one input field no validation necessary because minimum value which has to be filled out is 1 -->
   <country code="AT">
      <searchFields>
         <textField label="patient.data.surname" min="3" max="-1" dtoIndex="1" />
         <textField label="patient.data.givenname" min="3" max="-1" dtoIndex="2" />
         <textField label="patient.data.birth.date" min="-1" max="-1"/>
         <textField label="patient.data.code" min="-1" max="-1" dtoIndex="27" />
         <textField label="patient.data.city" min="-1" max="-1" dtoIndex="25" />
         <sex label="patient.data.sex" />
      </searchFields>
      <validation>
         <field label="patient.data.surname" />
      </validation>
      <validation>
         <field label="patient.data.givenname" />
      </validation>
   </country>
</patientSearch>

Result at the interface level of the previous mapping file:

STORK eIdentification

In the STORK eIdentification process an national Identity Provider (IdP) is used to identify a citizen with the help of identity tokens such as smart cards, mobile phone based solutions, certificates or simple username/password tuples.

Based on the citizen's nationality the IdP redirection can be delegated to the proper member-state, using the Pan European Proxy Service (PEPS), also provided by STORK, and represented in the diagram bellow:

This redirection concept has special relevancy when a citizens wants to authenticate himself on a foreign country, using his (home-country) national IdP.

The STORK 2.0 mechanisms use SAML tokens to transport the authentication information. These SAML tokens contain a set of attributes with information related to the citizen's identity.

The following set of attributes are presented in STORK:

Personal Attributes	Business Attributes	Legal Attributes

When a redirection for authentication with STORK is performed, the requesting application (such as the OpenNCP Portal, represented as "SP" in the diagram) needs to specify which attributes are required to be present in the SAML token, provided by STORK as a response (after successful authentication performed at the IdP).

The information present in the attributes will be used for the requesting application (e.g. OpenNCP Portal) for the several processes.

On the next topic you can see how this information is requested and used by OpenNCP use-cases.

Patient Access

For the Patient Access, concerning the integration of STORK with OpenNCP, we have the following requirements:

We need to identify a citizen, which in this case is a patient, to allow him to log in into the service and access the Patient Access portal;
In order to re-use the already existent implementation of the Patient Access (which re-uses the existent workflows, that include XCPD, XCA profiles. More info on Section 4.2 at: https://openncp.atlassian.net/wiki/x/AwCy) we need to gather the required information to feed the XCPD profile in order to obtain a match for the patient (See topic Background);

For the requirement 1, the STORK structure already offers the necessary means to authenticate a patient, providing in return the minimum information to have it logged in into the OpenNCP portal.

After being logged in, the Patient will access his own clinical information using Patient Access service. In order to allow this operation, the requirement 2 needs to be satisfied.

In order to fulfill the requirement 2, we need to request STORK the necessary attributes to feed XCPD and have them mapped into epSOS required attributes (for XCPD).

After obtaining a match for the Patient, using XCPD, we can proceed with the subsequent workflows.

Please check the following diagram:

Mapping procedures

We need to establish a mapping of the attributes provided by STORK (see topic STORK eIdentification) and the epSOS required ones (to feed XCPD - see topic Background).

The process needs to be slightly dynamic, as the portal can be installed on different countries, with different means to identify their patients. So the selected strategy, was to make use of the already existent Search Mask files (See topic Background), by adding additional information to establish the mapping of STORK to epSOS.

Example (please note the attribute naming "stork"):

(...)
<textField label="patient.data.surname" min="3" max="-1" dtoIndex="1" stork="surname" />
<textField label="patient.data.givenname" min="3" max="-1" dtoIndex="2" stork="givenName" />
<textField label="patient.data.birth.date" min="-1" max="-1" stork="dateOfBirth" />
<id label="patient.search.patient.id" min="-1" max="-1" domain="2.16.840.1.113883.2.16.3.1.3.100.990.1" stork="eIdentifier" />
(...)

With this information, the OpenNCP portal is now able to infer which information needs to be requested to STORK and how this information will be converted to epSOS attributes to feed XCPD (See Workflow Diagram).

Future considerations

The main goal for this strategy was to be compliant with the current Patient Access implementation and to add some dynamic functionality to the mapping process.

Of course on an ideal/long term scenario other approaches can be considered. For instance:

Skip the XCPD step, obtaining the final, unique identifier for the Patient, compatible with the XCA profile (for querying and obtaining documents) directly from STORK;

This approach would solve the problem where STORK is unable to provide the required attributes to feed XCPD.

This approach can be used either on current Patient Access model but also on Patient Service (retrieval of Patient Summary).