Communicating Across Institutional Barriers
By Robert Rowley, MD, co-founder and Chief Medical Officer of Flow Health
Twitter: @RRowleyMD
In healthcare, there has been much talk and much activity within health IT circles about communicating across institutional barriers. We are now in an era where a majority of physicians, and most hospitals, have moved from paper recordkeeping to Electronic Health Records (EHRs). By-and-large, these EHRs are implemented within healthcare institutions (hospitals, large delivery systems, and independent doctors’ offices), and the medical data about patients is confined to the institution that created them. To date, EHRs do a poor job of communicating with each other across institutional lines.
Two kinds of problems arise when data about a patient doesn’t flow well from one setting to the next: (1) duplicated services are performed (one party doesn’t know that the test has already been done by someone else), which is wasteful, and (2) gaps in care arise, where something that should be addressed simply “falls through the cracks.”
Some large-scale institutional EHRs have done a pretty good job of facilitating communication about patients between different places within that institution – hospital to emergency department to in-house medical clinic. Often, though, the tools are cumbersome, and clinicians use alternative work-around ways to communicate with each other, including non-HIPAA-compliant methods such as text messaging and email. And communicating about patients outside the walls of the institution often falls to phone-and-fax, as good collaboration tools simply haven’t been developed yet.
With attention being paid to addressing this dilemma, there has been some confusion between simply communicating and actually collaborating. What is the difference?
Simple communication
A number of companies have arisen that offer HIPAA-compliant alternatives to text messaging – the field, in fact, is pretty crowded. Most of these offerings are intended for use inside an institution, linking with the institution’s Active Directory, so that managing the trusted identities of each end of the communication is done by the institution’s system itself (and does not fall on the communication vendor).
The use-case here is that clinicians within a hospital communicate with each other all the time, often using non-secure methods such as SMS texting, even though the hospital uses an EHR system that can allow in-house messages.
Creating the ability for individuals outside of an institution to sign themselves up, and go through a rigorous authentication process that verifies they are who they say they are, is a step beyond simple in-house secure text messaging. GroupMD, for instance (the predecessor to Flow Health), is an example of messaging that can cross institutional barriers and allow self-signup of community physicians.
However, all of these efforts are simple point-to-point free-text messages between verified users. There is not a “hook” into patient data, so that the only way that patient data can be communicated is via attachments to the message. Putting the attachment into the patient record is manual, voluntary, and not something visible upon further conversation about the patient. The sender and the recipient’s medical records (assuming they are on different systems) remain separate, just supplemented by message attachments when they are sent (not unlike faxes).
Collaboration is more complicated
In order to expand a secure text messaging tool and allow identification of the patient, and therefore create the ability to capture the conversation and attachments into a patient-centered data layer that perseveres over time – this requires building a “hook” within the communication tool. This is not an easy task, and involves several things which are hard to do. It also goes beyond identifying and authenticating the endpoints of the conversation, which (for the sake of this discussion) will go assumed.
Hard thing #1: The first element that must be built is a rigorous way of uniquely identifying the patient. Each institution may refer to the patient differently. There are no universal patient identifiers in this country. In order to bring it all together and unify the data feed into a single place, a high-specificity patient identification engine must be built.
Hard thing #2: The second element that must be built is a universal clinical data architecture that can accommodate medical data from many different sources. Fortunately, with Meaningful Use 2 specification for EHR vendors in 2014, there are some standardized data formats that can drive clinical data. The Consolidated Clinical Document (C-CDA) allows capture of much clinical information. Other data types also need to be captured, and need to be parsed into a central data store. Therefore, a good HL7 parser needs to be built, which can feed the clinical database. The source of each data element that is brought into the data store needs to be kept track of.
Hard thing #3: Consent and permission for access to a patient’s data needs to be managed. A patient-centered consent model needs to be created, so that only those people who are given permission by the patient are able to see the data. Different kinds of data might be visible differently to different viewers, like a timeline where some elements of the feed are visible and others are not, depending on consent and permission.
These pieces are technically challenging, but must all be in place in order that a communication tool can capture clinical data and store it in a patient-centric, longitudinal way. It is like building a bridge, which must be completed before the first car can cross.
The way forward
However, once such a platform is built, then a whole new era of health IT opens up. By way of clinical collaboration, patient data can be built incrementally with each encounter in the healthcare system. This can be from peer-to-peer communication about patients, but with “2.0” versions of the secure texting tools that allow a “hook” into universal patient data. It can also come from broadcast of Admission/Discharge/Transfer automated messages from hospitals and emergency departments to outside clinicians. It can come from community-to-community referrals of patients in a disconnected outpatient environment, or from requests for medical records from one clinician’s office to another.
By building the infrastructure, these kinds of tools begin to create a cumulative, independent patient-centric data layer that can become quite robust and valuable. Once most of the information currently siloed in local EHRs is uploaded into this universal layer, the fundamental value proposition for EHRs changes. They are no longer “all-in-one” applications, but can be modular, smaller, UI-only tools that are designed for specific clinical settings, which can all interact with the same patient data.
This is a profound and fundamental change. Over the next few years, the health IT landscape will look quite different.
About the Author: Dr. Rowley is Co-Founder and Chief Medical Officer of Flow Health. Previously, Dr. Rowley served as Chief Medical Officer of Practice Fusion. This article was original published on the Flow Health blog and it is republished here with permission.