Utilization of BPM+ Health for the Representation of Clinical Knowledge: A Framework for the Expression and Assessment of Clinical Practice Guidelines (CPG) Utilizing Existing and Emerging Object Management Group (OMG) Standards

Abstract

Clinical Practice Guidelines (CPG), meant to express best practices in healthcare, are commonly presented as narrative documents communicating care processes, decision making, and clinical case knowledge. However, these narratives in and of themselves lack the specificity and conciseness in their use of language to unambiguously express quality clinical recommendations. This impacts the confidence of clinicians, uptake, and implementation of the guidance. As important as the quality of the clinical knowledge articulated, is the quality of the language(s) and methods used to express the recommendations. In this paper, we propose the BPM+ family of modeling languages as a potential solution to this challenge. We present a formalized process and framework for translating CPGs into a standardized BPM+ model. Further, we discuss the features and characteristics of modeling languages that underpin the quality in expressing clinical recommendations. Using an existing CPG, we defined a systematic series of steps to deconstruct the CPG into knowledge constituents, assign CPG knowledge constituents to BPM+ elements, and re-assemble the parts into a clear, precise, and executable model. Limitations of both the CPG and the current BPM+ languages are discussed.

Introduction

Clinical Practice Guidelines are the distillation of vast amounts of clinical knowledge and randomized controlled trials into knowledge artifacts (papers, algorithms, processes definitions, etc.) that are meant to represent the current state of understanding, recommendations, and best practices for the delivery of care.¹ They are defined by the National Academy of Medicine as “recommendations, intended to optimize patient care, that are informed by a systematic review of evidence and an assessment of the benefits and harms of alternative care options”.²

Narrative text is the default method for representing clinical practice guidelines with tables, figures, and flow diagrams used to attempt to make the CPG more clear.³ It is generally accepted that there are multiple limitations with the current methods for representing clinical knowledge in CPGs.^4,5 These issues are compounded by the volume of CPGs that often contain conflicting recommendations between the CPGs.⁶ Current methods using narrative text are inadequate for communicating evidence-based best practices for reuse partly due to the intrinsic limitation of natural language and its misalignment with the complex and varied types of clinical knowledge present in a CPG.^7,8

Healthcare domain-specific languages (DSL) such as PROforma, EON, Asbru, and GLIF do not individually provide the language constructs necessary to express the range of semantically complex medical concepts in a CPG.⁹ At the same time, because of the historical isolation of the development of these DSLs, their overlap and concept overload prohibits effective use of them in combination. Further, having one language that addresses all the medical concepts is problematic and generally not scalable. Attempting to address all the requirements of all knowledge types adds complexity to a single solution and will potentially lead to implementations that are brittle. Thus, A one-size-fits-all language would not adequately provide the richness required for the wide range of concepts that are needed in the healthcare domain. Appropriately, as an example, Clinical Quality Language (CQL) focuses only on decisional logic or queries and does not provide support for process knowledge.¹⁰ Further, despite the importance of DSLs and their role to express clinical knowledge, the semantic quality of these languages is often subjective leaving their quantitative characteristics under assessed.^11,12

As healthcare DSLs and requirements advance for expressing CPGs, adding new knowledge type support could be complex and costly over time.¹³ To mitigate these potential complexities and difficulties, the available languages should share a common infrastructure and/or be well integrated. It is the authors’ opinion that a strategy that allows CPG authors to choose the languages that are fit for purpose and aligns with the target knowledge types is required. As a method to address complexity, separation of concerns (SoC) addresses these difficulties by dividing the domain knowledge into smaller, logically cohesive and decoupled languages.¹⁴ Keeping this in mind, the authors prefer to leverage generalized cross-industry efforts utilizing the SOC approach for developing a family of languages.¹⁵ These efforts take advantage of shared development and knowledge leading to best of breed and potentially better-rationalized modeling languages. Furthermore, using languages that are cross-industry has a broader appeal for uptake and will encourage tool development.

Standards such as FHIR, CQL, CDA, CDS-Hooks, and SNOMED are further examples of DSLs used to articulate various knowledge types such as process, decision logic, event condition action (ECA) rules, assertions, and semantics. BPM+ provides three domain-independent languages that focus on expressing process, decision and case knowledge. The assessment of healthcare DSLs’ ability to express clinical knowledge is often subjective.¹⁶ As quantitative features of a modeling language, Domain and Comprehensibility Appropriateness (DCA) provides a system of properties by which the quality and fitness of a language to express knowledge can be measured.¹⁷ The authors discuss a framework and methodology for the identification of knowledge constituents in a CPG and the constituents' respective transformation into Business Process Model and Notation (BPMN)18, Decision Model and Notation (DMN)19, and Case Management Model and Notation (CMMN)20 to express process knowledge, decision knowledge, and case knowledge. Further, with the mapping of the CPG to BPM+, DCA quality measures can be applied to assess the semantic translation. In addition to assessing the quality of a language, the authors will discuss how the framework assists in the identification of ambiguity & omissions and supports the translation from one language to another.

In September 2019 the Business Process Management for Health (BPM+ Health) initiative was officially established under the auspices of the Object Management Group (OMG). OMG is an international, cross-industry standards development organization who standards include the Unified Modeling Language (UML)²¹, BPMN, DMN, and CMMN. The primary charter of BPM+ is to establish a knowledge ecosystem focused on improving national and international health by leveraging open and available industry standards for the disambiguated and concise representation of clinical knowledge. Several of the authors were intimately involved in the development of these standards and with establishing BPM+ Health; Dr. Soley is CEO of OMG, Mr. Lario was an OMG Board member for over 10 years, co-chairs OMG Healthcare, and is Director of Methodologies and Standards at BPM+ Health, Dr. Kawamoto is also a Board Member of the collaborating Health Level Seven International standards development organization, and Dr. White is a co-author of BPMN and contributed to CMMN and DMN.

Here the authors describe a framework and methods for systematically deconstructing a clinical practice guideline and the re-rendering of the clinical knowledge utilizing the existing standards within BPM+ Health. The authors explore the efficacy of the OMG’s BPM+ family of languages to express process, event and decision clinical knowledge as a means to facilitate a standards-based expression of clear and disambiguated clinical knowledge.²² The proposed framework: 1) utilizes the strengths of conceptual and meta-modeling for the classification of knowledge constituents in a CPG, 2) facilitates rendering of these constituents in BPM+, and 3) enables the assessment of the CPG and BPM+’s DCA.²³ To this end, we introduce and utilize a construct-concept framework and OMG’s meta-knowledge levels to manage the separation of concerns between knowledge types, mappings, and levels for the deconstruct and rendering of clinical knowledge in BPM+ languages.^24,25 This framework provides a repeatable systematic method for semantically grounding the knowledge constructs.²⁶ As part of the methodology, the authors utilize Guizzardi construct-concept framework to establish the CPG authors’ conceptual knowledge (Figure 1. Conceptual Construct Framework).²⁷ Finally, the authors combine the framework with meta-knowledge levels to manage the separation of concerns (SOC) between languages and knowledge types.^28,29 This pattern underpins the identification and partitioning of the clinical knowledge into the modeling languages used by the CPG authors and the transformation of the CPG language(s) constructs into the BPM+ representation.

Figure 1.

Conceptual Construct Framework

Methods

The American College of Obstetricians and Gynecologists’ (ACOG) “Assessment and Treatment of Pregnant Women With Suspected or Confirmed Influenza” was selected to provide a focused and clinically accepted body of clinical knowledge for the evaluation of the framework and BPM+ methods.³⁰ In order to successfully model this CPG, we needed a conceptual framework for making sure that the clinical concepts and processes of evidence-based medicine (EBM), as represented in the narrative CPG, would be accurately translated into the model. Guizzardi has expressed a framework for construct mapping that describes the separation and interrelationships of modeling languages, clinical concepts, EBM in general, and the specific instance of a CPG.³¹ The fidelity of the CPG created depends on the “fitness” and DCA of the modeling language to represent the conceptualizations held by the authors and the ability of the authors to transform their concepts into the target modeling language constructs.³²

Clinical knowledge present in a CPG consists of rules, situational data, sequence of actions, complex decisions, directives, and event definitions.³³ Addressing the complexities found in clinical knowledge, the criteria or principles of the partitions should be applied to the viewpoints of the types of knowledge present.^34,35 Once the partition types are identified, the selection and application of the appropriate modeling language can be identified.³⁶ It has been shown in the literature that a CPG contains models of declarative and/or imperative knowledge.³⁷ The declarative knowledge can be broken down into situational data, rules, semantics, and event-condition-action (ECA) knowledge. Imperative knowledge within a CPG conveys process, sequencing, and temporal constraints. In this paper, we demonstrate the alignment and coverage of these knowledge types with the BPM+ family of modeling languages.

There are many factors that can impact the quality of the CPG.³⁸, including the quality of the underpinning study or trial, the domain knowledge of the authors, and their methods for articulating the CPG. A reader of a CPG assesses the constructs in the CPG and creates their own respective construct-concept tuple bindings (their understanding). Potential misunderstandings can result if the reader and the author do not share the same conceptual space or language construct-concept bindings. In addition, the quality of the CPG is directly impacted by the (modeling) language’s suitability to represent the conceptual domain of the CPG.²³ The CPG authors’ ability to articulate clinical recommendations and the readers' comprehension thereof is a product of the modeling languages’ DCA. Whereas the readers’ understanding is hampered by the presence of DCA deficiencies’ construct overload, construct excess, construct redundancy and/or construct deficit. These factors point to ambiguity and omissions by the CPG authors.³⁹ At best they lead to wasted resources and poor quality of care, at worst they lead to patient harm.^40,41

By using this conceptual framework, we had our process for translating the ACOG CPG into BPM+. This consisted of 3 major activities: 1) CPG Language and Construct Identification and Deconstruction, 2) Language Construct-Concept binding, and 3) BPM+ Concept-Construct binding and BMP+ rendering.

Language and Construct Identification and Deconstruction.

Harnad’s “Category Induction and Representation” framework was loosely used to guide and direct the identification of respective modeling languages present in the CPG.^42,43 We further used Barsalou’s perspective system to identify the modeling languages’ Color, Graphical (Spatial), and Natural Language in the ACOG CPG.⁴⁴ These systems were reviewed with ACOG clinicians for clarity and served as the major categories for delineation and categorization of the respective modeling language constructs.

Initially, the authors inventoried all the constructs for each of the modeling languages present in the CPG, treating each construct occurrence as unique within its context. This inventory was reviewed with ACOG clinicians to ensure completeness and coverage of the constructs present in the CPG. 207 language constructs, for example, ‘Red’, ‘Cough’, and ‘Box’ were identified across the three modeling languages (Color, Natural Language, Graphical) as previously identified.

Language Construct-Concept binding.

The medical ontologies RxNorm⁴⁵, SNOMED⁴⁶, and LOINC⁴⁷ were used to bind each identified language construct to a reference terminology for example (‘Red’, 103391001 |Urgency (qualifier value)) and (‘Cough’, 49727002 |Cough (finding)), creating a collection of construct-concept tuples representing the CPG authors’ conceptualization of the CPG.

During the first phase of binding, a preliminary candidate list of construct-concept binding to SNOMED, LOINC, and RxNorm was created. Subsequently, each construct-concept tuple was subjectively reviewed with clinicians for the construct-concept tuples’ relative atomicity and decomposability within its respective frame of discernment.⁴⁸ Once the entire construct-binding process was completed and approved the tuples were reviewed and further classified as either an Activity (Observing, Intervening, Assessing), Rule, Flow, or Finding. The graphic constructs (boxes and arrows) that are spatially oriented across the page within the CPG were reviewed with clinicians to determine the constructs’ purpose and their clinical significance. It was agreed that boxes as a construct would be bound to the initial high-level SNOMED concept ‘71388002 |Procedure (procedure)’ and arrows as a constraint of the sequencing of procedures. The activity that is the source of the arrow must be completed before the activity that is the target of the arrow can be performed; semantically this is a dependency that the second activity has that the first activity is completed.

cOne method identified in the CPG was to express clinical recommendations through the combination of graphical boxes containing simple statements such as “cough” or “runny nose”. It is left to the reader to infer that these are potential findings as a result of engaging in some observations. In addition, the exact observations and range of potential values and findings for each clinical observation is also left for the reader to infer. Further investigation during the construct-concept binding phase review with clinicians revealed that the boxes were also meant to communicate the activity of assessment. During the interviews with clinicians, it was ascertained that the boxes represented a collection of complex construct-concept tuples. The squared boxes in the CPG and their respective content were meant to communicate that the task of making an Observation(s) was to be performed by the clinician and a value recorded (examples of construct deficit and overload). Further, a clinical rule is applied to the observation and respective values to be assessed asserting a new clinical Finding(s). These findings, in tandem with the implied observation(s), can be aggregated into a compound observation. Where this compound observation is then Assessed using a rule or clinical algorithm creating yet another new finding. Based upon this new finding, the CPG Branched accordingly progressing to the next procedure of either making a new observation or performing an Intervention. This pattern continues to repeat: Observations that are Assessed resulting in Findings followed by a respective Branch inflow into either a subsequent Intervention or Observation (Figure 2. Observation Assessment Finding (OAF) Pattern).

Figure 2.

Observation Assessment Finding (OAF) Pattern

Next, we assessed the tuples for missing elements using the aforementioned pattern to infer potentially missing constructs and their respective concepts. This stage of knowledge explication was supported by the fact that SNOMED explicitly contains upper concepts “363787002 |Observable entity (observable entity)” and “404684003 |Clinical finding (finding)” and LOINC with Clinical and Lab Observation tuples. As such, constructs bound to concepts subsumed by these upper concepts can be explicitly classified as an Observation or Finding. For example, the construct ‘Fever’ which was bound to the SNOMED concept “386661006 |Fever (finding)” is a construct-finding tuple. The pattern highlights that the clinical knowledge of an observation-bound-construct is always conceptually paired with a finding-construct in a CPG. As such, the presence of a finding or observation construct not paired with an explicit conjugate implies that a construct is missing. Applying this to our list of (construct, concept) finding tuples, the conjugate construct-concept observations were delineated and added. For example, the presence of the (Fever, 386661006 Finding) resulted in the tuple (“What is the patient’s temperature?”, 8310-5 Body temperature) being added. Further, the presence of an observation-find pair implies the task of making the observation. As such, (Task, 268984004 |Examination of fever (procedure)) was added. This step added 38 new construct-concept tuples not explicitly stated in the CPG.

BPM+ Concept-Construct binding and BMP+ rendering.

BPM+ languages contain visual constructs (Box, Arrow, Diamond, etc.) that are bound to concepts in the conceptual spaces Process (Task, Sequence, Gate, etc.), Decisions, and Case. For example, the rounded rectangle graphical symbol is bound to the concept ‘Task’ in the BPMN Specification creating the construct-concept pair (Box, Task). Since each modeling language defines its respective construct-conceptual tuples space, the regions where these conceptual spaces overlap provide integration or conceptual bridging between modeling languages construct-concept tuples. These relations can be used to help direct how construct-bindings inventoried earlier materialize in BPM+ tuples. For example, the concept ‘Task’ is shared between BPMN and CMMN and subsumes the concept ‘71388002 |Procedure’ in SNOMED. As such, the tuple (12 Week Check up, 169712008 |Antenatal 12 weeks examination) is subsumed by the tuple (Box, Task) and the construct “12 Week Check up” materializes in a BPMN model as Box (See figure Language and Specification Meta Levels).

To further manage and level the construct-concept tuples the authors utilized Floridi’s Gradient of Abstraction (GoA) and OMG’s Meta modeling framework.^28,49 Relying on GoA, the authors stratified the (construct, concept) tuples and (concept) into Meta-Meta (M2) and Meta (M1) layers. Where M2 is the family of construct-concept relation and concept tuples for the modeling languages specification (BPMN, CMMN, DMN, SNOMED, LOINC, RxNORM, etc.), M1 contains the (construct, concept) tuple space for expressing medical knowledge utilizing M2 Language tuples. For example, the (Box, Task) tuple as defined at M2 in BPMN language can be used to express the task of performing a ’12 week checkup’ at M1 as the tuples (Box, 169712008 |Antenatal 12 weeks examination) and (12 Week Check up, 169712008 |Antenatal 12 weeks examination), and level M0 is the instance of M1 for the specific patient Avery Drew. (Figure 3. Language and Specification Meta Levels).

Figure 3.

Language and Specification Meta Levels

Using these methods, the authors then reviewed the inventory of M1 clinical construct-concept tuples, adding the corresponding M1 tuples derived from the construct-concept tuples in BPMN, CMMN, and DMN. Ensuring that this new list of BPM+ tuples had a one-to-one mapping to the CPG clinical tuples verified that the CPG authors' clinical guidance was accurately and completely captured and expressed in the new BPM+ models.

Results

Our analysis of the CPG yielded 245 constructs that were distilled into 185 construct-concept pairs capturing 4 major and 34 minor Observation-Finding assessments. These construct-concept pairs were mapped into BPM+ resulted in 1 overarching process model (Figure 2. Influenza Process Model), 4 case models (Figure 3. Clinical Respiratory Observations Case Model) and 4 decision models. The model consisted of 48 Tasks, 6 gateways, and 42 distinct rules in a DMN model. Applying our methods for parsing the CPG to develop corresponding BPM+ tuples exposed weaknesses in the original CPG. First, the authors found omissions (construct deficit) in clinical knowledge as elucidated by the missing conjugates in the Observation-Finding pairs. Further, the authors found instances where the same construct implied two different concepts (construct overload) or multiple constructs implied the same concept (construct redundancy). For example, the constructs expressing respiratory findings are considered at several points in CPG flow. At two points in the process, the construct “Difficulty breathing or shortness of breath” is used, perhaps with a different semantic meaning (subjective vs. objective). Later, the construct “respiratory compromise or complications” is also used. The intent of the CPG authors was unclear with respect to the differences between the phrases "Difficulty breathing or shortness of breath", "Does she have difficulty breathing or shortness of breath?" and "respiratory compromise or complications". If they are semantically equivalent, then they should not need to be repeatedly expressed nor repeated with different constructs (construct redundancy). If they are semantically different, then “Respiratory Compromise” bound to an appropriate finding concept such as (267036007 |Dyspnea (finding|) which then predicates a different Observation, perhaps LOINC’s (86675-6 Shortness of breath in last 7 days). The mapping of multiple concepts to a single construct in the CPG is a manifestation of “construct overload” and leads to ambiguity.⁵⁰ It is potentially the result of “construct deficit” where there is a lack of language constructs to express the desired clinical concept adequately. As a result, the CPG’s authors use near or like constructs to remediate the missing construct-concept tuple. In both cases, construct deficit and construct overload promotes potential ambiguity for the reader.⁵¹

Another important challenge we identified was the ambiguity of concepts. For example, the concept "Obstetric issues (eg, preterm labor)" in the CPG was found to be ambiguous. Is this concept to mean there is a history of obstetric issues in prior pregnancies? Is it specific to the current pregnancy having premature labor, or just generalized issues (False labor, other obstetrical issues)? Our conclusion was that the concept was to mean Premature labor, and was coded as "289733005|Premature uterine contraction (finding)". Misinterpretation of this concept could lead to inappropriate application of the guideline and its erroneous implementation within a CDS system.

Summary of Findings.

We have demonstrated a method to translate a CPG, explicitly and clearly articulate care processes, decisions and the supporting clinical data, and integrate these parts into a functional application. The method provides an integrated means to clearly and pedantically describe the clinical information. The resulting application was semantically clear, complete and unequivocal. Providing such a method will not only improve quality of care and reduce errors, but will also make the guideline more shareable, verifiable for completeness and accuracy, maintainable as the supporting clinical knowledge evolves, and potentially directly operational.

23 construct-concept pairs did not readily map into the existing BPM+ languages. For example, the tuples (ACOG Authors, 37920003 |Author (occupation)) and (Date of Publication, 410671006 |Date (attribute)) in the CPG were deemed to convey meta-knowledge about the creation of the CPG, not clinical knowledge. Therefore these tuples were excluded from the final BPM+ models. Where BPM+ provided the appropriate Process, Case and Decision constructs, some tuples were either difficult or not possible to clearly express. For example, the authors found it difficult to express a consistent data model across the three languages due to differences in how data is defined and utilized by those languages. Complex data patterns, for example, expressing medical orders such as ‘Oseltamivir (Preferred) 75-MG PO Twice per day for 5 days’ as a (423880009 |Medication coordination/ordering surveillance (regime/therapy)) were difficult to express with clear construct-concept tuples. In addition, the authors identified, albeit abstract, a collection of implied construct-concepts tuples concerning the organization and packaging of the knowledge in the CPG. Further, although not explicitly expressed in the CPG, construct-concept tuples regarding quality measures and the physical environment under which the CPG was to be considered and applied were identified during interviews with ACOG clinicians. What are the required qualifications, for example (442867008 |Respiratory therapist (occupation)|) of the care providers and what physical setting should the CPG be implemented? Is (39216000 |School infirmary (environment)) an appropriate setting for the delivery of care for the CPG? How should the delivery of the CPG be measured? Although not supported by BPM+, the authors believe these are important concepts requiring new languages that would impact comprehensibility, uptake, and confidence of users of a CPG.

Translating CPGs into artifacts that can be consumed by various platforms and generate identical outputs over a range of clinical scenarios is an important component of CDS development. Delivering quality care and being able to measure that quality is essential to improving value in our healthcare system. Having a way to bridge the gap between coders and clinicians, and generate artifacts that can be consumed by vendors is an important advancement. This project demonstrated that BPM+ can be used to describe CPG content with clarity and consistency that is a dramatic improvement over existing methods. Further, these methods have computation semantics, as such the model can be validated, tested and executed.

BPM+ languages are supported by well-defined semantics and supporting documentation, as opposed to the variety of custom-drawn flowcharts that are typical of current CPGs. Thus, the authors found that once learned by Clinicians and SMEs, all BPM+ models applied to CPGs were readily understandable.

As a result of this effort, we identified specific areas where the CPG could be improved. Clarity surrounding both the constructs (Obstetrical Issues, Respiratory compromise) and process flow (When to send the patient emergently to the hospital) were identified and sent back to ACOG for consideration in their ongoing process of CPG revisions.

Discussion

While much attention has been paid to the methods and standards for the development of CPGs, there has not been as much effort to standardize the specific content and format of the CPG itself. The "Standards for Developing Trustworthy Clinical Practices Guidelines" Standard 6 Articulation of Recommendations states, "Recommendations should be articulated in a standardized form detailing precisely what the recommended action is, and under what circumstances it should be performed". Further, it states that "Strong recommendations should be worded so that compliance with the recommendation(s) can be evaluated."(2) However, there is no standardized format for representing this clinical knowledge in a clear, unambiguous, reproducible and actionable manner. As our analysis exemplifies, semantic ambiguity and logical errors may hamper correct implementation of a guideline, but modeling them with this process can expose those gaps. Complex and nuanced concepts that are not adequately explicated potentially reduces the appropriate application of the CPG and potentially could lead to harm.⁵² All paths, workflow, and decisions should be explicitly stated.⁵³ This would of course preferably be done by creating CPG authors, prior to the guideline being published.

With the goal of promoting quality of care through the standardization of delivery, continuity, and coordination of care, it has been shown that CPG can improve consistency in delivery and improve clinical outcomes for patients.^54,55 However, there are many factors that can contribute to the ‘quality’ of a CPG, which can impact their uptake, delivery, and use by the healthcare community.¹⁶ One such factor is the quality (domain appropriateness and comprehensibility appropriateness) of the language(s) used by the CPG’s authors to express the clinical recommendations.^39,56 We define quality as the ability to completely, soundly, clearly, concisely, and unambiguously express a clinical recommendation in such a way as the reader fully comprehends the articulate knowledge without the CPG authors’ intervention or remediation. The quality of the language underpins the level of semantic interoperability between CPG and a reader’s comprehension.⁵⁷

Future Direction.

Several issues were encountered in the development of the BPM+ models. First, although the three methods were jointly developed under the OMG’s Business Modeling & Integration (BMI) Domain Task Force (DTF), they are not fully integrated nor do they share a consistent common underlying meta-model in the treatment of data for example. It’s the authors’ opinion that the OMG should engage in a harmonization effort to address the weak integration of the treatment of data across the existing methods.

Further, the existing methods do not provide a standard mechanism for associating clinical concepts to the BPM+ modeling constructs (terminology binding). For example, a task could be added to our model expressing the medical activity of an “Exam of 7 Month old”, but there is no clear way to explicitly bind our BPMN User Task to the clinical concept “170309003 |Child 7-month exam (procedure)” in SNOMED directly in the model; the BPMN specification meta-model does not account for semantic binding. It is the authors’ opinion that remediating the BPM+ languages at their M2 specification is required and would be of significant value.

The authors found that the existing family of BPM+ modeling languages provide extensive coverage of CPG construct-concept tuples when expressing Process, Decision, and Case clinical concepts. However, in some cases the authors found it challenging to associate some construct-concept tuples utilizing the existing BPM+ languages. Beyond BPM+, the authors found that there was a natural cohesion and grouping of these outlying tuples into three logical groups. Relying on the SOC principal, the authors identified these groups as Knowledge Packaging (KP) constructs, Pedigree and Providence (PP) constructs, and Situation Data (SD) constructs. Constructs that addressed meta-data about “when”, “where” and “how” the CPG should be used were classified KP constructs. Constructs associated with the CPG authors, document version, metadata concerning supporting clinical evidence that underpins the CPG and the creation of the CPG were classified as PP constructs. Although the existing BPM+ standards offered support for the articulation of assertional data, it was deemed that a richer integrated meta-model for expressing the data utilized or created in the BPM+ models is required. Constructs that fell into this latter category were classified as SD constructs. It is the author’s position that these three categories predicated the need for new modeling languages and encourage future development, extending the BPM+ family of standards accordingly.

Further, the Observation-Intervention pattern identified should be integrated at the M3 level in these new emerging modeling languages to include constructs such as Effects, Goals, and Measures. Presently, these constructs are not available, and it is the authors’ opinion that unnecessary effort was required to express these medical concepts in the BPM+ model. Finally, the framework utilized to deconstruct and reconstruct the BPM+ models provides the foundation for systematically and quantitatively assessing the quality of the modeling languages.^58,59 The domain and comprehensibility appropriateness of a modeling language, for example, FHIR can be assessed for its efficacy to express clinical knowledge.^60,61

Conclusion

Using BPM+ and the described methodology and framework to describe a CPG provides a standardized, shareable, computable artifact that leaves little room for misinterpretation or ambiguity. To improve the representation and reuse of clinical knowledge within CPGs, the authors recommend the use of BPMN, DMN, and CMMN as a standard way to represent a process, decision and case knowledge in clinical practice guidelines. These standards provide a unified means of describing clinical processes in a clear and precise manner. They provide a graphical representation to improve communication and understandability for all stakeholders involved in creating, reviewing, using and implementation of CPGs. CPG authors and subject matter experts (SME) can use the same tools as the software engineers tasked with integrating the CPGs into functional applications. If vendors and application developers also agree to accept this format as a standard, then CPGs will be able to be incorporated into various platforms in a standardized way, which can hopefully result in higher quality care.

Acknowledgments

Authors have no potential competing interests to declare.

Figures & Table

Figure 4.

Influenza Process Model

Figure 5.

Clinical Respiratory OAF Case Model