In my last post, I introduced the concept of client-cloud computing as a technology paradigm that stands to advance our thinking about how to build HIEs. This is a model that combines the power of intelligent, distributed client software with the world of cloud computing where applications are made available as Internet services. Today, I would like to dig deeper into the concept of intelligent clients and some of the exciting possibilities that emerge when these two models are combined.
Today’s intelligent clients have advanced greatly from the clients of yore, which evolved from mainframe and client/server computing. Intelligent clients are independent and capable of operating on their own regardless of the state of the Internet connection (i.e., they can continue operation even if the Internet cable is cut). They can interface to local applications like EMRs and PM systems (bi-directionally). They can store and manage data locally without the need for a remote server. They can exchange information directly with other client platforms. They can perform application functions locally.
This level of independence and capability opens up many possibilities. For example, if an intelligent client were to be deployed and interfaced to a local EMR, it could run analytics processes to examine data in the EMR for specific criteria (e.g., the number of patients with HbA1c tests performed in a particular timeframe). It could then report metadata about its discovery to a cloud service that collected this type of analytics data from clients across a community. The cloud service could then report the aggregate number of “hits” discovered in the community across all reporting clients to the interested registry or service.
This simple example flips the notion of data analytics on its head. Conventional wisdom states that we move the data to a registry or repository for analysis. The emerging client-cloud model is to move the analytic intelligence to the data. This greatly reduces the privacy concerns surrounding anonymized data since the data is never distributed outside of the environment. It also gives data control back to the source, reducing the need to decide who “owns” the data or seeking consent for secondary data use.
The ability for clients to exchange information directly and to store data locally also offers a new approach to patient data aggregation and identity management. One emerging model is to use the client to collect information relative to a patient and store it locally (e.g., demographics, insurance, and scheduling from PM systems and hospital ADT data, clinical data from labs, hospitals, EMRs, and others). The client can organize the information into a structured object that can then be exchanged with other clients. Intelligent clients works with these objects in a way similar to how people use email today:
- The client can create an object about a patient and share it with other clients by adding their “address” to the object header (similar to the “To” and “CC” fields of an email).
- Clients can “push” the object to other platforms using a simple, cloud-based messaging service that is similar to email post offices. Like email, each client independently checks with the post office to receive any new updates from other clients.
- Once downloaded, each participating client has a copy of the object just like a threaded email message.If any participating client has new data on the patient, it simply adds it to the object and distributes the new update to other participants in the thread.
If the object is structured in such a way that also captures local patient IDs, the object can be used by the private community of clients as a personal MPI of the patient. Each client can reference the object to see what other clients are reporting on the patient and use the object to update others with data generated locally.
This approach in effect, creates a private social network around a patient and their care team (the group of participants most likely interested in a particular patient). Because it is based on a distributed object, no one outside of the local care team can access the information (they physically cannot see or access it). Of course, the data in the object can be passed to a cloud service to update PHRs, repositories, and other aggregators and services to satisfy broader needs of an HIE community.
The distributed patient object is an ideal model for emerging Patient Centered Medical Homes that require close collaboration among members of the patient’s care team. It may also be an interesting approach to addressing bundled payment requirements in the future (an ephemeral object created for the duration of the episode).
Client-cloud computing has the opportunity to change the way we approach HIEs in the near future to solve problems that have been introduced by technologies of the past (e.g., the patient identity problem was introduced when we started putting patient data in databases – not when doctors started treating patients).
Or, as Einstein once famously said, “you cannot fix problems by using the solutions that created them.”
Amen.
