Daniel Newman, MD, chief medical information officer at technology integration firm MEDfx, recognizes health information exchange as "a laudable goal" in terms of everyday communications, but he emphasizes that it's really part of a bigger issue: making data useful to clinicians.
PhysBizTech recently caught up with Newman for further discussion of HIE as it applies to the small-practice environment. Highlights from that conversation follow.
Q: What have you seen in your own experience that relates to how clinicians utilize an HIE?
A: I was the CMIO of Boston Medical Center and I still practice there. We have several community health centers attached to us, but they have their own databases. Even when a patient was admitted to our hospital, we may not have known what was going on with that patient previously because we had no access to that patient's EHR.
It was a serious issue, so we put in an HIE to start exchanging data. Exchanging documents can be useful, and there are certainly positive aspects of that, but it's not completely within the typical workflow of a clinician.
So how do you take the data and make it usable so that it is right within the clinical workflow? How do you take this extra data and start providing real-time knowledge that allows you and your team to start taking care of patients?
Q: What is your company's approach to making the data usable to a clinician who might be at a community clinic or small practice?
A: An HIE by itself is just a repository with a registry on top of it that allows you to exchange information by matching patients with their demographic information. And usually the HIE comes with a portal -- which we have as well -- that shows you an aggregated look at all the information that's in the information exchange.
Different portals come from different groups, and they have different functionality. So the first step is taking the data from an HIE and sending it in a way that makes sense clinically.
A lot of portals just show a list of documents, so they're not really taking the codified information that's available within the HIE and presenting that information in a way that makes sense to a clinician. A clinical summary of meds, problems, allergies and labs is useful. But if I start having to click through multiple documents to start putting together my own list in my own head of what the meds, problems, allergies and labs are, that becomes a painful exercise. It's not something that physicians are going to accept.
Q: What would be an alternative approach?
A: Our strategy is that the portal has to actively bring in all of the Continuity of Care Documents. A CCD document is structured with most of the information in there having some code behind it -- be it ICD-9 for problems, LOINC for labs, those kinds of things. It's taking that information and shredding those documents, and then presenting codified data in a list that makes sense to clinicians. You can see a med list that gets generated, a problem list, an allergy list -- but you also get to see a timeline of events for the patient, the documents that were created and things like that.
So that's the first way to start liberating data. However, it's not completely within the workflow of a clinician.
New EHRs are becoming more robust. They're able to take that information, shred it, and put it into their EHR directly, which I'm all for. But that's really for new versions of EHRs that are out there. Most people are on legacy applications that don't have that ability yet.
So when I think about accessing data from an HIE, I think about it in a few different ways:
You can have a portal that's external to your EHR that you have to log on to. You can eventually get some good information that way. But it's an extra logon, and it isn't optimal.
You can embed the portal within the EHR in a web tab. Many EHRs have the ability to add a web tab, and then you can look over to that tab to see the information that is external to your EHR. That's much easier to use, but it's not being brought directly into the EHR.
The best option is if you have a newer version of an EHR that can take the information, shred it, and then populate it directly into the meds, problems and allergies list. That allows you to do a reconciliation process as a clinician, and it's definitely the best way to use the information.
Q: What do you mean by the term "shred"?
A: The data in an HIE resides in separate documents. Each CCD is a document, and it contains a snapshot in time of the patient's medications, problems, allergies, labs, etc., in codified format. It's an XML document, which is structured, but it can be presented in human-readable format pretty easily.
So by shredding, you take this XML document, the CCD document, and remove all that codified data and present it within appropriate areas of the chart. So for example, if I shredded through the last seven documents and can show all the medications that were given with some de-duplication, that's a more comprehensive list of medications to help me with reconciliation -- as opposed to looking at just what the last medication was two months ago.
For labs it makes sense because I need to see trends; you don't want to have to scroll back and see a bunch of labs. The ability to shred all the labs and present them in a way in which you can see the trends without having to flip through documents is a much more usable way of seeing the information. When you are making a clinical decision, it's not just whether the lab itself appears as a higher level, it's your clinical judgment based upon the patient's status.
It's really about understanding the patient's entire lifetime record in a way that is easily usable by clinicians.
Q: Are there any potential drawbacks to that approach?
A: What scares me -- and what I think scares most doctors when we start talking about HIEs -- is how much information am I going to have to look at? If I start having access to every single bit of information from multiple hospitals and other specialty groups, what is my legal responsibility? Am I able to get through all that? I'm already doing so much.
So while HIEs help, and you start out in small ways by exchanging the maximum value information, at some point -- which is what we're working on -- you have to take a massive volume of information and process it in some way that can then be presented to clinicians. It may be in a rules-based system for an analytics perspective or a reporting perspective to drive care. You don't want to rely on people to click through information and come up with a list of patients who need to be called today.
Q: How are you approaching that problem?
A: Our plan is to leverage applications that sit on top of the information exchange. So you take the data and you put it into a repository. On that repository you can then run analytics, reporting and rules.
In many ways EHRs are focused on point of care. We're focusing more on the accountable care or population health management group where we need to look at patients over time. Most of the time it's not going to be a physician who is logging on to the system. It's most likely going to be an ancillary member of the staff -- an extender or even a referral coordinator.
So the applications are based upon taking information that comes into an exchange, processing it, and then presenting it in various ways -- a separate web portal application, an embedded application or even sending messages using Direct -- to present that information in a useful format to the entire clinical team.
Q: How would it work in practice?
A: We know that there's a big push to reduce hospital readmissions from Medicare and others. To do that, they actually created a new CPT code called TCM, transitional care management. You can charge the code if you see patients that are complex within three days, or if it's less complex, within 14 days of their discharge date.
ADT [admit, transfer, discharge] messages can be sent directly into the registry section of the HIE. It will show all the times a patient has been admitted or discharged from this hospital or their ED.
We then run a report on a nightly basis off of that information. An attribution model determines which primary care doctor is the patient's doctor. And then there is a report generated that shows all the admissions to the ED or hospital from yesterday with their admission diagnosis, and all the discharges from the hospital specifically.
That can be sent as a single report on a daily basis or in accordance to whatever the request is from the physician. Usually daily is what the physician wants.
The report can be sent through Direct messaging, an email protocol that's secure for handling patient information. It can be sent directly into an EHR -- many are now Direct-compliant because that's a requirement for meaningful use -- or it can be sent to a portal that allows you to review Direct messages.
The Direct message can also be sent to a delegate -- a nurse or nurse practitioner, who can open the report in the morning, see all the patients who have been discharged, and give them a call to make sure they have an appointment to see us within a certain amount of days. It's valuable both in terms of providing better patient quality because I'm following up appropriately on complex patients, but also generating more revenue because I'm charging the higher TCM codes.
Looking ahead, as we move from fee-for-service to ACO models, it will be very important to know exactly where my patients are. Of all the patients attributed to me in the ACO model, I need to know if they are being seen external to my environment.
When you get to the next level of capitated payments and ACOs, your goal is to have practices that trust the information and know they will get reliable information back from you. When I am going to refer somebody, the biggest issue is this: If I make the referral, will the patient actually get the appointment, and will the practice communicate with me when it is done?
With this technology, if a patient gets admitted, I'll know about it. That makes me more loyal, more willing to refer to that hospital or practice. So HIEs can dramatically improve the collaborative experience.