Toward a Process-Oriented Clinical Care System

by Jerome Carter on July 18, 2016 · 0 comments

My explorations in clinical care system design are progressing well.   In particular, I am pleased with the responses to the posts on primary care and EHR design.  There is a groundswell of interest in better systems that do more to help clinicians with the tasks they find burdensome.  Perhaps the retrenchment of MU has given everyone new hope.    Whatever the reason, I am grateful for the comments, suggestions, and insights that have been shared. 

Regular readers know that I consider processes important as a basis for clinical care system design (not more important than data, but equally important).   Having spent the last few months exploring application design with BPM suites, I now find myself faced with a new challenge – determining the best way to actually build process-aware clinical systems.   Attempts at solving this problem have resulted in two paths of inquiry: 1) how to objectively define clinical processes,  and  2) how to create a UI that intuitively provides process support.    

While there are numerous articles and books on BPM and clinical workflow modeling, none offers an objective way of demarcating when a process begins and ends.  Typical units in workflows and process maps—steps, tasks, activities, processes, and subprocesses—are all subjective.  For example, a task is often referred to as “a unit of work.”   Unfortunately, there is no reference manual that lists standard units of work.   It is up to the individual modeler to determine process boundaries and the number of tasks and steps involved.   When the goal is creating a process map or workflow diagram, vagueness about boundaries, steps, tasks and the like is acceptable because those models are meant to be shared with other humans.    However, if application development is the ultimate goal, precision is required.  Computer programming requires detailed, explicit instructions. 

Many BPM applications are geared to managing forms: expense reimbursement, vacation time requests, loan applications, and other typical business activities.   Forms make work concrete, so within a typical business setting, forms help to remove the subjectivity from terms such as “task” or “unit of work.”   Applying for a loan consists of completing a form and sending that form through a series of reviews until an answer is forthcoming—straightforward.   What happens when forms do not encapsulate the crux of the process? 

Consider what happens during a patient visit.  There is no form completed by patients that contains all the information required for the visit nor does a completed chart note mean the goal of the visit was met for the patient.  Looking at clinical care, one can see that care delivery is more loosely organized around forms than are typical administrative processes within the same organization—that is, the forms only capture or tell part of the story.

If one sets out to create a process-oriented clinical care system, then identifying and mapping clinical processes precisely is critical.    And lest anyone become offended, I am not talking about making every clinician conform to arbitrary process definitions. No, the goal is to capture the nuances of clinical work with the highest possible fidelity with the ultimate goal of creating systems that can support clinicians in their day-to-day activities. 

A necessary first-step in accurately mapping clinical work processes is the development of  criteria for objectively defining process units (steps, tasks, processes, etc.).   That work was completed in June and is waiting to be tested.   Now, the second step—applying those criteria to real-world clinical care and extracting clinical process definitions and organizing clinical work concepts—is underway.   If everything goes according to plan, completion of the second step will result in executable clinical process definitions. But, and there seems to always be a “but,” there is a not so small snag that has to be addressed first.    There is no standard set or list of clinical processes.  Looking at national reports, research articles, conference proceedings, and reviews failed to turn up anything resembling a common list of clinical process definitions.

Here is a list of clinical processes distilled from the sources mentioned above.   These are the internal classifications and definitions I will use in future posts and in designing workflow applications (I am not trying to set a public standard).   Each group represents a common set of tasks that clinicians perform. 

Clinical Process List
Order and Results Management – tracking of any test from initial order until final disposition

  • Notifications
    • Test not done
    • Results
    • Patient
    • Abnormal
  • Tracking
    • Not Done
    • Abnormal Follow – up
  •  Review
    • To Do
    • Flag

Referral Management – tracking and notification for all referrals to other clinicians (similar to above)

Patient Visit – support for activities that occur within a visit

  • Information gathering
    • History & Patient Concerns
    • Vitals
    • Exam
  • Patient Education
  • Care Plan
    • Medications
    • Labs
    • Referrals
    • Education

Patient Engagement/Communication – interactions with patients outside of standard visits

  • Notifications
  • Feedback
    • Direct
    • Medical Device
    • Application (mobile/web)
  • Patient-initiated queries
  • Care Plan
    • Medications
    • Labs
    • Referrals
    • Education

Care Coordination/Collaboration – interactions with other clinicians that are centered around a common patient or group of patients

  • Messaging
  • Intervention requests
  • Notifications
  • Patient Information Sharing
  • Synchronization

Population Management – oversight and interaction with a defined set of patients.

  • Disease registry
    •  Set-based queries
    •  Status
    • Common Issue (all with result “X”)
  • Preventive care
    • Notifications/Tracking
    • Required Interventions
    • Planned Intervention Initiation (e.g. Flu shots)

Problem/ Diagnosis Management – capture and management of patient problems, concern, and diagnoses

  • Logging
    • Presumptive/Definitive Diagnosis (linked)
    • Complications (complication from disease directly linked in timeline)
    • Interventions (linked to diagnosis)
  • Notification
    • Care Team Update
  • Knowledge Access
    • Direct Access
    • CDS

Medication Management – capture and management of medication usage history and outcomes

  • Logging
    • Side Effects
    • Adverse Reactions
  • Management
    • Reconciliation
  • Knowledge Access
    • Direct
    • CDS

Note Management – Creation and management of care intervention and patient interactions

  • Create
  • Review
  • Search
  • Update/Append

When reviewing this list, please keep in mind that it is a list of clinical processes from the standpoint of someone trying to figure out how clinical processes can be supported with workflow technology.  Accordingly, this list is not representative of UI elements or a navigation tree.   

From here, I will refine the list (I hope with input from all of you) with the goal of creating a more detailed set of activities.   In order to keep this work grounded, I will use results management as a concrete example to guide my understanding of process components—what they are, how they work in the real world, and how they are best modeled for execution.  The results management application will be created using one of the BPM suites mentioned in previous posts (ProcessMaker, Bizagi, Bonita, or possibly, AgilePoint). 

The results management application will be presented in a series of posts on Clinical Workflow Center.   If all goes well, the work on process definitions, clinical process models, and BPM app development insights will be published in a book on clinical process management.  At some point, I will take up the second path mentioned above–creation of a process-oriented UI.  Until then, there is  plenty to keep me busy.

{ 0 comments }