Process Data Model Integration "Patterns" (draft)

The following are not design patterns or integration patterns in the typical application of the approach

But they have similar structure to design patterns as the have a problem/solution/consequences

Problem Statement

Integrate a (sharable) process model into an existing infrastructure by providing the instance information to meet the requirements of the process.

(This is not about REST vs SOAP but the fulfillment of actual information needs; for instance the process needs the patients current temperature. )

(To reiterate - Types and scopes of “models” vary differently and the application of a name to a model infers perspective that can distract the discussion. For this discussion going forward - “Process Data Model” is the structures and relationships need to execute the process. The following pattern describes approaches to integrating/defining/modeling the Process Data Model)

Native Integration Pattern for Process Data

Solution

The premise of this pattern is to modify/refactor/?? the Process Data Model such that the structures being used by the process match the native/local syntax and semantics. The steps taken would also need to modify the logic and rules of the process model.

Consequences

Modifying/refactoring comes at cost of development/testing the initial model. This cost can be prohibitive to initial adoption and up keep with new versions of the model. Brittle in nature such that changes to the infrastructure also requires updates to the model.

Shared Integration Pattern for Process Data

The premise of this pattern is the process model and the infrastructure have an agreed upon “ 3rd party model”. Integration is implied from the beginning as the information in the infrastructure and the process are same patterns. So in the terms of OO, the Process Data Model is a “3rd party model” and the Infrastructure Data Model is a “3rd party model”

Consequences

The level of effort to integrate elements built upon the same semantics is very low. The level of effort to define and agree upon a shared semantic model is/can be very high. Several examples of these sharable semantics information models exists to varying degree of success and adoption. Localization of the model in order to support specific use case for the infrastructure represents a risk of fracturing. Versioning of the shared semantic information model would result in cost of maintenance.

Translator Integration Pattern for Process Data

or

Black Box Integration Pattern for Process Data

The premise of this pattern is to allow both the infrastructure and the process model “information” evolve and be defined independently. This solution relies heavily on transform services from infrastructure model to the process model and back again.

Consequences

The expectation is the process model will be executed “as is” and the infrastructure will provide the needed services to populate process and consume any results from the process. Implementing such services results in cost. The process model information requirements need to be very explicit to avoid mis-interpretation of the requirements - this is not a simple task.

Decision Service Integration for Process Data

This pattern has more to do with the initial model definition versus a pattern for implementation but was implemented as part of HIMS with VHA and Perspecta. The initial model does work with typical patient information but instead is build around questions/queries such as “Does the patient have emergent condition?” The implementation in this case for the question was in fact a CDS hook which in turn as an solution queries for the Native FHIR content itself. The response was simple structure in the operation outcome such as valueBoolean. Essentially the BPM+ model works the response from the decisions service and not really with any direct patient information.

Consequences

This puts a priority on the model - the initial model would need to follow this path. Or at least support some type of transformation. The model is not expressive in the sense that the decisions logic is hidden and not easily consumable by SME for validation.

The implementation is not overly complex except for aligning the decisions in the model with actual services available.