Wednesday, December 26, 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. This is great for planned transitions in care. It is the basic delivery of information from one provider to another. It can be as basic as sending results from a test or study back to the physician who ordered it. It can be a more advanced communication for a care transition between providers such as a hospital transfer or discharge.
 
This is the basic replacement of the fax machine that most HIEs start with. This is the HIE the verb it is accomplished by either peer to peer or centralized HIE services.

More advanced versions of this support active monitoring of the patient. For example, I defined and had my team implement a "Subscribe with Consent" functionality that is the cornerstone of our offerings for care managers. It is essentially, publish/subscribe that complies with the NYS consent policy. This allows the care manager to subscribe to the patient events and get a PUSH notification or document to trigger care coordination. For example, we can send discharge summaries to care managers for the patients from whom they have collected affirmative consent. That monitoring is a value of HIE the noun over pure peer to peer (P2P) solutions.
 

Review Patient Clinical History

This is the primary purpose of the HIE PULL functionality. The PULL has mistakenly been described by some as the naked and unconscious in the ED use case. However, that is not the case. This functionality covers any unplanned or uncoordinated transition in care. Showing up at the emergency department is one of these, but naked and unconscious has nothing to do with it. In fact, if that were the case, I don't think it would work if the treating team could not identify you. It is more likely that the patient is dressed and conscious and has granted consent to access their records. This is also valuable for other ambulatory visits to review recent activity with other providers that your family physician or specialist may have been unaware of otherwise. It saves time and money tracking down records with other providers.

This is the slightly more advanced HIE query/response that replaces phone calls and fax machines and does in seconds what would have taken hours and probably not even been attempted. This is what more advanced clinical HIEs do today. This is HIE the noun as most people see it.
 

Schedule Patient Visits

The clinical HIE is the ideal place to exchange (both PULL and PUSH) schedule data. It gives the provider a view of upcoming appointments and missed appointments. Being able to request appointments and get one scheduled via HIE enables collaboration between the patient, care coordinator (if not the patient), and the care team (all providers).
 

HIE must Support Care Manager Use Cases

Manage Care Transitions

  • Notify Care manager when patient meets criteria for transition assurance.
    • This is the use of functionality such as the "Subscribe with Consent" mentioned above.
  • Track patients enrolled in various management programs
    • This is basically an additional demographic of the patient. What programs are they enrolled in?
  • Schedule Appointments with Practices. 
 

Manage Patient Adherence to Quality Standards and Physician Orders

  • Support direct contact with patient for Follow-up scheduling. The HIE should be able to connect the consumers system (a PHR or similar) for communicating with their care team.
  • Notify Care Manager when patient falls out of adherence or is about to. This can be adherence for quality measures, attending appointments, or filling orders for medications, lab work, image studies, or other referrals.
 

HIE must Support ACO Program Development and Evaluation Use Cases

 
The product of the ACO is lower cost, higher quality care through evidence based management of the patient care lifecycle. Analytics/Reporting against the HIE activities is a mean to close the loop in that lifecycle for continuous quality improvement (CQI).
 

Analyze Current Operation

The HIE needs to support reporting on clinical and financial outcomes with ability to segment and aggregate based on patient care lifecycle (how the patient flowed from point a to point b with or without intervention along the way)
 

Develop New Programs

The HIE needs to support an ability to define a program and enroll patients into that program. This is covered above in program enrollments as well.
 

Implement Change

The HIE needs to support an ability to assign patients to care managers. The care managers are the implementation of the care management program.

This is all about getting the right data sent to the right person. For example, "subscribe with consent for whom?" The answer is for care manager X and ACO Y or for the PCP, etc.
 

Measure effectiveness

The HIE needs to support the reporting need as “Analyze Current Operation” but with ability to compare with and without ACO program and cost savings versus the cost of the ACO program itself (Value of the ACO program).

This closes the loop on the question: "Did the program work as we expected it to?"
 

HIE must Support ACO Revenue Cycle Use Cases

 

Track patients enrolled in various management programs

This is simply reporting against the HIE by patient demographics (program registrations are essentially just a slowly changing dimension of the patient demographics).
 

Report Quality for Pay for Performance (P4P) measures.

Ease reporting submission to CMS’s Physician Quality Reporting System as it moves to accepting QRDA XML submissions.
 
Theoretically, quality will be how ACOs and other may be paid in the near future. The HIE is a great vehicle not just to submit these documents but to find exceptions in them and to share them with other providers.
 
By finding exceptions in the quality reports, providers can benefit from increased compensation. The HIE can find where the patient is actually in compliance with a measure and send the information back to the ACO or PCP to recalculate their measures.
 
By sharing the quality reports as sections of the on-demand CDA document produced by the HIE for consumption by providers (The CCD or portal view that providers look at), they can get a quick view of patient non-compliance and have an opportunity to bring them into compliance. This opportunity can occur anywhere in the community, not just at the PCP office. The patient will then get the same message on compliance everywhere they go. They can be bought into compliance during an urgent care visit as well as at their PCP so long as compensation models support/reward it.

 

Summary

 
I think the evolution beyond displacing the fax machine above is what will make HIE a game changer for healthcare. We won't be supporting just a better mousetrap for moving information. We will support better management from better information.
 
 

Sunday, December 23, 2012

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 given up on the SOA/ESB model of exchange, HIXNY would not be where it is today as perhaps the most robust multi-stakeholder exchange in the country. During the process, it was like opening a restaurant with Gordon Ramsey, I had to keep the patrons (healthcare providers) in the restaurant, the cooks (my staff) in the kitchen, and the waiters (HIT vendors) getting the orders right and in line with what we could deliver and when.

The patrons wanted to eat and instead of waiting for their dinner, they wanted to eat some appetizers. Unfortunately, this would take away the stove from the main entree so we had to limit the appetizers to just a few. Those appetizers took the form of minor demonstration projects that were built on fragile infrastructure and would later have to be migrated to the more robust SOA infrastructure we were building. While this slowed overall achievement, it was necessary. Unlike when you cook dinner for someone, they can't see a half-baked HIE and get an estimate of when they will eat. It doesn't do anything the stakeholders will recognize until it is done. Those of us in IT knew when we were 90% of the way there, but the stakeholders couldn't tell 10% from 90%. To them is was all 0% or 100%. So they needed the distraction of minor demonstrations to prove that we knew what we were doing.

The cooks were mainly just afraid that the patrons would storm the kitchen. As long as I just made it clear that we were staying on our path come hell or high water, and they didn't see any fear in my eyes, we were fine.

The waiters were another issue all together. Basically, I had to play them against each other. Who would get an extra reward for being first to take an order and deliver it? Vendor X is going live next week, with all the work you put in don't you, Vendor Y, want to go first? The truth was nobody was going live. They all wanted to test more. The problem was, test data was never going to present all of the variation as production. Somebody was going to have to serve the first meal and hear that the meat is undercooked. Eventually, I got one to move through this competitive positioning and another to follow. The rest would then follow out of competition as well.

Taking Risks and Drawing on Experience


Even one of my key vendors didn't want to support our move to go live with repository exchange for the same reasons. Their exact response was "no don't do it, it’s not ready". I simply told them that they better put on more support staff and expect that we were going to open support tickets. The meals were going out to the patrons, ready or not. We were going to learn and fix at the speed of live production. If I didn't do it, who would? My problem was, I didn't spend two years of my life just to show a test implementation to NYS to get final payment from a grant. I did this to do it for real. So we were going live. We were between CEOs at that moment so I didn't need to ask anybody. It was my responsibility to make the call and my accountability to live with the consequences.

I had the prior experience taking ERP systems live across the globe. I knew that nobody was ever happy enough to take those live either, but we always made it through and had a more successful company at the end. So, I figured we would have some complaints but those would happen no matter when we did it and how much more testing we did. It was go time.

Sticktoitiveness is NOT Following the Herd

I could have followed the herd. The herd was just getting signoff on grants and never putting repository based HIE into production. The herd was so concerned with their customer having a perfect experience that there was no such thing as a "good enough" first effort that could be improved upon. To add to that, some parts of the herd were already moving onto the next thing, like Direct.
We didn't follow the herd and after one year in production with the standards everyone agreed to, we have delivered on the promise. The customers see the value developing. There is still more to do to make this easier and more valuable but we are on the right track. By taking the risk, we eliminated the chance that HIXNY would give up and follow the herd of non-compliance with the state model.

Deliver with Integrity because the game never ends

In the HIXNY case, we have a payoff for now. This is a changing market however. Thus, those who did not stick, may still wind up on top. I suggest anyone building an HIE stick to what they say they are going to do and achieve something besides pulling down grant funds. Even if others pocket more money and perhaps win over you in superficial ways, at least you can have self-respect and there are always other opportunities for those who deliver on what they say they will deliver. The game may change. You may win a round or loose a round. But the game never ends.

Friday, October 5, 2012

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:
  1. What is the security policy of the system that actually authenticated the user
  2. 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 single signon (SSO) solution that allows a trusted connection to establish a session for a user. Or even if you have QueryHealth with a query and response over Direct in the future. Our first question should be, "What is the security policy of the system that actually authenticated the user?" If we have a policy for strong password, limit password reuse, two factor authentication, disable accounts after a number of attempts, maximum session time length, etc. shouldn't this client system to the HIE have to have the same policy or stronger? Yes it should, so these, if not expressed during connection in SAML, should be established by policy with all HIE participants.

Now suppose those web service connections rely on public key infrastructure (usually for SSL client authentication, encryption, and digital signatures). Or, suppose you do HIE via Direct (S/MIME protected email). The private key needs to be kept private. If the wrong person obtains private keys, then public key security is defeated. That person can impersonate the authorized owner of the private key. If the private key is a credential for a hosted EMR, the person can impersonate any of the users that that EMR vendor uses that key for during authentication. So our next questions should be, "What has been and will be the custody and protection of the private key?" and "What happens if you find out a key is compromised?" Then we need to evaluate those answers against our policies to see if we really want to connect to such a system.

From the other side of the equation, we should be asking ourselves, can I detect use of a stolen certificate even though the certificate owner does not know it has been stolen? Are we mapping IPs to certificates and participants? Do we have an XML Firewall (e.g. IBM Datapower or Level 7) in front of our XDS web services? Are we monitoring for unusual shifts in the use of these credentials using event monitoring for fraud detection? If not, maybe we should. Otherwise, maybe the VPN was better.

For password access, one of the most common techniques for 30 years has been to tell a user when they last signed on and from where. That way, if their account was compromised, they know it and can contact a system admin. This closes the loop. For certificates, maybe we should close the loop on federated security by reporting accesses back to the source system provider and they should match to authenticated user activity to find if the certificate was used by another system. This is of course a use case for query of the ATNA repository by the accessing system. However, the reality is that few if any client systems are prepared to close this loop by using query of ATNA.

The above sounds like a bunch of stuff the techies work out and nobody needs to worry about it. However, most of the above is policy not technology. We need to require policies for those we connect. Our password policy or stronger needs to be their password policy. Their certificate management policy needs to be acceptable under our policy. Those we connect to, to pull data from, should have similar policies to place requirements on us. In the end, even if your hospital or practice connects to the HIE via legacy connections and portals, you are still concerned. This is because it is the other guy, and how he is connected, that exposes your data. While I believe today's HIEs are secure, they rely too much on everyone to "do the right thing" without a policy or contractual agreement telling them what that is. So, I am advocating that we need to federate the security policies as we federate the authentication of the user. And we are federating the authentication of the user, because that is what lets them stay in the workflow of one system. So in the end, if we want access to patient data embedded in the workflow, we need to make sure we have good federated security policy.

Thursday, August 30, 2012

"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 upgrading, and nobody can move until everybody moves or the trading partners need to build the abstraction that they missed so that they can do both without losing granularity in the coding. Why repeat the ICD10 mess, build on abstraction!
Part of the argument for a P2P strategy is that current HIE is too expensive if you can even do it. I say ESB based HIE is less expensive than the support of P2P because of reuse and we do it every single day.

Essentially, I only see 3 possible ways to support electronic HIE:
  1. You build on a single standard and never change it so that P2P is inexpensive but is not adaptive to change or extensible for new solutions.
  2. You allow change but still want P2P so everyone runs an ESB and everyone supports every version of every standard and they need to tightly-couple to their trading partners by knowing what standard they support and transforming to that standard.
  3. You have a community service bus, an "HIE the noun", and thus you benefit from reuse. Everyone has one integration with the ESB rather than with each other. And you benefit from abstraction. You don't need to know how your trading partners can send or receive data, the HIE takes care of the transformation.
If option one were a reasonable model, we would all be running Version 1 of just about everything. So logically, that is not going to happen. Option two is what option one leads to once you realize standards version and get replaced. Option three is the cost saving alternative to two where you centralize the abstraction as a service. That abstraction service is called HIE and it is generally provided by RHIOs in the parts of the country that have successfully matured this service. So what is the argument for P2P being less expensive again if it results in every system having to be an ESB and everyone having to know how what their trading partners can support?

Friday, August 10, 2012

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 enterprise service bus best applies to the rules primarily due to its inherent focus on resuability and abstraction. So, if you are building your HIE using an ESB, I think you are probably heading in the right direction.

If you haven't yet met all the rules, you probably are not alone. The rules are what I think we aspire to. They are based on mostly where we are but to a greater degree where we are going.

To answer my title question, our HIE is effective and is mostly compliant to the rules, but like all HIEs, we still have work to do. Abstraction is an area that seems to always need continual maturity for both syntactical interoperability to transform between transports and schemas and semantic interoperability to translate terminology between different vocabularies. Syntactical interoperability allows one to know what the other is saying; semantic interoperability allows them to understand what you mean. This is never-ending work since new standards emerge or version on a regular basis. The abstraction rule is where myself and my staff spend a lot of our time. We see it as a big part of the technical solution value of HIE the noun.

Friday, August 3, 2012

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 process management (BPM) is the loom

 
As I mentioned in an earlier post, the well-architected HIE is based on a Service Oriented Architecture (SOA) and implements an Enterprise Service Bus (ESB). The HIE's ESB is essentially a "Healthcare Process Manager" and provides the ability for organizations to define business processes, otherwise known as "orchestrations", to automate care coordination activities based on events. HIEs provide the event notifications. The orchestrations, usually developed in Business Process Execution Language (BPEL), apply business rules to an event to decide to trigger additional events that drive action or care intervention. For instance, a patient is discharged from a hospital; this can trigger an event for follow-up appointment scheduling. It also may reset the clock on one or more quality measures. Based on either the immediate event (visit) or subsequent time based events (falling out of quality compliance if no more visits) intervention can be driven.
 

Business activity monitoring (BAM) cuts the fabric

 
While BPM allows the implementation of new business processes to manage care, without impeding on those providing care to perform varied activities based on compensation models, BAM lets you grade the effectiveness of those processes and business rules. With BAM we can answer questions like; How many patients are compliant now versus before a change?; How many patients have been readmitted with avoidable conditions based on our business rules?; and How have these changes over time as we change our business processes? This "Healthcare Activity Monitoring" provides the platform for answering all of these questions and driving action to change processes based on results.
 

Dashboards for care managers sew together a finished product

 
The above are implementations of existing abstract technologies for Business Process Management (BPM) and Business Activity Monitoring (BAM). The HIE differentiator comes from using its real-time data feeds to provide services like real-time quality reporting based on standard business rules for healthcare such as NQF quality measures. Additionally, BPM and BAM can provide the flexibility for power-users to define custom business rules and dashboards. Hence, the HIE portal platform can be extended as an application for triggering care coordination through event alerts and quality reporting dashboard mash-ups that meet individual needs.

Why the finished product is better than the patchwork


What we enable using the SOA/ESB based HIE (BPM, BAM, and mashups as needed) to abstract between program management and care delivery is an environment where care is delivered in a uniform manner.

  • With our finished product the management (definition, monitoring, and change) of the programs is on the program managers and not the care delivery. Mass customization using BPEL and mashups allows for many programs to be defined and manages without creating undue burdens. The patchwork alternative puts custom systems in place for every program and undue burdens on care delivery.
  • With  our finished product the patient gets a uniform message from care delivery based on information sharing, including patient history, quality measure compliance, and treatment plans. Thus, the patient can be guided towards the same quality care at any and every point in care.
I suggest that as new ACO and Healthplan programs are launched, they should look first to how they will use a SOA/ESB based central HIE to enable the program rather than put in another silo solution intended to support one programs need.

Tuesday, July 24, 2012

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 summary to a specialist? In this case, the PCP only wants to select the data to be sent, find the specialist in his address book, and press send. He does not want to know, and even his computer system does not want to know, how the specialist receives the data. In this case, perhaps the PCP system is sending via Direct (a secure email containing health information). Perhaps, the specialist receives referrals as Notifications of Available Documents (an email containing a link to the secure HIE repository from where it can be downloaded). Fortunately, a good HIE can seamlessly transform between these and other standards without either of the users knowing it had to happen.
As described in the above example, the HIE works like the telephone network. When you place a phone call, you don't care what kind of phone the other person has and they don't care what kind you have. You can call from a cell phone and talk to someone on Skype or on a 50 year old rotary phone. Doing this provides syntactical interoperability so that one can know what you are saying.
Another example of such abstraction or loose coupling could be results delivery. In this case, an HIE can take a legacy message feed for lab results, translate a local code set into a common vocabulary, transform the message into a Direct message, and deliver it over open standards. This is a value add to the results provider who doesn’t have to change their system and a value add to the receiving medical records system in that they don’t have to support multiple legacy transactions with different mappings into their system.
In the results delivery example, the ideal HIE needs to work like the phone network as well as provide real-time language translation so that one person can speak in Spanish and the person on the other end can hear English. This is the value that a terminology service for vocabulary standardization or translation at the HIE adds to the process. This is what is referred to as semantic interoperability so that one not only knows what you are saying but they also understand what you mean.
This is how SOA for healthcare makes the clinicians and other staff interoperable, not just computer systems interoperable. This is the business focused characteristic of SOA. It starts with the business view of making the medical provider interoperable. Then, we provide processes and infrastructure to support that business.

Friday, July 13, 2012

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 carriage returns that are in the narrative section. This can be done by adding the following code to any stylesheet.
<xsl:template match="text()">
               <xsl:choose>
                              <xsl:when test="contains(.,'&#x0A;')">
                                             <pre>
                                                            <xsl:value-of select="."/>
                                             </pre>
                              </xsl:when>
                              <xsl:otherwise>
                                             <xsl:value-of select="."/>
                              </xsl:otherwise>
               </xsl:choose>
</xsl:template>
I have tested adding this code to multiple stylesheets from HL7, HIE vendors, and EMR vendors. So far, it seems to work well for all.

Another solution would be to insert XHTML breaks <br/> into the narrative data. This should be respected by all of the stylesheets used to view CCDs, but in reality older stylesheet versions from HL7 do not always seem to work properly with this solution either. So, many EMR implemented stylesheets, which are based on the older stylesheets, may not work properly with this solution. Furthermore, since the structure portion of the CCD, refers to the unstructured portion for this data, the structured portion will pick-up this XHTML coding inside of the narrative text. That may not work well for some systems that may try display the data in a form other than in HTML.
While there is no perfect solution using the current CDA schema, which would probably require a new version of the CDA that did not have the dependency between the structured sections and the XHTML sections, we have a workable solution, which simply requires some guidance to EMR vendors on upgrading their stylesheets for better document viewing. I'll keep posting updates on this solution as we work with EMR vendors to include it in thier stylesheets of use one that we provide.

Friday, July 6, 2012

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 implemented a flexible horizontal capability for HIE based on services oriented architecture (SOA) and an enterprise service bus (ESB) rather than simply a vertical HIE application. This is critical because HEAL funded organizations that strictly adhered to SOA should be able to provide PUSH as a service between hospitals and physicians at a faction of the cost of those organizations setting up private HIEs. This is the value of reuse and this is what we are doing today. Overall, I agree with Micky; start with one or two use cases but build a foundation for reuse for all use cases. If your HIE is “well-architected”, it will take more time to create abstraction between data providers for either PUSH or PULL, but the value of reuse and abstraction is what leads to lower costs and greater sustainability for both models together as one.

A “well architected”, not over-architected, not under-architected, solution to me is one that uses a common information model (CIM) to provide a message-based, canonical view of the information being passed from source to destination in PUSH rather than passing what came in as is or doing individual source to destination transforms. This allows standardization of data structures among disparate systems, speeding deployment, and reducing the cost of integration by significantly reducing the number transformations that need to be built and maintained. It also gives the abstraction, or loose coupling, between source and destination so that their individual system changes do not affect each other and they don’t get frozen to their business partner. By using the same CIM for the PULL model, we also have reuse of the adapters built to load data into the exchange, cutting the number of adapters to be built and maintained in half yet again. All of this reuse and abstraction results in sustainability for public HIEs by creating an economy of scale that private HIEs cannot reach because they don’t have the reuse between PUSH and PULL that the larger state or regional HIE can create. This includes the reuse to implement Direct as a transport for push the same as any other protocol.

I propose an HIE should start with PUSH or PULL based on where the financing is coming from but either way the HIE needs to have enough time and funding to build the strong foundation required to do both rather than jumping in with a PUSH platform that won’t meet the need for sustainability, which requires both. I also propose that ACOs should be looking for a state or regional HIEs as an alternative to building a private HIE for Direct Push, as a “well-architected” public HIE should offer lower cost of operation. Some of the failed HIEs after all did start with PUSH but they couldn’t get sustainable because there isn’t enough revenue or cost-justification just around PUSH. As a side note, state and regional HIEs should not be implementing PUSH and PULL as two different systems as this will not yield the same level of reuse as the “well-architected” solution.