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:when test="contains(.,'&#x0A;')">
                                                            <xsl:value-of select="."/>
                                             <xsl:value-of select="."/>
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.