|
Health Information Service Providers (HISPs) As noted in the Connecting Technically module, health information service provider organizations (HISPs) provide the framework for secure exchange of clinical messages over the internet between disparate electronic health record systems. A HISP enables users to easily send information through Direct (LINK TO DIRECT SECTION OF TOOLKIT) protocols, while structuring an interface to verify Direct addresses of users and organizations. Additionally, a HISP ensures that clinical messages are sent and received in an accurate and usable manner at both ends of the exchange.
HIEs should consider moving past simply supporting the Direct project as a HISP. There are many ways that an HIE acting as a HISP can create economies of scale for hospitals, payers, and providers. It can:
- act as a trust broker – An HIE can encourage competing entities to share their data by acting as a trust broker between them.
- provide single sign-on services and two layer authentication – An HIE can offer one portal that providers can log into to access data from multiple systems. If an HIE provides single sign-on and multi-factor authentication, workflow can be improved.
- provide credentialing services – Every hospital currently performs credentialing services which can be costly. An HIE has the potential to introduce economies of scale; it can perform these services for all hospitals in a given region thereby reducing costs.
- provide a patient portal – Many hospitals, payers, and providers in a given geographic area will create patient portals. An HIE can create a single portal that pulls data from the entire HIE for a more comprehensive patient record.
- connect with untethered PHRs – HIEs can also provide connectivity to PHRs, allowing the patient to receive information and communicate with all of their caregivers. PHRs that are tethered to an EHR are limited to just that providers data.
- provide consent management – HIEs can provide electronic consent management.
Cloud HIE Technology, in general, is moving more and more to cloud computing (internet based services and storage). HIEs, although traditionally a hub and spoke model, will follow into the cloud. As physicians begin embracing browser based applications, they will move away from applications installed on their desktop. Instead, they will move into a cloud, public or private, that can be accessed through a browser. As more applications become cloud based, HIE services will follow the market trend.
Some HIEs are already using an application service provider (ASP) hosted model. In the ASP model, vendors provide mapping, translation, and data movement services through their own data center, rather than an HIE maintaining its own data center. As HIEs transition toward this model, EHRs will also move towards the cloud. In the ASP model, EHRs can integrate with HIE services at a web services level, rather than at a data level. These applications will be able to integrate in the cloud and provide more complex and innovative services.
While some HIEs are using an ASP hosted model, there is potential to move past that type of model to a true cloud. In a true cloud model, services are not hosted by an HIE vendor, but rather by a third party, such as Amazon, Cisco, IBM, or even a payer. Using a third party allows an HIE to leverage their computing power, making the HIE a more powerful data source. Using third parties will require clear policies and procedures for accessing data. They will need to be open to trusted partners, with appropriate levels of access to the data, to harness the computing power of the third party. HIEs in this case would build the trust framework and social capital for governance of the data. This future state could provide powerful tools for complex analytics.
Service-Oriented Architecture (SOA) SOA is a framework that enables HIEs to connect new and existing applications to the HIE via exposed Web services. Applications from multiple vendors can be integrated into a single infrastructure to provide an easy mechanism for HIEs to offer core and value-added services, to address the needs of the community. As described above, cloud HIEs will need to provide access to trusted third party applications; using SOA will allow HIEs to provide this access with less required infrastructure, quickly – bringing speed to value of the HIE to their stakeholders. It is critical to choose a well architected SOA platform, as one that is not designed well will lead to poor performance and scalability.
Mobile Health Tools are increasingly becoming available for consumers to manage their own health and play a significant role in their care. As HIE solutions continue to harness the capabilities of cloud computing, patient access to health data will continue to evolve. Adoption of mobile technology and availability of mobile health applications have been steadily increasing. Mobile technology allows patients and providers to access health information regardless of setting or location. Much of the work to date surrounding mobile health applications, has addressed patient access to data contained within patient portals or personal health records (PHRs), as opposed to direct access to the HIE. Patients may be able to manage a personal health record and exchange secure information with providers through a mobile device and specialized applications.
Looking towards the future, patients may be able to access and share the robust collection of their health data simply through a mobile device and application. As more and more consumers are opting to use the mobile web versus accessing the internet via a computer, go-anywhere, lightweight mobile applications may be key considerations for the future of HIE and supporting patient engagement. Providers may also use mobile HIE applications to access patient health information when delivering healthcare services in the field, when access to a computer may not be possible. Some HIE vendors have been opening their platform to third party application development, including mobile health applications, supporting access to providers that have not implemented EHRs.
|