A lot of EHR systems to date have established mechanisms to enable access to patient data via APIs, but there's one challenge that comes to the fore in working through these APIs in the context of accessing data for Public Health.
Many public health operations work with populations ... patients having a reportable condition, patients with COVID, patients with fill in the blank.
And many FHIR connectivity solutions presume that the "App" is going to be integrated via a Provider or Patient directed solution, launched by the EHR or as a standalone application, and will access data ONE patient at a time, and that patient will be known.
This is not so for some public health uses. For those uses, the app is likely a "Back End Service", the user is likely a system, not a person, and there may not be a provider or patient context to identify what information the system should have access to. FHIR Bulk data is a pretty good example for this kind of use, where a payer wants to collect information in bulk about patients it is concerned with (their panel of covered lives). Public health also has such a panel, but not necessarily unique identifiers associated with the populations they are concerned with. It may instead be a set of characteristics: Patients who are living in, or have been treated in, their jurisdiction.
And so, we see a conflict. The current APIs attempt to ensure that patient data is not intermingled during API access (hey, this is not just a commonly done thing, it's also a common sense rule to ensure patient safety). BUT, there needs to be a way to identify and collect data via APIs that allows public health to perform its duties.
Most of the Information Blocking Provisions are written with HIPAA as the context. HIPAA identifies a few significant organizations: Covered Entities, Individuals (patients), Public Health, the courts and State/Federal government, to grant them specific rights or responsibilities. Public Health generally isn't a covered Entity (in most cases, we'll leave the specific case of local public health providing treatment services out of this discussion -- which they often do).
And so where does Public Health fit with regard to Information Blocking? Can a Provider organization, Health information network, or certified developer of Health IT information claim under the exceptions listed in 45 CFR 171 that there's a legitimate patient safety, privacy, security, feasiblility or performancee need to prevent public health access from asking the question in simplest FHIR form: Show me all observations where code is in the list of COVID-19 testing results AND date is today, and result is positive?
I think this question is quite debatable, and I've seen both sides of this coin. I KNOW what my answer as an EHR Vendor was, is, and ever would be should I find myself in that role again, and that is NO. EHR systems CAN provide that access, some vendors have done so, and I would do so again. BUT, if an EHR vendor doesn't plan for, design for, and account for this need, public health with have to sit in its usual place at the back of the line, before they can get access to critical data to do their jobs.
Keith
For what it's worth, I know every EHR has a way to provide access to population data from outside of FHIR APIs. Arguably, if there is a way to do this safely, feasibly, and securely outside of FHIR, then it can be done using FHIR as well.
I would argue that if there is a way to communicate public health data "safely, feasibly, and securely outside of FHIR" (I'll add "standards-based" to the list as well) then you *should not* attempt to do the same thing with FHIR. Adding two *standard* methods to do the same thing reduces interoperability, as you increase the odds that two parties will support different methods, and not be able to talk to each other. The alternative is requiring all parties to support both methods, which is needlessly expensive.
ReplyDeleteNo, of course, we should never try to advance beyond the current status quo.
ReplyDeleteHaving said that, we DO need to be sure that we aren't just doing FHIR for FHIR's sake when we identify cases for adoption. Labs and Immunizations are mostly meeting the current needs, BUT, where there are additional use cases (e.g., where Immunization data or laboratory data flows to consumers would benefit from the use FHIR and are not part of the existing interoperability solutions), it's worth considering.