• Created by Unknown User (katrien.vangucht@imec.be), last modified by Unknown User (jeroen.brackez@imec.be) on Mar 28, 2018

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »


Guidelines

Interoperability defined

Interoperability is understood in different ways depending on the specification under consideration:

  • If the specification is about a communication protocol (e.g. a transfer protocol, an interface like the eHealth Hub webservices) and about the behavior of processors of this protocol, then interoperability is understood as the ability of two implementations of this specification – i.e. processors of this protocol - to communicate properly. In the case of an interface, ability of a user entity to communicate with an implementation (or processor) of the interface.
  • If the specification is of an artifact (e.g. a business document, a process definition, a policy contract, a medication scheme), then interoperability is understood as the ability to process this artifact with consistent results, using different platforms or processors. In such a case, interoperability is often described as portability from the artifact perspective (the artifact is portable across platforms), while the platforms or processors are qualified as interoperable.

Clear understanding of specification


Requirements

This paragraph should be moved to the requirements documentation.

Interop1 - Transparency in exporting of local data

Verify that it is visible for the user which locally edited data will be shared.
This includes explicitly visualising any removal of central data.

Interop2 - Transparency in importing of central data

Verify that it is visible for the user which displayed data comes from the shared central source.
This includes explicitly visualising any removal of local data.

Interop3 - Exhaustive data mapping

Verify that all the data from the central source is visible for the user.

Interop4 - Erroneous data mapping

Verify that the user is consulted when incoming data from the central source can not be processed. 

Interop5 - Input validation

Verify that the validation of user input is also applied for incoming data from the central source. If the validation fails, the data should be handled as erroneous data.

Interop6 - Transformation design

Verify that your transformation of central data is well-designed and documented. The design includes the restrictions the central data should apply to to be able to serve as input for the transformation.
All data that is not suitable for the transformation should be handled as erroneous data.

Interop7 - Server processing

Verify that the processing of erroneous data on a server (where there is no immediate user interaction) is logged, monitored and eventually presented to the user.

Interop8 - Logging

Verify that enough information about manipulation of central and local data is logged to enable later analysis of possible problems.


  • No labels