Advice to Health Information Exchanges

With the HIE grants around the corner, many communities are asking me for advice to prioritize their local/regional infrastructure and applications. Here are my recommendations based on leading an HIE for the past 10 years.

1. Define your business requirements based on the value proposition for participants. This will maximize the likelihood stakeholders will pay for the services they receive, ideally based on gainsharing a portion of their cost avoidance i.e. if a lab costs $1.00 to send via email and .20 to send via the HIE, the hospital can pocket .80 and everyone wins.

2. Ensure you have a business model - subscription-based is good, since grants are not a business model. Transaction fees are an impediment to commerce - they are a disincentive to using the HIE. A fixed subscription fee encourages maximal use of the HIE.

3. Ensure you have policies for consent, auditing, and authorization of trading partners. Policies constrain technology choices and ensure the exchange is trusted.

4. Start with Push transactions. This is a very important point. I've written several blogs about the importance of using the simplest possible standards to achieve the business goal. A RESTful approach which enables clinical data to be pushed from one clinician to another is simple to implement since it leverages existing standards and capabilities of web servers without requiring mastery of more complex techniques. In Massachusetts we push admission notification, discharge summaries, ED summaries and other CDA documents. We're currently implementing push of quality data to registries and public health surveillance to the Boston Public Health Commission. The advantage of Push is that it does not require a master patient index, since the messaging is provider to provider or organization to organization. Consent is easy since the patient simply consents for the push. Wes Rishel has written several great blogs about this approach, which are important to read as they reflect some of the discussion in the HIT Policy Committee's NHIN Working Group.

5. Have a vision for Pull transactions. At some point, the usual ED use case will be mentioned - how do you pull together the entire history of patient from all the sites they have received care in a community? You'll need a master patient index, a record locator service (what institutions have records on the patient) and a means to pull summaries from each site. This pull infrastructure is much more complicated and expensive. Consent is much more complex - who can pull what from where and when? Instead of a provider to provider push involving two clinicians, pull could result in hundreds of people viewing a record. Push is great, but it really does not help the Emergency Department gather data about a patient for life saving treatment. Eventually we'll need to implement Pull.

As I've said in my blog about the Genius of the AND - the right approach is Pull and Push - REST and SOAP.

In the upcoming weeks, we'll have the interim final rule on standards. In the upcoming months the NHIN Working Group will provide us with policy guidance. The 5 points above plus the work of the HIT Policy/HIT Standards Community should provide the guidance that HIEs need.