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.
John,
ReplyDeleteYour advice to start with point-to-point push along with a plan for pull is a practical one. Lets not forget that in some environments (small communities and NHIN across larger IDN) starting with both a push and pull is equally workable. In either case, pull needs to be very specifically planned and part of the initial design.
Unfortunately recommending to use a RESTful transport for point-to-point may not a good advice. Let me explain why it seems to be shortsighted:
1 - RESTful is not suited to support a standardized secure and functionally viable pull approach that support the access to structured data clinical documents from an EHR application (Rigid user authentication, akward URL queries, exposure of PHI in queries, etc.).
2 - The perceived simplicity argument of RESTful is far from proven. My EHRA vendor colleagues that deliver small office EHRs are far more concerned with having to support many variants and the incompatibilites generated than they are with the support of SOAP (WSDL is no longer rocket science).
Both of us are advocate for parcimony in standards harmonization. I also remain very open on using RESTful and SOAP, but by chosing the right approach for the right need. We can and we should offer a consistent and 2013 looking standards approach for push and pull of clinical data. Combining this with your deployment advice appears to be a superior winning combination.