I voted "Some". Mr. HISTalk requested an explanation, so here it is.
I work for one of the larger EHR vendors. in clinical support. For decades, all our interfaces have been HL7 based, with sporadic success. Very few of those were even web based. It wasn't until about two years ago that we introduced any API integration to our software. Aside from medical record exchanges, the early results are encouraging. For instance, we eliminated quarterly manual pharmacy formulary updates, and replaced them with real-time web based tools.
A great analogy for APIs is thinking about them like electrical sockets. You can plug any electric device into a wall socket without understanding the first thing about electricity. Thousands of devices "just work" when they are plugged in, and you can worry about what you want to do with them instead of making sure they are getting the right voltage. Similarly, I expect FHIR to power a new generation of connected health tools that are plug-and-play. It will just take us time to develop these tools.
If nothing else, the vendor focus on introducing support FHIR will spark consideration of new ways to use these tools. That can only benefit hospitals.
Mobile Man - 8 years ago
Why would this be any different than anything before? I won't say it's "never" been a technology problem, but it's never been a technology "problem"...
Malvern - 8 years ago
It would be interesting to find out how EHR vendors are deploying FHIR internally. The limited data I have says that such use is minimal, but it is a very small sample from a very large vendor.
ManAboutTown - 8 years ago
I'm trying to keep my expectations fairly low. I expect there will be limited improvement, and while I'm a fan of FHIR it is not magic pixie dust. Interoperability will only occur as the business model for healthcare changes
HIT Geek - 8 years ago
FHIR is an API specification. It does not specify how data gets to the API, nor what happens after a corresponding API receives it. Being stateless, it does not support a workflow with state transitions, nor coordination of multiple related actors. The data vocabularies referenced in FHIR, such as clinical code sets, are not controlled within the FHIR standard. The underlying RESTful transport specifications for FHIR are also not controlled within FHIR. The corresponding EMRs, IHRs, and PHRs are outside of the standard, And it says nothing about the end-user interfaces needed to create, read, and update data. The policies and regulations envelope for FHIR is a political and organizational crazy quilt, inhibiting interoperability even if FHIR supports it.
Similar things could be said about HL7 v2 and v3, including CDA.
While FHIR promises to resolve some technical issues, and that's certainly a necessary piece of the puzzle, we still have a lot else to do. The referenced and supporting standards for FHIR are relatively easy to coordinate, but will require ongoing effort. FHIR itself will need to evolve to incorporate changes in health care data, also with ongoing effort. Permanent sources of funding for the work, and willing participants, are needed. Volunteerism needs to be obtained from a wider set of sources and disciplines, including patients.
Dealing the crazy quilt is the most difficult problem. It's a whack-a-mole with more moles than wackers.
Furydelobongo - 8 years ago
I suspect I won't live to see true interoperability. What I expect is that an entry in System A can show up in System B as though it was natively entered directly there. Not that I can be treated to a "unified view". It simply isn't enough. Academic discussions of transport models or vocabularies focused on proving how clever we can be don't feel as though they will ultimately align with clinical workflow. While I'm glad we can make 835/837s from each disparate EMR, I'd be giddy if I thought that everyone knew I am at risk of anaphylactic shock after a dose of penicillin. Perhaps we should stop using the term interoperability until it actually is.
All hat no cattle - 8 years ago
Until fhir learns to handle data import, it will not make much difference. Also there needs to be some agreement on how receiving systems will display incoming data. While reading data is a start,it is now enough.
I voted "Some". Mr. HISTalk requested an explanation, so here it is.
I work for one of the larger EHR vendors. in clinical support. For decades, all our interfaces have been HL7 based, with sporadic success. Very few of those were even web based. It wasn't until about two years ago that we introduced any API integration to our software. Aside from medical record exchanges, the early results are encouraging. For instance, we eliminated quarterly manual pharmacy formulary updates, and replaced them with real-time web based tools.
A great analogy for APIs is thinking about them like electrical sockets. You can plug any electric device into a wall socket without understanding the first thing about electricity. Thousands of devices "just work" when they are plugged in, and you can worry about what you want to do with them instead of making sure they are getting the right voltage. Similarly, I expect FHIR to power a new generation of connected health tools that are plug-and-play. It will just take us time to develop these tools.
If nothing else, the vendor focus on introducing support FHIR will spark consideration of new ways to use these tools. That can only benefit hospitals.
Why would this be any different than anything before? I won't say it's "never" been a technology problem, but it's never been a technology "problem"...
It would be interesting to find out how EHR vendors are deploying FHIR internally. The limited data I have says that such use is minimal, but it is a very small sample from a very large vendor.
I'm trying to keep my expectations fairly low. I expect there will be limited improvement, and while I'm a fan of FHIR it is not magic pixie dust. Interoperability will only occur as the business model for healthcare changes
FHIR is an API specification. It does not specify how data gets to the API, nor what happens after a corresponding API receives it. Being stateless, it does not support a workflow with state transitions, nor coordination of multiple related actors. The data vocabularies referenced in FHIR, such as clinical code sets, are not controlled within the FHIR standard. The underlying RESTful transport specifications for FHIR are also not controlled within FHIR. The corresponding EMRs, IHRs, and PHRs are outside of the standard, And it says nothing about the end-user interfaces needed to create, read, and update data. The policies and regulations envelope for FHIR is a political and organizational crazy quilt, inhibiting interoperability even if FHIR supports it.
Similar things could be said about HL7 v2 and v3, including CDA.
While FHIR promises to resolve some technical issues, and that's certainly a necessary piece of the puzzle, we still have a lot else to do. The referenced and supporting standards for FHIR are relatively easy to coordinate, but will require ongoing effort. FHIR itself will need to evolve to incorporate changes in health care data, also with ongoing effort. Permanent sources of funding for the work, and willing participants, are needed. Volunteerism needs to be obtained from a wider set of sources and disciplines, including patients.
Dealing the crazy quilt is the most difficult problem. It's a whack-a-mole with more moles than wackers.
I suspect I won't live to see true interoperability. What I expect is that an entry in System A can show up in System B as though it was natively entered directly there. Not that I can be treated to a "unified view". It simply isn't enough. Academic discussions of transport models or vocabularies focused on proving how clever we can be don't feel as though they will ultimately align with clinical workflow. While I'm glad we can make 835/837s from each disparate EMR, I'd be giddy if I thought that everyone knew I am at risk of anaphylactic shock after a dose of penicillin. Perhaps we should stop using the term interoperability until it actually is.
Until fhir learns to handle data import, it will not make much difference. Also there needs to be some agreement on how receiving systems will display incoming data. While reading data is a start,it is now enough.