The message flow of the portal-like scenario has been depicted in the following Figure as a state machine.
Figure 37: State machine representation of the portal-like scenario The flow is initiated by a findIdentitiesByTraits, which is sent to the MPI (IXS MQ interface) in order to retrieve a patient context.
If the patient is found, the flow continues to point 4. Otherwise, a new patient context is created with the createIdentityFromEntity operation (IXS MQ Interface).
Accordingly, a new Workflow Document is created for the patient in order to track his pathway through a clinical process. A new XDW document is stored into the repository using the put operation of the RLUS MQ Interface.
The system enters an idle state waiting for incoming clinical documents (CDA2 reports) through the RLUS MQ Interface.
When a new ClinicalDocument (CDA2 report) is stored through an RLUS MQ put operation, the system retrieves the corresponding workflow document (get operation on RLUS MQ) and updates it accordingly in order to track the documented clinical activity. The workflow document is stored back into the repository replacing the previous version.
If the new ClinicalDocument is recognized to be a closing action, the workflow document is closed and the state machine arrives to the final state.
In order to correctly use the functional test procedures, it is important to provide a formalized vision of the state machine that reflects the scenario. This document has been created using the SCXML format, as shown below.
