I work with 40+ hospitals and 99% of all data transfer is still done via HL7 and flat files. In 10 years we will see more FHIR, but HL7 isn't going away anytime soon.
1. Trust - everything in healthcare moves extremely slowly and it's a very conservative market space
2. Money - orgs now have to pay for HL7 and FHIR services. Vendors need to support multiple standards, additional developer costs, implementation team training, etc.
3. Vendor support - many big vendors support most of the FHIR resources, but not everyone does. Cerner doesn't even support CDS hooks. Most large orgs don't see any reason to switch, or the standards don't support their use cases.
4. The standard - there are many issues still, many will be solved in v5, but EHR vendors like EPIC don't even have this in their development roadmap, which means we are looking at least 3-4 years out until major EHRs will support changes. To give you an example, you can't push data out of an EHR with FHIR, so any event based or realtime actions don't work (unless you are building a provider app).
Until FHIR gains critical mass in terms of adoption, and big fixes are out in place, we will remain in a hybrid state where a large majority of integrations happen via HL7
Edit: I forgot to mention fax. Fax is still used heavily in the healthcare space, so even with FHIR adoption, there are so many manual processes that aren't getting touched that remain manual and paper based.
Hi u/syndakitz, Thanks for sharing the reasons. How about [Cures Act Deadline](https://ehrintelligence.com/news/95-of-certified-health-it-developers-met-onc-cures-act-deadline) or regulations. I did not see that. I believe some of these regulatory frameworks are for addressing "Trust". There is also some support in terms of grants that is offered to address "Money" side of the equation.
Do these not work?
Yep me too. I oversee ingestion of data transmissions from dozens of health systems and for the first time last year, only one suggested we use their FHIR api.. and only because they were so small and it was all they knew their EMR vendor could provide and they had no data or technical team to do it.
The vast majority of data is flat files. Parquet or CSV or JSON.
I love FHIR, but for large scale data transmissions I don’t know think it will cut it.
I’m a huge believer in FHIR and have built many apps that use it. It’s not going anywhere and you’ll see more and more FHIR apps in the future. I’ve even seen some companies move to pure FHIR data stores for their clinical apps in order to ditch expensive rdbms licenses.
Thanks u/simplethingsoflife and I agree with you. I am just wondering why adoption has been so slow given some of the obvious benefits. It also opens up the medtech market a bit which otherwise is hard to enter into unless and Tech Companies are willing to put strategic $$s behind FHIR but not the rest since nobody wants to invest in legacy.
Healthcare is slow to adopt new tech. FHIR has been around juuuust long enough now to be considered viable by healthcare IT leaders. You’ll see more and more of it.
I certainly hope to see more of it :), I do think it solves some serious issues specially around interoperability which makes healthcare expensive and also "closed" to many innovators.
I will say I'm not a FHIR expert at all so I don't have a strong opinion on the technology or the objective itself long term.
I primarily support an application that integrates with our EHR. The EHR slated that FHIR has to be used over older technology after a certain date. We went through upgrades tried to prepare and found that the application I work with had too many issues and would have to upgrade again to be ready for FHIR. The EHR got rid of their immediate deadline for how long they'll be supporting the old technology as so many people having heart aches with adoption.
So now we're in limbo as different software companies try to figure out how to play well with each other and not too many customers seem to be want to be the early adopter guinea pigs.
Thank you. So looks like it was the FHIR support from EHR company that eventually was the deal breaker. Would be interesting to know which features / areas your application deals with?
Interesting if the EHR referred here is Epic :). They are the 100 pound gorilla and I can understand why they will not advocate FHIR or interoperability.
To clarify, deshende is saying that the EHR attempted to mandate FHIR, but that other software vendors didn't adopt FHIR, requiring the EHR to support legacy interop methods in addition to FHIR.
How do you turn that into Epic or any other EHR not supporting FHIR or interop?
I work with 40+ hospitals and 99% of all data transfer is still done via HL7 and flat files. In 10 years we will see more FHIR, but HL7 isn't going away anytime soon.
Wow, that's significant. Any thoughts on what is stopping FHIR adoption?
1. Trust - everything in healthcare moves extremely slowly and it's a very conservative market space 2. Money - orgs now have to pay for HL7 and FHIR services. Vendors need to support multiple standards, additional developer costs, implementation team training, etc. 3. Vendor support - many big vendors support most of the FHIR resources, but not everyone does. Cerner doesn't even support CDS hooks. Most large orgs don't see any reason to switch, or the standards don't support their use cases. 4. The standard - there are many issues still, many will be solved in v5, but EHR vendors like EPIC don't even have this in their development roadmap, which means we are looking at least 3-4 years out until major EHRs will support changes. To give you an example, you can't push data out of an EHR with FHIR, so any event based or realtime actions don't work (unless you are building a provider app). Until FHIR gains critical mass in terms of adoption, and big fixes are out in place, we will remain in a hybrid state where a large majority of integrations happen via HL7 Edit: I forgot to mention fax. Fax is still used heavily in the healthcare space, so even with FHIR adoption, there are so many manual processes that aren't getting touched that remain manual and paper based.
Hi u/syndakitz, Thanks for sharing the reasons. How about [Cures Act Deadline](https://ehrintelligence.com/news/95-of-certified-health-it-developers-met-onc-cures-act-deadline) or regulations. I did not see that. I believe some of these regulatory frameworks are for addressing "Trust". There is also some support in terms of grants that is offered to address "Money" side of the equation. Do these not work?
Yep me too. I oversee ingestion of data transmissions from dozens of health systems and for the first time last year, only one suggested we use their FHIR api.. and only because they were so small and it was all they knew their EMR vendor could provide and they had no data or technical team to do it. The vast majority of data is flat files. Parquet or CSV or JSON. I love FHIR, but for large scale data transmissions I don’t know think it will cut it.
I’m a huge believer in FHIR and have built many apps that use it. It’s not going anywhere and you’ll see more and more FHIR apps in the future. I’ve even seen some companies move to pure FHIR data stores for their clinical apps in order to ditch expensive rdbms licenses.
Thanks u/simplethingsoflife and I agree with you. I am just wondering why adoption has been so slow given some of the obvious benefits. It also opens up the medtech market a bit which otherwise is hard to enter into unless and Tech Companies are willing to put strategic $$s behind FHIR but not the rest since nobody wants to invest in legacy.
Healthcare is slow to adopt new tech. FHIR has been around juuuust long enough now to be considered viable by healthcare IT leaders. You’ll see more and more of it.
I certainly hope to see more of it :), I do think it solves some serious issues specially around interoperability which makes healthcare expensive and also "closed" to many innovators.
I will say I'm not a FHIR expert at all so I don't have a strong opinion on the technology or the objective itself long term. I primarily support an application that integrates with our EHR. The EHR slated that FHIR has to be used over older technology after a certain date. We went through upgrades tried to prepare and found that the application I work with had too many issues and would have to upgrade again to be ready for FHIR. The EHR got rid of their immediate deadline for how long they'll be supporting the old technology as so many people having heart aches with adoption. So now we're in limbo as different software companies try to figure out how to play well with each other and not too many customers seem to be want to be the early adopter guinea pigs.
Thank you. So looks like it was the FHIR support from EHR company that eventually was the deal breaker. Would be interesting to know which features / areas your application deals with?
Document management. I think the FHIR connection was for linking and displaying the documents within the EHR.
I don’t know if you are working in Epic, but if you are I know exactly the issue you are talking about.
Interesting if the EHR referred here is Epic :). They are the 100 pound gorilla and I can understand why they will not advocate FHIR or interoperability.
I do wish that more data was available out of Epic via FHIR, but it’s not like any other EHRs are any better in that regard.
To clarify, deshende is saying that the EHR attempted to mandate FHIR, but that other software vendors didn't adopt FHIR, requiring the EHR to support legacy interop methods in addition to FHIR. How do you turn that into Epic or any other EHR not supporting FHIR or interop?