Table of Contents
| Table of Contents |
|---|
...
Background
| Anchor | ||||
|---|---|---|---|---|
|
In the implemented workflows, such as Patient Service, the XCPD profile is used to obtain a match for a given Patient, concerning his identifiers.
...
Result at the interface level of the previous mapping file:
STORK eIdentification
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
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:
...
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
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).
...
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.
...