Most of the interoperability problems we have today can be readily solved. All we have to do is replace the systems we already have in place with newer better technology. Does that sound like a familiar strategy?
If you've been involved in Meaningful Use or EHR certification activities over the last decade, then it certainly should. The introduction of CDA into the interoperability portfolio of vendor systems has created a whole host of new capabilities. We added something new.
HL7 Version 3 attempted to replace HL7 Version 2 and it basically was a flop for most of its use cases, in large part because of the tremendous investments in existing infrastructure that would have to be replaced, and which in large part met some viable percentage of the capabilities that the end users were willing to live with and WEREN'T willing to spend the funds to replace with a more capable (yet complex and expensive) solution.
CCDA was a very effective change to the existing CCD and IHE specifications, and incorporated more or less modest changes. It may have been more than most wanted, but was at least little enough to retain or enhance existing technology without wholesale replacement.
FHIR is a whole new paradigm. It adds capabilities we didn't have before. It replaces things that are more expensive with things that can be implemented much more easily and cheaply. And it changes some things that can still be adapted. For example, an XDS Registry and Repository infrastructure can be quickly modified to support FHIR (as I showed a few years back by building an MHD (IHE Mobile Access to Health Documents) bridge to the NIST XDS Registry and Repository reference platform).
The key to all of these improvements is to ensure that whatever you are adding, replacing or changing: The costs to the customer (or your own development) are going to be acceptable and adoptable by them (or you) and the rest of the stakeholders in an appropriate time frame. FHIR has succeeded by taking an incremental approach.
The birth of FHIR was almost seven years ago. FHIR at 6 and 7/8ths years old (because young things care about halves and quarters and eighths) is doing quite well for itself. In that time, it has come a very long way, and very fast. Version 3 never had it so good. The closest standard I can think of that had anything close to this adoption curve was XML, and that took 2 years from initial draft to formal publication (FHIR took 3 to get to its first DSTU), and I expect widespread industry adoption to the final form (Release 4) to be well inside 2 years. Whereas it took XML at least 3 and some would say more (although it's industry base was much larger).
So, as you think about how we should be improving interoperability, are you Adding something new, Changing something that already exists, or Replacing something? Answer that question, and then answer for yourself the question of how that is going to impact adoption.
If you've been involved in Meaningful Use or EHR certification activities over the last decade, then it certainly should. The introduction of CDA into the interoperability portfolio of vendor systems has created a whole host of new capabilities. We added something new.
HL7 Version 3 attempted to replace HL7 Version 2 and it basically was a flop for most of its use cases, in large part because of the tremendous investments in existing infrastructure that would have to be replaced, and which in large part met some viable percentage of the capabilities that the end users were willing to live with and WEREN'T willing to spend the funds to replace with a more capable (yet complex and expensive) solution.
CCDA was a very effective change to the existing CCD and IHE specifications, and incorporated more or less modest changes. It may have been more than most wanted, but was at least little enough to retain or enhance existing technology without wholesale replacement.
FHIR is a whole new paradigm. It adds capabilities we didn't have before. It replaces things that are more expensive with things that can be implemented much more easily and cheaply. And it changes some things that can still be adapted. For example, an XDS Registry and Repository infrastructure can be quickly modified to support FHIR (as I showed a few years back by building an MHD (IHE Mobile Access to Health Documents) bridge to the NIST XDS Registry and Repository reference platform).
The key to all of these improvements is to ensure that whatever you are adding, replacing or changing: The costs to the customer (or your own development) are going to be acceptable and adoptable by them (or you) and the rest of the stakeholders in an appropriate time frame. FHIR has succeeded by taking an incremental approach.
The birth of FHIR was almost seven years ago. FHIR at 6 and 7/8ths years old (because young things care about halves and quarters and eighths) is doing quite well for itself. In that time, it has come a very long way, and very fast. Version 3 never had it so good. The closest standard I can think of that had anything close to this adoption curve was XML, and that took 2 years from initial draft to formal publication (FHIR took 3 to get to its first DSTU), and I expect widespread industry adoption to the final form (Release 4) to be well inside 2 years. Whereas it took XML at least 3 and some would say more (although it's industry base was much larger).
So, as you think about how we should be improving interoperability, are you Adding something new, Changing something that already exists, or Replacing something? Answer that question, and then answer for yourself the question of how that is going to impact adoption.
0 comments:
Post a Comment