Category Archives: Technology

A Changing Landscape in Healthcare IT Software

For many of the years that I have been involved in Healthcare IT I have had the good fortune of working for EHR software vendor organizations. It was very exciting to develop bleeding edge technology supporting interoperability standards, and see the benefits realized in real-world use. We broke through many barriers in the healthcare field, although we certainly did not reach the ceiling. However, as in many market sectors, times change and with such change innovation and new ideas take a front row to what has become solid and stable. EHR solutions are mostly now considered to be the foundation for the industry, providing a solid framework upon which more complete solutions are being delivered in interest of bettering patient health outcomes.

In the past few years so many niche applications have arisen to address very specific problem areas. This is in part due to a natural industry shift requiring fresh perspectives on older problems. This is in other part (in the US) due to government incentive programs driving forward a need to improve patient health outcomes such as ACO, PCMH, and MACRA (QPP).

As technology solutions mature, they naturally become more difficult to adapt to changing conditions. The more components a solution has the more effort it requires to update those components while retaining backwards compatibility and the harder it is to craft deployment packages that do not interrupt existing live productions in significant negative ways. Managing a technology solution over the long term definitely comes with its challenges as well as its benefits. New comers into the market are able to quickly adapt to changing requirements that exist, freely building innovative and creative solutions that are not so dependent on existing components and choices made earlier in development by the more established solutions. These newer solutions are able to be plugged into the older solutions to address gaps in functionality that might not otherwise be addressed. This is the nature of software engineering and development as it has progressed since its inception in the middle of the last century.

The other driver of new technology solutions in healthcare is that of federal incentive programs that are placing a strong emphasis on improving patient health outcomes. Research is beginning to show that improving health outcomes for patients across a population is more than just using a certified EHR system or following the medical practice guidelines from the appropriate medical college. Rather, it involves a much more complete and holistic approach of medical practice that looks not only at the clinical facts of a patient, but engages the patient in a relational aspect, understanding the impact that social determinants have on that particular patient. Understanding the mental health of the patient is also quite important, often times being very difficult to properly diagnose and treat for a number of good reasons. To address these sorts of issues doctors must find ways to meet patients where they are today, using tools and approaches that are natural to patients. This means making use of apps developed against popular platforms that interact with social media, are intuitive to use, integrate with existing systems of all kinds to provide seamless access and management of the patients health data and care from both the provider and patient perspectives.

This IS the new face of healthcare, this combination of the foundational EHR vendors’ existing solutions, in conjunction with newer solutions that focus in on very specific problems that need solving. And really, this is not much different than how technology has always been managed. As solutions age, various components of those solutions are wrapped with interfaces that abstract them away, providing a way for the newer, more efficient, and many times more socially accepted solutions to interact with the older technologies. In the same thought, wisdom is valued more than mere intelligence or trend. That wisdom is grounded in the foundational participants in healthcare IT that continue to drive forward standards-based development efforts, focusing on the shared goal between patients, providers, and payers of improved patient health outcomes for all.

Listening!

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?

Use Cases – A Path to Clarity

Some call them user stories, others all them use cases but all in all they serve much the same purpose: to align the business and the technical interests in a project. Use cases have many benefits when used correctly and I have seen them used effectively in several different areas of life including healthcare standards, software development, and family decisions.

Use cases are beneficial in many ways. At the very basic level they bring needed clarity to any given situation by stepping back to consider what it really is that is trying to be achieved. I’ve seen so many software developers that just jump in and start designing and coding without vetting the business requirements first. And I know this especially well because I used to be one of those developers (it is an impulse problem, and as a developer gains experience he/she should learn to control it) . Use cases act as a bridge between the business and technical interests by providing a communication path for these different groups. In earlier software design and development models the generally accepted approach was to thoroughly vet the requirements, which included use cases, by the business analyst/product team. Once everything was vetted properly, which could take months, documentation was handed off to the development team to execute on them and deliver software. The problem with this model is that there is little to no communication between those two groups. As we have learned in the past decade or so requirements often change before software is delivered to the field, and methods have been created to combat this challenge. Use cases and user stories are often used as a central discussion point in support of such methods. Use cases also bring confirmation of the goals of the project by illustrating what the software (or whatever the use case is being applied to) is supposed to achieve. It is a way to “check your answer,” similar to what one would do to validate a math problem.

I have much experience with use cases in the realm of healthcare information technology standards profiling in my work within Integrating the Healthcare Enterprise (IHE). A profile in IHE provides implementation guidance for systems in the healthcare domain. One of the base level requirements of a profile is a use case, or set of use cases. I have been involved in the development of over 15 IHE profiles over the past several years and every time I discuss a profile with someone, be they architects, engineers, product managers or VPs, I always get back to the use case at some point. It is a very effective way to center the conversation around one central goal, consistently representing the message across and between these different groups.

Use cases can often be effectively applied to planning family excursions as well. My wife and I are very fortunate to have four children, and this means that we must thoroughly think through any vacations we plan, day trips or other traveling we may choose or be required to do as a family. Although we do not use the same terms as I would in my professional career, we use the concept of use cases constantly by playing out what our trip will look like. For example, say we are planning a camping trip, we need to plan what to bring (because no one wants to be stuck in the woods without the necessary supplies to care for a two year old). So we could play it out in conversation, my wife may say to me “Honey, we will be changing a few diapers while we are in the woods so we will need to bring plenty of supplies.” And I may say “Ah of course! This is a fantastic idea and makes complete sense! Let’s be sure to pack those items so we do not end up in an undesirable situation.” This of course is a bit of a stretch because we would not necessarily need to have such an explicit conversation. At this point in our child rearing experiences we inherently know that diapers, wipes and a sealable trash bag are a must on our packing list. However the point I am making here is that all of us do this in our heads on a daily basis, whether it is for a camping trip, a grocery store run, or something else that needs to be planned. It is a natural part of our psyche, so it makes sense that this can be effectively applied in a work situation as well.

In the event that use cases are not used for a project or at least not done so properly many negative consequences may occur. The worst case scenario would be a complete mismatch between what the stakeholders are expecting and what the development team delivers. In the camping trip example this would be the failure of one spouse delivering what the other spouse is expecting. Projects that fail to keep communication lines open between stakeholders and the development team are at a very high risk of this landing in this situation. It is easier than you might think to accidently “fool” the stakeholders of what is being developed. Without consistent hands on functionality demonstrations and reviews it is hard to really get a pulse on how closely aligned the development work is aligned with the project requirements.

Use cases help to mitigate this risk by bringing together all parties on agreement and understanding of the story the software should tell, that is, the functionality that the user will interact with, the problem being solved, and how from any end user’s perspective it solves it. Not using use cases usually results in the developer writing code as directed but without at least in part understanding why. This results in a high risk of delivering a solution that is far off the original target as understood by the stakeholders. In the camping example from above this would mean a messy situation in the middle of nowhere. In which case I would at least hope there is a water source and the temperature is not too cold! In a work environment this means money lost, unhappy customers, or worse: patients not properly cared for because the system the clinician is using does not provide the appropriate functionality.

Use cases need not be complicated. If you are in doubt of how to start my suggestion is just to write a short narrative of what you want to accomplish. If you find your narrative becoming overly complex then split it apart to more manageable pieces. Most importantly remember that use cases are meant to help clarify the business requirements, improve communication and ultimately create better results in whatever situation they are applied to.