Monthly Archives: January 2017

Workflows in Healthcare Standards

Workflows are a big challenge in healthcare interoperability. Workflows exist everywhere, and in all forms. There are complex workflows, simple and straight-forward workflows, confusing workflows, cross-domain workflows, single-domain workflows, static workflows, dynamic workflows, defined workflows, and undefined workflows. Workflows are at the core of everything that happens in healthcare. We, as an industry are just beginning to understand how to go about defining workflows from an electronic perspective. For years IHE and other standards development organizations have been creating implementation guidance components that ultimately make up these larger workflows. These workflows derive from the various medical colleges that spend much time studying clinical workflows and producing guidance on implementation of these workflows in healthcare practices.

This blog post will not go into detail on all the different types and aspects of workflows mentioned above, however, it will introduce a couple of approaches that IHE has been using: static workflows and dynamic workflows.

Static workflows are those that are very well defined, and rarely, if ever, need to change from their original guidance. I admit that I am no expert in radiology, but I do know that the radiology domain profiles workflows that are fairly well understood and able to be controlled – at least to some degree. For example, a patient needs to have a certain imaging procedure performed, so they will first be registered in the system, an order will then be placed for the imaging procedure, the procedure will be scheduled and placed onto a DICOM Modality Worklist. The procedure is managed on the worklist according to the specifics involved (which are different for various imaging procedures). All in all, the process is fairly well understood. What happens outside the bounds of that particular procedure are of course variable, but the imaging procedure itself fits nicely into a well-defined workflow, and is finished within a single outpatient visit.

Dynamic workflows are much less predictable and must provide appropriate levels of adaptability in order to be successfully implemented. These workflows are those that are very open ended and dependent on many varying factors. Did the patient actually take their medication? Did the patient schedule that follow up appointment? It turns out that it is hard to ensure that patients follow their care plans prescribed by their providers. It is often times equally as hard for the patients themselves to follow their own care plans, amid busy schedules, with families to manage, work, etc. Sometimes tasks are forgotten or deemed to be less important than the task competing for their immediate attention. There is also a level of importance placed upon any given task in a patient’s care plan based on the amount of benefit that would be received from the task.

For example, a care provider may prescribe some sort of physical therapy, and if the patient completes the physical therapy then she will show signs of improvement (less pain, more mobility, etc). Maybe that is enough to satisfy the patient, but it would not satisfy her doctor. The patient decides to stop going to the physical therapy sessions because she thinks she is “better enough.” However, her condition worsens over the next few months, and she must schedule a follow up visit with her doctor to determine how to reengage with her physical therapy. The same scenario could be applied to many other situations, one common example being medication adherence for anemia.

Another aspect of primary care is dealing with patients that have comorbidities. Multiple chronic conditions can greatly complicate being able to effectively care for a patient. Combined with the fact that different people have different metabolic rates for medications that are not based on consistent factors – such as body weight, height, and vital signs – the doctor needs a system that is flexible and adaptable in order to do their job. This is one reason that adoption of EHRs has been so sluggish in the past few years. They tend to constrain care providers to a certain workflow that gets in the way of the doctor caring for their patient.

Workflows are addressed in IHE domains in various different ways depending on the clinical use cases being addressed. There are a handful of different underlying standards that are profiled, and in many cases those standards are profiled in slightly different ways for the varying clinical use cases present. Workflows exist everywhere, in every system – both healthcare specific and generic. What makes implementation guidance effective is a combination of factors, one of the key factors being how well the clinical workflow is understood by the specification author (or committee) and how well the underlying standard is matched to the clinical use case in a way that an implementer (i.e. health IT software vendor) can understand and write code to it, providing a useable product to the clinician.


High quality listening skills are so important to many roles across various types of organizations. I am reminded of this constantly. Recently, that reminder came through watching a documentary about the assassination of US President James Garfield in 1888. Dr. Willard Bliss, the physician treating President Garfield, was guilty of not listening. He was perhaps blinded by his own ambition, or maybe his ego. Dr. Willard was not an uneducated man, he was understood the importance of listening, he had to in order to achieve the status he had. When Alexander Graham Bell visited the injured president to offer the use of his newly developed technology in metal detection in attempt to find the bullet lodged in his body, Dr. Bliss would not allow Bell to test the instrument on the president’s left side, claiming that the metal springs in the bed were interfering with the device. Why Garfield could not be moved to another bed without metal springs, or why Bliss did not simply allow Bell to at least try on the opposite side of Garfield will likely never be fully known. Regardless, the hindsight wisdom is of course that he should have been more open to alternatives, putting his ego, ambition, or whatever was in the way of his ability to listen in the best interest of his President and patient.

In a software company listening to customers is also quite important. There are two parts to listening: the actual act of listening, and the interpretation of what is being communicated. The latter being achieved often by ensuring the right questions are asked to ensure the sharer of information is providing all of the right context and information necessary to make a good decision. In a product management role the act of listening to the customer is often driven by the organizational structure more so than the individual with the opportunity to listen. What I mean by that statement is that some companies promote as much communication as possible between product analyst teams and their end users (customers of the product) understanding the benefit that comes from that communication is much more often than not positive improvements in the product feature sets. Other companies stifle this communication by providing a process by which there are teams that build the product and then there are teams that manage the customer relations. The idea is to isolate or protect the builder teams from too much customer chatter to keep their productivity levels high. But the problem is the same one found in the game of Telephone (Chinese Whispers), where the resulting message communicated to the builders that originated from the client engagement folks is not the intended message! Building software is a complex task, and there is much room for error when taking this approach.

As the software industry matures, one of the leading ideas that has introduced an incredible paradigm shift in this regard is the Agile Manifesto, an idea that many of you are likely very familiar with. Following the Agile Manifesto, and associated methodologies that are built on its principals ensures that you and your team are outstanding listeners. In fact, the third rule in the manifesto is “Customer collaboration over contract negotiation.” Agile also supports a very strong idea of accountability, ensuring that you and your teammates are all good listeners, among other things. So how is your listening? Are you asking the right questions by deeply processing what your customers are saying and applying critical thinking?