Saturday, March 8, 2014

Modeling Care Pathways with BPMN

The optimization of healthcare delivery can be achieved through the standardization of care pathways and treatment protocols based on the latest scientific evidence. The following are some of the benefits of the standardization of care pathways:
  • Improvement in patient outcomes in the context of a shift from a fee-for-service to a value-based healthcare delivery model
  • Reduction in the variability in care quality
  • Facilitating the dissemination and adoption of evidence-based practice (EBP).

Different formalisms have been proposed over the years for representing the medical knowledge in clinical guidelines. Examples include GLIF (Guideline Interchange Format), Asbru, and PROforma. However, these formalisms have been largely confined to academia.

In this post, I discuss the use of the Business Process Modeling Notation (BPMN) for modeling and representing existing Clinical Practice Guidelines (CPGs) and Care Pathways (CPs). Once represented in BPMN, these guidelines can be translated into computer executable guidelines in the form of Clinical Decision Support (CDS).

As an example, let's review the algorithm below titled Management of substance use disorder, Module C: General Health Care which has been extracted from the VA/DoD Clinical Practice Guideline (CPG) for the treatment of substance use disorders.



The advantage of using BPMN is that it is widely used across industries and implemented by several commercial and open source tools. The algorithm above is not represented in BPMN notation. However, it is relatively easy to create a BPMN representation of the same diagram and doing so can actually help elaborate and clarify its use within a specific healthcare organization.

Clinicians often complain that CDS systems are not well integrated with clinical workflows. One benefit of using BPMN for modeling CPGs is that it facilitates the integration of business rules and business processes. As can be seen from the algorithm above, CPGs are typically represented as a network of tasks some of which are decision tasks. For example, in the diagram, there is a decision node with the question: Are Treatment goals achieved?. This decision task can be modeled in BPMN as a business rule task and executed by a business rule engine at run time.  There are business process management (BPM) and business rule management systems (BRMS) tools that provide this integration out-of-the box.

At a high level, BPMN represents business processes using events, activities, data objects, gateways, tasks, and grouping elements. Gateways control the splitting and merging  of sequence flows in a business process. The different types of gateways include: Parallel gateway, Exclusive gateway, Inclusive gateway, and Complex gateway. Gateways can also be implemented by a business rule engine. Data objects allow interaction with clinical data sources such as as Electronic Medical Record (EMR) systems.

Grouping elements like pools and lanes are used to delineate the responsibilities and roles of individual clinicians or organization in the process. For example, while the algorithm above is for the management of substance use disorder in general (primary) care, there is a note specifying that patients may be offered referral to addiction  specialty care at anytime. This separation of roles can be captured with lanes.

In addition to business rule tasks, BPMN also supports abstract tasks, service task, user task, and script tasks. A user task represents a human task and can support the creation of task-oriented user interfaces in CDS systems. A separate specification called the Web Services Human Task (WS-HT) specification provides an application programming interface (API) and a coordination protocol for interacting with human tasks in a service-oriented manner. The state diagram for human tasks below extracted from the WS-HT specification shows the different states of a human task and the transitions between them. The WS-HT also support notifications which can be used for alerts and reminders in clinical decision support.

Sunday, January 5, 2014

An agile approach to analyzing business rules

Business rules are used to capture complex operational decision logic typically found in corporate policies, government regulations, and industry guidelines. For example, in the healthcare industry, clinicians must adhere to clinical practice guidelines (CPGs) and other evidence-based care recommendations. Clinical Decision Support (CDS) systems which provide care recommendations to clinicians are usually designed with a business rule engine.

In the area of Big Data, operational decisions can also be derived from the analysis of operational data using predictive analytics. In the healthcare domain, the analysis of patients' clinical data in electronic medical record (EMR) systems can inform clinical decisions as well.

Benefits of Business Rules


The following are some benefits of designing business rules applications:

  • The business logic of the application can be externalized in the form of declarative business rules. This contrasts with an approach where business rules are embedded in procedural code.

  • Business Analysts (BA) and Subject Matter Experts (SMEs) can help create, test, and maintain the business rules. Some business rule management systems (BRMS) provide the ability for BAs and SMEs to use tools like a spreadsheet, a domain specific language (DSL), or an intuitive user interface for creating and testing business rules. Examples of BRMS include JBoss Drools and IBM ILOG.

  • There is often a requirement to integrate business rules and business processes. For example, clinical decision support (CDS) systems based on business rule engines should be well integrated with clinical workflows which are essentially business processes that can be modeled using the business process modeling notation (BPMN). There are different patterns for integrating business rules and business processes. A business process like a clinical workflow has decision points that are implemented by business rules. 

  • The ability to perform simulations and what-if analysis during development. 

  • Business rules enable consistent and repeatable decisions. In the healthcare domain, this can be used to achieve evidence-based care standardization among clinicians.

  • Business rules allow the organization to improve the quality and speed of operational decisions as determined by metrics like key performance indicators (KPI). In the healthcare domain, this can help meet clinical quality measures and improved patient-centered outcomes.

  • The effectiveness of the application can improve over time by logging and monitoring the executions of the business rules in an operational environment.


The Agile Business Rule Development (ABRD) methodology


Originally created by IBM and donated to the Eclipse Foundation, the ABRD provides an agile and iterative approach for designing, developing, testing, and deploying business rule applications. The diagram below represents a high level overview of the ABRD process (click to enlarge).


 The ABRD process is divided into the following five phases:

  • Harvesting
  • Prototyping
  • Building
  • Integrating
  • Governance

A complete description can be found on the ABRD page. The site also contain various tools and templates for using the ABRD. I also found these two books interesting for learning about business rule applications:

  • Jérôme Boyer, and Hafedh Mili. Agile business rule development process, architecture, and JRules examples. Springer, Berlin; Heidelberg; New York, 2011.
  • Taylor, James. Decision Management Systems: A Practical Guide to Using Business Rules and Predictive Analytics. IBM Press, 2011.

Monday, December 23, 2013

Usability Driven Development of the User Interface of Health IT Systems

The following are examples of patient safety incidents that can occur when using an electronic medical record (EMR), a Computerized Physician Order Entry (CPOE), or a clinical decision support (CDS) system:
  • Incorrect identification of a patient resulting in the administration of the wrong drug.
  • Incorrect medication dosage due to a miscalculation of body weight resulting from a mix-up of kilograms and pounds.
  • Missing data or incorrect data entry into a patient's medical record.
  • Misreading of patient's medical record due to a font size that is too small on a computer screen.
  • Errors in medication dosing frequency due to a non-intuitive menu.
  • Incorrect test ordered due to a clinician clicking on the wrong test.
In this first blog post, I suggest a usability driven approach to gathering software functional requirements and designing the user interface of health IT systems. The goals of this approach are the following:
  • Increased patient safety.
  • Increased productivity of healthcare staff through a user-friendly, predictable, and intuitive interface backed by scientific research and validation.
  • Reduced need for staff training due to a consistent look and feel across clinical applications.

 

The NHS Common User Interface (CUI) Program


Since November 2004, the British National Health Service (NHS) Common User Interface (CUI) Program in collaboration with Microsoft has been creating standards and guidance in support of the usability of clinical applications with inputs from user interface design specialists, usability experts, and hundreds of clinicians with a diversity of background in using health information technology.

The program is based on a rigorous development process which includes: research, design, prototyping, review, usability testing, and patient safety assessment by clinicians. The NHS CUI standards and guidance have been tested in production through the NHS Summary Record Application (SRA) project. The Guidance Catalog covers the following subjects with high impact on patient safety:

  • Patient Identification
  • Consistent Navigation
  • Accessibility
  • Abbreviations and Acronyms
  • Clinical Noting and Terminology
  • Decision Support
  • Handover
  • Information Entry and Display
  • Medications Management.

Usability in the Design and Development Phase


As a best practice, formal usability testing should be conducted early in the design and development phase as opposed to doing usability assessments only after the application has already been developed and deployed into a production environment.
 
In my experience as a Health IT Business Analyst, creating a mockup for new Health IT software applications is a very efficient way of capturing functional requirements. Mockups are very useful in helping to communicate the vision of the Product Owner and can also be very helpful to the other project stakeholders like end users, testers, and developers. I use Balsamiq to create mockups that comply with CUI guidelines. Usability testing can be performed against these mockups to ensure CUI compliance and also to obtain early feedback from potential users of the system. I perform Usability Testing of the mockups with end users using a proven methodology like the System Usability Scale (SUS).


Twitter Boostrap Components in Support of CUI Guidelines


Twitter Boostrap is a very popular and powerful mobile-first front end development framework that supports the Responsive Web Design (RWD) approach to achieving cross-browser and cross-device capabilities. There are emerging tools that can assist in converting a Balsamiq mockup into Twitter Boostrap Templates. An example of such a tool is Napkee.

Microsoft has published a set of UI controls that implement CUI guidelines using Silverlight, a now defunct front-end framework. Twitter Boostrap on the other hand is based on open web standards and framework like HTML5, CSS3, and JQuery (a JavaScript library) and is supported by a very large community of web developers. The availability of open source Twitter Boostrap UI components that implement health IT usability guidelines could result in significant cost savings and increased patient safety.