Is It Time To Put FHIR-Based Development Front And Center?

I like to look at questions other people in the #HIT world wonder about, and see whether I have a different way of looking at the subject, or something to contribute to the discussion. This time I was provoked by one asked by Chad Johnson (@OchoTex), editor of and senior marketing manager with Corepoint Health.

In a recent article, Chad asks: “What do CIOs need to know about the future of data exchange?” I thought it was an interesting question; after all, everyone in HIT, including CIOs, would like to know the answer!

In his discussion, Chad argues that #FHIR could create significant change in healthcare infrastructure. He notes that if vendors like Cerner or Epic publish a capabilities-based API, providers’ technical, clinical and workflow teams will be able to develop custom solutions that connect to those systems.

As he rightfully points out, today IT departments have to invest a lot of time doing rework. Without an interface like FHIR in place, IT staffers need to develop workflows for one application at a time, rather than creating them once and moving on. That’s just nuts. It’s hard to argue that if FHIR APIs offer uniform data access, everyone wins.

Far be it from me to argue with a good man like @OchoTex. He makes a good point about FHIR, one which can’t be emphasized enough – that FHIR has the potential to make vendor-specific workflow rewrites a thing of the past. Without a doubt, healthcare CIOs need to keep that in mind.

As for me, I have a couple of responses to bring to the table, and some additional questions of my own.

Since I’m an HIT trend analyst rather than actual tech pro, I can’t say whether FHIR APIs can or can’t do what Chat is describing, though I have little doubt that Chad is right about their potential uses.

Still, I’d contend out that since none other than FHIR project director Grahame Grieve has cautioned us about its current limitations, we probably want to temper our enthusiasm a bit. (I know I’ve made this point a few times here, perhaps ad nauseum, but I still think it bears repeating.)

So, given that FHIR hasn’t reached its full potential, it may be that health IT leaders should invest added time on solving other important interoperability problems.

One example that leaps to mind immediately is solving patient matching problems. This is a big deal: After all, If you can’t match patient records accurately across providers, it’s likely to lead to wrong-patient related medical errors.

In fact, according to a study released by AHIMA last year, 72 percent of HIM professional who responded work on mitigating possible patient record duplicates every week. I have no reason to think things have gotten better. We must find an approach that will scale if we want interoperable data to be worth using.

And patient data matching is just one item on a long list of health data interoperability concerns. I’m sure you’re aware of other pressing problems which could undercut the value of sharing patient records. The question is, are we going to address those problems before we began full-scale health data exchange? Or does it make more sense to pave the road to data exchange and address bumps in the road later?

About the author

Anne Zieger

Anne Zieger

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.


  • What will make FHIR work is to have implementations of what I’ve called a ‘patient data custodian’. This custodian is responsible for storage and access to patient data (security, privacy, etc.), data, in part, stored as FHIR documents as events posted to the custodian from provider EHRs, Labs, wearable devices, etc. FHIR can become the ‘canonical’ format that makes interoperability (interoperability with the patient ‘system of record’!) an achievable goal. Hoping to achieve interoperability between EHRs any other way is a pipe dream.

  • John,
    The data custodian would manage the data expressly according to patient desires (within the necessary medical requirements) for sharing. This would include who and in what role the data may be accessed to the field level. Say where the PCP would have access to behavioral data that a referred provider would not, nor the payer, employer, etc. except maybe in the aggregate. PII would not be available to researchers, but other data may without exposing PII.

    Typically, I don’t think data banks are set up this way. Don’t they usually store records from all patients without an unique identifier for the patient?

  • Tim,
    I haven’t actually seen any successful data banks. Just the concept, so there’s that. However, the descriptions I’ve seen for data banks do what you describe. They’re kind of like bank accounts which know each patient and it’s a place for you to store your health record. Of course, there are other companies that just store all the data without the unique patient identifier, but I don’t think they call themselves data banks.

Click here to post a comment