Clinical Software Engineering, Part II: Informatics Analysis

by Jerome Carter on July 13, 2015 · 0 comments

As mentioned in the last post, I am exploring a new way of developing clinical software that puts processes front-and-center from start to finish. I call the approach informatics analysis and design, and it is the approach being used for my iOS project.

Informatics analysis and design (IAD) assumes that real-world clinical care processes are non-random, have specific information inputs and outputs, and have measurable real-world consequences (patient outcomes).   Further, clinical care is assumed to be role-based and to have discernable patterns that can be codified, studied, and represented visually and algorithmically.   Finally, data sharing and patient engagement are considered both fundamental aspects of clinical processes and basic features of clinical software.   Development of IAD has grown out of the realization that current analysis and design methods require much better process analysis and representation tools if they are to be used to create process-aware clinical systems.

Structured/Object-oriented Analysis and Design Methods
From the standpoint of analyses done for the express purpose of creating software, there are two major camps—structured (SAD) and object-oriented (OOAD). Both approaches acknowledge the importance of data and processes; however, neither provides process modeling constructs that seamlessly integrate users, information movements, and control-flow.

Structured analysis techniques date back 50 years or more. Process modeling in structured analysis is done using data flow diagrams.   Data flow diagrams (DFD) model the flow of data from external sources to processes and data stores (1). (Here is a link to an example.) Processes are represented primarily in the context of data movements.   Control-flow is represented using flowcharts (2).

When processes are relatively simple, for example, collecting basic demographics for a store’s loyalty program, process boundaries are obvious and the steps few (filling in each field of the form).   In such cases, flowcharts and the accompanying DFD are not hard to follow. More complex processes with intricate flowcharts and DFDs make it harder to follow the combination of process steps and information movements.

Use cases are the primary object-oriented method for understanding user processes. (User stories/Agile methods do less up-front modeling, which I think is not conducive to creating complex clinical systems). I like use cases. They are an excellent way of capturing what users are doing and why, possible paths, etc. Unfortunately, moving beyond use cases to more detailed process modeling requires an assortment of diagrams. There are activity diagrams, sequence diagrams, interaction diagrams, communications diagrams and a couple more (3).  Regardless of the method chosen, structured or object-oriented, neither is well suited to analyzing and modeling clinical processes with complex information movements and step progressions within a single analytical and modeling framework.

Modeling and analysis are intricately linked. Analysis gives rise to models; models are then revised using additional analyses, and the cycle repeats until a satisfactory deliverable exists.   Using an array of diagrams requires too much context-switching, making it difficult to maintain a clear picture of how the model and analyses tie back to the real world.   A couple of examples should help in clarifying the problems encountered using current structured or OO methods for clinical software development.

Consider the differences between a process that has a well-defined set of inputs and expected outputs and one that is unavoidably open-ended.   A “registration” or intake process, whether for a clinic visit, new car loan, or loyalty program has a well-defined set of data elements, specific rules about mandatory items, and clear start and end points. Business rules are applied to the collected information, which then assign people completing registration into pre-determined groups. Employees who oversee the intake process rarely have any say in how enrollees are managed. Employees simply follow the policies and procedures of the company.

Now, compare the level of control clinical professionals have over the day-to-day clinical care processes that they participate in. Consider the actions of a speech-language pathologist in her first meeting with a patient who has suffered a stroke.   The goal is to assess the patient and develop a treatment plan.   In this scenario, how data elements are collected, the importance of each one, and whether additional elements are required will be determined in real-time during the patient interview and examination. Besides the immediate problem, co-morbid states, personal preferences, and the emotional state of the patient influence the SLP’s processes and the expected process outputs.

Typical business intake processes rarely allow for alterations by those interacting with customers, whereas clinicians alter processes all the time. Clinical care is a domain where process control rests with software users, and software design practices and methods must acknowledge this fact.

Processes as first-class citizens
Practically speaking, informatics analysis and design looks at real-world clinical work, then attempts to, in order: 1) identify processes, 2) determine process information needs, 3) assign information to roles, and then 4) assign specific user interface elements to roles.

From an analysis perspective, the big deal with this approach is seen in Steps 1 and 2. Processes are always analyzed and modeled with interactions, control-flow, and information use within the same framework—no context switching is required to trace any aspects of a process.

Clinical processes are usually analyzed/modeled at too high a level to be useful for software development or even implementation (see Clinical Workflow Analysis: The Value of Task-Level Detail ).   Influencing a process means intervening at a specific step, thus the boundaries and properties of every step must be explicit. When step properties and boundaries are ignored, workarounds are born.

Workflow patterns (see Workflow Patterns, Part I: A Pattern-based View of Clinical Workflows), because they offer a standard library of workflow information, can be used when analyzing processes and teasing out steps.  After reviewing hierarchical task analysis and cognitive task analysis methods and outputs, I am convinced that workflow patterns, properly adapted for clinical care, would be a boon as a lingua franca for clinical processes.

Another important aspect of IAD is the early and persistent linking of processes and information to roles.   Because clinicians direct clinical processes, significant accommodation has to be made for individual work habits.   Open-ended processes cannot be fully-specified in advance for all users; some variation is unavoidable.   Consequently, clinical software should support configurable workflows.

IAD is not an attempt to start from scratch.   I like OOAD overall, so informatics analysis borrows from it.   Use cases stay, acting as the initial means of identifying key processes.   Next, detailed process models that integrate control-flow, information movement, interactions and roles are developed. Process models capture requirements for clinical process support. In addition, process models are computable; that is, they can be used to program a workflow engine or to code algorithms.

The biggest challenge, thus far, has been developing a collection of objective terms and concepts for clinical work along with a notational system. Informatics analysis as a software design methodology cannot progress until this work is completed.  Fortunately, work on the basics is progressing well—enough, at least, for me to test out the analysis ideas on a real project.

Current EHR systems, at the deepest architectural level, are designed to capture the outputs of clinical processes. The key artifacts found in paper and electronic charts—the problem list, patient note, prescriptions, etc.—contain the data outputs of clinical processes.   As long as outputs are the main concern, data-centric systems are fine. However, as we see HIT become ever more ensconced in health care, influencing processes has become a major goal. For that, one needs process-aware clinical care systems.

Creating clinical software with sophisticated process-support requires a different approach to gathering requirements and designing systems.   Part of that new approach has to be the analysis and modeling of clinical processes at a level detail suitable for execution.   Informatics analysis and design, or something like it, is needed to close the gap between today’s generic methods and what’s needed for creating next-generation clinical care systems.

  1. Hoffer J, George J, Valacich J. Modern Systems Analysis And Design. 7th ed. Upper Saddle River, New Jersey: Prentice Hall; 2013.
  1. Structured Analysis Wiki – Ed Yourdon, Chapter 9 – Data Flow Diagrams. Available at: http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9. Accessed July 7, 2015.
  2. Unified Modeling Language (UML). Available at: http://www.uml.org/. Accessed July 7, 2015.
Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: