BEST PRACTICES FOR IMPLEMENTING AN HIE

 Tips for project managing a health information exchange (HIE) implementation from Rob Horst, Ai director and health information technology leader with over 15 years of project management and health information systems experience. More information about Rob follows this article.

   1.       Do not over sell the HIE!
The adage, “garbage in = garbage out” could not be more true with HIE technology.  HIEs are about standardizing data from multiple source systems into a consolidated view for clinical use.  HIEs are not EHRs – they don’t have the depth of functionality that users might expect and they definitely don’t look as sexy as some EHRs do.  Most also don’t have the robust reporting features that might be expected or assumed.  As a result, the data an HIE renders is highly dependent on each source system’s adherence to standards such as LOINC, RxNorm, SNOMED-CT, as well as the quality of the data in those systems.   Throughout an HIE project, you can expect that most source system EHR vendors will not move swiftly to make the necessary changes to their data so that it renders properly in the HIE.  As a project manager, expect to manage many requests to manipulate, or “normalize” source system data so that it displays more cleanly in the HIE.  These requests can cause significant delays to your project.  Set the proper expectations from day one and rely on your clinical stakeholders to manage expectations with the physician community.
   2.       Ensure clinical stakeholder involvement
“The physicians will love this feature, let’s just add it.”  Making assumptions inside of the confines of an IT department about HIE data presentation, user interface, look and feel, etc. is dangerous and can result in wasted time, effort and money.  No matter how good your intentions are, you should always plan on having your clinical stakeholders both sign off on new requirements and test them once the software is delivered.  HIEs are relatively new technologies, which makes it challenging to find clinical stakeholders that have the background, time and interest to devote to serving in an advisory role on your project.  Once you find them, use them and use them often.  I have been successful with an HIE Clinical Design Workgroup that meets twice per month.  The group understands what HIEs are and are not and serves as a conduit to communicate with the clinical user across the organization.
   3.       Prioritize HIE use cases
Inside of a large hospital network or IDN, the idea of an HIE excites a lot of people.  Let’s face it, it is an exciting prospect to have all of the clinical data in one place.  Your HIE use case “wish list” will grow quickly as word spreads about the ensuing implementation.  Entertain the ideas, but make no commitments.  Of course every person that requests a new use case will think theirs is the most important, so respect their viewpoint, but be clear that their use case will need to be reviewed and prioritized by your project stakeholders.  Your roll as project manager is to gather the requirements for each use case, communicate them to stakeholders and help them prioritize the list.  Some use cases will be easy wins – they might have high value to the organization with a low level of effort and complexity using “out of the box” HIE functionality.  Others may be of low value to the organization, but high level of effort and complexity.  I was successful in developing a matrix that weighed the value, level of effort and complexity for each use case and then broke them into project phases.  This tool helps keep the project more focused and acts as a “bible” of sorts to log all of the use case requests.
   4.       Communicate complex technical details into layman’s terms
While a project manager does not need to have the same background as say, an interface analyst, they do need to know enough about HL7, IHE profiles, master data management and the like in order to be effective.  Knowing how to communicate about complex technical issues at a high level will serve you well and will keep your stakeholders engaged.  Unless they are highly technical themselves, your stakeholders may not grasp what it means when you tell them, “the HIE cannot render the medication dose, route and frequency because the HITSP C32 specification treats this data as optional and this vendor happened to include it in the html section of the CCD.”  Another way of saying this to a stakeholder would be simply say, “the CCD does not send the medication SIGs in a way that the HIE can interpret them.”  However you want to say it, don’t lose your stakeholders in complex technical detail.  Keep it high level, think of good analogies and move forward while you have their attention.
   5.       Beware of the CCD
There are a lot of assumptions about CCDs.  Some IT executives may assume that every EHR vendor can send and receive one (they don’t think about the transport method), that every CCD will contain the clinical data that they want and that it can all magically coexist with all of the other data in the HIE.  I thought this way a year ago as well, but after seeing how CCDs interact in the real world, I sometimes wonder how this standard will scale.  The meaningful use legislation requires EHR vendors to generate, receive and display four categories of coded patient data with specific vocabularies: problem lists, diagnostic test results, medication lists and medication allergy lists.  The CCD requirements do not include key details about a medication, problem, or allergy; for example, medication SIGs (dose, route and frequency), status of problems, meds and allergies (inactive vs. active), etc. might be inconsistent, or might be missing altogether.  As an example, not having a medication status or SIG in the HIE will cause your clinical stakeholders to delay implementation in the spirit of patient safety, will force you to have the HIE vendor make the necessary fixes and will cause significant project delays.  My message here: build lots of cushion into your project plan for CCD testing and issue resolution.
More information about Rob
Rob Horst is a director at Audacious Inquiry and an experienced healthcare information technology leader with over 15 years of project management experience delivering clinical, financial and other technology solutions. Rob joined Audacious Inquiry in 2010, and was instrumental in the launch and subsequent success of the CRISP Regional Extension Center program. He is currently leading a large regional health system’s HIE technology procurement and implementation, which will revolutionize the data flow and availability between over a dozen clinical systems. In February 2012 he presented at HIMSS, the leading heath IT conference in the nation, on the topic of facilitating effective transitions between long term care facilities and hospital emergency departments, based on his experience as program manager for the CRISP HIE “Challenge Grant” project. Rob also serves as professional faculty for the Johns Hopkins Carey Business School, where he teaches Medical Informatics and recently ranked among the top health data innovators in Maryland.