Patient Access to Information PAC

Patient Access to Information PAC

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

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

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

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

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

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

FR05

Patient identification and authentication: a univocal digital ID

Description

  1. The translated information and metadata about the translation service must be sent to country A.

  2. 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.

  3. The availability of the translation of the coded elements into the target language will depend on prior decisions taken by country B.

  4. The information received at the NCP-A node must be delivered (must “talk”) to the specific National Patient Access service.

  5. In the case that the PS or eP contain several items, this must be confirm with the agreed CDA tool.

  6. 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

  1. Country A and B NCPs – depending on translation responsible

  2. Common components in central services: CDA display tools

FR06

Information Traceability

FR06

Information Traceability

Description

  1. The information describing the process and the data involved in the process must be able to be retrieved.

  2. 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.

  3. 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.

  4. Main parameters for traceability of translation requested from an NCP-A to any translation responsible are:

    1. Requester: Country of Patient identification/authentication

    2. Country Language of the Patient accessing the PA Interface

    3. Selected output language ( translation language requested )

    4. Language of the document (health information) accessed

    5. Timing( time stamp) of the transformation

Associated Goals

  • Security reasons

  • Legal and liability reasons

Actors

  1. National Patient Access Service provider

  2. National EHR subsystem

  3. NCP-A

  4. Translation responsible

  5. NCP-B – depending on translation responsibility

FR07

Peering both original documents and translations

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

  1. Patient

  2. Healthcare professional

  3. 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

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.

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

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

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:

  1. New Patient Role;

  2. Section navigation filtered, according to user role;

  3. 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;

  1. 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;

  1. 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;