Stream: IPS
Topic: machine-attestation in IPS
Ken Sinn (Sep 01 2020 at 03:03):
Hi all,
In the context of the primary "unplanned cross-border care", I remember we had recognized the importance of human attestation in a patient's IPS. As use of IPS expands beyond that initial use case, is there any guidance around allowing "machine-attestation" of IPSes, e.g. an IPS compiled based on all available data in a patient's records across multiple repositories/assets?
Composition.attestation.mode="official" seems to support this, with Composition.attestation.party[Organization] pointing to the organization assembling the data.
Does this seem like an appropriate use? Or is the attestation component not relevant for situations like this (IPS electronically compiled based on avail data across repositories)?
Rob Hausam (Sep 02 2020 at 21:48):
My guess is that attestation isn't particularly relevant in general for the use case that you are describing. But, if "machine-attestation" did seem to be needed or desirable to use in a particular situation, I think the way that you described doing it (except that it's Composition.attester) seems to make sense. Other thoughts?
Derek Ritz (Sep 16 2020 at 18:44):
Ken and Rob -- I think on-demand generation of IPS documents will be hugely important as a use case and the issue of attestation, or the related issues of provenance (of the document... and of the underlying content) will loom large. It seems to me to make sense that a machine-compiled IPS would carry the provenance of the underlying data into the generated document. Is that how others see it, too?
Morten Ernebjerg (Sep 16 2020 at 19:44):
@Derek Ritz We are also looking into this, including how to deal with mixtures of healthcate provider data and patient-reported data. I agree that for purely generated IPS instances, some sort of more fine-grained provenance tracking will likely be needed. For smt. like current medications, I guess you would have to go down to resource-level granularity if you want to include patient-reported over-the-counter meds together with prescribed meds. But we don't have anything concrete yet & are looking for inspiration.
One thing I am asking myself, however, is how well clinical systems receiving IPS instances will be able to deal with such fine-granular provenance (for cases where they actually want to integrate the data in some way). I'm not very familar with such systems, but I could imagine they might react by requiring manual review of each piece of data before integration. In which case one is merely shifting the work of human review to "the other side".
John Moehrke (Sep 16 2020 at 19:54):
a receiving system could be given the 'expected action' that says they 'could' save the provenance, thus allowing them to be provenance ignorant. The fact that it is carried in the IPS does not need to be a burden... however missing it, does present a problem of unknown provenance.
John Moehrke (Sep 16 2020 at 19:57):
There is a Basic Provenance IG that sets forth a minimal provenance of (a) where did you get this data from, and if known (b) the original author. Encouraging this level of provenance on all resources in the IPS would be useful.
Derek Ritz (Sep 16 2020 at 20:19):
In my view, the provenance of an on-demand IPS should be supported at the resource level (if available) and mandatory at the document level. Is that how others are feeling, too?
John Moehrke (Sep 16 2020 at 21:14):
I am unclear what you are meaning... certainly a Provenance can be declared at the document level that indicates that the agent that authored it was a service and not a human. This is always possible with all Provenance.
Ken Sinn (Sep 17 2020 at 02:11):
I'll need to take a look at the Basic Provenance IG, but if it identifies where each resource in the IPS is sourced from, I don't think that would be considered too much detail. It might not carry the full provenance/history of the data (e.g. medication is sourced from the provincial drug repository, contributed by the provincial billing system, via a billing submission from pharmacy XYY) , but it should identify the immediate system (the provincial drug repository). It provides a "next steps" to investigate if any of the data is amiss.
At the very least, if a primary care physical pulls up a patient's IPS, they can see that oh, these three labs came from the provincial lab repository, these 2 labs came from acute care repository (even though the actual labs and actual acute care facilities aren't tracked on the provenance). And that's only if the EMR software feels it important to process and display that information to the end-user. In some cases, that might not even be a requirement.
So how would the provenance resource be best transmitted along with the IG? through the custom provenance header? What happens if the IPS is delivered strictly as a json/xml file, without header information?
Ken Sinn (Sep 17 2020 at 02:14):
Is http://hl7.org/fhir/us/core/STU3.1.1/basic-provenance.html the one I should be looking at?
John Moehrke (Sep 17 2020 at 12:10):
yes that is it.
John Moehrke (Sep 17 2020 at 12:14):
I am noticing in the FHIR core on the documents page http://build.fhir.org/documents
The document bundle SHALL include only:
The Composition resource, and any resources directly or indirectly (e.g. recursively) referenced from it
A Binary resource containing a stylesheet (as described below)
Provenance Resources that have a target of Composition or another resource included in the document
John Moehrke (Sep 17 2020 at 12:15):
which seems to indicate implicitly 'all provenance'; where I would expect it to be just 'basic provenance'.
John Moehrke (Sep 17 2020 at 12:16):
I would have actually expected that Composition would need to explicitly include these basic provenance, so as to differentiate from all provenance.
John Moehrke (Sep 17 2020 at 12:17):
this is all just the unknown given the maturity of FHIR documents. So, the experience of IPS should create a set of CR to improve the core spec.
Lloyd McKenzie (Sep 17 2020 at 14:40):
I don't think it's saying that Provenance must be there or how much, it's just saying you're not allowed to send stuff that isn't linked to the Composition. I think Provenance gets called out because it points to the target as opposed to stuff in the document pointing to it. It's certainly not wrong for a document to have full Provenance. The typical case is that a document won't contain any Provenance (because that's the typical case for data sharing with FHIR everywhere, unfortunately).
John Moehrke (Sep 17 2020 at 14:44):
@Lloyd McKenzie I very much agree with you. I see nothing wrong. I was more advising IPS to add more specificity within the IPS, and to remind them that CR are welcome.
Last updated: Apr 12 2022 at 19:14 UTC
