General

Scope

This document describes the way to deal with software interoperability issues found during the use of Vitalink, and this within the operation as agreed in the agreement between imec and VAZG for Vitalink in 2016/2017.

Goal

The goal is to identify all interoperability issues that now occur, to document and resolve them on a reactive basis and to prevent them on a structural basis. Reactive is the intention to limit the impact within that one case for the end user. To try to solve the problem within that one incident, so as not to have to wait until a structural solution exists. Structurally however, an improvement action must be initiated (if that proves necessary after analysis by imec.HIE). In addition, the goal is to be able to generate a report at any time that clearly reflects the state of affairs, both per software supplier and aggregated.

Flow

End users

Every end user:

• has to report a software problem to the 1st line support of his supplier. (1)

Software vendors

First-line support:

• Will analyse whether the notification concerns a possible interoperability issue or not.
• Will try to solve the problem.
• Will escalate a possible interoperability issue to its second-line, irrespective of  whether the specific problem for that single end user is resolved or not. (2)

Second-line support:

• Will analyse whether it is indeed an interoperability issue or not.
• In the case of an interoperability issue, will escalate the problem to imec.HIE (in case it's not resolved) or at least inform imec.HIE about it (thus also if the problem of the end user is resolved). (3)

The split first-line support and second-line support is only conceptual for the flow. In reality these 2 can coincide, that is the choice of the software vendor. However, the "second-line" concept serves as the party that is in contact with imec.HIE.

imec.HIE

imec.HIE:

• Never becomes owner of the problem.
• Will analyse the problem.
• Will try to reproduce the problem if the packages in question are installed there.
• Will provide the parties involved with the necessary information in connection with analysis and reproduction.
• Will be able to give feedback to the reporter. (3)

The possible actions depend on the cause and can be (possibly several):

• Feedback to the reporting vendor if the cause of the problem appears to be there. (3)
• Addressing another vendor as a possible cause. (5)
• Ask clarification (in case of ambiguity) from VAZG. (6)
• Propose UX improvements.
• Integration of the relevant scenario in the validation tests.

Initially, the entire flow is triggered reactively, because an end user reports a problem. On the other hand, imec.HIE can proactively anticipate possible problems.

This can happen:

• From a theoretical basis, but always with a reproducible scenario and proof when reporting.
• From kinship with a problem under analysis.
• As an output of the implementation of the ever expanding validation tests.

VAZG

VAZG:

• Will give clarification.
• Can adjust the documentation if necessary.
• Can adjust the connector/gateway if necessary.

JIRA

General

imec.HIE uses Jira Core as a collaboration tool. imec.HIE acts as an administrator for all projects. For extensive documentation the official Jira documentation is referenced. For this cooperation however, some rules are agreed on.

Entities

Parties

There are currently two types of parties that can collaborate with imec.HIE in Jira projects:

• Software vendors
• VAZG

The Jira workflow is the same for everyone. If it turns out that differentiation would be necessary in the future, this can be changed on demand. If these parties appear further in this document, they are referred to as "Vendor" unless explicitly referred to as one of these two.

Projects

Each project serves for the cooperation between one vendor and imec. Cooperation between vendors within one project is not possible.

The table below gives a description for each project and who has access to them. imec.HIE is not mentioned because imec.HIE has access to all projects.

Access

Each vendor has access to his own project (Vitalink vendorName) and to the EVS project (not by default).

imec.HIE has administrator access to all projects.

Accounts

each vendor has a maximum of two accounts. One of these is a primary account. A primary account is the account where, by default, the issues will be assigned to.

Limitations

A number of Jira functionalities are limited to clarify operation.
A non-exhaustive list of these restrictions:

• Subtasks can't be created.
• Voting functionality is disabled.
• Issues can not be deleted by the vendor.
• Only imec.HIE can create labels.

Some of these functionalities have not been stopped technically, so it is sometimes a question of discipline. Most of the actions are still protected by the configuration and every action is traceable.

Workflow

Creation of issues

For each problem, question (for information) and/or proposal for change, one Jira issue is made. The description of the issue should be kept as static as possible in order to be able to understand the comments that follow (during the collaboration) afterwards. An important change of the description is then explicitly shown in the description by using the word "UPDATE" during the adjustment and if possible also adding the date.

Issue Type

Summary

Brief description of the issue. Information that can be entered in the other fields, should not be entered here.

Priority

There are three priorities: High, Medium and Low. The choice when creating an issue should be done according to common sense.

Application

This is the application in which the problem is seen. This is not necessarily the application where the problem is caused. If the cause lies elsewhere, a linked issue will be created by imec.HIE. For that linked issue, this field will be the application with the cause.

Where the request or change request concerns the Vitalink documentation, the application "Vitalink" may be chosen.

Application Version

This is the version of the application for which the issue applies. This is a non-mandatory free text field. It is recommended that this field is filled in. It was decided not to keep a list of versions per application to make the administration not too heavy.

Application Component

This field serves to distinguish the scope of the issue. Again this is partly a matter of common sense. Combinations are not possible, so the most appropraite choice has to be made.

External Reference

This is a free text field, where a reference to your own ticketing or task system can be entered. This field has meaning for the external users, for imec.HIE this remains abstract.

Description

It should be clearly stated:

• What does not work, stating what the desired behavior is.
• What is not clear, stating a concrete, not too open, question.
• What is proposed as a change, stating the original specification and what exactly the change would contain.

In case of a problem, if applicable, the contact details (at least the name) of the end user.

Attachments

The attachments that a issue should contain are:

• Screenshots (if applicable) of the problem within the software.
• An (anonymous) export of the KMEHR message from the Patient Health Viewer (if the problem concerns the Vitalink medicationscheme).

Assigning issues

After creating an issue, it must be assigned to the primary account of the other party. Jira supports notifications as well as internal communication, so the assignee of that issue can always be informed.

Assignment is done by the "Assign" action, after which an assignee must be chosen, in combination with a useful comment.

If the assignee has done his part of the work, the task can again be assigned to the primary account of the counterparty, or to a specific other account if that was agreed earlier in the task.

Re-assigning issues

Each may assign a task that is assigned to himself, but now requires an action by imec.HIE, to the primary account of imec.HIE. However, an extra comment must always be added with the necessary action, or other sufficient documentation.

Transfer of issues

If a reported problem involves a communication to another party, imec.HIE will organize this communication. In another project a new issue will be created with a reference to the original issue. This will be viewed ad hoc, depending on the need and the contractual confidentiality. The issue of the original project is protected and can only be viewed by the vendor of that project and imec.HIE.

Resolving issues

Each may put a task that is assinged to himself and is completed on "Resolved" with the "Resolve" action. It's best to add a comment with an explanation or a reason how it was solved and a resolution. Assign the issue back to the reporter.

Resolution

Possible resolutions are:

Resolution version

Just like "Application version" this is a free text field, in which you can indicate in which current or future version of the application this issue is solved.

Closing issues

Only the reporter of the issue is allowed to "Close" an issue. This occurs when an issue is "Resolved" and the reporter has reviewed the solution.

If the closing of an issue turned out to be incorrect, a clone issue can be created.

Status in combination with assignee

The Jira workflow is tuned for use as described above. In addition, the combination with the "assignee" field always has a certain meaning, with actions expected for this. Based on the table below, a Jira user can define the necessary search actions to make his work list(s) visible. As far as possible, combinations that are not allowed are prevented by the Jira configuration, but they are listed for completeness and security.