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

Page History (main updates):

Page Version

Date

Author

Short description of changes

v1.4

 

eHDSI Business AnalystRemoved the reference to the business and solution requirements.
v.1.3

 

eHDSI Business AnalystAdded a new gap after discussion with eHDSI Architect (linked to requirement: EHOPERATIONS-234 - Ensure auditability of the exchanged data).
v1.2

 

(in progress)

eHDSI Business AnalystUpdated the GAP Analysis by integrating the review remarks from eHDSI Project Manager.
v1.1

eHDSI Business AnalystRefined the GAP Analysis table by adding a new column to each gap identified (''Type of Gap''), so that we make clear between 'what' and 'what' the gap is.
v1.0

eHDSI Solution Provider

First version created based on the discussions (and raised issues) between the eHDSI Business Analyst and eHDSI Solution Provider team.

Last updated:  May 20, 2019 15:26

Table of Contents

Goal of the current page 


Summarize the identified gaps within eHDSI artefacts and the further actions to be taken to solve these gaps.

Depending on the type of the identified gaps, they can occur between different eHDSI artefacts, as follows:

  • Gaps between eHealth Network (eHN) Guidelines/Applicable legislation and eHDSI Business Requirements.
  • Gaps between eHDSI Functional Requirements and eHDSI Specifications.
  • Gaps between the eHDSI Specifications/Applicable standards and the current Implementation.   
  • Gaps between eHDSI Specifications and Test Validators.
  • Gaps between eHDSI Requirements and Audit Readiness Criteria.

Summary of Identified Gaps



#

TYPE OF GAP

(Gap between)

DESCRIPTION OF THE IDENTIFIED GAPSACTIONS TO BE TAKENCURRENT STATUS
1eHN Guidelines (Release 2) - eHDSI Business Requirements

eHDSI Functional Requirements documents refer to the planned care as being in scope of eHDSI. This reference is not accurate, as it contradicts the eHN PS Guidelines (Release 2). - See Article 3: ''Concept and intended use''.


  • Add the planned care as out of scope for eHDSI.

This was added to the eHDSI Scope page.

DONE

2

eHDSI Functional Requirements (Word documents) - eHDSI Business Requirements (New catalogue)

Frequency of visit/ Classification of mobility:

  • Two separate use cases were defined for the situation when the patients visits are for a short period of time or for longer periods (and more frequently).
  • It was concluded within the PS Functional Requirements document that the two separate use cases will have no impact on the PS requirements and they were treated as a single use case.
  • By consequence, only one single use case was considered for the new version of eHDSI Business Requirements.
  • Consider only one single use case for the PS, within the new version of the eHDSI requirements.


DONE

3
  • GDPR - eHDSI Business Requirements
  • Cascade impact of other eHDSI artefacts (Functional Requirements, Specifications, Implementation, Test Validators, Audit Readiness Criteria)


Consent Management:

  • As the consent is not the only lawful basis to process personal data under the GDPR, it should not be mentioned as is in the PS use case. The use case should be kept more generic, to cover all the possible lawful basis to process the health data within eHDSI.
  • Information about Consent management within eHDSI is mentioned in several eHDSI Business Requirements, as well as in several eHDSI Specifications documents and other artefacts.
  • Update PS use case to become more generic and apply to all possible lawful basis of health data processing (not only the Consent).


Note: We should define one action for each type of gap.


IN PROGRESS

4
  • GDPR - eHDSI Business Requirements
  • Cascade impact of other eHDSI artefacts (Functional Requirements, Specifications, Implementation, Test Validators, Audit Readiness Criteria)


Consent Management - the same remark as the one for the PS Use Case.

  • Update eP/eD use case to become more generic and apply to all possible lawful basis of health data processing (not only the Consent).


NOT STARTED

5

eHDSI Functional Requirements (Word documents) - eHDSI Business Requirements (New catalogue)

At step 15. of the use case, it is specified that if the pharmacist is not able to report the medicine dispensed to the dispense provider, s/he should report this issue to the Assistance service.

  • Clarify the reference to the Assistance service at step 15. of the eP/eD use case.


NOT STARTED

6

1. Technical Specifications (SAML Specifications) and implementation:

Roles currently implemented (according to Technical Specs): Doctor, Nurse, Pharmacist, Ancillary Services, Clinical Services and Clerk Administration.

  • In case ''Ancillary Services'' or ''Clinical Services'' are used, the attribute ''On behalf of'' (Doctor/ Nurse/ Pharmacist) must be configured as well. 
  • By using these roles as specified in the Technical Specifications document, the user is authorized to access the eHDSI services (clinical documents).
  • BUT, in case Ancillary Services/ Clinical Services/ Clerk Administration are used, the user has no access rights to view/ edit eHDSI clinical documents. - An error message is received at OpenNCP level.
  • By consequence, there is a GAP identified between the functional requirements and the technical specifications (and implementation).

Consider the identified GAP between the Identity Management document and SAML Profile Specification (and implementation), as follows:

  • Functional Requirements (Identity Management Specification_v2.1.0):
    • Specify Medical roles in eHDSI:  Doctor, Nurse, Pharmacist.
  • Technical Specifications (SAML Specifications):
    • Specify Medical roles in eHDSI: Doctor, Nurse, Pharmacist, Ancillary Services, Clinical Services and Clerk Administration.
  • Solution:
    • Analyze if there is any valid clinical/ business case to consider the 3 new medical roles within eHDSI.
    • If the case, update the Functional Requirements, by specifying the meaning of the 3 new medical roles from clinical/ business point of view.
  • Solve the identified GAP between the Identity Management document and SAML Profile Specification (and implementation).

NOT STARTED

7
Country A - Emergency situation (unconscious patient) is not detailed and therefore, not implemented.
  • Clarify Country A - Emergency situation (unconscious patient). Consider the new GDPR requirements for eHDSI.

8

Country B - Emergency situation (unconscious patient) is not detailed and therefore, not implemented.

  • Clarify Country B - Emergency situation (unconscious patient). Consider the new GDPR requirements for eHDSI.

NOT STARTED

9Only Minimum (basic) and Maximum (extended) data set categories should be used at Business and functional levels.
  • Clearly differentiate from Business, functional and technical point of view, the following concepts: Minimum/ Mandatory/ Maximum data set.


NOT STARTED

The PS Guidelines (R2) contradict this remark and state that health data could be used with other purposes, if the National legislation allows it.
  • Clarify the statement from the PS Functional Requirements document: It is also out of scope in eHDSI other potential uses of the PS information (e.g: public health, epidemiology, health management, etc.).


NOT STARTED

10

  • Update the descriptions of the concepts with more complete/ meaningful information. Example: Add definition of ''Implant Date''.

NOT STARTED

11


NOT STARTED

12
The current implementation allows exchanging only the original PS document, if the creation of the PS - Friendly Document B fails.
  • Check if there is any functional requirement stating how the errors should be handled when the creation of the PS - Friendly Document B does not succeed.
  • Define a Business Rules catalogue for eHDSI to collect the functional requirements of the errors and warnings. Consider the exceptions defined in the PS and eP/eD use cases.

NOT STARTED

13

Patient Summary presentation is specified in the CDA Display Tool Specifications document.

The CDA Display Tool Specifications document currently contains both technical information (reference to CDA documents) and functional requirements.

  • Clearly separate the technical and functional information from the CDA Display Tool Specifications.

NOT STARTED

14
ePrescription process improvements are needed: There is only one section in ePrescription and it cannot have 'Null flavour', but there could be data elements missing (e.g., coding was not possible for one medicine?).
  • Clarify the 'Null flavour' value in case of ePrescription.

NOT STARTED

15
The current implementation allows exchanging only the original eP document, if the creation of the PS - Friendly Document B fails.
  • Check if there is any functional requirement stating how the errors should be handled when the creation of the eP - Friendly Document B does not succeed.

16
eDispensation process improvements are needed.
  • Align the Solution Requirements based on the following Hot fix on Dispensed Packages: https://ec.europa.eu/cefdigital/wiki/x/6MJUAw.
  • Clarify the 'Null flavour' value in case of eDispensation. Could we have 'Null flavour' values in case of eDispensation?
  • Clarify the difference between Partial and Exceeding Dispensation and the applicable rules.

NOT STARTED

17
It should be clearly stated that Country A must ensure that the same medicine is not dispensed several times. Currently, the ePrescription use case only specifies that Country B must inform Country A about the dispensed medicines and Country A should confirm receiving this information.
  • Check if there is any requirement to impede the multiple dispensation of the same ePrescription/ medicine.

NOT STARTED

18

Consider the KPIs update when specifying the solution requirements for the Automatic Data Collector.

  • ''Performance'' should be redefined to consider the Policy perspective as well, not only the Technical perspective.
  • Proposal for the KPIs definition:

KPI-1.2: Number of ePrescriptions exchanged:

- The number of ePrescriptions successfully exchanged between Country A and Country B, within 3 months timeframe (quarterly).
- The ePrescription is considered to be successfully exchanged independently of the fact that it was dispensed or not.


KPI-1.3: Number of Patient Summaries exchanged:
- The number of Patient Summaries successfully exchanged between Country A and Country B, within 3 months timeframe (quarterly).


KPI-1.4: Number of interaction between Countries:

Currently, there are 6 possible interactions within eHDSI:
1. Patient demographics exchange
2. Patient Summaries list exchange
3. Patient Summary details exchange
4. ePrescriptions list exchange
5. ePrecription details exchange
6. eDispensation details exchange


NEW KPI: Number of dispensed ePrescriptions exchanged
The number of ePrescriptions dispensed by Country B and for which the eDispensation was processed by Country A, within 3 months timeframe (quarterly).

NEW KPI: Number of unsuccessful exchanges between Countries

- The number of unsuccessful exchanges between Countries, for all the possible interactions defined within eHDSI, within 3 months timeframe (quarterly).
- Each unsuccessful interaction will be split based on:
-- Type of interaction (the 6 below)
-- Where the error occurred: at OpenNCP level, National Infrastructure level, at Network level.

-- Reason: No consent, No information for the patient, No available eP.

1. Patient demographics exchange
2. Patient Summaries list exchange
3. Patient Summary details exchange
4. ePrescriptions list exchange
5. ePrecription details exchange
6. eDispensation details exchange

  • Specify the Solution Requirements for the Automatic Data Collector implementation.

NOT STARTED

19

Consider the following GAP identified between the Technical Specs (XCA Profile document) and the current implementation.

  • When solving this GAP, consider if the missing security alerts (last 2 bullet points) must be implemented at NCP-A level (due to technical constraint) or at Reference Implementation level. Currently, as the technical specifications specify these alerts, we can conclude they must be implemented in Open NCP.
  • Consider detailing this NFR to include the info below, as origin for the technical specifications on this topic.

MUST verify that all documents provided by NCP-A are assigned to the patient who is indicated in the TRC assertion.  In case that one or more of the requested documents are assigned to another patient, NCP-A

  • MUST NOT provide any documents to NCP-B
  • MUST respond with a “No Data” warning in order to not disclose any information on the existence of a certain document to a potential attacker
  • MUST write a respective audit trail
  • MUST issue a security alert to the operator of NCP-A.  The operator of NCP-A MUST take responsibility that the alert is as well made known to the operator of NCP-B
  • SHOULD block all further requests that are issued by the suspect HP
  • Solve the GAP identified between the Technical Specs (XCA Profile document) and the current implementation.
  • Update the security requirements in order to specify the Client Connector Consumer (Country B) minimal set of security requirements for this component (developed as part of the Reference Implementation).
    Currently, there are no security requirements for the communication between the Portal and the Client Connector Consumer.

NOT STARTED

20eHDSI Specifications/Applicable standards - Current Implementation

''IHE IT Infrastructure Technical Framework'' is defining three methods for the Identifier format of a CDA document. eHDSI current implementation can interpret (read) any of the three formats.

  • The eHDSI_XCA Profile_v2.2.0.pdf Specifications document restricts the use to only one of the formats. A gap was identified between the generic definition of the Identifier according to ''IHE IT Infrastructure Technical Framework'' and the Audit message.

Art-Decor contains the generic definition of the Identifier and does not need to be updated.

  • Update the eHDSI_XCA Profile_v2.2.0.pdf Specifications document with the generic definition of the ''Identifier'' (ParticipantObjectID), according to the definition in Art-Decor.

NOT STARTED

21

Part of Business Requirement: Any loss of integrity of the transmitted data must be recognizable by the recipient.

  • Data Integrity: Ensures the clinical data (content) sent and received were not altered in any way. → To be clarified how this requirement was implemented, as the end-to-end encryption is not enough to cover this requirement and prove the content was not altered. Is there any other technical solution to cover this requirement without storing the sent and received data?
  • Clarify that the integrity of data requirement refers to the integrity of the content of the clinical document exchanged within eHDSI.

NOT STARTED

22

Consider the linked JIRA issue and separate between Non-repudiation and Data Integrity requirements, as follows:

  • Non-repudiation: Ensures the data (transactions) were sent and received. No clinical data are stored.
  • Data Integrity: Ensures the clinical data (content) sent and received were not altered in any way.
  • Clarify if the non-repudiation only refers to ensuring the sending and receiving of the clinical documents and not to the content (which is covered by the Data Integrity requirement).

  • Rewrite CP-001 to contain the functional requirements instead of the technical solution.

NOT STARTED

23

There are no Solution Requirements specified for the CTS implementation.


Specify (reverse-engineering the current Portal ) the Central Services Portal Functional Specification.

NOT STARTED

24

Specifications are not updated according to CP-009.

Semantic Task Force considers this change proposal should be revoked.

Update the Specifications according to CP-009. Analyze first if this is needed.

NOT STARTED

25

Missing documents on the Confluence page (Specifications):

  • Automatic Data Collector component.
  • CDA Display Tool Specifications (added after the last release).

(Update the design and) Add Automatic Data Collector specifications document on the Confluence page (Specifications).

Make sure that all the official documents are on the Confluence page (Specifications) and MS representatives are informed about the changes.

NOT STARTED



  • No labels