Stream: social
Topic: Ending the fax (and HL7v2)
Brendan Keeler (May 21 2021 at 14:02):
Some rambling about why old technology persists. Hope you enjoy:
Brendan Keeler (May 21 2021 at 14:02):
https://healthapiguy.substack.com/p/chasms-and-fires
Jean Duteau (May 21 2021 at 14:08):
hmm, he refers to the standards as X12, NCPDP, Direct, and USCDI FHIR, instead of HL7 FHIR
John Moehrke (May 21 2021 at 17:00):
any time a regulation specifically names a "solution", it will create a future problem. Regulations need to be specific about the "outcome" they desire, not the "current best practice to achieve that outcome is XYZ". Regulations move way too slow to keep up with technology, but more importantly technology can move faster than any regulation ever could. Mandate the "outcome" and everyone will optimize the "solution". The solution is often built upon working solutions, almost never is it a totally different technology. Comparing Healthcare to Netflix is not fair. Netflix is a single business that can act on a business driven policy. Healthcare, especially in the USA, is hodgepodge of parties with their own view of what optimum is. Left without policy of the right outcomes, it will never optimize for the whole.
Brendan Keeler (May 21 2021 at 17:45):
@John Moehrke
"Comparing Healthcare to Netflix is not fair"
We're actually in agreement. You say "Netflix is a single business that can act on a business driven policy. Healthcare, especially in the USA, is hodgepodge of parties with their own view of what optimum is. Left without policy of the right outcomes, it will never optimize for the whole."
I literally say this in the next paragraph:
"But when it comes to standards of exchange as the product and our national healthcare ecosystem as the overall total addressable market, that skillful maneuvering is nigh impossible. It’s like trying to turn a cargo ship on a dime. The leaders of a standards committee like HL7 or national exchange network like DirectTrust do not have the luxury of the precise command and control of a normal company. They are constituted of diverse and divergent interests, more often competitors than collaborators, and ensuring uniform adoption is like herding cats."
My whole point of that section is that crossing the chasm is hard enough for a private company, but the complexity of standards makes it nearly impossible without luck or a transformative change. Well-crafted regulation bridges that gap.
Brendan Keeler (May 21 2021 at 17:46):
@Jean Duteau not sure I follow. The USCDI (as a subset of HL7 FHIR) is what has been regulated and mandated, along with the previous standards that the US has regulated and mandated
Brendan Keeler (May 21 2021 at 17:47):
@John Moehrke I think explicitly naming a solution is fine as long as there's an expiration. Explicitly naming a solution ensures we get to a place of uniform ubiquity, but we need to be able to iterate thereafter.
David Pyke (May 21 2021 at 17:48):
The USCDI is not a subset of FHIR, it's a completely different initiative
David Pyke (May 21 2021 at 17:49):
USCDI is a dataset that is aligned with a single FHIR IG (USCore). It has nothing to do with FHIR as a whole
Cooper Thompson (May 21 2021 at 17:50):
The cynic in me is really tempted to make some snide remarks about the US Government being incapable of making well-crafted regulation, but ONC's rules have been (in my opinion) pretty well crafted, reasonable, and moving at a pace that balances optimism and realism very well.
Cooper Thompson (May 21 2021 at 17:54):
I'm not 100% sure I agree with the proposition that we should rip and replace old stuff. Faxing... I can be convinced (easily). But replacing HL7v2 and other electronic options seems undesirable for two reasons: 1) adding a new standard to an existing use case cause a reduction in interoperability, as you increase the chance that two parties implement different standards and can't talk to each other and 2) achieving feature parity is really expensive, not just in time and money, but there is also a major opportunity cost.
Cooper Thompson (May 21 2021 at 17:55):
Evaluating the tradeoffs of old vs. new is important. Very important in my opinion.
Cooper Thompson (May 21 2021 at 17:59):
I actually have this quote on my guru page:
The reliability of a ubiquitous solution beats the functional advantages of a technically superior one.
-Keeler's rule
David Pyke (May 21 2021 at 17:59):
Moving from V2 to FHIR is a definite improvement but V2 will have a place for a long time as there's far too much embedded equipment that can only spit out V2 messages and so many flows require messaging paradigms that we're going to be stuck wiht it for a long time. Forced obsolescence would cause a huge problem with equipment upgrades.
David Pyke (May 21 2021 at 18:00):
Even though you can replace the message paradigm using FHIR, simply having a simple machine send out resources would cause issues if that resource isn't normative (and the machine isn't easily upgraded)
Cooper Thompson (May 21 2021 at 18:01):
Why is moving from v2 to FHIR an improvement? Are you saying just replace the formats? Or move from messaging to REST?
Cooper Thompson (May 21 2021 at 18:01):
When you have a FHIR shaped hammer, everything looks like a nail. I push back on the "FHIR is better than v2" blanket statement HARD.
Cooper Thompson (May 21 2021 at 18:01):
You need to pick the right tool for the job. So you need to know the job in front of you before you can make that statement.
David Pyke (May 21 2021 at 18:02):
I'm well familiar with both (all to familiar with V2). And most of the V2 is good enough crowd is because they've set up workflows that mandate it. Changing to FHIR resources and REST requires workflow retooling and people are already mad enough about changes
David Pyke (May 21 2021 at 18:03):
As a wise man said, "V2 is what cockroaches will be using, long after humanity is dead"
Cooper Thompson (May 21 2021 at 18:05):
Is that good or bad? That demonstrates reliability and usability of that standard. In a lot of ways, FHIR isn't any better than v2. The important point is what exchange paradigm you use (messaging, query/response, pub/sub, document exchange, etc.).
David Pyke (May 21 2021 at 18:05):
Faxing is reliable and usable. So why rail against it?
Cooper Thompson (May 21 2021 at 18:06):
It's a tradeoff. For faxing, security is probably on the other side of the scale.
David Pyke (May 21 2021 at 18:06):
Most faxes now are computer to computer with no actual fax machines involved. So, we need to revise the wire protocol and leave it alone otherise?
David Pyke (May 21 2021 at 18:08):
That's the problem. Any standard, even faxing, can be said to be good enough (with minor changes). That's the attitude that stops us from deprecating old standards
David Pyke (May 21 2021 at 18:09):
Time to end the fax machine, migrate off V2 and move forward with technology from this decade. V2 is 30 years old, time to let it go
Cooper Thompson (May 21 2021 at 18:10):
We shouldn't deprecate standards because they are old. We should deprecate them when there is something that is meaningfully better.
David Pyke (May 21 2021 at 18:10):
But "meaningfully better" is not an objective measure
Cooper Thompson (May 21 2021 at 18:14):
Right, but you should come up with objective measures (which will probably be different by use case). Just being "old" is not a measure I'm convinced is useful.
David Pyke (May 21 2021 at 18:25):
Old isn't the measure, it's the fact that V2 has 60+ ADT messages because the use cases vary so much. Add to that the myriad other messages for all the uses shows that it's time to put it aside and have one that's flexible.
Jean Duteau (May 21 2021 at 18:26):
Brendan Keeler said:
Jean Duteau not sure I follow. The USCDI (as a subset of HL7 FHIR) is what has been regulated and mandated, along with the previous standards that the US has regulated and mandated
Sorry, Brendan, I didn't clue in that you were the author of the post. There is no such thing as USCDI FHIR. There is USCDI which has a number of data elements. Some of those elements have a FHIR resource and/or profile derived for them in the HL7 FHIR US Core Implementation Guide. If you want to refer to FHIR, then you shouldn't prefix it with USCDI.
Cooper Thompson (May 21 2021 at 18:53):
@Jean Duteau you are technically correct, but the term "USCDI FHIR" is used very often within Epic and Epic customers (and probably others) as a shorthand for "sending USCDI data using FHIR R4 APIs conformant to the parts of US Core IG that pertain to USCDI". I think "USCDI FHIR" is likely to become (or already is) a nearly ubiquitous shorthand term.
Cooper Thompson (May 21 2021 at 18:54):
David Pyke said:
Old isn't the measure, it's the fact that V2 has 60+ ADT messages because the use cases vary so much. Add to that the myriad other messages for all the uses shows that it's time to put it aside and have one that's flexible.
I mean in order to achieve equivalent functionality, we'll need to re-invent those 60+ ADT message types in FHIR... Not all systems need event-driven message exchange, but some do.
David Pyke (May 21 2021 at 18:55):
We don't really, the reason all those exists is because of the rigidity of the V2 spec. Most would be wiped out with the level of flexibility from a bundle with a Patient and Encounter in it
Cooper Thompson (May 21 2021 at 18:56):
100% disagree. A bundle with Patient and Encounter don't communicate the event. You need MessageHeader with an event code for that.
David Pyke (May 21 2021 at 18:56):
True, that would be the third resource.
Cooper Thompson (May 21 2021 at 18:57):
Yup. With a list of MessageHeader ADT event codes that is ~60 long...
David Pyke (May 21 2021 at 18:58):
No, not really, they can be summarized
Gino Canessa (May 21 2021 at 19:02):
jumps into the ring (hopefully dressed as a referee instead of a combatant ;-)
Before I say anything else, I'll note that I'm of both opinions here - I would like to see the industry move away from V2, but I'm also in no rush to replace it before the replacements are fully baked (and many areas of FHIR do not meet that bar yet).
I don't think it's difficult to come up with reasons why FHIR is "better", nor is it difficult to find mitigations for those reasons, nor is it hard to find areas where V2 is "better". With so many use cases, trying to assign valuations to each reason (IMHO) doesn't have much value.
As an example, FHIR is more readable than V2. I can pick up an arbitrary JSON or XML representation, even via wire capture, and understand what it is - both overall, and each element therein. When I spent more time with V2 (now I sound like an old curmudgeon), there were sets of messages/segments I could do that with because I spent enough time with those exact ones. Today, I need to look up definitions and count separators.
Does this matter to you in your use case? Probably not. Any company that has been working with V2 has tooling built out such that this doesn't matter. But, if you have ever tried to migrate old data (e.g., no software available) or interop with an old/unsupported legacy system, readable representations are better to work with. If you have a new team/developer, JSON or XML is much more familiar than arbitrary pipe-syntax data. If you are building a new AI model and want to train it, it's easier... and so on.
But because of that, V2 is smaller over the wire. There's a tradeoff here, but hopefully it's moving the needle towards "better" for the industry as a whole. If it isn't, I think everyone would be interested in knowing so those things can be addressed.
The way I see it, most people aren't interested in doing this much work without a good reason. There was plenty of work available with V2, so it isn't a matter of "I need to invent something to have something to do". If V2 met all of the modern needs and challenges, there wouldn't be a FHIR (nor would there have been V3). That said, software is just time and effort - if you want to solve a problem using V2, someone can figure it out.
Lloyd McKenzie (May 21 2021 at 19:03):
I'm not a fan of pushing to migrate existing v2 solutions, but if you were going to, the arguments would be:
- v2 is tied to only messaging, and messaging is a poor fit for a lot of problem spaces
- porting data between v2 and FHIR is difficult and sometimes impossible (particularly if you're wanting to take advantage of a paradigm other than messaging, which would be the primary point of migration)
- v2 doesn't scale terribly well - once you get outside an organization, there's lots of site-specific adjustments implementation engines need to make for data to flow. This seems to be less true for FHIR.
- FHIR's infrastructure for documenting interfaces, discovering interfaces and validating instances is significantly better
- It's cheaper/faster/easier to find both tools and people that can understand FHIR solutions than v2
All that said, I'm not sure those arguments will be sufficient to justify replacing "something that works" for many organizations. It's also risky for a standards organization to try to push implementer decisions on what to adopt. If the community gets the impression "we're going to take things away because we want you to use our new 'shiney'", we're in trouble. We can advise that we think migration is useful and when and why, but in the end, the choice is implementers and shouldn't be pushed by HL7.
Cooper Thompson (May 21 2021 at 19:03):
v2 supports (some) query models. We support MPI and Sched query, and have many active production integrations using it.
Lloyd McKenzie (May 21 2021 at 19:08):
It does, but the degree of consistency across systems varies quite a bit - and there isn't the same graceful ability to discover capabilities and manage filters that weren't applied. So queries tend to need to be set up on a system-by-system basis in v2 more than that's true in FHIR.
Lloyd McKenzie (May 21 2021 at 19:08):
At least that's what I've seen. If you've found good cross-system interoperability with specific types of queries, awesome :)
Cooper Thompson (May 21 2021 at 19:10):
I guess my overall point is that we need to look at the entire list of pros and cons for each technology and use case. We can't just focus on the technical pros/cons. Economies of scale, switching costs, network effects and other non-technical considerations are all valid items to put on the pro/con list alongside the technical items.
Cooper Thompson (May 21 2021 at 19:11):
The perspective of the IT manager at a safety net hospital with a shoestring budget is a great persona to throw this decision at.
Brendan Keeler (May 21 2021 at 19:18):
Okay, I apologize for a lack of sufficiently precise language when discussing USCDI and revise in future posts
Brendan Keeler (May 21 2021 at 19:19):
I see both sides of the debate, which is the point of the article - old technologies persist because of the factors we mention in this thread.
Brendan Keeler (May 21 2021 at 19:20):
I think the legacy of mixed standards is increasingly baggage on people trying to create in healthcare. In many ways, the addition of FHIR for some (but not all) functions actually is worse than a pure HL7v2 world
Brendan Keeler (May 21 2021 at 19:20):
Brendan Keeler (May 21 2021 at 19:21):
Suppose for a use case, I have an API with certain connectivity / transport and then HL7v2 with VPN (or maybe some super custom HTTPS stuff)
Brendan Keeler (May 21 2021 at 19:21):
Support for all of that surface area is costly for servers / EHRs
Brendan Keeler (May 21 2021 at 19:21):
Learning all of the necessary technologies and nuances is costly and hard for app developers
Brendan Keeler (May 21 2021 at 19:21):
And then you multiply across EHRs, with different lines in the sand of what's available or not and in which bucket it lives
Brendan Keeler (May 21 2021 at 19:22):
FHIR doesn't help interoperability in that case. It distinctly increases variability and entropy. A player like Redox becomes more necessary.
Brendan Keeler (May 21 2021 at 19:23):
I get the different perspectives, though. A deprecation of HL7v2 (or X12) would be wild. There would be switching costs and all sorts of others challenges
Brendan Keeler (May 21 2021 at 19:24):
Thus, in that way, that rearchitecture of the fabric of our national infrastructure landscape is not unlike a product team's decision to switch to a modern stack. It could be too much. It could fail.
Gino Canessa (May 21 2021 at 22:02):
Eh, I think the biggest thing to keep in mind is that these kinds of changes take time. Whatever you are thinking? More time that that. =)
Medical devices in particular have long cycles. I'm a few years out from field interactions, but for me it wasn't uncommon to be dealing with systems that were 5 or 10 years old within a given facility. I know of a DICOM archive, still operating today, that I installed almost 20 years ago. It uses a Magneto-Optical library for near-term storage, if that helps explain how old it is. That system does not receive any sort of updates because both the hardware and software companies that made those products are gone; the products were deprecated as End of Life... a decade ago? But the archive works, talks with all the modalities they have onsite, and any new systems must interoperate with it*. That means that software installed there cannot use things like DICOM-web (which didn't exist at the time) without the additional work of a proxy of some sort. Yes, that is more work for someone who wants to use the new areas of the spec. But no, I don't see an alternative without replacing their systems - which nobody can force them to do.
*the physician-owner of the facility plans to retire "soon", so it isn't worth replacing everything. It has been that way for years.
Especially with web technologies (though by no means restricted to them), people have become used to instant changes and forklift upgrades (e.g., changing CSS libraries). Healthcare can't do that. Devices need to go through approvals to ensure patient safety, and even new versions of software need to be tested extensively, which takes time and money. The more extensive the changes, the more time (and money) that goes into that process. At this level, we need to iterate fast and hard on the specifications in order to provide a safe and stable space for implementers. If the benefits outweigh the costs, the industry will transition.
So in my view, progress is painful and feels slow, but the long-term benefits are still there. In the meantime, yes, there are many use cases that will use one standard, the other standard, or even mixes of the two. Not that we shouldn't work to mitigate the pain of it, but as far as I know it's unavoidable.
As far as the potential to fail - sure! Well, sort of. Maybe before FHIR is truly ubiquitous we'll need a new version (FHIRv2 would have my vote to confuse everyone =). But even if that happens, what we are doing and learning will get rolled into it. Eventually, there will be a new "winner", where new systems won't go through the effort of implementing the old specs anymore.
John Silva (May 22 2021 at 00:50):
HL7v2 has a lot of "pre-computer-science" history. I remember talking with folks who were there in the days of V1.x and the "represtatation language" was not even a well-formed computer grammar, which is why parsers for it were (and are) few and far between and are built specifically for it (can't use standard off-the-shelf tooling). However, to be fair, V2 was created before "the Internet" as we know it, in fact, before TCP/IP if I remember right and early interfaces were RS-232 only (if you remember what that is/was) ;-).
However, some of the problems being solved were not just about wire protocols or transports, etc., they were (and are) fundamentally about semantics. V2 folks recognized this an established the Andover Working Group to start to address this problem. In fact, many of the conformance concepts of FHIR are inherited from V2 Conformance work except with more modern computer technologies, e.g. XML/JSON (*), etc. When I first made the "jump" from V2 to FHIR it was nice to be able to use modern tooling but to me much of it was a "different representation syntax" -- Resources vs Segments, fields vs properties, etc. It also seems to me that FHIR extensions are the equivalent of the "bad boy of the V2 world", Z-segments. It seems that there is a proliferation of FHIR extensions and profiles and IGs that maybe help constrain systems to meet common interoperability patterns, but each system needs to be able to understand those IG/profiles/extensions (just like V2 Conformance profiles) in order to get semantic interoperability. FHIR might have the advantage of being able to specific this via computer exchangeable mechanisms but if any system in the workflow doesn't understand any of the extensions, that piece of the interoperability will still be missing. (I still don't know if IG/profile/extension "stacks" can work on FHIR servers - i.e. where a server has to support multiple profiles that do not necessarily have the same common base other than FHIR Rx.)
I think the biggest advantages of FHIR are 1. that it uses computer standard technologies so that Comp-sci trained folks coming out of schools can jump right in and be productive (unlike V2) and 2. it doesn't require a PhD in Modeling Design (like V3) in order to understand the FHIR 'data model'. [Then again, I suspect openFHIR might be "just as good" as FHIR, but it just hasn't got as much traction as FHIR??)
(*) - in fact V2 used XML Schema and Scematron for validation tooling; I believe it took a while for FHIR to add the equivalent validation tooling
John Silva (May 28 2021 at 12:43):
I just remembered the other 'biggest advantage' of FHIR over HL7v2 -- the FHIR specifications are very accessible, not only to (paid) HL7 members but to anyone and everyone. In the 'days of V2' it was hard to get access to the V2 specs if you or your company wasn't an HL7 member.
Brendan Keeler (May 28 2021 at 13:02):
Open docs a huge revolution in and of itself, for sure
Frank Oemig (May 28 2021 at 15:41):
Please see here for all v2 versions: http://www.hl7.eu/HL7v2x/hl7.htm
Lloyd McKenzie (May 28 2021 at 15:45):
HL7 has moved to having all our standards open (in part because keeping the others closed would accelerate their demise), so that's not a differentiator, though we can thank FHIR for starting that process.
Elliot Silver (May 28 2021 at 15:53):
Lloyd McKenzie said:
(in part because keeping the others closed would accelerate their demise)
Wait... I'm confused. Is that desired or not? :thinking:
David Pyke (May 28 2021 at 16:01):
You can hide the V2 spec, but it will never die.
John Silva (May 28 2021 at 16:21):
I seem to remember though that if anyone made V2 specs available on their own servers (for public availability) they were considered in violation of HL7 rules. This made it much harder for folks new to the healthcare IT domain to get up to speed and productive with V2 (besides the fact that it didn't use comp-sci standard tooling). FHIR and, as Lloyd points out, new HL7 policies, make this much easier for folks now.
Yunwei Wang (May 28 2021 at 17:54):
John Silva said:
I seem to remember though that if anyone made V2 specs available on their own servers (for public availability) they were considered in violation of HL7 rules.
I thought HL7 had changed that rule several years ago.
Chandrakant Bhoslay (May 28 2021 at 17:56):
(deleted)
Brendan Keeler (May 28 2021 at 19:00):
HL7 changed their policy to have open docs in 2012 / 2014, as Lloyd notes
John Silva (May 28 2021 at 19:04):
Time flies -- I guess I've been working on HL7 for a while that I forgot that this happened in 'modern history' (2012/2014) ;-)
(giving away ... I remember when the HL7 specs could be ordered and you'd get an Access DB with the spec, tables, etc. but couldn't share that with anyone)
Lloyd McKenzie (May 28 2021 at 19:29):
Technically the initial change was to open non-FHIR standards to non-members 6 months after publication. That constraint was recently eliminated, so specifications are now available to non-members at the time of official publication. FHIR specifications have been free since we started.
Richard Townley-O'Neill (May 31 2021 at 05:04):
Someone recently asked me where they could get CDA documentation that is as easy to access and use as the FHIR docco is. I had to disappoint them.
Frank Oemig (May 31 2021 at 06:53):
Well, the Access DB is still available. Now with v2.9, but it is provided in addition for convenience. Everyone can start without. BTW, the link for V2 is given above, and we are working to get it on the HL7.org domain.
Vassil Peytchev (May 31 2021 at 22:37):
There is some online help for CDA implementers: http://cdasearch.hl7.org
Brendan Keeler (Jun 03 2021 at 16:43):
What about this? https://build.fhir.org/ig/HL7/cda-ccda-2.2/background.html
Brendan Keeler (Jun 03 2021 at 16:43):
@Richard Townley-O'Neill
Richard Townley-O'Neill (Jun 04 2021 at 03:56):
Looks great! If I'd known of it I would have told them.
David Hay (Jun 06 2021 at 05:45):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
