Workflow Control

The RFH specification is based on RESTful web services. These web services provide the basic pieces from which an integrated Service is built. These integrated services can take multiple different forms.

Building Integrated Services

As an example, consider the exchanges between a Laboratory system and a clinical records application. The laboratory system generates lab reports (a defined resource), and the clinical records application users need to access the lab reports. The following examples show some of the different ways in which this can be achieved:

• the lab system provides a read-only interface for reports, and the clinical systems accesses reports as they are needed using the search and read interactions
• the lab system pushes reports to the clinical system using create/update/delete, and the clinical system stores them internally as desired
• the clinical system uses the lab system's update list to keep informed of what reports have changed on a regular basis, and uses the read interaction to fetch changed reports for storage internally.
• the lab report pushes it's update list to the clinical system, and the clinical system uses the read operation to access the reports
• the lab reports pushes an aggregated update list to the clinical system on a regular basis (perhaps every time there is a change)

What interactions are possible between the systems can be determined from their conformance statements. What interactions are appropriate depend on local business and network conditions.

Giveen this, there is obviously utility in a workflow control layer that allows healthcare providers and vendors to manage the procurement, deployment and management of their applications.

Managing Workflow

TODO: specify a workflow definition layer. This needs to allow the kind of patterns above to be described, and then for applications to make conformance statements about them so that interoperability can be checked.

© 2011