Stream: implementers
Topic: Initalisation and unload operations
Lauri Karppinen (Apr 16 2019 at 08:36):
I have been using provenance resource to present operation made by practitioner. 'CREATE' is at the moment used for "Measurement operation" and 'UPDATE' for "Update operation". Codes are from: https://www.hl7.org/fhir/v3/DataOperation/cs.html. Now I would need a way to present few more operations. These operations are associated with serial monitoring study where the device is initialized for patient. Patient makes measurements and practitioner unloads measurements afterwards. So I would need way to present initialization of device and another for unloading of measurements from the device. Any tips how to present these would be much appreciated.
Lloyd McKenzie (Apr 16 2019 at 12:51):
Keep in mind that Provenance represents metadata associated with the creation of a new version of a resource. Would all of these result in new versions of the Device resource? If not, you might want to look at AuditEvent instead.
Lauri Karppinen (Apr 17 2019 at 09:14):
Thanks fro the answer @Lloyd McKenzie . I'm not sure if I fully understood Your reply. Provenance was recommended for me earlier as a best way to present operations. Now I'm confused how to get this work. I already added provenance to our implementation. Provenance has now reference to practitioner and to top level grouper observation which groups whole study together (grouper observation is referenced from target and practitioner from agentWho). Reference to this grouper observation is obligatory because there can be several studies. So device itself is not referenced directly from Provenance. Device is only referenced from observation. These operations which I'm trying to present are operations practitioner can make for the "study" (measurement, update, initialization of device, unload measurements from device and later calibration check for device). I have been studying AuditEvent resource. There can be only one resource as a agent.reference. Is there a another place for reference in AuditEvent, I can't figure that out? If I have to use AuditEvent could the operation itself be presented as ("outcomeDesc": "Device initialised") and action would be ("action": "E"). If this is the right way to use this resource it seems more flexible than provenance.
Lauri Karppinen (Apr 17 2019 at 10:29):
For provenance as activity I was considering code: ENT, Data Enterer, from http://terminology.hl7.org/CodeSystem/v3-ParticipationType to present UnloadMeasurements. For initalization of device I didn't find anything suitable. So does the use of Provenance seem wrong way to do this?
Lloyd McKenzie (Apr 17 2019 at 15:13):
Provenance reflects the creation of a new 'version' of one or more records. It doesn't reflect things that happen in the real world unless there's a record that's updated as a result. The Provenance must point to the record version that was created as a result of the event the Provenance is describing. (That's what Provenance.target does.) You could have a Provenance for each Observation made and each time a Device was updated. Alternatively, if you want to capture that there was some manipulation of the device and don't want to record an update to the Device, you could capture a Procedure that reflected device initialization or calibration. And those Procedures could be 'partOf' the overall observation
Lloyd McKenzie (Apr 17 2019 at 15:13):
AuditEvent is generally not explosed to clinical users.
Lauri Karppinen (Apr 23 2019 at 08:43):
Hey! I'm back at trying to solve this problem after holidays. At the moment when I'm referring from provenance to "study" observation which groups whole study together. Provenance does not directly effect to this observation but other resources under the tree of observations and other resources are effected. Actually one operation can effect more than one resource at the same time. So it would be new version after each operation. At least under the tree of observations. If practitioner makes a measurement which would be a 'CREATE' action. Measurement would make the whole tree of observations provenance referring to the top of the tree. So would this actually be the right way to do this? Using provenance I still have problem how to present "InitialiseDevice", "UnloadMeasurements" and possible calibration check.
So if I would need to use AuditEvent to store these operations, would it be right way to use it as I tried to demonstrate earlier? Measurement would be create ("action": "C", "outcomeDesc": "Measurement"), "update" would be ("action": "U", "outcomeDesc": "Update"), "InitialiseDevice" could be ("action": "E", "outcomeDesc": "Device initialised"), "UnloadMeasurements" could be ("action": "E", "outcomeDesc": "Measurements unloaded").
If this is proper way to use AuditEvent it seems more flexible than provenance. I still don't know if it can be used because I need a link to top level observation because there can be several studies which are made by same practitioner. I hope i managed to explain my use case right.
Lloyd McKenzie (Apr 23 2019 at 14:52):
Actually, Provenance would point to every single new version created. If you do an 'import' operation that creates 30,000 new records, in principle there should be a single Provenance that points to all 30,000 new resource versions. There's no notion of parent-child inheritance with respect to Provenance (or much of anything at all) in FHIR. AuditEvent would tend to work the same way.
Last updated: Apr 12 2022 at 19:14 UTC
