Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Primary actors:

  • The Patient
  • A HCPPrescriber
  • A Dispenser

Secondary actors:

  • Patient identification, authentication & role authorization service;
  • The epSOS Patient Access translation service;

Diagram 1: Use case diagramloremipsum

The following diagram illustrates the basic use case for the MRO service.

Image Added

Figure 1. Process diagram of the medication distribution 2 (eP and eD) + distribution II (medication related overview).

 

Basic explanation of the Use case

  • The patient, who is referred to (or reports himself to) a physician.
  • When the decision is made that the patient has to take medication for treatment the physician, in his role as prescriber, issues a medication prescription that can be seen both as an order to a pharmacist as well as the agreement between the physician and the patient on the specific treatment with this medication. For doing this, the prescriber receives relevant historical medication information.
  • The pharmacist, in his role as a dispenser of medication, receives the prescription, in some countries he receives relevant historical medication information, and dispenses the medication. The pharmacist then issues information about the dispensation, which serves two goals: it is added to the historical medication information, and it is used to update the status of the prescription (in some cases it lowers the amount of remaining items that can be given out from the prescription). The patient again, finally, receives the medication and takes care of the administration, with or without the intervention of family members and/or nurses.

2. Requirements

Actions and Steps

...

Service State diagram

Image Added

Non-Functional Requirements

loremipsumFor Non-Functional requirements please consult the D 1.4.3, page 71;

Legal Requirements

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

Security Requirements

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

Clinical Requirements

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

Additional Architecture NCP / Central Service requirements

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

 

3. Implementation Strategy Design

Overview

Loremipsum

Proposed Solution

4. Testing Strategy

The chosen implementation strategy will make use of the existent Arquitecture and implemented profiles. Following you can fin a table that maps the required steps, in order to accomplish this service and the behaviour that will occur within the OpenNCP system.

Proposed Solution

StepActionsOpenNCP actions and operations descriptionTo be implemented in the OpenNCPRelated Profiles
1Health professional identification and authentication
  • The health professional will authenticate himself in the OpenNCP portal (e.g: using database-stored credentials or LDAP);
Already supportedXUA
2

The patient’s identity has to be validated in country B, the patient’s identifier(s) from country A must be used for retrieving the MRO.

  • The health professional selects the corresponding country flag in the OpenNCP portal and performs a validation of the Patient Identifiers;
  • The NCP-B will communicate with NCP-A and perform the findEntityByTreats() operation using the Identification Service;
Already supportedXCPD
3

The patient must agree with sending the MRO to country B (patient consent in country A).

  • The Health Care professional submits the consent or tries to query for the MRO documents immediately;
  • If the patient has previous consent given, an answer, regarding the available MRO documents, will be provided.
  • If not, the submit consent window will be presented;
Already supported, some light adjustment is needed.XCA
4

Country B requests the MRO from country A. Country A processes this request and sends the MRO to country B.

  • In this workflow the NCP-B will communicate with NCP-A using the XCA protocol.
Already supported, some adjustments are required in the client and server part, mostly at the NI interface level. The portal also requires some changes in order to dispolay the MRO correctly.XCA

 

4. Implementation Issues / Tasks

Portal-B

Gadget
filterIdfilter-10800
isConfiguredtrue
preferencesfilterId=filter-11802&num=10&columnNames=summary%7Cdescription%7Cissuekey%7Cpriority%7Cassignee%7Cstatus&isConfigured=true&refresh=30
columnNamessummary|description|issuekey|priority|assignee|status
authorMarcelo Fonseca
num10
width100%
refresh30
urlhttps://openncp.atlassian.net/rest/gadgets/1.0/g/com.atlassian.jira.gadgets:filter-results-gadget/gadgets/filter-results-gadget.xml

Protocol Terminators

Gadget
filterIdfilter-10801
isConfiguredtrue
preferencesfilterId=filter-11803&num=10&columnNames=summary%7Cdescription%7Cissuekey%7Cpriority%7Cassignee%7Cstatus&isConfigured=true&refresh=30
columnNamessummary|description|issuekey|priority|assignee|status
authorMarcelo Fonseca
num10
width100%
refresh30
urlhttps://openncp.atlassian.net/rest/gadgets/1.0/g/com.atlassian.jira.gadgets:filter-results-gadget/gadgets/filter-results-gadget.xml

4. Testing Strategy

Regarding the testing strategy, the following topics need to be covered:

  • Extend integration testing for both CLIENT and SERVER part;
  • Add extra validation in CI environment;

Related issues

Gadget
filterIdfilter-11803
isConfiguredtrue
preferencesfilterId=filter-11804&num=10&columnNames=summary%7Cdescription%7Cissuekey%7Cpriority%7Cassignee%7Cstatus&isConfigured=true&refresh=30
columnNamessummary|description|issuekey|priority|assignee|status
authorMarcelo Fonseca
num10
width100%
refresh30
urlhttps://openncp.atlassian.net/rest/gadgets/1.0/g/com.atlassian.jira.gadgets:filter-results-gadget/gadgets/filter-results-gadget.xml

5. Documentation and References

...

Attachments
uploadfalse
labelsmro-specs

 

Sample MRO Documents

Attachments
uploadfalse
labelsmro-sample

References