Stream: Argo Write
Topic: discussion items for 7/28 call
Eric Haas (Jul 20 2021 at 21:40):
I am preparing a set of discussion items for the nascent argo Direct Write API. @John Moehrke can you comment on #3 meta.tag v meta.security ?
Eric Haas (Jul 20 2021 at 21:40):
link: https://confluence.hl7.org/pages/viewpage.action?pageId=113672554
John Moehrke (Jul 21 2021 at 12:37):
I am not sure what to react to. Is the ask that I react to "name sucks "? The name of the element is now fixed in normative specification, so it is what it is. We are having serious discussions that the vocabulary binding and given valueSets need to be relaxed.
John Moehrke (Jul 21 2021 at 12:39):
if the question is why do we have .security and .tag... I don't know. I think if we had a chance to design it again.. which we don't, because it is normative... we likely wouldn't have bothered with two different tags. However, it is what it is, and it is normative.... so, the distinction are that .tag is for workflow, and .security is for protection (security and privacy... there is no good word, so we used security as it is broader than privacy but includes privacy enforcement).
John Moehrke (Jul 21 2021 at 12:42):
I also note a question of provenance... Two other alternatives
a) X-Provenance header --- I am not a real fan of this, but it is an alternative that is documented
b) Server automatically creates Provenance based on the create/update transactional context. Very likely that there are OAuth tokens associated with the transaction, plenty of good food for Provenance in that OAuth token. This might not be a descriptive Provenance, but if another more descriptive Provenance is sent later, then the two can be used in combination.
c) Provenance can be sent in a second create/update... classic REST.
Josh Mandel (Jul 21 2021 at 14:08):
distinction are that .tag is for workflow, and .security is for protection
This makes sense; I think we're talking about workflow ("tag"
) here.
Lloyd McKenzie (Jul 21 2021 at 14:48):
What is the behavior that results from having the 'tag'? It seems to be "this needs review", then "this has been reviewed", which would definitely point to workflow.
Josh Mandel (Jul 21 2021 at 15:03):
"Needs" review is a bit strong, but "this was submitted by patient and appropriate workflow should be applied" it is roughly the intent. We also want to make it very easy for searches to partition query results based on this value (e.g., filtering based on the tag).
Eric Haas (Jul 21 2021 at 15:32):
distinction are that .tag is for workflow, and .security is for protection
I think patient supplied is for protection of the server too and that drives workflow so that is not really a distinction. They both both function to inform you of the data provenance. I am OK with using tag although there will be confusion no matter what we do, the concepts are identical in both spaces and I am going to push for reuse of the security codes rather than creating a parallel code system to maintain.
Also I am trying to flush out opposition now instead of later in the process.
Josh Mandel (Jul 21 2021 at 15:42):
I'd try to avoid a direct dependency on a system like https://www.hl7.org/fhir/v3/ObservationValue/cs.html -- this seems like 1) a kitchen sink from v3, 2) intended specifically for Observation "value" use cases, whereas our use case covers other kinds of patient-submitted data
Eric Haas (Jul 21 2021 at 15:44):
b) Server automatically creates Provenance based on the create/update transactional context. Very likely that there are OAuth tokens associated with the transaction, plenty of good food for Provenance in that OAuth token. This might not be a descriptive Provenance, but if another more descriptive Provenance is sent later, then the two can be used in combination.
yes the server can and may update its own provenance once the data crosses its threshhold, but that is not what we are talking about here. This is specifically client side provided provenance. I should make that clearer. We are trying to define a minimum set of data and avoid transacting large bundles of data including practitioner and organization. See the contrived example at the bottom of the page.
I forgot about x-provenance thanks for that and thanks for your response
Lloyd McKenzie (Jul 21 2021 at 16:16):
Kitchen sink terminologies aren't necessarily something to avoid if there's an appropriate code there. (SNOMED is far more kitchen sink than ObservationValue, and we rely on it heavily.) Better question is whether the semantics of the code tightly align with your requirement. If not, then fine to define a new one, though that'll probably end up somewhere in terminology.hl7.org too - once the usage has matured to the point where we're comfortable defining an 'official' code
Josh Mandel (Jul 21 2021 at 16:28):
I will also note that paradoxically, providing more nuanced modeling may make it more difficult to build interoperable solutions here. For example, have different codes for patient asserted versus related person asserted versus caregiver asserted... makes it harder to detect/filter/search for "stuff that came in from a patient app". I think we should be parsimonious and basically define one tag, if we can get away with it.
Lloyd McKenzie (Jul 21 2021 at 16:41):
It's also possible to mandate one tag and allow systems to also send finer-grained tags if they find value in doing so.
John Moehrke (Jul 21 2021 at 17:44):
there is a security tag vocabulary that seems to be what you are looking for.
http://hl7.org/fhir/R4/v3/SecurityIntegrityObservationValue/vs.html
PATAST patient asserted Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient.
John Moehrke (Jul 21 2021 at 17:45):
that tag would indicate the data came from the patient. I think the workflow need to have someone review it is independent from marking that it came from the patient (provenance). This valueset holds many assertions of quality/integrity/accuracy/precision/sourcing... as simple tags vs a whole Provenance that would need to be interpreted (and would likely use these vocabulary anyway)
Eric Haas (Jul 21 2021 at 17:51):
@John Moehrke that is what we are discussing above, I am proposing reusing some of those and Josh is proposing a new set. I am willing to prune it down to a scant few.
John Moehrke (Jul 21 2021 at 17:54):
scant few...as in ONE... right?
John Moehrke (Jul 21 2021 at 17:54):
your implementation guide should certainly not send them to the wolves (like we did in the core spec... sorry about that).
Josh Mandel (Jul 21 2021 at 18:02):
"patient asserted" is a bit over-specific; it's close, but the semantics we've been discussing are more like "This came from a patient channel" (collected by a patient's app or device, or communicated by a patient-facing app -- but that could include data generated by an outside EHR, etc)
John Moehrke (Jul 21 2021 at 18:20):
PATRPT patient reported Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient.
Eric Haas (Jul 21 2021 at 18:21):
lets be specific.....here is what I have proposed side by side.
John Moehrke (Jul 21 2021 at 18:21):
not trying to say I have picked the best code.. or that the valueSet given is perfect. Just pointing out that the concept of an integrity tag seems to be part of what you are looking for... where a different part is that the data needs yet to be reviewed by a clinician.
John Moehrke (Jul 21 2021 at 18:23):
I would agree that there seems to be a missing code needed by modern technology... data asserted by a device the patient has chosen.
Last updated: Apr 12 2022 at 19:14 UTC
