Building an HIE Solution: The Theory

Initiate's Bill Klaver helps you think through your HIE plan to avoid obstacles
We’ve discussed the challenges facing HIEs as they try to share information across disparate systems, as well as the importance of IHE profiles. But how do you actually go about building an HIE?
Start by understanding the current standards used in healthcare, within IHE, and by the vendors in your environment. Then understand how you fit into any local, regional, state or national initiatives.
Canada, for example, has Canada Health Infoway, while the US has an array of different sets of standards and initiatives, including ONC, HIPPA, HITSP, CMS, HHS, NIST and others.
The more you know and understand about standards, how they are being used and who is mandating them the better your chances to qualify for funding by government agencies.
Next get a detailed understanding of your current environment, understand what business processes need to be integrated, what data needs to be shared, how the data and processes need to be protected, and what systems provide critical components to your environment. This is what we commonly refer to as Discovery.
From the vendors who provide solutions in your environment start by understanding: what systems and software versions do you already have? Are they the most current versions? What existing interoperability capabilities already exist within and between your legacy systems?
As with any solution, you cannot make wholesale changes so you need to leverage what you currently have. However, if it cannot be leveraged you need to pressure the vendor for changes or replace them.
Make sure you monitor any and all progress and successes to date, revise, adjust, and make everyone accountable from there. Don't forget make sure your stakeholders are on board as early as possible – without them, you won’t get anywhere. Get the stakeholder involved with the discover process.
Then, with stakeholders involved, define your interoperability requirements by educating yourself on what others are doing. Use that insight to build out your use cases and a blueprint. Note that the blueprint should NOT be static; rather it will evolve as requirements, mandates and technologies change. You’ll gain additional information along the way, too, and this will also impact your blueprint.
Next, you must begin to examine the actual technology that will drive the solution. This is a post in and of itself, which we’ll pick up with next week when we talk about PIX/PDQ.
This is part of Bill Klaver's series, Building a Health Information Exchange Through International Standards. For other posts in the series, visit the Table of Contents.
Leave a Response







Entries(RSS)