Stream: argonaut
Topic: Provenance is too detailed
Michele Mottini (Sep 25 2019 at 14:19):
Something I briefly raised in Atlanta: in our system (that is an IHE basically) it impossible to generate provenances as currently specified in the implementation guide - we do not have that level of detailed information available, for example no distinct author and organization
Brett Marquard (Sep 25 2019 at 15:12):
Do you record who provided you the data? At minimum the spec is pushing to collect and pass along who sent them data.
Brett Marquard (Sep 25 2019 at 15:12):
Use case 4 is likely to be reworked, we plan to discuss on Structured documents tomorrow.
Michele Mottini (Sep 25 2019 at 16:20):
Yes, we do record where the data comes from - that is sort-of an organization, but not exactly: we can receive two feeds from the same organization and they could be recorded as different.
John Moehrke (Sep 30 2019 at 14:38):
@Michele Mottini can you be more specific about what is not available? Everything you need should be in either the SubmissionSet (DocumentManifest), or the DocumentEntry (DocmentReference). What specifically is missing?
Is this simply the nature of some publishing actors that don't fill out the optional author data? When it is filled, it should be useful. The PCC profiles do encourage proper filling.
Michele Mottini (Sep 30 2019 at 14:57):
We do not receive data as FHIR DocumentReference or submissions sets. WE have some tens of different drivers (CDAs, X protocols, flat files, HL7v2, direct database connections) with hundreds of different configurations. What we store is a general 'record authority' for each data source, that roughly corresponds to the organization that data comes from (but not exactly) and that's what we have
John Moehrke (Sep 30 2019 at 15:02):
Okay, well that is your problem.. not XDS...
Michele Mottini (Sep 30 2019 at 15:04):
Maybe is my problem but makes Provenance as currently profiled uninplementable - and I wonder how many other systems are in the same boat
John Moehrke (Sep 30 2019 at 15:09):
Understood. getting this level of detail might be hard. But this "basic provenance" is being asked for on the consuming side. Thus the overall intent is to improve quality; knowing that this improvement might be painful to some.
Lloyd McKenzie (Sep 30 2019 at 15:33):
Be cautious about using a base-line profile to drive improvement in behavior. Baseline profiles should generally reflect the lowest common denominator. You can define "raising the bar" profiles that encourage systems to do more, but it shouldn't be a situation of systems simply can't. If the data isn't coming in, then it can't be populated. The system has no control over that.
Brett Marquard (Sep 30 2019 at 15:45):
Base line profile is very baseline.... Provide the author organization if you have it; provide the organization that handed you the data (Transmitter).
Brett Marquard (Sep 30 2019 at 15:46):
Both are must support (send if you have). If the current profile is unimplementable, I am curious what would be more baseline then keep track of who gave you the data.
Michele Mottini (Sep 30 2019 at 16:47):
OK - maybe I am just misunderstanding things - the way I understand 'must support' is 'you must have this in your data model - even if sometimes it is not populated'
Michele Mottini (Sep 30 2019 at 16:48):
If it is just 'send if you have' then we are good
Jean Duteau (Sep 30 2019 at 16:52):
'must support' never means send it always. That would be a minimum cardinality of 1. Here is what the spec says about 'must support': Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way.
Depending on the profile, that might mean that you have to be able to store and send the element, i.e. if I send you an instance with this element and then read the same instance, I expect that element to be there, or it could be something more or less. The profile needs to define what it means for 'support'.
Lloyd McKenzie (Sep 30 2019 at 16:53):
mustSupport generally means "you must be capable of sending". It wouldn't be considered 'supported' if your system was never capable of providing a value.
Lloyd McKenzie (Sep 30 2019 at 16:54):
If there are situations where you'll have the data and some where you won't, you're fine. If you'll never have data and couldn't pass it on if someone gave it to you, that would be a problem.
Brett Marquard (Sep 30 2019 at 17:17):
Lloyd's correct. For the current profile, if you aren't able to provide author organization, and transmitter organization when it's available to you, that's a problem.
Brett Marquard (Sep 30 2019 at 17:19):
I am curious @Michele Mottini , for each of the different drivers what you capture for 'source information'...I would expect you would need some bread crumbs to trace back to where you got the data
Drew Torres (Sep 30 2019 at 17:26):
Might be related, but want to get thoughts on this. What about writes? If system A supports a mustSupport element, but system B doesn't. Is it OK that system B never accepts that data on a write from system A, or an error should be returned?
Jean Duteau (Sep 30 2019 at 17:37):
If a system claims conformance to a profile, they are claiming conformance to the mustSupport elements of that profile along with whatever the profile dictates about what mustSupport means. If SystemB didn't conform to the profile, then they could do whatever they wanted with the mustSupport element.
Drew Torres (Sep 30 2019 at 17:47):
That makes sense.
Michele Mottini (Sep 30 2019 at 17:55):
(The relevant definition of 'Must support' is at https://build.fhir.org/ig/HL7/US-Core-R4/general-guidance.html#must-support)
Michele Mottini (Sep 30 2019 at 17:57):
(that from a responder point of view I interpreted as 'element must be in the data model' but not required to be populated)
Michele Mottini (Sep 30 2019 at 18:02):
@Brett Marquard all the data coming in from a specific driver instance is tagged with a 'record authority' - that is basically a string with values like 'Lourdes Health System (Camden - Invision)', 'Lourdes Cclf Caregiver', 'Holy Cross (Allscripts/IDX)', 'Holy Cross (Meditech)'
Michele Mottini (Sep 30 2019 at 18:02):
so a sort of organization
Brett Marquard (Sep 30 2019 at 18:06):
'must support' continues to be a thorn, we plan to discuss further (again) on SD this week.
Michele Mottini (Sep 30 2019 at 19:11):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
