The concept of health information exchange (HIE) is really not new. HIEs already have been successfully established in several U.S. and international venues. However, today's healthcare environment increasingly pits the need for comprehensive data access against the need for robust data analytics – with marked implications for HIE structure.
Fortunately, valuable "lessons learned" can be drawn from international, state and local organizations that already have tried various strategies to achieve the right foundation for both data access and analysis. Definite pros and cons have emerged for a single, or "federated," HIE model, while a de-centralized, or hybrid, model utilizing application specific databases also has advantages and drawbacks.
Federated is preferred for access
One large example of a single/federated model is the "Connecting for Health" HIE and Care Records Summary used by the United Kingdom's National Health Service (NHS). While it is a preferred model for data access, it does have significant limitations. Since it's centralized, this model offers a single, authoritative data source that provides consistent data representation though all database access points. However, all disparate applications accessing the database must interpret data independently, which introduces the possibility of inconsistent data use and presentation.
The main advantages of this HIE architecture include uniformity and interoperability. With one database, all of an organization's applications share the same data and users can be confident that the data accessed is "apples to apples." Security can be tightly controlled, and database maintenance and updates are more efficient, too, because updates and maintenance need only occur in one place – avoiding potential data synchronization problems. Furthermore, data is more often than not available in real time.
Despite these benefits, a single/federated database model is not practical or realistic in most cases. The main reason is legacy systems and software. Starting from scratch with a federated database requires a massive hardware, software and data standardization overhaul. Moreover, when data is shared by multiple applications, it may still lose its original meaning through transformation or interpretation by each individual application's logic. For example, a fetal head measurement value of 100 may be presented to a user as a "diameter" in one application but as a "circumference" in another application.
When data is fed into a shared environment by multiple applications, values also may be stored in inappropriate table fields. For example, a clinic's application may consider a "resource" to be a physical room, a person, or piece of equipment. A radiology department application, on the other hand, might enter each of those pieces of data – room, person or equipment – within different fields. Therefore, performing a resource-allocation analysis based on data fed from these applications could deliver a highly variable report.
Efforts to address this issue have been in progress for years, but further efforts are needed to standardize data representation, presentation, transformation and application logic within domains such as medications, orders and results.
Hybrid model is more agile
The model used by most U.S. statewide HIEs is a de-centralized/hybrid architecture. This structure works well with existing applications and HIS/HIT systems – a critical consideration in a healthcare environment full of legacy systems.
One could argue that having separate databases instead allows better customization to the specific analytic needs of each organization, while at the same time feeding critical summary information into a central repository. For example, a university-affiliated hospital may have significant additional, research-based data requirements that can be met in a separate database. With this architecture, data can be transformed in batch mode and placed into a repository. Naturally, however, this results in data that is not maintained in real time. While a hybrid model lacks the advantages of real-time access to data, it affords more agility and flexibility in regard to issues associated with database performance, security and design.
For organizations that have the ability to start from scratch, a single/federated HIE model is ideal. For most of the U.S. and world, however, different forms of a de-centralized/hybrid model are much more realistic, and the hybrid model can be considered as a first step toward a centralized architecture since it is far easier to architect and deploy. The model provides a pragmatic and cost-effective centralized database solution and is often the only choice for cost-constrained organizations. To mitigate risk within the hybrid environment, the standardization of both data transformation and presentation business logic is essential.
In either model, the only way to ensure that data is used correctly by applications and is presented to users as intended is to work further on the three layers of data, logic and presentation standards. Only when healthcare finally reaches a consensus on this standardization will we truly enable a robust health data exchange.
Andrew Underhill is Chief Technologist for Systems Made Simple, Inc. (SMS), provider of IT systems and services to support critical architecture, data and application challenges in the healthcare industry.
