Keywords
business process model and notation - decision model and notation - contraception
- medical eligibility criteria - clinical pathway - clinical guideline
Background and Significance
Background and Significance
Our objective was to model the processes and decisions for birth control initiation
according to the Centers for Disease Control and Prevention's (CDC's) 2016 “U.S. Selective
Practice Recommendations for Contraceptive Use,”[1] in a formally standardized fashion, and to evaluate the suitability of the Business
Process Model and Notation (BPMN)[2] and Decision Model and Notation (DMN)[3] modeling languages for this purpose. A more global approach to modeling medical
processes has been described,[4] but our goals were more specific. The ultimate goal was to produce a model that
would give clear, precise, unambiguous instructions to a software developer for instantiation
of this guidance into an application. Validation of this approach[5] will be the subject of future investigation.
A commitment to evidence-based medicine includes a commitment to making clinical practice
safer, more consistent, and more effective.[6] Nonetheless, the data continue to show that health care providers are making decisions
in the context of incomplete information, uncertainty, and time pressure, which leads
to diagnostic errors,[7] unexplained practice variability,[8]
[9]
[10]
[11] and guideline noncompliance.[8] Furthermore, data now show that usability issues with electronic health records
(EHRs) are potentially contributing to patient harm.[12]
To address these issues, it will be necessary to translate narrative clinical guidelines
into a format that would facilitate incorporation into a digital platform, by giving
clear, precise, unambiguous instructions that could be used as a “blueprint” by a
software developer. Surfacing this guidance at the point of care may facilitate better
informed decisions by health care providers.
The CDC has produced a 72-page document titled “U.S. Selective Practice Recommendations
for Contraceptive Use” in 2016 which contains the medical eligibility criteria (MEC)
for contraceptive initiation or continuation based on a patient's current health status.
The CDC also condensed this document into several other formats, including a two-page
summary chart, a “wheel” calculator, and an application for a mobile device. All of
these derivative artifacts serve to more easily expose the guidance for a specific
condition. However, true integration with a digital platform such as an EHR has not
been achieved. This gap between a narrative guideline and a digital instantiation
of that guideline would require a translation of the clinical processes and decisions.
This translation would require input from both clinicians and experienced informaticians.
Using a notation that is both standard based and open source would make the resultant
work product usable in a variety of digital platforms. A community of interest (BPM+)
has been established to investigate whether the BPMN and DMN notations would be suitable
for this purpose. This article presents an example demonstrating the suitability of
this approach.
This project was led by a clinician (SH) with assistance from expert modelers (RL,
FH). The specific requirements for the data elements and decisions were elicited from
the two-page summary chart[13] of the CDC MEC. Processes were determined based on clinical input. The models were
built using the Trisotech modeling tool.[14] Modeling clinical pathways by using the Object Management Group (OMG) BPMN and DMN
standards has been suggested in related literature.[15]
[16] The integration of BPMN and DMN has also received a significant amount of attention,
as it was suggested that the process and decision-modeling concerns should be separated,
yet consistently integrated.[17]
[18]
[19]
[20]
[21] In this article, we adhere to these modeling guidelines on the integration and use
of BPMN and DMN models. Thus, instead of modeling decision constructs in the process
model, the decisions are externalized and encapsulated in a separate DMN decision
model. The process can provide the relevant input data to the decision model and thus
invoke the decision logic stored in the decision model. Subsequently, the decision
model returns a decision outcome to the process for further interpretation.
Using DMN and BPMN models for modeling clinical pathways provides a standard-based
format which ensures that the resultant model would be understandable by both clinicians
and software engineers.[15]
[16] This was recognized by other researchers in the field as well.[22]
[23]
[24] The investigation in this article was designed to further determine the suitability
of the BPMN and DMN standards with a fairly large and complex clinical guideline,
and expose challenges that could lead to potential extensions for the standards. Furthermore,
to the best of our knowledge, this is the first article standardizing the contraception
clinical pathway by using process and decision-modeling standards.
Methods
Scope
Our goal was to model the process for birth control initiation according to the CDC's
guidelines. We did not model the conditions for method continuation. We did not specify
in the model where the data elements should come from as this aspect of data interoperability
is rapidly changing. Some might be available through an application programming interface
(API), in a format such as Fast Healthcare Interoperability Resource (FHIR).[25] Other elements may have to be provided at the point of care by the user (patient
or provider). We did not model drug–drug interactions, as this functionality is already
widely available. We also did not model the process for additional evaluation or testing,
for example, blood work to determine if a thrombogenic mutation is present. Finally,
we did not include conditions which did not present a significant risk, even though
some of these are included in the MEC specification.
Process Modeling
When we began modeling the prescribing process, we realized there were three scenarios
that could occur. The first was the scenario for the patient who knows which birth
control method they would like to initiate and wants to determine if that particular
method is safe for them. The second was the scenario for the patient who wants to
initiate birth control and wants to know all of the methods that would be safe. The
third scenario was that a patient has known, specific health conditions and wants
to know what method is safe to initiate based on those conditions. The example provided
in this article is the first scenario, that is, the patient wants to initiate a birth
control method if that method turns out to be safe for them.
The CDC MEC summary chart states the level of risk of seven different birth control
methods, based on a list of different health conditions from anemias to viral hepatitis.
Risk levels range from 1 to 4, with 1 being relatively safe and 4 having the risks
far outweigh the benefits. Level 2 indicates more risk than level 1, but the benefits
still outweigh the risks. Conversely, Level 3 indicates more risk than level 2, but
the risks outweigh the benefits.
To determine if a birth control method is safe to initiate, a long list of questions
must be answered. To minimize the number of questions asked, questions were grouped
into categories such as cancer, breast feeding, and diabetes. For example, patients
would be asked if they have diabetes and if the answer was “yes,” five additional
questions would be asked. If the answer was no, these additional questions could be
skipped and the provider could proceed with the next category of questions. Questions
were also asked in order of risk level to minimize the number asked. Level 4 questions
were asked first. If “yes” was answered to any of them, the birth control method would
be classified as unsafe and no further questions would be necessary. Level 3 questions
followed the level 4 questions. All “yes” responses were compiled into a list for
further consideration by the provider at the end of the process. Questions which were
level 2 or 1 were not asked, because these indicate the birth control method is relatively
safe to initiate.
Both BPMN and DMN were necessary to model this process. Both of these modeling standards
are open source, and have clearly defined semantics. There are also multiple modeling
tools available for creating these models. In this article, we used the Trisotech
modeler for developing the clinical pathways. However, the models can be exported
in an eXtensible Markup Language (XML) format and imported in other tools such as
for instance Camunda. BPMN was used to model the overall process, allowing the user
to choose between the three scenarios. Within each of these scenarios are BPMN subprocesses
which detailed the list of questions that needed to be answered prior to initiating
the birth control method. In these subroutines, the responses to the questions were
captured and compiled into a list. The models make decisions for level 4 questions
and create a summary list for level 3 questions that can then be reviewed by the provider.
Terminology Modeling
The BPMN and DMN models do not have an overt way to organize and supply metadata about
a data object. From a terminology standpoint, a data element may have a label, a value
set of answers, a cardinality, an associated code from a reference terminology, and
a patient-facing question. All of these components can be more easily organized in
a spreadsheet, but the integration of that “data dictionary” into the BPMN and DMN
models is not yet part of the standards. Therefore, a separate modeling approach was
needed. We identified all the clinical concepts in the specification, and transferred
those elements to a spreadsheet. We then added additional clarifying information to
additional columns in the spreadsheet. This step expanded the single column of conditions
in the CDC summary chart to three columns for conditions, subconditions, and additional
details (sub-subconditions). For example, the summary chart assigns higher risk levels
to “Multiple Risk Factors for Arterial Cardiovascular Disease,” which we included
in the conditions column. The document clarifies this with a list of risk factors,
which were added in the subconditions column, including older age, smoking, diabetes,
hypertension, low high-density lipoprotein, high low-density lipoprotein, and high
triglyceride levels. Multiple calls were held with the CDC to clarify the terms and
the intent for their use so that the correct logical model could be agreed upon.
We added three additional columns and began the task of assigning SNOMED-CT (systematically
organized computer processable collection of medical terms—clinical terms) codes to
each of the conditions, subconditions, and additional details. SNOMED-CT codes were
chosen because they are an extensive library of clinical descriptors. They also contain
adjectives that may be used to clarify other terms. For example, the code for “hypertension”
does not include a descriptor for time frame, but it may be relevant that it is current
hypertension. By combining the SNOMED CT term “current” as a qualifier value, this
information can be conveyed accurately. We also assigned metadata to each element
including how well a term matched a SNOMED-CT code, if there were parent–children
issues, and if there were parameter issues that made precise mapping difficult. We
also included a column with a patient facing question that could be used to gather
the data directly from a clinical encounter.
This additional artifact provides clarity about the data elements used in the model.
To actually instantiate this whole process as a decision support application, a software
developer would need to know how the model elements relate to other data that may
already be available in an electronic form, as well as how best to solicit the data
elements that are unknown directly from the application user. Combined with the BPMN
and DMN models, this additional information increases the clarity of the “blueprint”
for actually building an application.
Decision Modeling
Data from the terminology spreadsheet were imported into the DMN models as True/False
(Boolean) values. For level 4 questions, a decision was made, again as a Boolean.
If the answer to the question was true, the output variable “Is this method safe?”
was false. Since this is a simple decision evaluating a single Boolean, it was not
implemented as a separate DMN decision model, but rather as a decision point (i.e.,
exclusive gateway) within the control flow of the process itself. For level 3 questions,
a list of conditions was created. For this purpose, true/false responses to the questions
were imported into the DMN model with a collect hit policy, thus combining the outcomes
of all satisfied decision rules into a list. This list was exported into the BPMN
model, where it was made available for conducting the more specific questions regarding
the existing conditions in a subprocess specified for each condition. The answers
to the specific conditions were compiled into a list of observations which the user
reviews after all level 3 questions had been asked. Based on this list, the user makes
the decision about whether or not the birth control method is safe to initiate.
Results
There were 137 medical conditions called out in the specification. A shortened list
of 105 conditions was created that consisted of conditions for which level 3 and level
4 ratings were present. Of these 53 were a perfect match to SNOMED-CT codes and 44
were a close match. Parameter issues, such as time periods or modifiers requiring
additional SNOMED CT codes, were present for 33 of the conditions, and 45 of the conditions
were parent SNOMED-CT terms with children.
BPMN and DMN were successfully used to model birth control initiation. [Fig. 1] provides an example of the process and decision model that was created. This example
determines if Depo-medroxyprogesterone (DMPA) is a safe method of contraception to
prescribe to a patient. [Fig. 1] is the entire process from beginning to end. EHR is represented as a data store
of information that can transfer information to each set of questions. The first questions
asked are level 4 questions, as indicated by the conduct DMPA level 4 questions activity
shown in [Fig. 1]. A question is asked and the response is recorded in a data object, DMPA level 4.
Subsequently, this data object is then used to check for current breast cancer. If
the data object in figure recorded a “true” response, the decision model determines
that the answer to “Is DMPA safe?” is false. If the model determines DMPA is not safe
to prescribe, no more questions are asked and the provider is guided to determine
another method of birth control. If DMPA was determined to be safe based on the level
4 questions, the level 3 questions are then asked. This is done by checking whether
level 3 conditions are present in the decision activity (decide on DMPA level 3 conditions).
These were grouped into categories to minimize the number of questions asked. A list
of conditions is returned by the decision model, and in the consequent subprocess
(conduct observations of conditions), more specific questions on conditions were asked,
each in their respective subprocess. As such, a list of observations on the conditions
is compiled. As an example, one of the questions asked is “Is a liver disorder present?.”
If the answer is “true,” a subprocess is enacted that conducts observations on liver
disorders. Three questions are asked and the “true” responses are recorded in a data
object, list of observations. This data object contains the responses to all level
3 questions asked at any point in the process. The responses are then presented to
the provider as a list at the end of the model in [Fig. 1]. The provider must analyze the data and make a decision. Based on the provider's
decision, the contraceptive method is prescribed or an alternative method is considered
([Figs. 2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
).
Fig. 1 Process and decision model to determine if DMPA is a safe method of contraception
for the patient. DMPA, Depo-medroxyprogesterone; EHR, electronic health record.
Fig. 2 Conduct miscellaneous observations subprocess.
Fig. 3 DMPA level 3 conditions decision requirements diagram. DMPA, Depo-medroxyprogesterone;
EHR, electronic health record.
Fig. 4 DMPA level 3 conditions decision table. DMPA, Depo-medroxyprogesterone.
Fig. 5 Conduct observations of conditions subprocess.
Discussion
Modeling clinical pathways into a language that will be both human readable by clinicians
and can provide software engineers with precise build instructions is in its infancy,
but is a task that needs to be addressed.[26] Several groups, including the Veterans Health Administration and the Mayo Clinic,
are actively pursuing using the OMG standards for this purpose. With the addition
of a spreadsheet, these models can include precise terminology bindings and clear
process depiction. They include the actions of providers, decision support rules,
quality measures, and complex decision making. We were able to successfully model
the CDC MEC specification and most of the data elements, thereby creating templates
for software engineers. Of note is that BPMN and DMN models can also be used as an
executable “microservice,” and as interoperability progresses, this mode of model
utilization may become more important.
While a general guide to this work has been developed, there are still several issues
that are encountered at a granular level.[27] Most important is the need for clear data definitions. We used a spreadsheet, and
mapping to SNOMED CT codes to clarify our data definitions, this is currently not
an integrated part of the BPMN 2.0 standard. Assigning SNOMED-CT codes to all of the
terms in the summary chart was challenging. Some of the language in the specification
was vague, and it was not clear what the authors of the recommendations intended.
SNOMED-CT codes do not exist for every term in the specification. For example, time
periods are often not available as SNOMED-CT codes. Some terms used to quantify values,
such as “more than 15 cigarettes a day,” are not SNOMED-CT terms. In our model, questions
that contain these terms must be asked by the provider, they cannot be answered using
standardized, coded-concept data from the EHR. Obtaining a new SNOMED-CT code can
be a lengthy process. This may prove to be a bottleneck for scalable modeling efforts.
A new reference terminology, Solor,[28] may help solve this problem.
SNOMED-CT parent terms with children presented another problem. To ensure that the
proper code was available to a provider, all children of parent terms would need to
be included. This can be a significant number of terms. Diabetes mellitus (SCTID:
73211009), for example, has 25 children and hundreds of subchildren. The existence
of a terminology server may be very useful here as well. If a parent term was used,
the server could automatically include all of the children.
BPMN and DMN provide the opportunity to clearly describe many processes and decisions.
A weakness is their ability to model a series of questions. These processes often
result in complicated models, hence the large number of individual tasks in our models.
An extension of the BPMN 2.0 standard to accommodate this functionality should be
considered. The incorporation of “situational data,” which is a list of data elements
with the associated metadata (e.g., SNOMED CT binding), should also be considered
for inclusion into the standard. Toward achieving these goals, works revolving around
process and data integration provide a good basis. Overall, the process–data interaction
was studied for BPMN models.[17]
[29]
[30] More specifically, the issue of process–data integration in medical settings has
received some attention in literature as well. Bazhenova et al provided a framework
for extracting DMN decision models from BPMN process models by proposing a mapping
of process patterns to decision patterns.[31] They illustrated their method by applying it on a case dealing with diagnosing patients
with suspected chronic obstructive pulmonary disease. Hewelt et al defined treatment
cases TCs and give an operational semantics for their evolution based on BPMN models.[32] This is part of their process information and guidance system approach which provides
an overview of treatment history, as well as recommendations based on the current
treatment state and multiple process models.
Fig. 6 Conduct immune disorder observations subprocess.
Fig. 7 Conduct diabetes observations subprocess.
Fig. 8 Conduct vascular disorder observations subprocess. LDL, low-density lipoprotein;
HDL, high-density lipoprotein.
Fig. 9 Conduct liver disorder observations subprocess.
Medical care becomes more complicated by the day, and complexity brings risks. Appropriate
evaluation prior to birth control method selection may help improve care and decrease
risk. It is unreasonable to expect a provider to remember all of the necessary questions
to ask prior to prescribing a form of birth control. It is also unreasonable to expect
the provider to ask an extensive list of questions during an office visit, given their
time constraints. Incorporating this care pathway into a digital platform—whether
an EHR, a SMART (substitutable medical apps, reusable technologies) on FHIR app, a
mobile application, or a patient facing Web site or portal—is dependent on being able
to give clear, precise, unambiguous direction to a software developer. We have demonstrated
the feasibility of modeling a clinical specification into a standardized format suitable
for digital consumption, to leverage the ability of the specification to improve care.
Conclusion
We successfully translated a complex clinical guideline into a standardized format
with precise terminology bindings. This model may be used to inform a digital platform,
ease the burden on the provider, and improve patient outcomes. This model may also
be used to generate data for further analysis and improved models in the future. The
BPMN and DMN languages can be used, with addition of a spreadsheet, for this purpose.
Clinical Relevance Statement
Clinical Relevance Statement
For the practicing clinician, this effort is aimed at improving the quality of care,
reducing burden, and enabling a value-based care approach to documentation. For researchers
and payers, these models specify discrete data elements which can be used to assess
the quality of care, as well as serve as data streams for research. For clinical societies,
these models serve as a way to enter into the digital world, and successfully communicate
their best practices to any number and type of digital platforms. EHRs, Web sites,
mobile apps, patient facing apps, and telehealth apps all need clinical content that
has been vetted by a respected source. If a standardized format is adopted by multiple
modeling efforts, these platforms will have a much easier time in creating the tools
our providers so desperately need.
Multiple Choice Questions
Multiple Choice Questions
-
SNOMED-CT codes are often unavailable for which of the following types of information?
-
Adjectives (moderate).
-
Time periods (21–30 days).
-
Broad disease classes (breast cancer).
-
Specific disease details (EGF2-negative breast cancer).
Correct Answer: The correct answer is option b. This was discussed in the “Methods” section under
“Terminology Modeling” and in the “Discussion” section.
-
When modeling a clinical pathway, which of the following are important to include?
-
Processes.
-
Decisions.
-
Terminology.
-
All of the above.
-
None of the above.
Correct Answer: The correct answer is option d. This was discussed in the “Methods” section under
the “Process Modeling,” “Terminology Modeling,” and “Decision Modeling” sections.
