Stream: social
Topic: Stakeholder buy-in
Joe Etten (Jun 05 2020 at 12:46):
So while I personally see the value in implementing a FHIR standard, its becoming increasingly apparent to me that our dev team doesn't like it. At least from an internal systems integration standpoint. The pushback seems to be mostly centered on the belief that the standard has an overly complex structure. Conversations usually devolve into responses like this: "Why would I want to include all these other properties, structure and other garbage if all I need is an object with these 3 things in it?"
Part of me agrees in the sense that it requires more complex logic and has some overhead costs as well. But having to reinvent the wheel every time we need to pass data to a new application or system is a maintenance nightmare in the long term. A standard simplifies this process for everyone. Unfortunately, I must not be explaining it well enough because I have yet to have even one person buy into the idea.
Has anyone else run into hurdles like this? How did you overcome them in your organization?
Michele Mottini (Jun 05 2020 at 12:52):
Pretty much everything in all FHIR resources is optional - you can include only what you need / what you have
Joe Etten (Jun 05 2020 at 12:59):
True, but the structure isn't (its kind of the whole point of a standard). I'm also not saying this is the only issue, its just one example.
Michele Mottini (Jun 05 2020 at 13:03):
Have them work on CDAs for some time maybe?
Michele Mottini (Jun 05 2020 at 13:10):
(That's the situation in my organization - we have been working a lot on older standards and FHIR is much easier...none ever questioned it)
Morten Ernebjerg (Jun 05 2020 at 13:24):
The standard in is entirety is indeed pretty large, it's a very different beast than, say, learning the openAPI syntax. If you dive in unprepared in search for one specific fact as a dev, you can easily overlook something or go down a rabbit hole - and I think we are well advised to acknowledge that (I'm saying this as both a dev and and as a wannabe-FHIR-nerd). I personally believe that one thing that can help a lot is to provide targeted (custom) documentation for the specific dev work needed, e.g. lots of examples and explanations of the specific bits of FHIR being used (even if it means a lot of work). The standard documentation is excellent but obviously huge, so I think it makes a big difference if we can provide "guided tours" through it.
Also, in general I'm wondering whether the dev dissatisfaction is with FHIR specifically or rather with the complexity of healthcare data in general (multitude of coding systems & information bits, "historical leftovers", high safety requirements etc.). If it's the latter, then one laconic argument - like Michele is saying - is perhaps simply that the alternatives are worse. You can maybe ignore or push around the complexity for a while, but any custom format will necessarily converge on (at least) the same level of complexity (with, as you say, plenty of maintenance pain along the way).
René Spronk (Jun 05 2020 at 13:42):
A homegrown one off solution will always be faster than anything else. But it doesn't scale. An oh my (rolling eyes), one does need scaling indeed to deal with the complexities of healthcare data. Why did Google decide to adopt FHIR as the basis for everything they do when dealing with healthcare data? They didn't want to reinvent the wheel, there is no such thing as an easy solution when it comes to healthcare data.
Lloyd McKenzie (Jun 05 2020 at 14:06):
Using the standard takes more up-front investment, but it lets you leverage the expertise and experience of (at this point) thousands of others in the healthcare space. As a result, your solution will be much more likely to stand the test of time as your own requirements evolve. The RESTful API approach also means that your solution will be largely use-case independent. The endpoints you create for one purpose will turn out to be useful for other purposes, which will save significant effort over the long run.
More importantly, using a standard means you'll interoperate with other systems. Sure, you could define a custom structure in JSON or some other language that's an exact fit for your requirements, but your chances of finding other communication partners who would support that out-of-the-box is nil, and it'd be a significant up-hill battle with every single partner to convince them to support it. You're likely to find many who'll outright refuse and demand that you use a standard (because they don't want to cover the development and ongoing maintenance costs of having a different interface for every partner).
Using a standard also allows you to layer on other technologies that depend on standard interfaces. For FHIR, that means things like SMART and CDS-Hooks and others
Finally, using the standard gives you a tie-in to the community. The value of being able to ask a question about how best to encode a type of data, solve a given problem, do things in a way that will be consistent with the expectations of future interoperability partners is immensely valuable.
Good luck with your sales pitch :)
Dave deBronkart (Jun 05 2020 at 18:48):
Lloyd McKenzie said:
More importantly, using a standard means you'll interoperate with other systems. Sure, you could define a custom structure in JSON or some other language that's an exact fit for your requirements, but your chances of finding other communication partners who would support that out-of-the-box is nil ...
... Using a standard also allows you to layer on other technologies that depend on standard interfaces. For FHIR, that means things like SMART and CDS-Hooks and others
...Finally, using the standard gives you a tie-in to the community.
In my experience (outside healthcare) these are always the advantages of a standard and are always opposed by people who are accustomed to doing the minimum possible to get one specific task done. Without being pejorative I'll point out that they're driven to accomplish a specific task and they only get interested in a standard when they get tired of doing the same thing over and over.
I personally first witnessed it in the 1980s with the radical idea of interoperable word processing formats. "Moving text between Vydec and Wang systems?? Okay, I can do that. Wang and Lanier? Sure. Lanier and IBM? Sure..." Then different PC word processing tools (WordStar, WordPerfect, Word), then typesetting systems (a major farce)...
What's hard to see for such earnest workers is that eventually they are doomed when consumers get the ability to move the data around however they want, by themselves. This is exactly how desktop publishing killed traditional graphic arts prepress processes.
So, @Joe Etten , I hope you can appeal to the strategic minds who I hope are guiding your organization, because to focus on "let's optimize around our immediate needs today" is to doom the enterprise, consciously reducing its ability to respond to change in an agile way.
Joe Etten (Jun 05 2020 at 20:54):
Wow.. Amazing responses all, I truly appreciate it!
Grahame Grieve (Jun 07 2020 at 00:37):
@Joe Etten one way to frame this is in terms of data requirements. The standard represents the joint agreements about everybody's requirements. That's always going to be more complex than your current known requirements. But your current known requirements are always less than your future requirements, and change is hard.
So there's 2 gaps of interest:
- the gap in your knowledge about your actual requirements
- the gap between the your actual requirements and everybody's actual requirements
If you are are highly confident that the first is small - well, it's likely you don't understand what you are doing. But sometimes it's possible to be genuinely confident about that. On the other hand, there's almost always a gap between your requirements and everybody's requirements.
My experience is that every team I've worked with chooses to compromise between standards and doing custom stuff. Sometimes they make bad decisions and sometimes they make good ones. When I'm deciding about this, I pay attention to things like, what's the cost of change? How good are the markers around my requirements gathering process? What's the business balance between spending money up front and spending it later. And as Dave points out, how much does not using standards expose me to being blown away by someone that did invest in that up front?
Dave deBronkart (Jun 09 2020 at 22:16):
Sidebar alert
@Joe Etten speaking of not adhering to a standard, a most-favorite story EVER is that word-processing data conversion shops had a special problem with Vydec word processors: the floppy disk drive spun backwards compared to all others.
So even if you had a super-tech wizard in your shop who could jigger the 8" floppy drives to read different systems' non-standard formats with a single drive, you still needed a separate drive for Vydec.
Abbie Watson (Jun 10 2020 at 03:10):
tl;dr - Things that are easy to implement are often difficult to maintain, and things that are easy to maintain are often difficult to implement.
David Hay (Jun 10 2020 at 05:14):
Things that are easy to implement are often difficult to maintain, and things that are easy to maintain are often difficult to implement.
nice!
Dave deBronkart (Jun 10 2020 at 13:35):
Abigail Watson said:
tl;dr - Things that are easy to implement are often difficult to maintain, and things that are easy to maintain are often difficult to implement.
Abbie!! This deserves to be a widely known "law" I googled it and didn't find it - did you get it somewhere??
Abbie Watson (Jun 12 2020 at 17:43):
Aaaaah.... I can't remember? I'm mostly just describing my experiences doing 60 or 70 prototypes/pilots/rollouts with FHIR, and working with maybe two dozen different groups? Been through this argument and stakeholder buy-in process a lot of times now.
Thank you though. :)
Marvin Malcolm (Jun 22 2020 at 10:15):
I know I'm late to the discussion, but as someone relatively new to FHIR (with no baggage) it seems at first glance the complete opposite of what a dev in recent years as come to expect from a "simple" REST based interface. If you remember we came from a SOAP WS-* landscape which became fairly complex, but doable because we had development tooling to support it.
Then came REST and it simplified things imensely, notwithstanding there were a bunch of things it couldn't do that WS-* handled for us.
For a developer, looking at FHIR (many of who never knew SOAP) it looks monstrous (hope no one feels like I'm calling the baby ugly).
There is however, great benefit in using a std like FHIR where, especially for integration, it's a no-brainer.
For internal use within a system (e.g. internal APIs or database schemas etc.), more debate needed especially when trying to understand the impact of FHIR schema upgrades and maintainability etc.
Grahame Grieve (Jun 22 2020 at 10:16):
hi Marvin. We would really like FHIR to be simple. And your comment is a common one for people who haven't been exposed to the horror that is healthcare requirements (let alone the existing system)
But healthcare requirements are deep and broad and very diverse, so we've ended up where we are
Grahame Grieve (Jun 22 2020 at 10:18):
We didn't design FHIR for internal system architecture, though lots of people have found that it's the least worst approach for them, even though using an interoperability specification does mean that their system is complicated by everyone else's requirements
Grahame Grieve (Jun 22 2020 at 10:18):
it depends how much control you have over your own requirements - I've written about this here:
Grahame Grieve (Jun 22 2020 at 10:19):
http://www.healthintersections.com.au/?p=2776
Grahame Grieve (Jun 22 2020 at 10:20):
if you can see areas where you think we have unnecessary complexity - after you've accounted for real world requirements - then we're all ears.
Marvin Malcolm (Jun 22 2020 at 10:21):
Agreed and my comment about the developer tooling will be the key to getting developer buy in imo. That, I suspect will evolve over time.
Michael van Bokhoven (Jun 22 2020 at 10:46):
Hi @Marvin Malcolm - I've actually found the opposite, though that may be due to the particular way in which I'm using FHIR. Looking at the documentation, most resources look enormous. But looking more closely, the minimum requirements for resources are usually pretty simple, so you can get away with really quite compact models if you don't need huge amounts of detail. I'd be really interested to hear what you found complex, and whether it was during implementation, or looking at the docs (which I could totally understand, as above).
Marvin Malcolm (Jun 22 2020 at 11:35):
Hi @Michael van Bokhoven - having just watched a bunch of novice healthcare devs try and use FHIR for the first time, I suspect it's probably the documentation that is the stumbling block.
They are used to a swagger (openAPI) definition that they can just start and use. They can even generate client stubs that they can start from and just require them to implement their logic and map to the fields in an object definition and off they go.
Now the trick question is what fields do I need as typically most are optional. Even with a simple identifier, reference or codeableconcept, they have a lot going on, so it would be confusing to a newbie.
I suspect that anyone coming from HL7 v2 or CDA would have an inherrant appreciation of some of these things, but it's clearly not obvious to everyone
Regarding documentation, I just looked at the presentation for the Subscription proposal for R5. That presentation, for me, very clearly describes how subscriptions would work with some simple and clear examples. If I look at the R4 Subscriptions page (https://www.hl7.org/fhir/subscription.html), I could read and read and still not get the same level of understanding as 10 minutes reading through that presentation.
Richard Townley-O'Neill (Jun 22 2020 at 23:38):
I read the draft specs (e.g. R5) to understand the intent and read the relevant stable specs (STU3 or R4) to see what is possible.
Andrew Berry (Jun 23 2020 at 03:28):
This is an excellent question. My own answer is that it is perfectly reasonable to only use FHIR for external interactions, but “external” should include any service with its own lifecycle (i.e. autonomously maintained and released), even if that service is maintained within your organisation.
Regarding the question of when to use FHIR as the internal representation within a service, for services that are net producers of data, using a non-FHIR internal representation will likely make more sense. For example an IoMT repository might store data from managed “things” in a compact, device-native form, especially if the “things” are somewhat homogenous. For services that are net consumers of data, using FHIR as an internal representation is likely to make more sense. For example, an eHR consolidating clinical records from many sources.
Further, it is worth considering CQRS patterns (e.g. https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs), which distinguish write/update and read/query services. The separation can make it easier to reason about the optimal internal representation.
Michael Lawley (Jun 30 2020 at 21:37):
One of the real challenges here is that "novice healthcare devs" are new to healthcare - when they see the breadth of FHIR they're being confronted by (some of) the complexity of healthcare across many tiers of delivery.
But we shouldn't kid ourselves that FHIR is itself without (at least) accidental complexity, something that always seems to increase over time.
Grahame Grieve (Jul 01 2020 at 01:46):
we're not kidding ourselves about that, and feel free to draw attention that you think we have
Abbie Watson (Jul 02 2020 at 19:51):
One thing I like to bring up when a potential client starts talking about the complexity of the spec, is the productivity gains from having a fully documented API. I often challenge them to produce any API specification for their existing systems; and then nitpick it apart on business considerations that the FHIR spec covers but they hadn't considered (yet). It frames the complexity of FHIR as a strength, rather than a liability. They need to view that API complexity as a giant heavy lift they can leverage that was taken care of by someone else.
Dave deBronkart (Jul 02 2020 at 20:34):
Is it complexity, or detail/completeness?
Lloyd McKenzie (Jul 02 2020 at 20:43):
A bit of both. Things like mustSupport, vocabulary bindings, multiple syntaxes, profiling are definitely added "complexity" you wouldn't generally find in a home-grown solution. But they're all there for a reason.
Last updated: Apr 12 2022 at 19:14 UTC
