Skip to main content

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.

Comments

Post a Comment

Popular posts from this blog

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR) I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor". The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR. In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary ...
7 comments
Read more

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between provi...
3 comments
Read more

"Version the Verb" is more efficient with "HIE the Noun"

What happens when you version the standards for P2P exchange? One of the key value propositions of "HIE the noun", for example an Enterprise Service Bus (ESB) based regional patient-centric exchange, is that it abstracts between data providers and data consumers. Thus, if a new standard comes along, some can implement it and some can hold off. The HIE provides the abstraction between the two. There is no tight-coupling between trading partners. In the "we will all do the same thing peer to peer" model, doesn't it break when something new comes along? Otherwise, every P2P end-point needs to support every standard that emerges as they emerge and until everyone has it implemented, the world is frozen. That sounds an awful lot like where HIT is with ICD10 right now. Most systems seem to have tightly coupled to the ICD9 codes rather than having an abstraction in their system between internal coding and the outward facing standard codes, now they have trouble upg...
Post a Comment
Read more