Skip to main content

Posts

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,
Recent posts

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to? There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to? How is this a problem? In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of

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

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 providers This is the primary purpose of the HIE PUSH functionality

The Audacity of Tenacity

A Lesson in Strategic Management of HIE Recently I was awarded "The Game Changer" award by the HIXNY collaborative RHIO, where I am the current COO. It was a very nice presentation including a letter of recognition from Senator Charles Schumer. In reflection though, I didn't "change the game". What I did was I continued to play the game long after the other regions around the state abandoned the statewide strategy for other pursuits. As a result, HIXNY is the only real implementation of the SHIN-NY standards. Strategic Management Many years ago, in a class on strategic management, we studied the varied aspects of strategy. Most of it was fairly basic common sense, but a couple of the more unusual aspects of strategic management that stuck with me were serendipity and sticktoitiveness. Thus, I try to never miss an opportunity that falls in my lap, and I try to be tenacious and never give up too soon. Managing Stakeholders and Expectations If I had

Preventing the HIE Cloud from Raining Data

The HIE of yesterday was based on legacy connections across private networks (VPN mostly). Access may have been over the Internet with just a user ID and a password. While this seems little security, it is generally pretty good so long as your password policy is strong and your users understand the basics of passwords (no sticky notes on the monitor). That type of HIE had a centralized security model. Now, I welcome you to the modern HIE, connected by either web services and secure email. This decentralized or federated security model is not something healthcare is used to dealing with. There are two major issues that need to be addressed: What is the security policy of the system that actually authenticated the user Is the system that authenticated the user, actually the system I think it is. Suppose you have users connected via web services for cross domain data sharing (XDS) by which they can pull clinical data into their system or viewer. Or suppose you just have sin

"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