Lessons Learned: 5 Questions You Need to Ask in any Interoperability Project

We spoke with colleagues from across the country to understand what caused their biggest challenges on interoperability projects.  Initially, larger issues such as project funding, governance, procurement, naturally came up.  But when pressed if there was anything they could have done to prevent those issues, most people said no. Looking at the other issues they faced that they felt could have been prevented led to the following 5 questions anybody involved in an interoperability project needs to ask.

What is the complete set of detailed clinical and economic benefits that are expected to result from the data exchange?
If the benefits are not clearly stated and re-emphasized throughout all stages of the project, the thousands of decisions that shape the interoperability architecture and standards throughout the design and implementation phase may inadvertently prevent one or more of the clinical or economic benefits from being realized.  Post-implementation, a benefits’ realization assessment will enable the measurement of success against the expected benefits and begin to build the statistics for future integration project improvements.

Does the project team have common terminologies to describe everything about the system, from the conceptual level through to the physical?
Most people think of terminology as the code sets used to represent concepts, and as such leave the process of developing data dictionaries well into the logical and physical design stage.  Describing clinical benefits requires common terminology that everyone involved in the project needs to understand.

The concept “order” is a perfect example.  To some people it implies a request to complete a task (such as ordering a lab test), to others, it’s a command to complete a task.  The subtle difference is that a request can be denied, or countered with an amendment, but a command needs to be followed.  Proper application of common terminology should be an architectural principle adopted by all projects.

How will users be authenticated to access the data?
At the start of a project you need to plan on how the clinician will be authenticated to access to the data.  Many projects we’ve seen have taken an individual approach to authentication, which leads to a single user having different login credentials for each system they interact with.  This challenge is particularly amplified when the systems are federated and different organizations are responsible for granting access.

If the project is going to require users to create yet another set of login credentials you can expect adoption levels to drop before you’ve even started the conceptual design. Waiting to deal with this challenge until the end of a project is like waiting to check that the projector works seconds before you’re about to give a big presentation.

How exactly are patients, providers, and service locations uniquely identified at the physical level for the sending and receiving systems?
Everyone knows that uniquely identifying people and places is the cornerstone of all eHealth systems.  Often though, the different systems may align at a conceptual or logical level, but divergences at the physical level impact identifier mapping approaches and linking algorithms, which can lead to the wrong identifier being associated with the wrong person or place.  These subtle differences can inhibit the ability to link clinical data to the right patient, ensure consent directives are followed, and implement single sign on.

How will the collection, access and disclosure of information be audited at each stage in the exchange process – from sending application to integration engine to receiving application?
Trying to interpret the numerous laws and policies regarding personal information and personal health information can be an onerous task.   As a result, many projects default to logging every transaction.  However, querying each of these systems using different  approaches introduces a complexity that will prevent a timely response to Privacy Commissioners questions regarding who accessed what information when.

Auditing solutions should not be built for a single project.  Instead, projects should be built with audit in mind.  IHE ATNA is a common interface for audit, regardless of the interface you use to access the data. Implementing a single audit approach across all systems reduces individual project costs and decreases the time required to answer audit questions.

Conclusion
While not an exhaustive list of questions, what was surprising is that these are the same fundamental questions that interoperability experts have been wrestling with for decades.  This leads us to one final question; is this just history repeating itself or a sign that we all need to indoctrinate these questions into eHealth projects?

share this article...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn