BPM in Healthcare Organizations

27th of March 2019

This Coursera course caught my eye last week, as it combines one of my passions, business process management with situational knowledge of the healthcare industry, which is adjacent to the sector in which I am working in at the moment (healthcare payor industry). The MOOC is organized by Rutgers the State University of New Jersey, and in its introduction, it promises to include an overview of all processes governing the healthcare sector, with a drilldown into processes involving electronic patient records and other patient-centered processes, as well as discuss approaches on how to manage them. Later in the course, there will be topics that can serve as a foundation for entrepreneurship in the private part of the sector.

On a quick side note, the bulk of the MOOC is presented as reading content with the sporadic video thrown in as a supporting tool. The reason for not employing video lectures as most of the other MOOCs on Coursera is that this would increase the direct relationship between learner and material to absorb. However, if I would put that against the learning pyramid which maps teaching methods to levels of retention of the course material, reading does not rank that high in the retention percentages with a mere 10% on average. Then again, there have always been plenty of articles about that debunk this pyramid.

Learning Pyramid
 

BPM in Healthcare Organizations (week 1)

27th of March 2019

The first week of the MOOC starts with listing some definitions for several concepts of Business Process Management (BPM). It starts by elaborating that there is still no consensus on the definition of what a business process is. The following references are given:

  • The Business Dictionary: A series of logically related activities or tasks (such as planning, production, or sales) performed together to produce a defined set of results.
  • The BPM glossary: A business process must have clearly defined inputs and outputs. Inputs make up all of the contributions for a product or service. [not really an attempt at a definition in my opinion, but rather some observing statement]
  • The American College of Healthcare Executives (ACHE):[Funny Acronym right there!] Business processes are the processes which pertain to “specific areas/concepts of the organization”. [Isn’t this nice and generic?]
  • The essence extracted by the course: A business process is a series of actions completed to achieve a specified organizational objective or goal.

I have always favored the definition of Davenport and Short given in 1990, which is very similar to this one: “A business process is a set of logically related tasks performed to achieve a defined business outcome.” Add to this the elements that a process is structured and measurable, and we get most of the relevant dimensions of a business process. Another staple of BPM conceptual theory is the types of processes that occur within organizations: Operational processes (the day-to-day work), supporting processes (such as HR, IT, procurement and the like), and management processes (managing the processes in the previous categories). This last category also contains any transformation processes, such as optimization and improvement initiatives.

In order to formalize business processes, there is a set of information that needs to be specified. As a bare minimum, the course lists the following characteristics: the purpose/objectives, the input needed, the process flow, and the process output. I tend to stipulate SIPOC as a bare minimum: Supplier, Input, Process description, Output, and Consumer. This can typically be extended to encompass the objectives (as indicated by the course), and the control points/relevant measurements. In order to exhaustively describe a process, the course adds the following to their previous list: process name (which I would always specify in any level of detail), scope, boundaries, exception flows, control points and measurements, roles and responsibilities, and approval procedure. For visualizing the process flow and exception flows, the course indicates that BPMN is the standard, and the only way to go.

In the wake of trying to define business processes, two more definitions get their moment in the spotlight: Checklists (a summary of completed activities that are not a workflow) and use cases. The course identifies this more as a reporting tool, but I would say this falls under the umbrella of cases in the form of a set of unstructured activities. Use cases are defined as the fashion in which an end user interacts with the process. I always considered use cases to be an elaboration of how an individual activity/task within a process functions. Use cases are defined by their name, description, actors, pre- and post-conditions, use case flow (also called the sequence), and alternative flows.

A logical progression after defining the process is to define the discipline for managing the processes: BPM. Although it presents some alternatives, the course identifies a general agreement on the definition of Keith Swenson made in his book “Passports to Success in BPM” back in 2015:

Business process management is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.

A clear conclusion about healthcare organizations is made: They should not only document business processes, but also the existence of business processes. This is what the BPM discipline calls a process architecture: a complete inventory of all processes within your organization. The Process Classification Framework of APQC gives a nice head start for this type of exercise.

The remainder of the week’s topics delve into elaborating specific processes within the three process categories. I will list them here, but won’t go into the same level of detail as the course:

  • Operational Business Processes:
    • Patient/Customer Intake (Admissions Process)
    • Healthcare Delivery
    • Patient/Customer Discharge
  • Supporting Business Processes:
    • Human Resources Management Processes
      • Employee Recruitment, Hiring and Onboarding
      • Compensation and Benefits
      • Performance Evaluation and Incentives
      • Training and Development
      • Employee End of Employment
      • Organizational Compliance with Laws and Regulations
    • Financial Management Processes
      • Strategy Collaboration for Short-Term and Long-Term Financial Goals
      • Budgeting (Estimation, Distribution and Follow-Up)
      • Financial Controls
  • Management Processes

A quick side note on the examples of the process flows attached to this week’s topics. Some of them show what the IBM “Business Process Management Design Guide” Red Book labels the String of Pearls Anti-pattern (red rectangle). This is a series of tasks that are executed by the same actor within the same transaction boundary. This is an indication that these are not separate tasks, but in fact a single task with multiple steps. Although this is acceptable in the descriptive process level, this should be filtered out once a process design moves to its analytical level and might therefore as well be avoided in all levels altogether. It is a simple guideline: tasks are distinct from each other if they are executed by different users or if they are separated in time.

Another minor remark is that the BPMN specification allows for a gateway to serve as both a splitting and a merging gateway (blue rectangle), the process becomes a lot clearer if two gateways, one right after the other, are used. The first gateway as a merge of incoming sequence arrows, and the second to split the sequence flows up in the different possibilities. Personally, I never bothered much with this suggestion either, and I am only mentioning it to be complete.

With the advent of Decision Modeling Notation (DMN), it has become clear that we want to extract decision logic from processes in order to render them more “clean”. Much like in IDEF practices, the decision logic should be extracted to a separate entity/component, a decision service, followed by a single splitting gateway branching of in the different alternative flows. Take the example of the “Nurse Only Visit” from the course, where there is a chain of gateways each representing a Yes/No question. These can be reduced to a single gateway splitting in 4 flows based on the return value of a decision task, where we can model this decision structure using DMN.

The general feeling I have about the first week of the course is that it sets the stage by clearing up some general concepts, and already touching on the different specific processes that govern the healthcare industry. My hope is that these will be elaborated further in different aspects, but that remains to be seen. As for the beauty mistakes in the processes, there are not too blatant, so my perfectionist tendencies are not yet getting the better of me. On to the next week.

BPM in Healthcare Organizations (week 2)

22th of April 2019

The second week of the course deals with changes in business processes, either through extensive use and progressive insight into their workings or by disruptive innovation. The main questions: How to improve them (BPI), and how to tackle Business Process Re-engineering (BPR). It also visits the types of processes that deal with this change or cause it: research, development and innovation processes. A final type of processes to be looked at are those that diffuse the change and innovation throughout the organization: technology transfer processes.

Business Process Improvement (BPI) can be achieved by either have incremental improvements in processes that profit from them, or by completely redesigning the process using BPR. To determine which processes are deserving of an improvement or overhaul, control points and measurements should be set for each process to be checked against benchmarks so we can determine that the process is functioning as intended. This fits into the standard BPM lifecycle consisting of five steps: Design, Modeling, Execution, Monitoring and Optimization. I tend to extend this lifecycle with some steps pertaining outsourcing and disposal, but the core concepts are a very solid starting point.

BPM Lifecycle

The states of this extended lifecycle are:

  • Identified - The process has been selected for modeling and automated process management.
  • Defined/Refined - The business aspects of the model have been captured, modeled, and refined to a sufficient level to support this iteration of process optimization. On the first iteration through this cycle the identified process selected for automation undergo process discovery and definition; on subsequent iterations the process, having been already defined, is merely refined. (descriptive modeling)
  • Outsourced – The process has been deemed opportune to be outsourced to a third party. This is followed by a periodic assessment of whether or not to continue with the outsourcing or to consider the process for refinement again.
  • Designed - The technical aspects of the process model have been addressed including integrations, message handling, interface specification, exception handling, security, transactions, etc. (analytical modeling)
  • Composed - All external integrations, message wiring, and security roles have been configured. (executable modeling)
  • Tested - Any software engineering needed to support the process has completed and has been tested along with the process.
  • Deployed - The executable process model, and all external dependencies, have been deployed into a production environment.
  • Approved - Final QA approval. All testing and user acceptance procedures have been completed. The model has been commissioned and BPM system manages execution of the business process.
  • Monitored - Process metrics being are collected and provide actionable business intelligence.
  • Disposed – The process no longer has a purpose and all allocated assets are repurposed.

One of the shortcomings of this chapter is however that it only focuses on BPI and BPR, while there are numerous other methods of improving a process, that at least deserve some lip service. I added a little illustration of some of the more prominent techniques and where they apply in the business process in the illustration below.

Process Optimization Approaches

The second focus for this week’s course is about three concepts: research, development and innovation. This was a particularly instructive part of the course, as it deals with those processes that focus on managing change (both externally and internally caused). It deals with incorporating new elements into your existing processes and corporate culture. These processes make up part of what is commonly known as the Change Management discipline. In order to adopt change into your organization as soon as possible, the two types of business processes that are needed, are those devoted to staying aware of relevant innovations and those that determine how to implement them.

Although these three concepts are in the same sphere of influence, they are not synonyms. Looking over the definitions in the Business Dictionary teaches us their differences. Research is a systematic investigate process for increasing or revising current knowledge by discovering new facts. Development is the systematic use of scientific and technical knowledge to meet specific objectives or requirements. It is also an extension of theoretical or practical aspects of a concept, design, discovery, or invention. Lastly, innovation is the process of translating an idea or invention into a service that creates value. In short: Research necessitates development to generate inventions that can lead to innovation. This innovation can be categorized as either product/technology innovation (bringing a new or improved product to market), process innovation (improvement of an existing process), or business model innovation (a new way of thinking, such as for example Uber for taxi services).

Although these three concepts are in the same sphere of influence, they are not synonyms. Looking over the definitions in the Business Dictionary teaches us their differences. Research is a systematic investigate process for increasing or revising current knowledge by discovering new facts. Development is the systematic use of scientific and technical knowledge to meet specific objectives or requirements. It is also an extension of theoretical or practical aspects of a concept, design, discovery, or invention. Lastly, innovation is the process of translating an idea or invention into a service that creates value. In short: Research necessitates development to generate inventions that can lead to innovation. This innovation can be categorized as either product/technology innovation (bringing a new or improved product to market), process innovation (improvement of an existing process), or business model innovation (a new way of thinking, such as for example Uber for taxi services).

The processes dealing with moving a concept from research to development are called technology transfer processes. The processes dealing with keeping the organization aware of innovations, especially if early adoption is part of the organization’s strategy, are called innovation diffusion processes. They focus on being aware of innovations in their field, gathering sufficient information about the innovations to determine whether or not they could be beneficial, and then coming to a decision to go ahead with this innovation or let it pass by.

Delving deeper into disruptive innovation: These are the innovations that render existing technologies/products/services/organizations obsolete and require immediate attention. Peter Drucker supposedly stated “Innovate or Die” as a truth to live by in a business context. This type of innovation usually originates in a new organization or start-up. Even when the innovation is discovered in a existing organization, it usually results in a spin-off company testing the viability of the innovation before introducing it into the mother company. A passing thought on this section of the course: It does remind me of a phrase in one of the previous MOOCs I followed on business management: There are millions of books on innovation, each of them describing how others have achieved innovative breakthroughs. However, you do not innovate by copying what others have done before you.

BPM in Healthcare Organizations (week 3)

07th of May 2019

Week 3 deals exclusively with the different characteristics of the electronic patient record. While very lightly touching on the business processes involving this record, the course mostly focuses on listing the different types of digital records that healthcare organizations need to be aware of. They rely heavily on the definitions by the Office of the National Coordinator for Health Information Technology (ONC). Please note that this is a course that is about Healthcare in the US, and as such the specifications might differ from what we here in Belgium consider important characteristics and distinctions.

The different types of digital records are the following:

  • The Electronic Medical Record (EMR): a digital version of the paper charts used by the medical staff. It contains the medical and treatment history of the patient in a single practice.
  • The Electronic Health Record (EHR): the cumulative digital records of all clinical data collected at all practices. This record is shared across all medical practices in order to insure the optimum care for the patient. This information is shared across the EHR network and can be accessed by all participating practices.
  • The Electronic Dental Record (EDR): a digital record of dental records and history.
  • The Personal Health Record (PHR): a digital record which can be accessed by the patient, either completely separate from the EMR/EHR or derived from it (called a tethered PHR).

When sharing information of this nature, interoperability is a key concern. The ONC suggests adopting standards for information models (such as the SNOMED-CT for clinical vocabulary) and technologies (such as the Health Level 7 standard). These standards are maintained and provided by the HealthIT.gov Interoperability Standards Advisory (ISA) website. Participation in this EHR network is incentivized by the government at this time but can soon become mandatory with penalty clauses for non-participation.

A secondary concern with this type of knowledge sharing is the privacy of the patient. The EHR network must take care to store and exchange the data in a secure manner so that no unauthorized personnel get to see it. Moreover, the patient should be able to determine who the people are that are authorized for his/her data. This security should be enforced using both technology and laws governing the use of the data. The main body of law dealing with this is the Health Insurance Portability and Accountability Act (HIPAA).

Some of the business processes interacting with the EMR and EHR are those pertaining the prescription, prescription transmission (also called E-Prescribing) and pharmacy processes using in organizations in charge of distributing medical drugs. These drugs are characterized in 5 schedules that indicate the acceptable level of medical use and the drug’s abuse and dependency potential. These levels go from schedule 1 (or illegal) over schedule 2 to 4 (indicating the drugs are only on prescription with varying degrees of restrictions) to schedule 5, which are over-the-counter drugs. All prescribed drugs are recorded on the medical record of the patient for reference. Pharmacies also keep a for of EMR called the Patient Medication Record (PMR) which contains this information.

The course also delved a bit in the history of each of these records and what prompted them to emerge into existence, but this is mainly fluff and doesn’t really add to the business knowledge of the industry.

BPM in Healthcare Organizations (week 4)

15th of May 2019

Week 4 is the conclusion week for the course. It no longer adds to the body of knowledge assembled in the previous weeks, but instead asks to produce a synthesis of what has been learned. This synthesis should come in the form of a memo written as if you were the Chief Healthcare Officer for your organization. It should adhere to the principles of sufficiency for its intended purpose and the ease with which to grasp its content. This content should encompass the following topics:

  • Name of the healthcare organization
  • Brief description of the healthcare organization
  • Most important use cases of your organization
  • Brief description of a broad overview of the operational business processes important to these use cases
  • Brief description of a broad overview of the supporting business processes important to these use cases
  • Description of how these two categories of processes are managed in function of them performing well and meeting the use case
  • Brief description of processes to deal with innovation relevant to your organization
  • Description of the entrepreneurship within your organization
  • Brief description of business processes surrounding the EHR

I found the term “use case” in the list of requirements a bit misplaced, as it is clearly the business case “patient-centricity” that the explanations go on about. Use cases for me are the descriptions of the individual activities of the processes being listed. Maybe a matter of terminology, but it follows the same line I have discerned throughout the course of it remaining on the surface and not caring too much about the details of the topics they attempt to get across. This leaves me for the course in its totality a bit disappointed. I had high hopes for this course, even though it is the introduction course to a larger specialization. It did not give me any drive to take up the rest of the courses.

Review Healthcare Sector BPM