Page tree
Skip to end of metadata
Go to start of metadata

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

StepsActions
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

FR01Patient 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
  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

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

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

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 ElementOpenNCP Existent ComponentDescription
Country-A Patient Access ServicePortal-B with Patient Access Section + NCP-BAs 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 ServiceNCP-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-ANCP-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

StepsActionsOpenNCP actions and operations descriptionTo be implemented in OpenNCPRelated 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;
  • 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


Mapping table of required steps into components actions and operations

StepsActionsPortal actions and operations descriptionTo be implemented in the PortalRelated 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 National Connector implementation dependency to query the Patient Documents based on the Patient Identifier;
  • 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);
NI specific
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;

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

  • Not required
  
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 Portal uses the Transformation Manager toEpsosPivo() operation to transform the document to epSOS Pivot
The Transformation Manager toEpsosPivot() invocation; 
7

The translation responsible retrieves the epSOS MTC of Language B

  • Transformation Manager operations, using the LTR, shared with the NCP;
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 Portal uses the Transformation Manager translate() operation to translate the document to the requested language

The Transformation Manager translate() invocation;

 
9

The NCP of country A conveys the information translated into the interface of the National Patient Access system

  • The Portal obtains the result of the Transformation Manager translate() operation
  
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.
   

5. Test Strategy Design

(To be defined after strategy validation)

6. References

  File Modified
PDF File D1.4.1 EED SERVICES including use cases for all services.pdf D1.4.1 EED SERVICES including use cases for all services Feb 11, 2013 by Marcelo Fonseca
PDF File D1.4.3 EED SERVICES including specifications for all services v1 0 20120911.pdf EED SERVICES including specifications for all services Feb 13, 2013 by Marcelo Fonseca

9 Comments

  1. Perhaps we could link to the 1.4.1 EED document? Or plain upload it to this page?

    1. Done! Uploaded document.. (wink)

  2. Take a look especially at page 107 in D1.4.3 (available above):

    Step 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
  3. "Implementation Scenario" child page removed after integrating its contents to the main page.

  4. I agree with Konstantin, the basic idea was to use the national patient portal of Country A to:

    • authenticate the patient
    • request the translation of the selected document(s)
    • display the translated document(s)

    This approach needs no extension to the epSOS portal, only to the NCP, ie. to perform the translation in place (Country A). All the problems related to patient identification are out of scope. Similarly, the displaying of the translated document can be left to the national patient portal.

    1. Our intention was to provide a working and ready to use solution for PNs without national patient portal, by re-using the existent workflows.

      My interpretation of "Patient Access" implementation is that we should provide the "full" set of software required to execute the workflows, otherwise we would only be developing a single translation service (and call it "Patient Acces"), and that is only a portion of the Patient Access process.

      My proposed solution C also works with Konstantin statement (and it was first based on his idea). If you just want translation services you can add the Transformation Manager dependency directly at the national patient portal - in this situation no development is required in OpenNCP.

    2. I fully agree with Marcelo's answer. Indeed, if patient identification and document fetch are the responsibility of the country implementing the portal (and the portal itself is naturally a responsibility of the country also), no changes in OpenNCP are needed. Instead:

      • The country developing its own portal uses the TM (transformation manager), TSAM (transformation service access manager) and LTR (local terminology repository)
      • Fetches translations using TSAM-sync.

      All these software components are readily available. What is somewhat unclear still is TSAM-sync configuration tweaking, in order to get translations in all available languages. However, this is out of scope of OpenNCP.

      The option C proposed by Marcelo adds a little bit "extra" to that, allowing the country to use a ready-to-use portal and a national connector interface.

      1. Having a ready-to-use portal is of course a great solution for countries without a national patient portal. What I don't see yet is to how solve the problem of secure and general (ie. applicable to all PN) patient identification.

        1. I am afraid at the moment there is no one size fits all solution. Different countries use different identity providers / ways to identify citizens. Perhaps collaboration with Stork might provide some solutions.