Skip to main content

Posts

Showing posts from 2012

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

"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

Is our HIE Effective?

In " Ryba's 16 rules of effective HIE " published in Government Health IT, I recently wrote about what I believe to be the rules that can be used to define an HIE that is reusable across all use cases. I don't get into what technical implementation it supports or even what type of healthcare information is being exchanged. However, if your HIE complies with these rules, I believe you have a "fully effective" HIE. That said, if it does not, it may or may not be adequately effective for where the world is today. The point is, these rules are what I think exchanges, public or private, should comply with, or at least should be able to comply with, from a functional perspective. How soon you will need to meet all of them will probably be determined by market forces or government mandates in your area. While I left technology out of the rules, if you follow any of my previous writings, you know I of course believe that a services oriented architecture and enterp

Weaving the "Fabric of Care"

There have been a lot of varied models of care management for many years now that are described by terms like Health Homes, Patient Centric Medical Homes, Primary Care, Managed Care, Accountable Care, etc. One thing I have noticed is that the industry seems to skim over the fact that this cannot be a patchwork quilt of care. It needs to be a woven fabric of care that can be cut and sewn into varied models through mass customization. We cannot expect that a provider is going to function differently if the patient in front of them is enrolled in a particular program or not. That certainly isn't going to create administrative efficiencies; quite the opposite. If they have to capture different information, provide different information, or provide different treatment based on how care is paid for; they will certainly be less efficient due to administrative burdens. Therefore, the customization needs to happen in the background as part of the ACO business processes.   Business proce

Using SOA to create Interoperablity between Providers

In the State of New York we have found the key to interoperability for Healthcare Information Exchange (HIE) is in building on a services oriented architecture (SOA). The preferred SHIN-NY 1.0 architecture was based on SOA in order to get the benefits of its characteristics, which are having business focused services based on open standards that provide reusability, flexibility, agility, and loose coupling (abstraction). Abstraction is also one of the foundational concepts of computer science. In HIE, we want abstraction between providers and consumers of information; such that the provider does not have to know how the consumer wants the information and the consumer does not have to know how the provider sends the information. One of our business goals is to make HIE a value-adding process for users in that it transforms between standards without losing the meaning of the content being shared. For example, what if a primary care provider (PCP) wants to send a referral patient summ

Exchanging Care Plans, Discharge Summaries, and other Unstructured Narrative Content

In an ongoing debate about the readiness of HIE for Medicaid Health Homes and other ACOs, one of the issues has been the need to exchange care plans. Unfortunately, I think people are hung-up on the concept of structured XML documents and structured data. Just because the document is structured and contains many areas of coded, structured data; should not be interpreted as though there cannot be sections of data that are unstructured narratives with limited structured elements describing the content such as date/time, author, and type of report. Recently, we have gone so far as to add narrative data in several areas of the CCD where it can be supported. These include pathology reports, image studies, discharge summaries, and care plans. Part of the problem with exchanging this type of data is that the default stylesheet (XSLT) from HL7 for viewing a CDA R2 document, such as a CCD/C32, as an HTML document, does not display narrative data properly. Basically, it just needs to respect

The Well Architected HIE and Direct Push

In "The Dangers of Too Much Ambition in Health Information Exchange" published in ihealthbeat, Micky Tripathi recently wrote about "over-architecting" HIEs. Mickey is correct that HIEs should not try to boil the ocean. However, the final point of Mickey’s article seems to be “Start with PUSH” because it is high value to physicians and low risk. It is true that PUSH is high value to physicians and that it is the primary thing they are willing to pay for. But, this alone will not make an HIE sustainable because physicians and hospitals won’t pay enough for it. On the other hand, Governments and Health Plans have been willing to make longer term investments into the data warehouse that supports PULL of a patient centric record. So to some degree, HIEs have to follow the money. This isn’t such a bad thing as for example the money for New York HEAL grants was to establish a strong foundational architecture for HIE. If regions followed the State architecture, they imple