Design Perspectives for Clinical Software: Getting Everyone on the Same Page

by Jerome Carter on March 28, 2016 · 0 comments

For the last six months or so, I have been doing parallel work with Apple Swift and BPMN 2.0.   For each, I decided to do a deep dive, meaning I tried to closely follow object-oriented analysis and design (OOA&D) best practices for Swift and an equivalent methodology for BPMN. The differences in philosophy between the two ways of developing information systems are both huge and important for the next generation of HIT.

BPM/BPMN 2.0 sees the world as a collection of processes that access data stores, pass data objects, and exchange messages. OOA&D sees the world as a collection of self-contained objects that maintain their state and have well-defined behaviors. Obviously, both can be used to create applications. However, their ways of modeling the world are sufficiently different that reconciling them requires deliberate intent. Here are general outlines for creating new clinical applications for each method


  1. Interview clients, review documents, etc.
  2. Do textual analysis
  3. Create use cases
  4. Look for candidate classes
  5. Create domain model
  6. Create classes and methods
  7. Refine internal design – activity diagrams, state charts, sequence diagrams
  8. Refine user interface
  9. Repeat any of the above until finished



  1. Interview clients, review documents, etc.
  2. Do textual analysis
  3. Look for candidate processes
  4. Create high-level process models
  5. Create detailed process models
  6. Create executable process models–add data requirements, messages, etc.
  7. Refine user interface
  8. Repeat any of the above until finished.

OOA&D makes users and their behaviors implicit in the system.   In an EHR, there would be objects representing patients, clinicians, medications — every interesting entity. Everything happens as a result of the interactions between objects. Consequently, a good deal of time doing OOA&D is spent studying and refining object interactions and behaviors. Once the system is built, the behaviors and interactions are hardwired, and changing them would require repeating some portion of the development process.   In a complex system like an EHR, a large number of objects are involved, and their interactions can be quite involved. A real-world activity, such as passing a form from a doctor to a patient, happens in an indirect manner. For instance, assuming there are doctor, patient, and form objects, a doctor object could instantiate a form object and pass a reference for the form object to the patient object.

From the process-based side of things, tasks are the cornerstone. Work happens as tasks are executed. The passing of a form from doctor to patient is explicitly modeled. The form likely is located on a server separate from the process engine as are business rules that dictate which forms may be used in a given setting. A major application design goal is matching the flow and meeting the needs of real-world processes. BPM systems make application behavior explicit.

It now occurs to me that my prior separation of clinical software into data and process-centric camps conflated two design groupings: data and objects. Data-centric designs start with data, and then culminate in applications that focus on allowing data elements to be saved, queried, updated, etc.   Relational and earlier types of database systems gave us data-centric software because the data were the most important part of the system. (Data processing was an apt description of early business computing.)

Object-oriented designs do not start with data.   OO analysis looks for objects and then fills out their properties, associations, methods, and interactions. So there are actually three philosophical camps: data-centric, object-oriented, and process-centric. The challenge is how to reconcile them to create the next generation of clinical care systems.   (Data-centric and object-oriented are not necessarily mutually-exclusive. One can focus mainly on creating data models, then use an OOP language to create an application to access the data, which likely applies to many, if not most, current EHRs.)

Perhaps the first step is recognizing that data-centric and OO design methods grew out of formal software engineering approaches. They can be used to build any kind of software (many BPM systems seem to be Java or C#-based).   BPM/BPMN are not formal software engineering methods as much as they are problem-solving tools. They are a level above data-centric and OO design methods when it comes to supporting tasks. In some ways, BPM systems remind me of Fourth Generation database development tools from 20 years ago.

For a while back in the 90s, Fourth Generation (4GL) development tools were all the rage. Typically, 4GL tools were development systems that made it easier to develop data-based applications (e.g., Clarion, FoxPro). These tools combined graphical design tools with languages that “understood” relational databases. They were very handy because many enterprise computing needs revolve around data. It simply made more sense to create the new Employee Vacation Management application using a database development tool than to write one from scratch in C. Designing forms, creating data schemas, and writing queries were all far easier and more productive when starting with a 4GL rather than a pure programming language like C or Pascal. Eventually, Microsoft stole the thunder of 4GL tools with the Visual Basic/SQL Server development pairing.

BPM systems seem to be analogous in many ways to 4GL tools in that they provide high-level views of tasks, allowing designers to design with activities, events, and gateways instead of functions, methods, and objects.    Obviously, at a technical level, OOA&D and process-centric approaches are not at odds — many 4GL systems were written using C just as many BPM systems are written in Java.  So we have multiple approaches to designing systems, and each has something to offer, but, unfortunately, they are rarely used together.

Developers who are expert in Java, C#, C++, Swift, or Ruby are not usually the same folks who do BPMN or YAWL in the same way the FoxPro experts were not usually C gurus. It is similar to the way that there are distinct groups interested in clinical workflow, but each has its own vocabulary and preferred tools (see Workflows with Friends).   Getting the best of all worlds for the betterment of clinical software means creating dialogs between groups that don’t usually interact. How do we share ideas???

Looking at the development outlines above, clearly everyone, no matter what the design philosophy, completes steps 1 and 2. The question is, what is best done next?   For clinical software developers then, the issue becomes one of the proper design perspective to take when building a new application. Are there times when each approach is best for a specific type of clinical application? Who knows?   Robust OOA&D tools are less than 20 years old, and BPM systems are just now coming into their own. For a very long time, the only viable choice was data-centric — relational database + graphical front end. The question of proper design perspective choice has only recently become pertinent for clinical software. Now that quality tools exist to support each perspective, making a choice has some meaning.   I have a few suggestions for choosing between data-centric and process-centric (see Clinical Software Design Principles).

There is a growing demand for clinical care systems that are more usable and better at supporting clinical work. And some clinical applications such as care coordination, results management, and decision support seem to be poster children for process-aware designs. Yet, few current products have such capability. It seems we have arrived at a time when clinical software development needs to chart a new path — one that embraces all three perspectives and borrows what is needed from each. How do we get everyone on the same page?


Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: