The purpose of this page is to provide a better clarification on the specification of the implementation of the Patien Access Service on the OpenNCP scope.

To discuss this page please use the following issue:

PT-178 - Getting issue details... STATUS

______________________________

PAC Service Implementation Overall Status

Table of contents:

1. Scenarios Clarification

Goals

The goals of the main actor, the patient, in UC.PAC.1 is to access and understand what the Health Professional has recorded in the PS or eP, in order to:

Participate in his or her own care, and/or to improve the information he or she gives to a New Health Professional;

Actors

The actors involved in the epSOS PAC Use Case are:

Primary actors:

The Patient;

Secondary actors:

The Health Professional, acting as a Healthcare Provider, producing the medical information used in the document to be accessed;
The Health Professional at a new encounter (New Health Professional);
Patient identification, authentication & role authorization service;
The epSOS Patient Access translation service;

Diagram 1: Use case diagram

2. Requirements

Actions & Steps

Steps	Actions
1	(This step is in the National Domain, and is a prerequisite for the PAC service) The patient affiliated in Country A requests access to PS or eP in Country A, by contacting the Country A National Patient Access Service The patient identifies himself The National Patient Access system verifies the patient’s authorization The National Patient Access system retrieves the document
2	The Patient requests an epSOS translation of the retrieved document
3	The National Patient Access system passes the request to the epSOS NCP in Country A
4	The epSOS NCP in Country A provides a dialogue for selecting the source and target language (Language A, Language B)
5	The National Patient Access system sends the document (in Language A) to the epSOS NCP in Country A
6	The NCP-A transforms (transcodes) the document indicated (or received) from Patient Access system into a translatable epSOS pivot document and then makes this pivot document available to the translation responsible.
7	The translation responsible retrieves the epSOS MTC of Language B
8	The translation responsible translates the pivot document and makes the translated document in language B available to the NCP of country A
9	The NCP of country A conveys the information translated into the interface of the National Patient Access system
10	The patient accesses the translated document in his specific device display
11	The use case is finished/closed EXCEPTIONS The translation responsible does not have access to the epSOS MTC of language B. The translation responsible informs NCP of country A of the failure. The NCP A cannot inform the Patient Access System about the failure.

Basic Service Functional Requirements

FR01	Patient Access Basic Requirement
Description	The Patient must have the possibility to access his/her own medical information available at his/her national PA service ( affiliation’s country) and get it translated into any epSOS country language Specific PA services asks first its NCP-A for PS/eP translation service. As a consequence NCP-A requests a translation. Each translation request to an NCP-A must include these parameters 1. Affiliation country where the Patient has identified/authenticated himself 2. Language of the Patient accessing the PA Interface 3. Selected output language ( translation language requested ) 4. Language of document (the health information) accessed
Associated Goals	Existing PS/eP in epSOS network must be available to patients either in his own language or in any of the languages of the participating PNs. After the identification of the patient who requests healthcare, in country A or B, the patient requests through a simple action (just a click) the visualization of the PS/eP in the selected language (that one that fits either with his own language or with that of the health care professional). The patient must be able to access his usual national Patient Access service. National PA service asks NCP-A for the list of available translations service , and this list is sent and presented to specific Patient access service including for each access date/time of access.
Actors	1. Patient 2. Specific national patient access service 3. NCP A
Preconditions	Pre-existence of national Patient access service Pre-existence of epSOS NCPs, at both sides at the country having Patient access and in the output language requested by the patient.

FR02	Patient identification and authentication: a univocal digital ID
Description	epSOS Patient Access (PAC) must be in accordance with the Patient Access policy of patient’s Country of Affiliation [9]. Access by the patient to epSOS related functionalities through its National Patient Access shall not interfere with this rule. The patient will be univocally identified in a reliable way (unique and unequivocal id) to consult his information. Patient authentication will be guaranteed at national level based on the concept of mutual trust.
Associated Goals	To have certainty of the identity of the patient Independence of national/regional PA systems. The responsibility for patient authentication and identification should remain within the patient’s country of affiliation
Actors	1. Patient 2. National Certification authority in country A
Preconditions	Pre-existence of digital certification authority. The certification authority has already assigned a digital ID to the citizen. There is a legal basis for access by citizens to their healthcare data in country A Pre-existence of the Patient access service in country A

FR03

Trust between countries

Description

Country A and B are integrated on one circle of trust (technical and functional). It’s necessary an agreed framework for creating trust, by establishing policies, processes and procedures for critical data protection, privacy and confidentiality issues as well as mechanisms for their audit. Such issues include, but are not limited to:

Identification, authentication and authorization mechanisms.
Security and trust mechanisms.

Associated Goals

To enable the exchange of information between countries. Based on the recognition of given Certification authorities.

Actors

NCPs and their translation catalogs (MTC)
Certification of provider’s servers/ environments
Certification authorities (CA)

FR04	Request from country A for a document translation
Description	For any provided epSOS pivot content in structured form (both CDA level 1 and level 3), Country A requests the translation of all coded elements that are used to describe the epSOS data set. Country A has to provide original data in epSOS CDA compliant form, i.e. the friendly document that has exactly the form of epSOS pivot document, (Ref.: in Specs of common components p.19)
Associated Goals	none
Actors	NCP A Translation’s responsible (either Central services, NCP-A or NCP-B) to be decided at architectural level.

FR05	Patient identification and authentication: a univocal digital ID
Description	The translated information and metadata about the translation service must be sent to country A. When creating a epSOS pivot document, in coded elements the information about code, code system and version should not be repeated in the translated element when the elements are the same as in the original data. The availability of the translation of the coded elements into the target language will depend on prior decisions taken by country B. The information received at the NCP-A node must be delivered (must “talk”) to the specific National Patient Access service. In the case that the PS or eP contain several items, this must be confirm with the agreed CDA tool. Country A NCP must answer/inform translation responsible of the successful receipt of the translation.
Associated Goals	The NCP of country A must be informed about the delivered translation. Health care actions happening in country B as a result of Patient Access won’t be reported back / won’t be included! This is part of Use case PS extension. Adaptation/integration/enlargement of current national Patient access services Security reasons
Actors	Country A and B NCPs – depending on translation responsible Common components in central services: CDA display tools

FR06	Information Traceability
Description	The information describing the process and the data involved in the process must be able to be retrieved. PAC functionalities include the transformation of national PS oeP into epSOS documents, using transcoding and translation mechanisms based on MVC / MTC mechanisms. These epSOS transformed documents are then made available to the patient through the National Patient Access. The information describing the process and the data involved in the transformation process must be traced and recoverable. It includes such information as the identification of the requester, steps in data transformation and timing of transformation. Main parameters for traceability of translation requested from an NCP-A to any translation responsible are: Requester: Country of Patient identification/authentication Country Language of the Patient accessing the PA Interface Selected output language ( translation language requested ) Language of the document (health information) accessed Timing( time stamp) of the transformation
Associated Goals	Security reasons Legal and liability reasons
Actors	National Patient Access Service provider National EHR subsystem NCP-A Translation responsible NCP-B – depending on translation responsibility

FR07	Peering both original documents and translations
Description	Patient and healthcare professional must be able to consult a copy of the original document (with no epSOS semantic transformation) and the translated document.
Associated Goals	none
Actors	Patient Healthcare professional NCP-A
Preconditions	Availability of documents (eP/PS) Availability of the pair of language translation involved

FR08	Consultation of PoC through the patient access service - OPTIONAL
Description	For this service the steps in the country National Domain are the same as above for eP/PS. For the realm of epSOS the National Patient Access system retrieves the PoC through the NCP or from the epSOS website.
Description	The patient must be able to consult available PoC in the area where he is interested in for any type of health care providers (e.g. hospitals, healthcare centers and pharmacies). It is a Browsing function returning the list of all PoC in the specified territory value set. The patient triggers the event; the requested Point of Care in an area is the origin of the event; the Service consumer is NCP that triggered the event
Associated Goals	Give guided access to epSOS web site maps/PoC. Guided offer of a collection of retrieved PoC in www.epSOS.eu
Actors	Patient = Active participant Passive participant /object= Directory/Value set of epSOS PoC www.epSOS.eu Patient Access system calls NCP-A for this service
Preconditions	Availability of PoC in the requested area (not mandatory). Return value may be zero. Correct PoC maintenance in www.epsos.eu is under responsibility of the NABs

Service Legal Requirements

For service legal requirements please consult the D 1.4.3, page 112;

Service Security Requirements

For service security requirements please consult the D 1.4.3, page 114;

Service Clinical Requirements

For service clinical requirements please consult the D 1.4.3, page 115.

Service Usability and Data Presentation Requirements

For service usability and data presentation requirements please consult the D 1.4.3, page 117.

Additional Architecture NCP / Central Service requirements

For additional Architecture NCP / Central Service requirements please consult the D 1.4.3, page 122.

3. Clarification

The purpose of this topic is to clarify some remaining questions and doubts about the Patient Access specification of OpenNCP.

Can the service workflow be accomplished using the NCP-B + Portal-B?

4. Implementation Strategy Design

4.1. Overview

Multiple ways can be followed in order to implement the Patient Access service on the OpenNCP. The most direct one is to make use of existent components and implemented services. Others will require further development.

4.2. Solution A: Re-use the Portal-B + NCP-B as Patient Access and Translation Service

Basic solution diagram

In order to promote the maximum components re-use we can define the following table to map the required PAC service elements into the existent OpenNCP components:

Mapping table of Patient Access Elements into OpenNCP components

Patient Access Required Element	OpenNCP Existent Component	Description
Country-A Patient Access Service	Portal-B with Patient Access Section + NCP-B	As a default implementation, the Patient Access service can be provided by the existent Portal solution for OpenNCP. It will be necessary to implement a Patient Section.
Translation Service	NCP-B (In patient country of affiliation)	The translation service can be provided by the NCP-B of the country of affiliation, since it will support the target language selection
NCP-A	NCP-A (In patient country of affiliation)	The NCP-A can be used as it is, with no further modification.

We can also map the required steps into the following OpenNCP actions and operations:

Mapping table of required steps into components actions and operations

Steps	Actions	OpenNCP actions and operations description	To be implemented in OpenNCP	Related Profiles
1	(This step is in the National Domain, and is a prerequisite for the PAC service) The patient affiliated in Country A requests access to PS or eP in Country A, by contacting the Country A National Patient Access Service The patient identifies himself The National Patient Access system verifies the patient’s authorization The National Patient Access system retrieves the document	The patient will access to the Portal-B Patient section; The portal will use its "Portal-B" capabilities to query the Patient Documents based on the Patient Identifier, using the NCP-B; The retrieved (as whole document) or available (as list) documents are presented to the user; The patient may retrieve the document (if it isnt yet) or move to next step;	A Portal-B Patient Section, with the following aspects: New Patient Role; Section navigation filtered, according to user role; Default document search, constrained to the user id (not possible to user other id);	XCPD, XCA
2	The Patient requests an epSOS translation of the retrieved document	(Portal GUI)	(Described further bellow)
3	The National Patient Access system passes the request to the epSOS NCP in Country A	Not required
4	The epSOS NCP in Country A provides a dialogue for selecting the source and target language (Language A, Language B)	The patient selects the target language for the document at the portal and requests the document; The Portal performs a request to the NCP-B, also specifying the translation language selected by the patient;	Target language selection for translating a document at the Portal-B patient section; List of available languages must be displayed;
5	The National Patient Access system sends the document (in Language A) to the epSOS NCP in Country A	The NCP-B then requests the document at the NCP-A	Already supported;	XCA
6	The NCP-A transforms (transcodes) the document indicated (or received) from Patient Access system into a translatable epSOS pivot document and then makes this pivot document available to the translation responsible.	The NCP-A request the document at the National Connector and transforms it to epSOS Pivot	Already supported;	XCA
7	The translation responsible retrieves the epSOS MTC of Language B	(NCP-B operation, using TM)	Already supported by TM;
8	The translation responsible translates the pivot document and makes the translated document in language B available to the NCP of country A	The NCP-B retrieves the document from NCP-A and translates it to the target language;	Adapt Client Connector to support language specification when retrieving a document; Include extra language parameter in the document retrieve request message;	XCA
9	The NCP of country A conveys the information translated into the interface of the National Patient Access system	The NCP-B returns the document to the Portal;	Already supported;	XCA
10	The patient accesses the translated document in his specific device display	The Portal displays the document using the specific XSLT resources	Adapt portal to support multiple XSLT for each language; Possibly add PDF production feature (for easier portability and printing);
11	The use case is finished/closed EXCEPTIONS The translation responsible does not have access to the epSOS MTC of language B. The translation responsible informs NCP of country A of the failure. The NCP A cannot inform the Patient Access System about the failure.

Implementation Mapping with existent Workflows

Assumptions - Example

Country B is Greece;
Country A is Italy;

Existing Portal-B workflow	PAC Workflow
Pharmacist accesses Greek Portal-B	Italian Patient accesses Italian Portal-B
1. hcp asserion	1. hcp asserion (needs to be specified new role and permissions for patient). I am not sure if patient is an HCP (healthcare point)
2. identification service (finds an Italian patient)	2. identification service (the system automaitically identifies itself, the patient stores to the portal the personal identifiers needed for matching with the patient)
3. TRC Assertion	3. TRC Assertion (the system automatically creates a trca with purpose of treatment, new role has to be defined)
4. patient service	4. patient service (the system automatically retrieves list of documents)
5. Consent handling if needed	5. Retrieval and display of document (translation of document not needed, it's in italian language already, no transformation needed)
6. Retrieval of document (translation of document in country b language - greek in this occasion)	6. Consent handling must be part of ncp-a in order to allow patient to see its own data

Questions

Does it needed a new audit event for this transaction?

So if the patient role had permissions on patient service he could probably see his documents

Implementation Issues / Tasks:

Portal-B

Protocol Terminators

Transformation Manager / TSAM / TSAM-Sync

Considerations

In this scenario we will re-use all the existent components to meet the PAC Service requirements;
Some security issues need to be taken into account, in order to restrict the retrieval of "patient-only" documents;

4.3. Solution B: Newly create Patient Access and Translation Service components

In this option we would need to expose an additional service for translation purposes only at NCP-A, skipping the re-use of NCP-B.

(To be completed if required)

4.4. Solution C: Use Transformation Manager and National Connector library as Portal dependencies

With this solution we would have the Portal communicating directly with the National Infrastructure, using the already implemented National Connector (by the OpenNCP PNs). The translation would be performed by the Transformation Manager, added also directly as a dependency of the Portal.

The following diagram tries to explain the proposed solution.

Basic solution diagram (click to enlarge)

In order to clarify the portal dependencies, the following diagram is presented:

Portal dependency graph