Stream: social
Topic: HIMSS definition of interoperability
Grahame Grieve (Mar 25 2019 at 18:43):
https://www.healthcareitnews.com/news/himss-writes-new-definition-interoperability
Grahame Grieve (Mar 25 2019 at 18:43):
Not sure what I think about this personally. I'm also not sure whether the FHIR community should respond directly, or leave it to individual members
Grahame Grieve (Mar 25 2019 at 18:45):
HL7 will probably comment
Gay Dolin (Mar 25 2019 at 18:51):
Isn't the comment period over? At the end it states: "HIMSS is seeking feedback, so interested parties can comment here until March 23, 2019."
Gay Dolin (Mar 25 2019 at 18:53):
But the new level, "Organizational", reminds me a little bit of your #3 here (http://www.healthintersections.com.au/?cat=35): "Driving the solutions home – the last leg of the journey – that’s actually the hardest part of the journey."
Espen Stranger Seland (Mar 25 2019 at 18:56):
I like the European Interoperability Framework (EIF) model the best. It's divided in legal, organisational, semantic and technical interoperability (split into some more layers for eHealth). Even politicians can understand it, a point for some of us.
Espen Stranger Seland (Mar 25 2019 at 19:01):
Grahame Grieve (Mar 25 2019 at 19:38):
I didn't notice the date :-(
Grahame Grieve (Mar 25 2019 at 19:38):
the 3 legs blog post actually arose out of discussions with the HIMSS CTO
Chris Moesel (Mar 27 2019 at 13:38):
The article was posted March 22 with feedback due March 23. A little more lead time would have been appreciated.
Gay Dolin (Mar 27 2019 at 20:17):
Looks like they updated the feedback date to March 30th: https://www.himss.org/library/interoperability-standards/what-is-interoperability
Dave deBronkart (Jan 07 2021 at 20:18):
@Grahame Grieve @Chris Moesel anyone (cc @Debi Willis) where did this discussion end up, nearly 2 years ago?
A particular item came up in the Patient Empowerment call today - is it legit / compliant to define a workflow or IG that mandates using a proprietary tool that cannot be accessed without a fee? Would HL7 approve such a thing?
Michele Mottini (Jan 07 2021 at 20:59):
There are implementation guides mandating code sets that require a license (CARIN BB being apparently one)
David Hay (Jan 07 2021 at 21:25):
@Lloyd McKenzie is probably the best to answer, but I doubt that this would be acceptable...
David Hay (Jan 07 2021 at 21:26):
kinda surprised by Carin TBH...
Peter Jordan (Jan 07 2021 at 21:27):
Probably an issue for @Wayne Kubick and the TSC.
Jean Duteau (Jan 07 2021 at 21:27):
there are multiple guides that require code sets that require a license - NCPDP codes, X12 codes, ISBT codes, etc. To be clear, the actual exchange of the codes does not require a license, but having the full set of codes and their relationships does require a license. I suppose SNOMED would be similar. That is obviously different from requiring a proprietary tool however.
Wayne Kubick (Jan 07 2021 at 23:12):
+1 to Jean. It's typical and expected with terminologies. But mandating a proprietary tool would violate our vendor independence principle. Typically mandating use of a specific tool - even a free open-source one - is not specified in an HL7 standard.
Lloyd McKenzie (Jan 08 2021 at 01:11):
We work very hard to ensure that international standards are free-to-use, so for example, with FHIR, we prohibit mandating the use of SNOMED or other non-free terminologies unless the codes (and anything necessary to use them in implementations) has been made freely available by SNOMED International. (They have done so for some of the terminologies used in International Patient Summary, for example.) For U.S. specific standards, where regulation already mandates the use of non-free terminologies, HL7 implementation guides will use them. And where a terminology is 'free for use' in the jurisdiction due to national license agreements, those are fair game too. However, if you're looking at introducing the use of something that isn't already required by regulation or free for use, then you should try to find another solution or seek vetting from the TSC.
Dave deBronkart (Jan 08 2021 at 09:38):
Thanks to all. IF (if!) I understand correctly, the situation that came up today was a proprietary / fee-based place to store and access a patient's document. I'll try to confirm and will reply here later. (If I read @Wayne Kubick correctly, this would seem to violate our vendor independence principle.)
btw, back to my initial question: where DID the "definition of interop" discussion end up 2 years ago?
Wayne Kubick (Jan 08 2021 at 12:53):
I doesn't seem like there was ever a resolution to the discussion 2 years ago, but HIMSS is definitely leveraging their interoperability definition and maturity model widely, including their involvement with GDHP and the Global Consortium for eHealth Interoperability (which is a new collaboration with IHE and HL7). If we wanted to see some modifications to the definition, I could bring that up thru the Consortium.
John Moehrke (Jan 08 2021 at 13:44):
this is confusing... as the topic being discussed has nothing to do with HIMSS definition of interoperability.
John Moehrke (Jan 08 2021 at 13:47):
how does a proprietary application relate to the HIMSS definition? I don't find a clause in their definition that leads me to think that would be in scope.
Dave deBronkart (Jan 08 2021 at 15:01):
John Moehrke said:
this is confusing... as the topic being discussed has nothing to do with HIMSS definition of interoperability.
Sorry for not being more clear, @John Moehrke ... when the topic I described arose yesterday I searched zulip for 'definition of interop' to see if there was any existing answer, and ran across this thread.
More generally I was curious about whether something would qualify as a FHIR interop standard if it requires use of a proprietary tool. I think this thread's answer is no.
Lloyd McKenzie (Jan 08 2021 at 15:40):
The answer isn't absolute, but requirement of anything proprietary would certainly be a red flag.
John Moehrke (Jan 08 2021 at 16:43):
it certainly would be absolute for a specification HL7 publishes.. right? Other organizations could write implementation guides that require things that are okay to require by that organization. I would be very disturbed by HL7 endorsing a vendor solution. That seems wrong.
Lloyd McKenzie (Jan 08 2021 at 17:03):
It really depends on the circumstance. AMA is a 'vendor', but we endorse the use of their codes. We'd have to have a really good reason and it would need to be a situation where we weren't creating an advantage amongst competitors. But that doesn't mean that weird situations don't sometimes come up...
Dave deBronkart (Jan 08 2021 at 17:10):
Again, code sets are one thing ... requiring a specific document platform seems odd.
It's hard for me (non-tech) to imagine why a specific platform would even need to be required, unless it uses a private protocol that no other system can use, which would seem very non-FHIRy.
Paul Church (Jan 08 2021 at 17:28):
My personal political view from the CARIN BB discussions is that license-encumbered code systems (especially in the payer space) are a significant hidden barrier to US patient access that will become a flash point in the future as small startups, open-source, or non-profit app developers start running into them. Patient advocates should push on this issue in the US regulatory process.
John Moehrke (Jan 08 2021 at 17:34):
I was addressing Dave's question about a "proprietary tool", not a code set that has licensing. I read this as an application or software.
Dave deBronkart (Jan 08 2021 at 17:38):
Paul Church said:
Patient advocates should push on this issue in the US regulatory process.
Related: to encourage consumer engagement in these discussions we need a summary table somewhere of which code systems are "license-encumbered" (as you put it) and which aren't, so that as more consumer voices join the space (because they CAN think about using their data, at last!), they can get up to speed. EG:
- ICD-10: disease classification codes (conditions a patient has). Free / not-free?
- CPT: procedure codes, i.e. things providers do (for your conditions) and submit bills for. Owned by the AMA; expensive license fees if you want to do ____ but not if you just want to _____.
- SNOMED-CT: ____
- etc
@Paul Church it would be helpful to hear a simple example from the CARIN BB discussions. Anything that impedes consumer access will surely cause harm to someone, and it's just not fair to do that to someone for commercial benefit.
Josh Lamb (Jan 08 2021 at 17:48):
I agree that licensed code systems will limit startup app developers' ability to display data in a meaningful way. The easiest solution would be to include the descriptions along with the codes. That way, an application developer without a license can display the data in a meaningful way.
Even if an FHIR standard does not require proprietary technology, these requirements can be implicit. We see this now with the PDex Payer-to-payer IG. The guide does not require the use of any proprietary/non-standard technologies. But for the desired interactions to occur, several new technologies need to be adopted.
Lloyd McKenzie (Jan 08 2021 at 19:24):
Depending on the license, that's often not allowed. In fact, in some cases, even storing or displaying the codes themselves if they don't have a license. Also, some code systems (e.g. SNOMED) don't have definitions for most of their codes - instead the meaning comes from relationships. And sharing code relationships without a license is generally prohibited.
Paul Church (Jan 08 2021 at 19:32):
@Dave deBronkart The CARIN BB IG has a page listing terminologies requiring licenses and their owners: http://hl7.org/fhir/us/carin-bb/Terminology_Licensure.html
John Moehrke (Jan 08 2021 at 19:48):
note that terminologies licenses are not usually a problem for patients. This is especially true for patients receiving data created somewhere else. As Josh stated the solution there is to always include the display name for a code along with the use of that code. The terminology licenses usually only apply to times when one is creating data, cases where the set of terminology needs to be within the system. This can happen to some degree in Patient-Generated-Health-Data situations, where the patient would need to choose from a set of terminologies.
So where data is coded with ICD-10 codes, the licensing is handled at the data creator side. A patient downloading this data is not affected by the licensing. As long as the data created included the display name for the codes used.
Paul Church (Jan 08 2021 at 20:37):
It was not clear in the CARIN discussions whether the data creator including a display name and distributing that code+name would be compliant with the license rights they have purchased.
Peter Jordan (Jan 08 2021 at 21:23):
Lloyd McKenzie said:
Depending on the license, that's often not allowed. In fact, in some cases, even storing or displaying the codes themselves if they don't have a license. Also, some code systems (e.g. SNOMED) don't have definitions for most of their codes - instead the meaning comes from relationships. And sharing code relationships without a license is generally prohibited.
The (free-to-use) SNOMED CT Global Patient Set - which includes all the SNOMED CT concepts used in the International Patient Summary - does contain Fully Specified Names which are the definitive, unambiguous descriptions of a concept - along with the Concept Identifier and the Preferred Term from the US Language Reference Set. However, as Lloyd points out, it does not include the defining (or indeed any) relationship data. So, it's basically a simple, non-hierarchical Value Set.
Debi Willis (Jan 08 2021 at 23:58):
Dave deBronkart said:
Grahame Grieve Chris Moesel anyone (cc Debi Willis) where did this discussion end up, nearly 2 years ago?
A particular item came up in the Patient Empowerment call today - is it legit / compliant to define a workflow or IG that mandates using a proprietary tool that cannot be accessed without a fee? Would HL7 approve such a thing?
@Dave deBronkart
A presentation of the Advance Directive interop flow was presented to the Patient Empowerment workgroup yesterday. In the presentation, the patient's AD was stored in a proprietary system and a pointer to the data in that system was being shared with the patient and the EHR. The data itself was not being shared. (This question was asked and confirmed that it was a pointer to the data...the AD itself was not being sent to the patient or EHR. ) This brought up a question offline about the definition of "interoperability". Is interoperability sharing data in a standard format so that all systems involved in the exchange have the data or does it include just sharing pointers to data in a proprietary system. We need clarity on that.
I believe we would have a better understanding if we could find the Advance Directive IG. @Dave Hill @Maria D Moen Can you point us to the FHIR IG for Advance Directive?
Dave deBronkart (Jan 09 2021 at 00:04):
@Maria D Moen this is the answer to the question you emailed :smile: Clarity will be a boon to moving this forward
Dave deBronkart (Jan 09 2021 at 00:09):
John Moehrke said:
A patient downloading this data is not affected by the licensing. As long as the data created included the display name for the codes used.
Excellent, relevant clarification - thanks @John Moehrke !
Dave deBronkart (Jan 09 2021 at 00:11):
Lloyd McKenzie said:
Depending on the license, that's often not allowed. In fact, in some cases, even storing or displaying the codes themselves if they don't have a license. Also, some code systems (e.g. SNOMED) don't have definitions for most of their codes - instead the meaning comes from relationships. And sharing code relationships without a license is generally prohibited.
Wow, now I'm thoroughly confused. Was I wrong in taking @John Moehrke 's word a moment ago that I as a patient don't need to care about licensing, or not?
Josh Lamb (Jan 09 2021 at 02:56):
Hi @Dave deBronkart,
Unfortunately, people should verify what is allowed for themselves (not everyone will have the same license agreement, I think), but from what I have found by reviewing the licenses used in CARIN IG, we can send the descriptions with the codes, as @John Moehrke said.
Frank Oemig (Jan 09 2021 at 08:34):
For me, the definition of interoperability is perfectly demonstrated with the child's game "Chinese Whispers": it includes the verification that data is used as originally intended respectively known within the sender.
Dave deBronkart (Jan 09 2021 at 15:36):
Frank Oemig said:
For me, the definition of interoperability is perfectly demonstrated with the child's game "Chinese Whispers": it includes the verification that data is used as originally intended respectively known within the sender.
I've never heard it called that - in North America we call it telephone. And I think this will be a useful way to introduce the subject to consumer/patients who've never thought about the subject - so thanks, @Frank Oemig!
Frank Oemig (Jan 09 2021 at 15:42):
In German it is called "Stille Post" - silent post. A translation service told me that. Maybe it is not correct.
Anyhow, in Germany, perhaps everywhere interoperability is declared to reuse data. But how do you know that it is correct? Simply using it is not sufficient.
Interoperability is also chaining it. That brought me to that game.
If we do it the same way in healthcare, we are killing people.
Dave deBronkart (Jan 09 2021 at 15:50):
Returning to the thread title, the HIMSS definition of interoperability two years ago, I'd love to see a simple / consumer-friendly example described at the four levels in that definition. Help, someone?
For a start, let's say a local lab wants to send me my coronavirus PCR test results. (Are there codes established for these tests? If not, we may need a better example here.)
- Foundational ... the inter-connectivity requirements...
This would just be the ability for the lab to send me ANYTHING, with neither system knowing what it is. "Hey messaging software: send this thing to Dave. No clue what it is - could be a JPEG for all I know. Just send it."
- Structural ... the meaning of the data is preserved and unaltered. ... interpreted at the data field level.
At this level, the sending system knows that SOME data field has been received, but still doesn't know what it is.
- Semantic ... the ability of two or more systems ... to exchange information ... so that the receiving systems can interpret the data.
At this level, the receiving system KNOWS WHAT IT MEANS. ("Semantics" is about meaning.) "it's a coronavirus PCR test result, and so does the receiving system - right?
This is often where it can get messy, because different systems as used by different hospitals may have slightly different meanings for the same term - right? How might we express this in the PCR test example, or would a different example be better?
- Organizational
I confess that I have no clue what this means. Help?
Frank Oemig (Jan 10 2021 at 15:09):
Semantic: believes to know what it means. IMO, a verification is missing to ensure this belief is correct and therefore the intended reuse allowed.
Frank Oemig (Jan 10 2021 at 15:10):
Organizational: according to structures and work. That can be observed if different organizations are merged.
Josh Lamb (Jan 10 2021 at 17:13):
@Dave deBronkart, it sounds like you are proposing that the word "interoperable" is not currently interoperable.
To me, interoperability is a way to describe something that can be "operated upon in a meaningful, predictable way by two actors.". Nationwide or global health data interoperability would be an amazing achievement. From what I understand, interoperability within a single health system can be a huge victory too. This understanding should temper our expectations about the degree of interoperation between systems.
So as we look at interoperability, it will always be a moving target. We can always interoperate better.
Within an industry, terms like interoperability become loaded. A nice strong definition for the general public will be good. I do not think the public will hear about this as interoperability, though.
Dave Hill (Jan 10 2021 at 18:20):
@Debi Willis The Advance Directive IG is still in the very early phases of development and does not exist yet. We are currently establishing agreement on the use cases we need to support. The PACIO Project will be working on developing the IG over the next several months. @Dave deBronkart @Maria D Moen
John Moehrke (Jan 11 2021 at 13:54):
The purpose of having these levels of interoperability is not to say that the word "interoperability" is not understood. It is to give a maturity evaluation to the stepping-stones one needs to go thru to get it. The model that HIMSS is putting forward is specific to healthcare for treatment. The core internet networking has a similar model that is lovingly referred to as the OSI 7 layer model https://en.wikipedia.org/wiki/OSI_model
One can have a network that is only addressing layers 1-4, but one gets more interoperability if they add layer 5, etc... so it is an effort in defining models.
René Spronk (Jan 11 2021 at 14:02):
A European framework can be found here: https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20151123_co03_en.pdf , similar yet again, but not the same.
Peter Jordan (Jan 11 2021 at 19:23):
Ah.... the good old OSI Model that I had to memorize as a student, 35 years ago! Little did I know then how big a role the 7th Level would play in my career! IMHO, this is more about connectivity and, as such, better viewed as a pre-requisite for the interoperability of healthcare information. I've found this a good, graphical overview.
Lisa Nelson (Jan 11 2021 at 19:52):
@Debi Willis , @Dave deBronkart , @Dave Hill , @Maria D Moen , @Matt Elrod
I don't know what you meant, Debbie, when you said, "A presentation of the Advance Directive interop flow was presented to the Patient Empowerment workgroup yesterday. In the presentation, the patient's AD was stored in a proprietary system and a pointer to the data in that system was being shared with the patient and the EHR. The data itself was not being shared. (This question was asked and confirmed that it was a pointer to the data...the AD itself was not being sent to the patient or EHR. )" That is not an accurate description of what we are showing. The AD information is stored in a system that offers a standard FHIR API. The AD information is released using standard FHIR and C-CDA mechanisms. Systems don't only receive "a pointer to the data" , they query for the information and actually receive the standard document that holds the AD information. This will be demonstrated at Connectathon in the PACIO Track. I recommend you check it out. Standard, interoperable exchange of Advance Directive information.
Debi Willis (Jan 11 2021 at 20:26):
Lisa Nelson said:
Debi Willis , Dave deBronkart , Dave Hill , Maria D Moen , Matt Elrod
The AD information is stored in a system that offers a standard FHIR API. The AD information is released using standard FHIR and C-CDA mechanisms. Systems don't only receive "a pointer to the data" , they query for the information and actually receive the standard document that holds the AD information. This will be demonstrated at Connectathon in the PACIO Track. I recommend you check it out. Standard, interoperable exchange of Advance Directive information.
Thanks @Lisa Nelson I am glad to hear that! I am hoping to attend the session and watch the process. I'm in two other tracks so juggling a bit but looking forward to seeing this happen.
Jan Oldenburg (Jan 11 2021 at 21:31):
I'm puzzled by this thread as well, as I understood Connectathons to be the process by which people who may have proprietary systems showcase how those systems demonstrate the standards being used/developed so that we highlight both what we have to improve about the interoperability rules and also showcase what is possible using the tools and systems that may already have been commercialized or are in the process of being commercialized. That being said, I think it's true that most of our rules about how APIs operate are using data that is fixed in time and being exchanged. ADs are different, in that the person's AD may change over time and you always want the most up-to-date version. In this case, it seems logical to me that the API would provide pointers to the storage point--the current source of truth--rather than the actual data. That doesn't stop a consumer from choosing to use system A vs system B as their storage point...
Maria D Moen (Jan 11 2021 at 21:59):
Agreed Jan. I think we have a tempest in a teacup here, and as is the case with so many things in life - a failure to communicate ideas and concepts. image.png Isn't that just typical when people get together?
Debi Willis (Jan 11 2021 at 22:04):
I think part of the issue is that if there is a login to system A (where my AD is stored) and i go into a hospital in another state that is not aware of system A and doesn't have a login to system A, how are they supposed to get my AD? But, if I am able to create an AD and have it in my consumer app and share it with EHR 1(my primary doc) in a structured way...and EHR 1 is able to absorb it and share it with EHR 2 (the hospital in another state) then they both have my AD. And if i have a copy of it in my consumer app, my care advocate that is linked to my app could have it on hand without trying to figure out what my password is for system A.
It sounds like Lisa is able to absorb the data and create a CCD which can be stored in a consumer app and shared with any provider, and that provider can share it with another provider (via CCD).
There has been a lot of discussion about the importance of a patient having a copy of their own data. If we built a system where a patient shared a pointer to a single system for providers to view the patient's most current medication list, there would be obvious concerns raised about that method. Having data stored somewhere and only sharing a pointer to it (and requiring a login) can cause severe road blocks that will impact patients who are in an emergency situation. I am happy to hear the plan is to share the actual data and not just a pointer to the data in a locked system that needs a password. Don't get me wrong. I think having systems that can store a patient's AD is good, i just don't think it makes sense to build interoperability standards that only share pointers. But, Lisa answered the question that was asked last week: "Are you sharing a pointer or are you sharing the data?" I believe i heard "We are sharing a pointer" last week, but it sounds like I misunderstood. Happy to see the data flow! That is so important to patients.
Jan Oldenburg (Jan 11 2021 at 23:03):
Debi, We can discuss this in a different context, but I believe that AD data is different in kind than the rest of the patient's medical record. The rest of the data is observations at a particular point in time that don't change. The lab I had taken on 1/6/21 has the same value no matter how many times it is passed around. But my AD might be quite different from time to time. I may have put in a DNR order last year when my health was in great jeopardy, but this year, when I am healthier, I want to recind my DNR order. Having a pointer to the CURRENT AD really matters and old copies floating around could result in a very different--and lethal--outcome. Other data it makes sense to trend and it's ok to have multiple copies because trending my lab results from 1/6/21 with similar lab results from the past provides useful trending information. Wishes are not the same.
Dave deBronkart (Jan 12 2021 at 00:06):
Josh Lamb said:
Dave deBronkart, it sounds like you are proposing that the word "interoperable" is not currently interoperable.
Ha ha, but yes, spot on.
My question was, at a deeper level, trying to get at what HL7 considers to be acceptably interoperable. After this discussion, I imagine that answer lives as much in the culture as in a document!
John Moehrke (Jan 12 2021 at 13:37):
@Debi Willis @Jan Oldenburg and @Maria D Moen please create a new thread when you have a new topic. Your discussion about AD is very important, but it is not about the "HIMSS definition of interoperability". By putting your discussion here, you will not be getting access to people who care about AD and not about HIMSS. And by putting it here you confuse those of us that are trying to talk about the HIMSS definition of interoperability.
Dave deBronkart (Jan 12 2021 at 13:53):
My fault, actually. I actually asked last week in the #Zulip stream if it was possible to break off and rename (afterward) a branch that had grown unexpectedly large. (Answer: it can be done, but...)
Thanks for calling us/me out on that. I totally agree - and your explanation of the consequences will be useful to others with less experience (though I think that's not any of us!)
brb
Brendan Keeler (Jan 12 2021 at 14:36):
In my mind, the biggest barriers in health tech today aren't slicing and dicing interoperability into layers but are functions of trust frameworks - intraorganization, between organization, and consumer mediated
HL7v2 and MLLP were fine for intraorganization exchange but were not well suited for interorg exchange.
Our foray into XML and mutual TLS has been okay as a tool for inter org exchange but wasn't great for patient mediated (via MU3 VDT and APIs). Aside from base transfer of care or prescription data, our national exchange networks are still very underdeveloped (not ubiquitous) for most use cases (referral, lab ordering, specialty clinical data, scheduling, public health)
FHIR has proven a very nice fit for patient mediated interoperability, less because of its format or content but more due to its status as open documentation, SMART authentication.
Thinking about standards in light of those trust domains is a cognitive map that's more useful to me than "how well are we encoding and parsing data" which equates our problems to mapping exercises. That's certainly something all organizations need to tackle, but without appropriate interoperability trust frameworks, there's no exchange to begin with.
https://healthapiguy.substack.com/p/trust-in-healthcare-integration
Dave deBronkart (Jan 12 2021 at 14:46):
@Lloyd McKenzie here's the thread branch I asked about last week in #Zulip re whether it's possible to rename "driftwood" (a drifted branch). At that time I said "I'm not asking for anything yet" but maybe it's worth exploring.
John Moehrke (Jan 12 2021 at 14:48):
I recommend on zulip to just abandon a discussion that started in the wrong place, start it in the right place, and leave a breadcrumb to point people to the right place. It is brute force, but it is effective
Dave deBronkart (Jan 12 2021 at 14:51):
I want to spotlight this for my own follow-up, and to draw attention to it in this thread. @Brendan Keeler I remember seeing your original Medium post in 2019 but its significance wasn't yet apparent to me. I'll add boldface to the money shot.
Brendan Keeler said:
In my mind, the biggest barriers in health tech today aren't slicing and dicing interoperability into layers but are functions of trust frameworks - intraorganization, between organization, and consumer mediated
HL7v2 and MLLP were fine for intraorganization exchange but were not well suited for interorg exchange.
Our foray into XML and mutual TLS has been okay as a tool for inter org exchange but wasn't great for patient mediated (via MU3 VDT and APIs). Aside from base transfer of care or prescription data, our national exchange networks are still very underdeveloped (not ubiquitous) for most use cases (referral, lab ordering, specialty clinical data, scheduling, public health)
FHIR has proven a very nice fit for patient mediated interoperability, less because of its format or content but more due to its status as open documentation, SMART authentication.
**Thinking about standards in light of those trust domains is a cognitive map that's more useful to me than "how well are we encoding and parsing data" which equates our problems to mapping exercises.
**
That's certainly something all organizations need to tackle, but without appropriate interoperability trust frameworks, there's no exchange to begin with.https://healthapiguy.substack.com/p/trust-in-healthcare-integration
Brendan Keeler (Jan 12 2021 at 15:18):
Thanks Dave.
A timely example of an "interoperability" problem - lab and vaccine reporting. Labs struggled to report to public health agencies. Now we're seeing similar with vaccination administration. Cue the "healthcare has interoperability problems" chorus. But it's not a semantic interoperability problem - CDC did great work to prescriptively guide states to use HL7v2.5.1 ORU/VXU/QBP/RSP. So if it's not semantic interoperability, what is it?
It's a function of failed trust. Labs can't/don't report because it's too hard to "onboard" onto each state's inter org trust policies. The greatest promise of FHIR here (and in general) isn't the semantic interoperability; it's the modern authentication patterns such as SMART or UDAP. The "better encoding" and easier readability of FHIR is just a bonus! By applying modern authentication, we get modern, scalable trust patterns in intra-org, inter-org, and patient authenticated interoperability.
For public health, a broad trust agreement with a centralized registry, akin to Carequality, would be a massive level up over today's "connect point to point with 64 different trust policies/processes"
Josh Lamb (Jan 12 2021 at 15:45):
- Every data holder can talk to the patient (patient access)
- Awareness of all data holders (so patient can access data)
- Healthcare SSO
- Healthcare wins
Frank Oemig (Jan 12 2021 at 18:39):
IMO "readability" is neither a precondition nor helpful, but most probably I am alone here. Correct understanding and implementation is key. Imagine the images: no one is visually testing by human reading of the instances. The tools have to work. That requires correct implementation which is founded on educated implementers which requires a good specification.
Healthcare domain seems to be simple so that this request can be denied. Therefore, no conceptualization...
Dave deBronkart (Jan 12 2021 at 19:42):
Brendan Keeler said:
Labs can't/don't report because it's too hard to "onboard" onto each state's inter org trust policies. The greatest promise of FHIR here (and in general) isn't the semantic interoperability; it's the modern authentication patterns such as SMART or UDAP.
Ahhhh.... I remember years ago when some smart people said things like OAuth could seriously change things, and now I'm starting to understand this at a much deeper level than ever.
So all this "trust framework" stuff (which always seemed cryptic to me - "framework"??) is making more sense. It's about an EASY, DEPENDABLE way to know you're talking to who you think you are. And that enables just letting the freakin' data flow, the way it should.
Yes?
Josh Mandel (Jan 12 2021 at 22:06):
What you are describing is mostly authentication @Dave deBronkart ; having a consistent approach to this is one part of a trust framework but the other part is deciding what data you will share with whom, under what circumstances, what the recipient is allowed to do with it, and who is allowed to define /adjust these decisions (roughly: authorization and related policies)
Josh Mandel (Jan 12 2021 at 22:08):
Typically this takes the form of a legal agreement that participants sign on to at some point, together with some technical means for sharing up-to-date information about who has signed on.
Brendan Keeler (Jan 12 2021 at 22:48):
Frank Oemig said:
IMO "readability" is neither a precondition nor helpful, but most probably I am alone here. Correct understanding and implementation is key. Imagine the images: no one is visually testing by human reading of the instances. The tools have to work. That requires correct implementation which is founded on educated implementers which requires a good specification.
Healthcare domain seems to be simple so that this request can be denied. Therefore, no conceptualization...
I'm confused by this. Having open documentation that is easily accessible reduces friction and allows developers to do their job. Building overly academic, unimplementable standards as ivory towers with pay walls benefits very few. Plenty of examples in the wasteland of failed standards to point to in this regard.
Lloyd McKenzie (Jan 13 2021 at 04:38):
Readability seems to be a precondition to understanding and implementation to me. (Plus readability increases the quantity of folks who even bother trying to progress to the understanding/implementation stages.)
Frank Oemig (Jan 13 2021 at 07:50):
The documentation must be available - and read by implementers. I talked about readability of resource instances
Frank Oemig (Jan 13 2021 at 07:52):
Using tools to "read" the instances instead of ascii editors help to ensure correctness
Lloyd McKenzie (Jan 13 2021 at 16:49):
The need to use tools to read instances creates friction when authoring, debugging and understanding. Realistically, in a formal computable exchange syntax, there's always a trade-off. But something like FHIR is certainly much easier for developers to work with (and is harder to mess up) than something like v2 - or even v3.
Michael Collier (Jan 13 2021 at 17:52):
@Brendan Keeler - can you expand on a few things here? When you say labs "onboard" onto each state's inter org trust policies, what exactly are you referring to? You mention authentication patterns like SMART and UDAP hold the most promise, but then say there is a need for a broad trust agreement and centralized registry. In your opinion, are the authentication patterns complementary to a centralized registry (enabler or other). It would seem that the centralized registry would be a workaround to a lack of implementation of modern authentication patterns, but interested in your perspective here. (Caveat - I'm a non-technical person interested in solutions for lab result reporting)
Dave deBronkart (Jan 13 2021 at 23:36):
Josh Mandel said:
What you are describing is mostly authentication Dave deBronkart ; having a consistent approach to this is one part of a trust framework but the other part is deciding what data you will share with whom, under what circumstances, what the recipient is allowed to do with it, and who is allowed to define /adjust these decisions (roughly: authorization and related policies)
That makes sense; but it leaves me a bit disoriented about what @Josh Lamb said: I may be misunderstanding, but he seems to suggest such authentication largely resolves the trust problem. Can you Joshes elucidate?
Josh Lamb (Jan 13 2021 at 23:45):
In short, @Dave deBronkart , authorization is a solved problem (mostly) when accessing data directly from a source. Individual right of access also avoid data segmentation issues that Josh was describing. No entity can freely consume all data but the patient.
@Josh Mandel, does this fall inline with your thoughts?
John Moehrke (Jan 13 2021 at 23:53):
yes. Patient Right of Access is very important.
Josh Mandel (Jan 14 2021 at 00:17):
I would note that even under the patient right of access, individuals still often want to limit the permissions that they share with certain apps. So there is a layering of permissions here; if I have access to certain data, then I can decide to share a subset of those data downstream. This is still a challenging problem in its own right... though of course it goes away in the sub case where you walk to share everything you are allowed to access.
Josh Lamb (Jan 14 2021 at 00:21):
@Josh Mandel, thanks. Right now it's all or nothing (by practice not technical capabilities). I can at least see a reasonable path from one SMART scope being the norm (read.*), to suppprt for more granular ones.
This is reasonable incremental progress.
John Moehrke (Jan 14 2021 at 00:40):
Josh, when the patient is the user, and they are introducing a new app to their FHIR api data... they will be able to refine the data that the app will get using the SMART scopes. Today the choices are rather un-inspiring.. but there is work on a more granular scope system. Which brings up the point that it is good to NOW bring up the kinds of things that a patient might want to limit an app to... Think an app that represents a clinical-research-project, I am willing to give it X kind of data, but not Y kind of data. Likely keeping it from my mental-health data.
Josh Lamb (Jan 14 2021 at 01:15):
Maybe I am off-base. I am imagining a patient pushing data through an application. The application should let the user control what is pushed (and only make available what is allowed).
The permission issues are much more complex if you have a business owned repository that is feeding data based upon patient consent.
Josh Lamb (Jan 14 2021 at 01:52):
In other words, data is shared when an application shares the data, not when an application pulls data for a patient.
This is also connected to the business-to-business patient facilitated application infographic I shared. A business-to-business application is trusted because of the protections offered by HIPAA.
If you use this mindset (and B2B applications when a business is receiving sensitive data), patient/*.read is not that bad. We want granular controls on create,update,delete.
Last updated: Apr 12 2022 at 19:14 UTC
