The Business Process Management for Healthcare (BPM+ Health) Consortium: motivation, methodology, and deliverables for enabling clinical knowledge interoperability (CKI)

Abstract

Objectives

To enhance the Business Process Management (BPM)+ Healthcare language portfolio by incorporating knowledge types not previously covered and to improve the overall effectiveness and expressiveness of the suite to improve Clinical Knowledge Interoperability.

Methods

We used the BPM+ Health and Object Management Group (OMG) standards development methodology to develop new languages, following a gap analysis between existing BPM+ Health languages and clinical practice guideline knowledge types. Proposal requests were developed based on these requirements, and submission teams were formed to respond to them. The resulting proposals were submitted to OMG for ratification.

Results

The BPM+ Health family of languages, which initially consisted of the Business Process Model and Notation, Decision Model and Notation, and Case Model and Notation, was expanded by adding 5 new language standards through the OMG. These include Pedigree and Provenance Model and Notation for expressing epistemic knowledge, Knowledge Package Model and Notation for supporting packaging knowledge, Shared Data Model and Notation for expressing ontic knowledge, Party Model and Notation for representing entities and organizations, and Specification Common Elements, a language providing a standard abstract and reusable library that underpins the 4 new languages.

Discussion and conclusion

In this effort, we adopted a strategy of separation of concerns to promote a portfolio of domain-agnostic, independent, but integrated domain-specific languages for authoring medical knowledge. This strategy is a practical and effective approach to expressing complex medical knowledge. These new domain-specific languages offer various knowledge-type options for clinical knowledge authors to choose from without potentially adding unnecessary overhead or complexity.

Introduction

The quality of a language(s) used to author clinical knowledge in Clinical Practice Guidelines (CPGs) can significantly impact the effectiveness of Clinical Knowledge Interoperability (CKI) and ultimately affect the quality-of-care delivery.^1–3 This pivotal role of language in conveying knowledge is not exclusive to healthcare; its significance permeates numerous fields, emphasizing the universal challenge of effective knowledge communication.

Building on this premise, the conventional approach of expressing clinical knowledge predominantly through narrative text and supplementary materials reveals certain shortcomings, especially when emphasizing knowledge interoperability.^4,5 Domain-specific languages (DSLs), such as Arden Syntax, emerge as potential solutions, offering a more structured and precise methodology to express clinical knowledge, thereby improving the quality of knowledge representation and sharing.⁶ Boxwala’s framework⁷ offers a helpful way to understand the spectrum of specificity in language according to 4 levels of knowledge representation, from narrative to highly structured languages like Arden Syntax, which are optimized for the specific needs of the clinical knowledge management domain.

Some DSLs, like Clinical Quality Language (CQL)⁸ and Decision Modeling and Notation (DMN),⁹ prioritize simplicity and efficiency in expressing medical knowledge and are focused exclusively on query and decision-type knowledge, respectively. As an example of separation of concerns, their focus helps manage the complexity by targeting one dimension of medical knowledge. Still, they lack the expressiveness to support other types of knowledge, such as epistemic (meta-knowledge) or ontic (facts about the world). On the other hand, some complex DSLs may favor a single integrated language, providing a breadth of expressiveness that covers a fuller range of knowledge types. For example, Fast Healthcare Interoperability Resources (FHIR)¹⁰ attempts to cross multiple knowledge types, including process, ontological (concepts that are grouped and organized by their types and relationships), epistemic, and messaging semantics.¹⁰ Where it provides some capability to express process knowledge, FHIR lacks the domain appropriateness¹¹ present in Business Process Model and Notation (BPMN),¹² a language for this knowledge type. Having one language to fulfill all requirements for expressing medical knowledge can be challenging and result in a ponderous language that becomes rigid in the face of change as complexity grows. However, having only a highly focused DSL such as RxNorm,¹³ which provides declarative knowledge on medications, or Clinical Decision Support Knowledge Artifact Specification (CDS-KAS), which provides constructs for event-condition-action rules,¹⁴ is problematic as well. These concerns led us to pursue a strategy of a family of independent but integrated DSLs where authors of medical knowledge can pick and choose languages that are knowledge-type specific as needed and are designed to work together.

The field of Systems Engineering offers design principles that may help address these complexities.¹⁵ These principles promote a modular design for knowledge interoperability, breaking down knowledge into smaller, self-contained DSLs that can be designed, tested, and used independently or collectively.¹⁶ Further, these methods advocate for building a layered and orthogonal family of solutions that allow hierarchical decompositions of clinical knowledge—providing the perspective of clinical knowledge as an integrated family of knowledge types, with each DSL supporting a specific kind and connecting with others.¹⁷ Following these principles in developing DSLs may reduce complexity and make solutions more straightforward to manage and extend over time.

BPM+ Health: vision and design principles

The Object Management Group (OMG), an international Standards Development Organization (SDO), launched the Business Process Management for Health (BPM+ Health) initiative in September 2019.¹⁸ OMG develops standards such as the Unified Modeling Language (UML),¹⁹ Business Process Model and Notation (BPMN),¹² Decision Model and Notation (DMN),⁹ and Case Management Model and Notation (CMMN).²⁰ This community initially adopted the 3 OMG specifications, BPMN, CMMN, and DMN, to support Clinical Knowledge Interoperability (CKI).²¹

The BPM+ Health community is dedicated to comprehensive medical knowledge management, emphasizing clinical knowledge interoperability as central to positive patient outcomes. The community’s focus spans the entire process and lifecycle, from creating and authoring specialized languages for curating medical knowledge to its uptake and application at the bedside. The organization intends to carefully coordinate perspectives, concepts, and relationships across all related artifacts, and the community aims to foster seamless integration and use of medical knowledge to enhance patient care and outcomes.

At the outset of BPM+ Health, Lario and colleagues evaluated the use of the 3 initial cross-industry languages concerning their ability to represent process, case, and decision knowledge in a clinical practice guideline (CPG).²² Their analysis revealed deficiencies in the original language portfolio regarding its capacity to express several types of knowledge within a CPG.^23,24 In this manuscript, we (1) describe the methods employed to define 4 new languages to fill the identified gaps, (2) outline how these languages can be used to represent clinical knowledge, and (3) discuss implications, limitations, and future directions. This manuscript aims to report and describe the innovation of several emerging DSLs that may apply to the expression of clinical knowledge, their interoperability, and the methods employed to develop these DSLs.

Methods

Design principles

The new languages were developed based on separation of concerns, cohesion, and loose coupling principles. These languages are designed to be organized, layered, and generalized to improve clarity (Table 1). The focus is on ensuring necessary and sufficient conditions for properties such as interoperability, traceability, accuracy, precision, composability, understandability, and modularity across the different curation phases.²⁵

Table 1.

BPM+ Health design principles are used to address the complexity associated with the development of languages to express knowledge.

Principle	Description
Separation of concern	Separate components for different aspects of a healthcare system, such as patient registration, billing, or medication management.
By separating the different concerns or aspects of a system, such as a language (lexicon and syntax), knowledge (concepts and semantics), and things in the world, it becomes easier to manage and maintain the complexity. It supports changes or additions to one part of a complex system without affecting other parts. This can help ensure that various types of clinical knowledge can be represented, evolved, and more readily related to different knowledge types as the knowledge accretes.26
Loose coupling	Standardized interfaces or APIs allow the systems to communicate without being directly dependent on each other.
Ensuring that the different knowledge types, their representations, and their use are independent and not tightly dependent on one another makes it easier to extend, update, and use the family of languages as needs change without significantly affecting pre-existing.27
Abstraction	Clinical data from a patient’s medical records is represented in a structured format that can be easily accessed and analyzed.
By using abstraction, the complexity of knowledge types, their respective representation formalisms, and the knowledge authored is reduced by hiding unnecessary details, thus exposing and focusing only on the necessary aspects. Reducing extra details can help ensure clinical knowledge is authored consistently and accurately.28
Layering	The data layer may be responsible for the storage, and the user interface layer is responsible for data presentation.
The knowledge types and reifications can be separated into different layers, each with a specific purpose and functionality. This can help reduce complexity, focusing the knowledge explication efforts on the authoring process to improve accuracy and ease of capturing clinical knowledge.29

Language quality and evaluation criteria

First introduced by Wand and Weber and later refined and elaborated by Gurr and Guizzardi, the principles of Domain and Comprehensibility Appropriateness (DCA) (Table 2) were employed in the DSLs’ evaluation and development.^30–33 These principles provide a means to objectively evaluate the quality of the DSLs for completeness and soundness against the conceptual space. In this context, “quality” refers to the capacity of a language (as outlined in the RFP) to express a clinical recommendation in a way that is complete, sound, clear, concise, and unambiguous, allowing a reader of clinical knowledge expressed with a DSL under study to fully grasp the conveyed knowledge³⁴ without needing intervention or clarification from the CPG authors. The emphasis is placed on 4 fundamental properties—Lucidity, Soundness, Laconicity, and Completeness—establishing demonstrable quality features between the Representation (constructs) and Knowledge (concepts).³⁵ These quality principles were used to guide the development of the DSLs and evaluate their efficacy—as specified in the RFP—to promote the development of high-quality languages. They are used by the OMG’s domain Task Force and Architecture Board to evaluate whether a DSL is suitable for adoption and publication.

Table 2.

Quality principles for evaluation of domain-specific languages.

Quality principle	Formal definition	Significance and explanation
Lucidity	Modeling Language (ML) is called lucid with respect to a Conceptualization (C) if a representation mapping from C to ML’s Constructs is injective. A mapping between C and ML is injective if and only if every entity in the ML represents at most one (although perhaps none) entity of the model ML. Violation of this tenet leads to Construct Overload.	When a single term or concept within a language is burdened with multiple meanings or functions, it can cause confusion and misinterpretation, as the context may not always make clear which specific meaning is intended. In medical terms, a single word or phrase describing several conditions or procedures might lead to misunderstandings between healthcare professionals or incorrect medical coding.
Soundness	Modeling Language (ML) is called sound with respect to a Conceptualization (C) if a representation mapping from C to ML’s Constructs is surjective. A representation mapping from C to ML is surjective if and only if the corresponding interpretation mapping from ML and C is total, that is, if and only if every entity in the ML represents at least one entity of model C (although perhaps several). Violation of this tenet leads to Construct Excess.	When a language has more constructs (terms or symbols) than necessary to express ideas within a particular domain, the constructs are superfluous and do not add expressive power. An excess of constructs can make the language cumbersome and complex, leading to difficulties in learning and using the language. In healthcare, too many specialized terms for a particular concept might make communication less efficient and more prone to error.
Laconicity	Modeling Language (ML) is called laconic with respect to a Conceptualization (C) if the interpretation mapping from ML’s Constructs to C is injective, that is, if and only if every entity in the model C is represented by at most one (although perhaps none) entity in the representation ML. Violation of this tenet leads to Construct Redundancy.	When multiple constructs within a language serve the same purpose or express the same concept, redundancy can lead to inconsistencies and make the language more challenging to learn and maintain. For example, having multiple medical terms that mean the same concept might confuse the documentation, leading to potential issues in patient care.
Completeness	Modeling Language (ML) is called complete with respect to a model Conceptualization (C) if an interpretation mapping from ML’s Constructs to C is surjective. An interpretation mapping from ML to C is surjective if and only if the corresponding representation mapping from C to ML is total, that is, if and only if every entity in a model (instance of the domain conceptualization) is represented by at least one (although perhaps many) entity in the representation ML. Violation of this tenet leads to Construct Deficiency.	The ideas cannot be communicated when a language lacks the necessary constructs to express all relevant concepts within a domain. If a language doesn’t have the terms or structures needed to describe specific ideas or processes, it can limit the ability to communicate or document the knowledge accurately. In medicine, a deficit in terminology might hinder the ability to describe a clinical action or observation, potentially impacting patient care.

Approach to developing and evaluating new languages

Figure 1 provides an abstract top-level view of the steps to create and evaluate the new specifications. These steps are central to the OMG standards development process and are described in greater detail in OMG’s “Modeling Language Standards.”^36,37 The OMG process guides the development and approval of specifications through multiple iterative stages, culminating in an “Approval and Adoption.” During this phase, the specification undergoes thorough review, evaluation, and voting to advance its acceptance. Submissions are subject to scrutiny and must be defended in front of the relevant OMG committees and membership. The proposal can be questioned during this stage, and further modifications can be suggested. Once a proposal has been satisfactorily revised and defended, it is put to a vote by the relevant OMG Task Force. If it passes this vote, the specification is moved to the OMG’s Architecture Board, where it is reviewed, defended, and voted on for adoption; upon passing this vote, the specification is adopted as an official standard. With several authors’ leadership, these new languages were created through this collaborative partnership between industry experts, vendors, and end-users.

Figure 1.

Methods sequence, activities, inputs, and outputs for the development of domain-specific languages at OMG.

The steps taken to identify and develop the new languages (Figure 1) are as follows.

Step 1: Identify deficiency to express clinical knowledge

Building upon earlier work by Lario et al.,²² The Methodology Working Group of BPM+ Health identified weaknesses in BPMN, CMMN, and DMN to express concepts in CPGs.³⁸ These deficits were classified into declarative, epistemic, and structural knowledge types, forming the basis for new language support requirements.³⁹ The paper identified weaknesses in BPMN, CMMN, and DMN for expressing concepts in CPGs.

Step 2: Develop a request for proposal

The Healthcare Domain Task Force (HDTF) reviewed the language requirements from Step 1 and established teams to develop Requests for Proposals (RFPs),⁴⁰ as delineated in Table 3. Weekly meetings were held to ensure the RFPs were complete and sound, and they were presented and defended at quarterly Domain Task Force (DTF) meetings. The DTF assessed the RFPs and voted to promote them for consideration by the Architecture Board (AB). Once promoted, the RFPs were presented to the OMG Architecture Board (AB) and formally approved for distribution to relevant communities to solicit responses.

Table 3.

List of requests for proposals (RFP) Submitted to OMG.

RFP	Submission date
Pedigree and Provenance Model and Notation (PPMN)41	12/08/2020
Shared Data Model and Notation (SDMN)42	03/14/2021
BPM+ Knowledge Package Model and Notation (KPMN)43	03/21/2021

Step 3: Formulate a response to RFP

Submission teams were formed for each approved RFP and followed the methodology outlined in “OMG Modeling Languages Standards.”³⁷ Weekly meetings were held to develop technical responses to the requirements. Each team developed a Platform Independent Model (PIM) describing the high-level constructs and concepts. This inventory of construct/concept pairs was iteratively and incrementally tested for compliance against DCA criteria as defined in Table 2. This model contained each DSL’s syntax, lexicon, and semantic definition. Finally, the teams used OMG’s “RFP Response Template”⁴⁴ to develop and submit their final response.

Step 4: Approval and adoption

Each specification presented underwent an iterative review process by the domain Task Force and the membership at large. This process was structured to enhance the specification through multiple rounds of defense and peer reviews, during which the specification was refined based on objective feedback, expert evaluations, and collaborative input.

For each DSL, these compliance checks were conducted against the principles described in Table 2. Using the PPMN DSL as an example, all 121 constructs underwent thorough scrutiny. Each construct was verified to correspond to a unique PMMN concept, adhering to the “Lucidity and Construct Overload” principle. In a parallel manner, every PMMN concept was assessed to ensure that it was represented by only one construct, demonstrating a commitment to the “Laconicity and Construct Redundancy” principle.

After adjustments were made in response to comprehensive feedback, the specification was submitted for a vote within the Task Force. Advancement past this phase was achieved with a successful vote, affirming that the specification met the DCA criteria (in the context of the RFP) and merited further consideration by OMG’s Architecture Board.

Further, each specification was subjected to another round of detailed review, defense, and assessment at the Architecture Board level. Expert evaluation at this stage focused on ensuring the specification’s further adherence to Domain and Comprehensibility Appropriateness. A positive vote by the Architecture Board endorsed the specification’s alignment with OMG’s quality and interoperability standards, promoting the specification as preliminarily adopted (version 1.0 beta). At this stage, each specification was moved to “Finalization” and was released for public use and comment.

Step 5: Specification finalization

As of the publication date of this manuscript, the finalization process for each DSL has not been completed. This stage is essential to the full development and ultimate ratification of each DSL. Currently, specifications are undergoing the Finalization Task Force (FTF) phase; during this time, they are available for public use and feedback. The FTF actively resolves any reported issues and defects, clarifies any ambiguities, and ensures consistency. Following the completion of this period, the FTF will compile the feedback, make necessary updates to the DSL, and submit the revisions to the Architecture Board (AB) for the approval and release of version 1.0.

Continuous evaluation

The evaluation of each DSL under the OMG framework was rigorous, involving iterative development, peer review, defense, and voting, grounded in the principles of scientific inquiry and assessment through Domain Comprehensibility Appropriateness (DCA) as an objective measure. Each DSL—KPMN, SDMN, PMN, SCE, and PPMN—underwent a process ensuring continual improvement and strict scrutiny. Each candidate specification was tested through peer review, during which it received detailed criticism and suggestions for enhancement, followed by a defense to challenge its theoretical underpinnings and practical utility, and successfully defended proposals advanced to a vote within the relevant Task Force, assessing conformity to established standards. Endorsement by the Task Force led to further appraisal by the OMG Architecture Board, applying DCA criteria to confirm the specification’s alignment with the required quality and interoperability before granting it official standard status. This iterative, peer-driven vetting process underscored the objective, systematic, and community endorsement critical to the standard's adoption and practical application.

Results

Within this research’s scope, 4 specifications were developed for expressing ontic, epistemic, package and manifest, and entity knowledge (Table 4). Further, to augment the versatility and applicability of these specifications, an abstract language library called Specification Common Elements (SCE) was developed and integrated, enabling their reuse in diverse contexts. These specifications were submitted and approved by the OMG.

Table 4.

Newly defined DSLs) to express epistemic, ontic, packaging and manifest, and entity knowledge to support the expression of clinical knowledge present within a clinical practice guideline.

Language	Knowledge type
Pedigree and Provenance Model and Notation (PPMN)45	Epistemic
Knowledge concerning how knowledge is acquired, evaluated, and justified. Knowledge of the methods and criteria for acquiring knowledge, as well as an awareness of the limits and uncertainties of knowledge. Meta-knowledge about knowledge or knowledge about knowledge.
Shared Data Model and Notation (SDMN)46	Ontic
Knowledge about specific facts or concepts. Knowledge about the nature of reality and the properties of objects or entities in the world. Knowledge deals with the existence, identity, and properties of things and is concerned with understanding the fundamental nature of reality.
Knowledge Package Model and Notation (KPMN)47	Packaging and manifest
Knowledge of grouping of knowledge types. Knowledge of how objects or concepts interact with other knowledge types.
Party Model and Notation (PMN)41	Entity
Knowledge of organizational structures of companies, organizations, people, communities, etc. Knowledge of roles they play with respect to each other and the locations where they exist.
Specification Common Elements (SCE)48	Utility library
The shared infrastructure of abstract constructs that are required across other BPM+ Health languages. Support reuse, development, and integration of high-order languages.

The following examples are based on the clinical knowledge found in the “Management of Chronic Kidney Disease” Clinical Practice Guideline of the VA/DoD (CKD),⁴⁹ and further discussion can be found in the associated Supplementary Material.

Shared data model and notation

Knowledge type: Ontic knowledge

Status/version: 1.0 beta

Description

The SDMN language is crucial for supporting other languages by facilitating the expression of a library of data items (ontic knowledge). This DSL allows the sharing of common data information elements across multiple languages, such as BPMN, CMMN, DMN, and KPMN. For example, when modeling the process of delivering care for CDK using multiple languages, common data information elements can be shared across models and languages. This language provides a consistent representation for defining these data objects’ types, structures, and value ranges, as seen in Figure 2. Having a single source of truth saves time for modelers and ensures that updates made concerning ontic knowledge are automatically reflected in the models that use them. However, the SDMN library is limited to the data items required for specific use cases and does not define all data objects for an entire enterprise data model.

Figure 2.

Chronic kidney disease (CDK) shared Data Model and Notation (SDMN) model depicting Data Objects and their respective relationships. Each Data Object contains property definitions and possible values.

When 2 or more languages are used together to create models for a specific topic, particularly in a knowledge package (see KPMN section), many data information elements are shared across the models and languages. For example, a BPMN model might include a Data Object for a “Patient CKD Lab,” and the properties and values of that lab might be used in a DMN model decision table. While the 2 languages might define these data elements slightly differently, they represent the same conceptual object.

Pedigree and provenance model and notation

Knowledge type: Epistemic knowledge

Status/version: 1.0 beta

Description

This specification is designed to create a common terminology for expressing information about the origin, history, ownership, control, status, and potential end of life of a Subject of Interest (SOI). It allows for the expression of meta-knowledge (who, what, when, where, why, and how) about the SOI and provides a way to verify or challenge information about it. The SOI can be a concrete or abstract entity, such as a physical device, person, idea, event, statement or utterance, law or rule, or logical assertion. Different parties may provide conflicting attestations about an SOI over time, and these attestations are not required to be logically consistent.

In addition, the language can be used as is or specialized, creating a unique DSL specific to a Domain of Discourse (DoD). For example, PPMN has the concept of Occurrence Type, which can be instantiated to Patient Interview (Figure 3) to denote that distinct instances of Patient Interviews will occur and they will involve Persons as Patients and Clinicians. Further, Clinical Information Records will be produced by these types of occurrences. This Occurrence Type represents the first activity, Obtain Initial Clinical Information, defined perhaps in a BPMN Model. When PPMN is used for a specific DoD, the relevant constructs are expected to be “wired in,” thus creating a unique DSL for that DoD. The Instance Model (Figure 3) illustrates the DSL defined in the Type Model to show a specific Patient Interview—Bob’s Appointment.

Figure 3.

Chronic kidney disease (CDK) Pedigree and Provenance Model and Notation (PPMN) example showing different observations (statements) types that may be created during a patient encounter.

Other industry standards address parts of this domain, but no open standard currently provides the necessary breadth and flexibility to express this type of meta-knowledge. Moreover, these competing standards do not use a common underlying representational (eg, Meta-Object Facility (MOF) compliant⁵⁰) language and do not integrate seamlessly with the BPM+ Health language suite. W3C PROV,²¹ the most widely used standard in this area, primarily focuses on the lineage of digital artifacts. In contrast, the scope of PPMN encompasses lineage, custody, and ownership of physical and conceptual SOIs.

Knowledge package model and notation

Knowledge type: Package and manifest knowledge

Status/version: 1.0 beta

Description

Knowledge Package Model and Notation (KPMN) provides the capability of packaging and distributing models that work together for a particular topic—hence the name “knowledge package.” Examples of knowledge packages include clinical guidelines for diabetes or antenatal care. Any topic that requires processes, decisions, case management, shared data, pedigree, or provenance is a potential candidate for being packaged and distributed through KPMN. Figure 4 depicts that the CKD CPG requires, among other knowledge artifacts, the DMN model “Does the Patient Have Urgent or Emergent Conditions.”

Figure 4.

Chronic kidney disease (CDK) Knowledge Package Model and Notation (KPMN) model depicting externally defined knowledge models used to collectively express the VA/DoD (CKD) Clinical Practice Guideline (CPG).

This language’s diagramming notation can show how the included BPM+ Health models interact. This visualization can depict the chain of processes, the connections between cases and techniques, and the relationships between decisions and procedures. It provides a holistic perspective that cannot be obtained by examining the individual models alone.

One analogy for KPMN is a cereal box. The box (the package) displays pictures, nutritional value, and general information about the contents (in this case, the models in the package).

Party model and notation

Knowledge type: Entity knowledge

Status/version: 1.0 beta

Description

This specification allows the expression of knowledge about entities such as organizations, people, positions, roles, and locations. These elements can be combined to describe complex organizational structures like multinational corporations or simple roles such as a Nurse and Patient in a healthcare process. The PMN diagram (Figure 5) shows the organizational structure of a fictional Angel Healthcare, including several departments and defined positions such as Clinician, which is additionally referenced in the PPMN (Figure 3).

Figure 5.

Chronic kidney disease (CDK) Party Model and Notation (PMN) depicting the entities and their organizational structure.

PMN can also specify party-related DSLs using Party Types and Location Types. For example, a DSL for party concepts related to healthcare might define Organization Types such as Hospital, Healthcare Network, and Clinic; Position Types of Surgeons and Nurses; and Party Role Types of Provider, Patient, and Guardian. Models based on such a DSL could then be constrained to use only those concepts.

Using the DSL and instance-level elements of PMN enables complex specification of the allowable concepts for a particular area of interest and the specific party-related instances.

Specification common elements

Knowledge type: Common language infrastructure (shared)

Status/version: 1.0 beta

Description

The SCE specification comprises common infrastructure constructs required across other languages: KPMN, PMN, PPMN, and SDMN, which can be shared and reused. The design of SCE was based on examining BPMN, CMMN, and DMN and identifying common concepts. These languages have some differences but are currently under consideration to be updated to take advantage of SCE’s capabilities. Examples of the core infrastructure elements include annotation elements, importing, external relationships, and how language elements are organized (eg, semantic elements in one package and diagram elements in another). SCE is not expected to be used alone but provides a backbone for the other BPM+ Health languages. As of April 2023, the core standards (BPMN, CMMN, and DMN) do not utilize SCE, and they are expected to be updated to include the foundation SCE provides.

Further, defining and reusing common structural elements will simplify vendor implementations by providing a unified infrastructure layer rather than managing details for each standard separately.

Discussion

Clinical knowledge comprises numerous intertwined types and abstractions, such as processes, algorithms, rules, representational statements, assertions of facts, and pre and post-conditions. To address this complexity, BPM+ Health has adopted a strategy of separation of concerns and cohesion, promoting a portfolio of domain-agnostic, independent, but integrated DSLs that medical knowledge authors can select as needed to suit their purpose.^15,51,52 Initially, BPM+ Health adopted BPMN, CMMN, and DMN to manage process, case, and decision knowledge. Subsequently, the portfolio was expanded to include additional types of knowledge, such as epistemic (PPMN), ontic (SDMN), packaging (KPMN), and entity (PMN) knowledge support. BPM+ Health’s approach of adopting and developing a family of integrated DSLs for knowledge representation could improve the quality of clinical knowledge interoperability, which could, in turn, help improve patient care and safety.

Strengths and limitations of the approach

Working with the BPM+/OMG community provided several notable benefits. Firstly, this community, consisting of 38 organizations, brought cross-industry experts, tool vendors, and leaders with significant experience and knowledge in their respective fields. This diversity promoted critical debate and provided various cross-industry insights and perspectives on the latest industry trends, developments, and respective best practices.

In addition, by working within this community, the costs, resources, and effort were shared, making the development effort more accessible and affordable for the individual stakeholders. This shared burden helped reduce participation barriers and encouraged involvement in the process. Further, these organizations brought an increased level of engineering discipline, rigor, and repeatability through established processes and governance. Arguably, diverse critical oversight and participation improved the relevance of these new languages and instilled confidence in their suitability. Further, the iterative and continuous application of the DCA criteria throughout the development process helps reinforce confidence in the fitness of the DSL.

Although the needs of the healthcare community drove the development of these new methods, engaging tool vendors and end-users helped ensure broader applicability and, consequently, may promote tool development. Multiple international tool vendors currently support BPMN, DMN, and CMMN, and they are expected to expand their support to include the new languages. Additionally, BPM+ Health’s collaboration with professional medical societies such as the American College of Emergency Physicians (ACEP) can help ensure that these methods align with the requirements of CPG development organizations seeking to implement them in Electronic Health Record (EHR) systems for clinical use.

Another strength of BPM+ Health’s approach is that they are authored at an appropriate level of knowledge representation. As a part of BPM+ Health’s effort, Lario et al. developed the “Multilayer Metamodel for Representation and Knowledge” (M*R/K) (pronounced “Mark”) framework for knowledge representation.²² The M*R/K framework is a conceptual model (Table 5) that delineates 4 phases in the knowledge lifecycle curation process. Each layer builds upon the knowledge products generated in the previous stratum. For example, BPMN (M2 under M*R/K) is used to author process models classified as M1 artifacts.

Table 5.

Multilayer Metamodel for Representation and Knowledge (M*R/K) framework layers for classifying knowledge representational formalisms.

Name	Phase	Stakeholder	Examples
M0 or ground	Uptake, use, and application of knowledge	Knowledge adopters	The application of the knowledge in a CPG to a specific person.
M1 or domain	Authoring of clinical knowledge	Knowledge authors	Definition of a specific Clinical Practice Guideline (CPG), FHIR resources
M2 or UNIVERSAL	Creation of languages	Language Designers	English (general purpose language), CQL (query knowledge), BPMN (process knowledge), DMN (decision knowledge)
M3 or meta	Creation of meta languages	Language architects	MOF53, KerML54

Each layer’s artifacts are authored using a higher stratum of knowledge of representational formalisms.

The framework provides a well-founded set of terms to facilitate discussions around representational knowledge formalisms, their relationships to other formalisms, and their role and context in clinical knowledge representation. All BPM+ Health languages are appropriately specified at the M2 level and are used by knowledge authors to create M1 specifications. This stratification is not always the case for other standards and can cause issues, as is discussed later concerning some Health Level Seven International (HL7) standards for knowledge representation.

A crucial aspect underpinning the expression and assimilation of clinical knowledge pertains to the intrinsic quality—Lucidity, Soundness, Laconicity, and Completeness—of the methods deployed to articulate evidence-based medical knowledge. A language lacking essential characteristics, such as adequate expressive power, renders itself neither practical nor efficient in the clear, concise, or unambiguous communication of complex medical concepts.

The quality of a language extends far beyond its immediate properties, resonating through the entire chain of utilization. Lario et al. demonstrated this notion, where the quality of a language invariably influences the quality of a specification authored within that linguistic framework.⁵⁵ This impact, in turn, dictates the levels of comprehension and usability achievable with the specification, ultimately impacting its overall adoption rate within the targeted community. Such a cascading effect underscores the importance of language quality in successfully applying and disseminating scientific knowledge, especially within the nuanced field of medical science.

Furthermore, the evaluation principles presented in Table 2 address the extent to which a DSL encompasses the conceptual space detailed in the corresponding RFP. Two pertinent considerations arise in this context: the precision with which the initial RFP captures the conceptual framework and the depth of the author's understanding of the specific domain knowledge they seek to convey. Firstly, any inadequacies in the RFP’s representation of the intended knowledge will manifest as shortcomings in the DSL. In essence, flawed requirements inevitably result in flawed implementations. Secondly, even if a DSL aligns perfectly with the principles outlined, the authors’ limited comprehension of the domain knowledge they intend to convey through the DSL could lead to imprecise, ambiguous, and erroneous representations. In short, the 4 properties—Lucidity, Soundness, Laconicity, and Completeness—are benchmarks for assessing the quality relationship between a DSL and the knowledge type (ie, process, decision, ontic, etc.). These properties specifically focus on the interaction between the language and the knowledge rather than evaluating the quality of the original RFP or the artifacts created using a DSL; evaluation of the efficacy of the DSL remains for further consideration.

Although working within the SDO’s development process was considered advantageous, difficulties were encountered. A significant issue was the time horizon between identifying the need for a new DSL and its ratification, which could take several years. While helping to ensure rigor and multistakeholder input, this deliberative and multistep SDO process could be too long for authors of CPGs who require more timely solutions. Consequently, interim methods that are nonstandard and potentially suboptimal may be chosen by CPG authors. Additionally, the extended development period allows multiple stakeholders with different concerns, sometimes with competing agendas, to enter and depart from the development process, which can be disruptive, require rework, and further lengthen the time needed to produce the standard.

While the BPM+ Health family of languages offers extensive coverage of various knowledge types, others still have not been addressed. Presently, there is little to no support for expressing an authored knowledge artifact’s objective(s), leaving these artifacts potentially underspecified and up to a reader to infer the respective objectives. Further, no support exists to express the known potential outcomes/effects or risks associated with the knowledge artifacts authored, such as the adverse effect caused by a recommended medication. Further, the availability of such metadata in a standardized manner could allow a system to automatically flag contraindicated CPGs, given their known goals and risks. The BPM+ Health languages do not have formal coverage for this type of knowledge.

Application of systems engineering

Using systems engineering principles for developing DSLs brought several critical implications, positively and negatively affecting the process and outcome of developing DSLs. This technique emphasizes structure and modularization, which helped reduce complexity, focus efforts, and improve the quality of the DSLs. However, this rigorous nature could lead to over-engineering, potentially resulting in a convoluted and difficult-to-use DSL. Further, the principles expressed in Table 1 promote quality in the targeted DSLs by enhancing clarity, maintainability, and adaptability. However, achieving these principles in the design of a DSL needs to be balanced with potential undue cost in implementation. While these methods offer substantial benefits in terms of efficiency, quality, and alignment with the requirements of DSL development, they also come with potential challenges and risks that the teams need to manage. The success of integrating systems engineering into DSL development largely depended on the thoughtful application of these methods, considering the unique requirements and constraints during the lifecycle of developing the DSLs.

Relationship to HL7 standards

HL7 has a number of standards for the expression of various types of clinical knowledge. For example, Clinical Quality Language (CQL) is an M2 language and is perhaps most closely related to DMN. From a language perspective, BPM+ languages can be considered visual low-code languages, while CQL is predominantly low code. Although all these languages are low code and user-friendly for subject matter experts, the difference is that BPM+ Health languages rely heavily on drawing pictures.

Although the needs of the healthcare community drove BPM+ Health languages, these languages themselves are industry agnostic, whereas CQL is designed explicitly for healthcare. Being healthcare specific, CQL incorporates various healthcare concepts, such as patients and populations. In contrast, BPM+ Health languages do not inherently possess healthcare-related notions, and these must be incorporated into BPM+ M1 models when needed. Additionally, CQL is more geared toward creating healthcare queries, computing healthcare measures and ratios, and working with HL7 Fast Healthcare Interoperability Resources (FHIR).

In contrast to CQL, HL7’s FHIR resources are categorized as M1 knowledge specifications and primarily represent ontic knowledge at the M0 level. However, there are some instances where embedded epistemic knowledge about the lifecycle of a resource instance at M0 is included in the resource definitions. For example, FHIR’s Medication Request contains properties such as “status,” “statusReason,” and “statusChanged” that aim to capture epistemic knowledge about the lifecycle of the resource instance.⁵⁶

Moreover, in certain instances, FHIR resources can contain multiple types of knowledge at varying levels of abstraction within the same M1 resource (eg, Medication Request’s status) and, in some cases, can completely change their meaning at M0. PlanDefinition⁵⁷ is an example of a polymorphic M1 specification that alters its meaning at M0 based on the value of its “type” property. A PlanDefinition instance at M0 can represent an order set (ontic knowledge), a rule (decision knowledge), or a workflow definition (process knowledge).

In addition to entangling epistemic knowledge directly into the M0 instances, FHIR’s Provenance (M1) provides another means to express lifecycle information.⁵⁸ Communicating epistemic knowledge is beneficial in healthcare settings where there is a need to track patient data's history and lineage (epistemic knowledge) (ontic knowledge). For example, it can be used to trace the source of a particular diagnosis, medication, or laboratory result. It can also support auditing and compliance requirements by recording who accessed or modified a specific resource.

The Provenance and other resources can support a loose sense of authoring by narrowing or repurposing the resources through a process called profiling. This process involves defining specific constraints on the base FHIR resource structures, such as Provenance, to create customized profiles that meet the requirements of specific use cases or contexts. The profiling process starts with identifying the base FHIR resource as the starting point for creating the profile. Then, specific data elements and their associated value sets are selected and constrained according to the use case or context. These constraints may include specifying narrowing data types, reduction in cardinality, subvalue sets, and other requirements. This “authoring” process narrows down the resources in expressivity. While possible to do, this approach to knowledge representation using M1 resources introduces complexity.

BPM+ Health's strategy involves using a family of M2 languages that are independent but work together to define M1 specifications. From a BPM+ Health perspective, SDMN (M2) would be used to create structured definitions of healthcare data, such as the information specified in a Medication Request (M1). PPMN (M2) would then describe how an SDMN definition of a Medication Request (M1) goes through its lifecycle. At the same time, PMN would outline the various roles and parties involved in managing a Medication Request. Then, BPMN (M2) could be used to map out the process and interactions between different parties and resources involved in fulfilling a Medication Request. Once all the M1 definitions are created, KPMN could be used to describe how the M1 specifications depend on each other and how they fit together as one complete set of knowledge to address the fulfillment of a medication request for a patient.

Conclusion

Clinical knowledge interoperability is a complex task that requires a systems-engineering approach to simplify the process. The BPM+ Health community's strategy of curating a collection of independent yet complementary DSLs is a practical and effective solution to the challenge of expressing complex medical knowledge. Using open and well-engineered languages for clinical knowledge interoperability can improve patient care and the healthcare system by providing a broader range of methods for expressing clinical knowledge clearly and concisely. The BPM+ Health/OMG standards development process was successfully used to produce the DSLs PPMN, KPMN, SDMN, and PMN to express epistemic, packaging, ontic, and entities and organization knowledge, respectively. A shared abstract language library, SCE, was additionally created during this effort to support reuse and integration across the family of BPM+ Health languages.

We hope these new formalisms will enhance clinical knowledge interoperability and improve patient care.

Author contributions

Robert Lario, Richard Soley, Stephen White, John Butler, Guilherme Del Fiol, Karen Eilbeck, Stanley Huff, and Kensaku Kawamoto provided:

1. Substantial contributions to the design of the work and interpretation of data.

2. Critically revised the manuscript for key intellectual content.

3. Gave final approval for the version to be published.

4. Agrees to be accountable for the work’s accuracy and integrity.

Supplementary material

Supplementary material is available at Journal of the American Medical Informatics Association online.

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors.

Conflict of Interest

None declared.

Data availability

Title	URL
Business Process Model and Notation (BPMN)	https://www.omg.org/spec/BPMN/2.0.2/PDF
Case Management Model and Notation (CMMN)	https://www.omg.org/spec/CMMN/1.1/PDF
Decision Model and Notation (DMN)	https://www.omg.org/spec/DMN/1.5/Beta1/PDF
Knowledge Package Model and Notation (KPMN)	https://www.omg.org/spec/BKPMN/1.0/Beta1/PDF
Party Model and Notation (PMN)	https://www.omg.org/spec/PPMN/1.0/Beta1/PDF
Pedigree and Provenance Model and Notation (PPMN)	https://www.omg.org/spec/PPMN/1.0/Beta1/PDF
Shared Data Model and Notation (SDMN)	https://www.omg.org/spec/SDMN/1.0/Beta1/PDF
Specification Common Elements (SCE)	https://www.omg.org/spec/BKPMN/1.0/Beta1/PDF