Monday, February 4, 2013

Mass Customization based on HIE Standardization

Building the Dell Computers of Health Information Exchanges (HIE)

In earlier posts, "Game Changing Healthcare Information Exchange" and "Weaving the Fabric of Care", I included examples of mass customization as an enabler of accountable care programs. What I left out was the fact that Standardization is the enabler of Mass Customization. Instead, I relied on an earlier post on "The Well Architected HIE and Direct Push", which points out the benefits of standardization using a Services Oriented Architecture and a Common Information Model for HIE. While I thought this was enough, I now think I need to explain more about the relationship between mass customization and standardization.

After a recent meeting on Medicaid Health Homes with several stakeholders, including the state department of health (DOH), I came to understand that some may see customization and standardization as opposing thoughts since they are somewhat antonyms. Actually though, standardization is what makes mass customization possible. In this meeting, I found myself explaining that "your (health home) secret sauce for managing care doesn't have to be the same as that of the next health home". I was attempting to explain in lay terms that "they could have custom business rules and orchestrations to notify them of what they want to know about when they want to know it" and that they could have a "custom dashboard" in the portal. This was confusing to the audience as they were talking to another HIE about a common user interface that everyone would use. So I went on to explain that we standardize at the data model, not at the user interface. At the orchestrations of business services and data transformations, we support customization to support a business process. This supports the fact that, while they don't see themselves as having "secret sauce", the information and events that they were asking for differed by organization because they had different business processes that they wanted to enable via HIE. Thus, they had a custom business problem that needed a custom solution.

I realized that I needed a better way to explain this than "secret sauce". So after the meeting, I thought about how they explain it in business school. Typically, B-schools use the Dell Computer Case Studies. Dell made its mark on the world offering custom products at packaged product prices with quick turnaround via mail order. Dell was able to do this because of the standardization inside of the personal computer. Since computers have a modular design built around a bus architecture, people can choose any combination of capabilities and all that needs to be done is the technician plugs them into the bus. The customer picks their case, motherboard, processor, memory, video card, sound card, keyboard, mouse, etc. The technician plugs it all together because it is all standardized to fit any PC. There were many case to motherboard combinations to choose from. There were many processors that you could use with that motherboard. The video and sound cards plugged into the common bus. The memory plugged into the memory bus. It was all easy to customize because standards enabled customization.

The HIE, like the desktop PC, is based on standardization within a bus architecture. On that bus, the enterprise service bus (ESB), you can have orchestrations and transformations that offer a customization to meet the business need. This is mainly going to be felt as notifications and dashboard mashups that are unique to a care management program. Each program, with different business goals for different patient conditions, may need to monitor and manage differently. This is what I call "mass customization through standardization for care management".

I also think that the HIE makes sense to be the enabler of this mass customization because of its unique position with the health information. The HIE is both the data repository and the patient consent enforcer. For example, some complex business processes need to rely on a choreographed processes by which one entity (e.g. a hospital) decides to contact another entity (e.g. a practice) based on what it knows about a patient in order to determine if there is more to be done or to know. The practice collaborates and uses what it knows to assist the hospital and provide more information or consume more information. This is a complicated iterative peer to peer interaction with different steps in the choreography having different knowledge about the patient. This is very expensive to do in the current healthcare world because it involves a lot of human labor for the interaction. In the HIE, we can actually automate this by having two or more separate orchestrations (one for each entity) that act upon their rights to the patient data. These can even invoke human interactions (e.g. via a task queue) as a long-running process. This composition of separate business processes is known as choreography in SOA/ESB terms. In this way the HIE can automate very complex business interactions, made more complex by patient data rights protections, and become a Low Cost Producer of Business Process Management and Execution between trading partners. I think this is one of the promised value proposition of HIE. It reduces time and labor for collaborative care. This is also similar to the Dell Case as they were a low cost producer of custom PCs because they could assemble to order at the same cost as a mass manufacturer rather than at the one-off cost of a local supplier.