Part III:
Going from Paper to Practice

Read Time: 3 Minutes

Welcome to the third installment of this three-part series providing an overview of the resources and steps required to achieve success when automating your first clinical guideline using the BPM+ family of open standards on the Trisotech platform.

In Part I we discussed how long it will take you to reach cruising speed for creating BPM+ visual models. In Part II, we discuss the critical step of grasping the knowledge presented in the guideline and standardizing your approach to deal with the various pitfalls you may encounter in doing so. Now we will delve more into the details of how to develop an automated guideline. While the Trisotech modeling tools provide low-code programming that is easily comprehended by novices, there are many details “under the hood” that need to be specified to achieve automation.

Stages of Development

The entire process of automating a guideline starts from a written guideline and proceeds through a sequence of stages to the final automated clinical model, as outlined in the following diagram. There is some flexibility in the process; however, it is not recommended to complete a stage without completing preceding one.

Narrative Explicitation, Concept Model, Computational Independent Model (CIM), Shared Data Model, Platform Independent Model (PIM), Platform Specific Model (PSM)

Narrative Elicitation refers to an in-depth understanding of the guideline, as was discussed in Part II of this series.

Concept (or Notional) Model: Here you start to lay out what you have distilled from the guideline into the core concepts (or notions). The Trisotech Knowledge Entity Modeler (KEM) can be useful to build a standardized terminology and to lay out concept maps. You will want to identify key decisions and how information flows to achieve each goal.

Computational Independent Model: Once you have a rough idea of what you want to model, then you can start building the models in DMN and BPMN. The more concrete that your planning is then the faster the building can proceed. Tasks include labeling elements, specifying data objects for input and output, and providing references. If you are building models just to document and train, then you may choose to stop at this level.

Shared Data Model: By now you should know what decisions you need and will have a good idea of what data is required. You will want to consolidate this data to a minimum. It is common to have several models using the same data inputs, but because they were developed at different times there may be some variability in how they are specified or used. You need to resolve any discrepancies in how they are defined or referenced. In addition, some data is easy to ask for but hard to get, so you may need to refine models to use data that is readily accessible. Finally, you need to know where the data is coming from and how to retrieve it. The various codes used for retrieving data (SNOMED. LOINC, ICD-10, RxNorm codes, value sets) need to be provided.

Platform Independent Model: During this stage you finally specify all of the fine details required for the models to execute. Every element of a model has an underlying structure and logic that needs to be specified. When this step is complete there should be a smooth execution of the models’ logic. You can release this model as an API and market it to clients. However, data mapping may be required since links to a specific data source have not been established. You will want to test your model now with your test cases.

Platform Specific Model: This stage requires system integration, where everything required to interact with the client institution is set. This is the stage where you will need EHR analysts to become involved. Once this is complete then the models should be fully automated and integrated. After testing they can be released to the end-users.

How Long Does It Take?

To give you some concrete numbers, here are some specifics about a collection of models that I developed for the Pain/Opioid LHS Learning Community (POLLC). It focuses on improving chronic pain management, referencing an 86-page guideline from the University of Michigan.

Complete modeling of the guideline required:

68 DMN models
15 BPMN models
1 CMMN model
2 Knowledge Entity Models
250 unique data objects with definitions and clinical coding

These models were taken to the Platform Independent stage but taking them to automation has been pending key additional resources.

It took 3 months for me to produce these models while working part-time. To fully automate these models will require an additional 3 months for model refinement, data connections and testing. You should expect that it will take you at least 6 man-months to completely automate the typical guideline. As you get more experienced the speed of development will improve. If you want to move faster than this, then you will need to apply more resources. If you have multiple team members, then each can specialize on specific tasks.

Some Recommendations

Here are some personal recommendations:

Clearly specify your goals in detail before you start.
Build all of the DMN models first.
Once the DMN models are built, optimize the data inputs. Remember that data is expensive so you need to use it judiciously and keep it to a minimum.
Conceptualize how you want things to flow and interact before you start to model processes.
Only start building the BPMN models when you have clear idea what you want to achieve.
Do not “overload” your BPMN models by trying to put everything into a few models.
Learn to recognize recurring patterns in clinical problems. Reuse of logic can speed development.
Use modular design to aid maintenance and reuse.

If you have read all 3 blogs in this series, then you should have a pretty good idea of how to automate a clinical guideline. While a lot of work, the benefits should far outweigh the costs.