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.
