Stream: implementers
Topic: event logs?
Craig McClendon (Nov 13 2018 at 17:08):
I need to track device event information such as last sync time, etc.
Eventually, this information may be used in an automated workflow of some sort.
For instance, a user may have a CarePlan that dictates they measure their blood pressure daily.
The device in question may connect to sync regularly whether there are new Observations or not.
The absence of data could trigger different actions depending on this information.
A stale "last sync time" might indicate connectivity problems rather than patient compliance with the care protocol, for instance.
Anyway, I'm trying to determine the most appropriate way to track these things which will (hopefully) also be amenable to an automated workflow process.
Can someone provide some guidance on the most appropriate resources for this?
Lloyd McKenzie (Nov 13 2018 at 17:18):
What would a "sync" look like? A post of an empty Batch? If so, you might look at Provenance or AuditEvent
Craig McClendon (Nov 13 2018 at 17:31):
All the information will be coming in via a proprietary 3rd party APIs. We will take the information and create FHIR resources from it (Device, Observation, etc.) which will be processed downstream and persisted. But there is other information beyond just the device readings. And "syncs" with no readings will also come in. So think of it as a json blob with sync time, and if present the device readings captured during that sync. A sync here being the device communicating to a hub/mobile app of some sort (PHG) which is sending the data up to the "cloud". If that makes sense.. I've considered AuditEvent, but am wondering if Communication would lend itself better to future uses as it's part of the workflow specification.
Lloyd McKenzie (Nov 13 2018 at 17:37):
Communication is intended to represent information sharing at the person-to-person level, not so much the system to system level. @Michelle (Moseman) Miller, perhaps we need to add some guidance that differentiates Communication from something like AuditEvent
John Moehrke (Nov 13 2018 at 17:41):
IHE has profiled AuditEvent for the purposes of tracking various events with the intent on being able to analyze those events for efficiency and workflow improvements. This sounds similar to what you are describing. See the SOLE profile https://wiki.ihe.net/index.php/Standardized_Operational_Log_of_Events
Craig McClendon (Nov 13 2018 at 17:50):
Thanks guys. The intent of AuditEvent appears solely focused on security rather than general operational events or logging - which gives me pause to use it here. Am I misunderstanding it?
John Moehrke (Nov 13 2018 at 17:57):
that is not correct. can you point at the specific wording that leads you to that? As you can see from IHE, they are using it well beyond security. It is a general purpose AuditEvent resource. Yes, the initial use-cases were security. Yes there are no examples, yet, beyond that.
Craig McClendon (Nov 13 2018 at 18:01):
"A record of an event made for purposes of maintaining a security log"
"The content of an AuditEvent is intended for use by Security System Administrators, Security and Privacy Information Managers, and Records Management personnel. This content is not intended to be accessible or used directly by other healthcare users..."
But reading more closely I see this, which seems to give an "out" for other uses :)
"The primary purpose of this resource is the maintenance of security audit log information. However, it can also be used for any audit logging needs and simple event-based notification."
Robert Ussery III (Nov 13 2018 at 18:10):
(deleted)
Robert Ussery III (Nov 13 2018 at 18:18):
(deleted)
Robert Ussery III (Nov 13 2018 at 18:18):
(deleted)
Craig McClendon (Nov 13 2018 at 18:19):
@John Moehrke - I don't see anything in the SOLE page linked that discusses FHIR or AuditEvent.
Robert Ussery III (Nov 13 2018 at 18:31):
(deleted)
Robert Ussery III (Nov 13 2018 at 18:32):
(deleted)
John Moehrke (Nov 13 2018 at 19:52):
sorry about that. The wiki page for SOLE should have had a link to the formal specification. It seems that committee has not kept their wiki page up-to-date... Here is the formal supplement https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_SOLE.pdf
John Moehrke (Nov 13 2018 at 20:05):
They have also not created FHIR conformance or vocabulary resources. @Kinson do you have a plan to provide these?
John Moehrke (Nov 13 2018 at 20:07):
"A record of an event made for purposes of maintaining a security log"
"The content of an AuditEvent is intended for use by Security System Administrators, Security and Privacy Information Managers, and Records Management personnel. This content is not intended to be accessible or used directly by other healthcare users..."
But reading more closely I see this, which seems to give an "out" for other uses :)
"The primary purpose of this resource is the maintenance of security audit log information. However, it can also be used for any audit logging needs and simple event-based notification."
good catch. I guess I am too close to this to see such blunt text. Yes, this should be softened.
John Moehrke (Nov 13 2018 at 20:10):
I created GF#19644 to drive for softening of that language. It is historic, but is not representative of current intent.
Kinson (Nov 14 2018 at 04:18):
@John Moehrke , thanks for letting me know. SOLE is first IHE Radiology profile that uses a FHIR resource and we are just starting learning what it all means to profile FHIR resources. I will bring this up during Radiology Technical Committee meeting this week and we will discuss how to proceed.
IHE Rad is starting to have new profiles using FHIR resources. So learning how to do it properly is important for us.
Elliot Silver (Nov 14 2018 at 04:19):
I submitted an IHE RAD CP earlier today to add the FHIR conformance resources to SOLE.
Michelle (Moseman) Miller (Nov 16 2018 at 09:19):
@Lloyd McKenzie you had commented earlier:
Communication is intended to represent information sharing at the person-to-person level, not so much the system to system level. @Michelle (Moseman) Miller, perhaps we need to add some guidance that differentiates Communication from something like AuditEvent
I don't think Communication is limited to person-to-person since sender and recipient can reference Device (for CDS). FYI -- I think the boundaries section does have some guidance on boundaries between Communication and AuditEvent as follows:
While AuditEvent can track electronic disclosures of information, it cannot track conversations, phone calls, letters and other interactions that are not system-to-system. And even for system-to-system communications, the specific end recipients might not be known. As well, AuditEvents are not considered to be "part" of the patient record, while Communication instances are. The Communication resource is not used as a general audit mechanism to track every disclosure of every record. Rather, it is used when a clinician or other user wants to ensure a record of a particular communication is itself maintained as part of the reviewable health record.
Lloyd McKenzie (Nov 16 2018 at 09:32):
I agree that it can handle sharing between devices, but it's not intended as a substitute for logging of data exchange. I'm happy with the quoted language from the spec in terms of setting appropriate boundaries
Craig McClendon (Nov 16 2018 at 14:48):
Thinking out loud.. It seems like a more generic resource could be useful. AuditEvent is still heavily security focused. All of the Valuesets are security related. And while they are defined with an Extensible binding, trying to fit non-security related events into it feels very much like a hack (to me).
It might make sense to have AuditEvent be defined more generically and have security profiles defined for it instead, although possibly too late for that. It might also be useful if there was some sort of generic event as part of the FHIR Workflow spec.
Lloyd McKenzie (Nov 16 2018 at 15:29):
Feel free to submit a change request with that feedback. It may be that the current value sets are overly tight. The resource has relatively low maturity, so changes are absolutely possible.
John Moehrke (Nov 16 2018 at 18:42):
I agree with Lloyd, both of these resources need more clarity. I have failed at keeping AuditEvent scope and description up-to-date with how it is intended to be used. I would disagree with an assertion that AuditEvent is not part of the patient record. The events associated with a patient record are part of that patient record. For example the AuditEvents that make up an 'accounting of disclosures', or 'access report' are clearly patient relevant. I am not sure what the quoted text is trying to distinguish. I would say that AuditEvent and Communication clearly are different intent. Please submit comments with your perspective to help us differentiate, distinguish, and clarify.
Jay Lyle (Jun 08 2019 at 21:13):
Several objects in VistA (mostly orders but not all) have "activity log" subfiles for capturing certain changes for clinical users. They contain dates, users, reasons, and sometimes the old content.
Following John's clarification, I think AuditEvent is the right tool; we need to extend the resources to contain AuditEvents. We'd profile it with a less regulatory-sounding name - ChangeEvent, perhaps, or Redaction. (We'd also need to add a few extensions for old content, comments, etc.)
Does this sound reasonable?
Lloyd McKenzie (Jun 08 2019 at 21:18):
Provenance gives you all changes to data. AuditEvent adds read accesses. Provenance is more typically exposed than AuditEvent
Jay Lyle (Jun 08 2019 at 21:38):
That's the other solution we considered. I take it the term "adds" suggests they are both acceptable in the areas of overlap?
The tooling we have produces the core object container, and it can point out, but it can't produce ancillary resources pointing back in.
Not the kind of thing you want determining your design but there it is.
Jay Lyle (Jun 09 2019 at 15:41):
Cases where we did specify Provenance (not for edits but for signers & verifiers) look like they'll be handled with extensions.
John Moehrke (Jun 10 2019 at 13:19):
I would like to dig deeper. Given what you have said, I don't know if it is more of a Provenance or AuditEvent. I would tend to say anything that is going to be used for clinical practice, should focus on Provenance. AuditEvent tends to be more for operations oversight (privacy, security, efficiency, safety, etc)... but this is just overall trend. But because of this trend, the AuditEvent is often filtered over time.
John Moehrke (Jun 10 2019 at 13:20):
note that a change that is approved but that I have not yet put into the specification is to recognize that Provenance.activity valueset should include all of the EHR lifecycle events.
Jay Lyle (Jun 11 2019 at 17:36):
It seems that there are clear cases where a thing is Provenance and not an AuditEvent (creation, transfer), and other cases that are AuditEvents and not Provenance (all the system-level stuff that's explicit in the definition). And there are things that could be either, like changes.
We have lots of MedicationOrder (DSTU2) record metadata, roughly in 2 categories:
1. Signer, cosigner, verifier: name, title, date, organization (not signature, just the metadata)
2. Changes: date, action, reason, person, object, old, new, action status
(These are all for the Pharmacist UI, though maybe a click or two deep.)
My assumptions were that the first was Provenance, the second AuditEvent.
I'm profiling the second as AuditEvent. It's a little more elaborate than I assumed, but it seems to work.
But I can't even start include Provenance in the profile because of the navigability: it points the wrong way. So the first batch may wind up being AuditEvents as well, less because of semantic intent than feasibility. Maybe they should just be extensions until this is worked out.
John Moehrke (Jun 11 2019 at 17:52):
These both look like Provenance to me.
John Moehrke (Jun 11 2019 at 17:53):
can you explain your concern on navigability?
Jay Lyle (Jun 12 2019 at 18:29):
Because the Provenance points at the Order, not vice-versa, we can't specify the required elements in an Order profile; we'll have to create a second profile for the Provenance, and we'll need some robust and clear natural language in the IG to make sure it's built right. (Or something more exotic, like a GraphDefinition.) Also, the integration engine may not support generating resources outside the top node of the Order; still looking into that.
John Moehrke (Jun 12 2019 at 18:50):
I am still missing something, especially when you say AuditEvent does not have this problem. Provenance and AuditEvent both would point AT the things involved, so there is no difference here. I really want to understand as I really think there is some misunderstanding. I am responsible for Provenance and AuditEvent, so I have a vested interest in them being used properly and am very concerned if there is a defect found that is preventing them from being used as intended.
John Moehrke (Jun 12 2019 at 18:52):
The direction of pointers in REST is related to which resource likely came second, and thus more naturally can point at the thing that came before, or said another way the older resource does not need to be updated each time some new resource points at it. Yet all pointers can be followed in either direction, one via dereferencing (the easy one), the other by a query by referenced value (slightly more hard).
Lloyd McKenzie (Jun 12 2019 at 19:02):
Even if the order pointed at Provenance, you'd still have to define a profile on Provenance separately from the Order profile. You can't nest across references when defining profiles.
Jay Lyle (Jun 12 2019 at 22:12):
John: right, the fact that AuditEvent has the same design intent has been brought to my attention. (But not the same constraint.)
Lloyd: right; defining another profile isn't the issue; it's instantiating two top-node resources from one container. The notional design on slide 8 uses an extension of type Reference profiled to point at the profiled AuditEvent.
I am unclear on the concept behind the MedicationRequest.eventHistory. If it can only refer to prior versions, it can't tell you how the resource got into its current state.
I've tried to digest our options in a slide deck. Maybe this could be a topic on a Security call? ChangeEventDesign.pptx
John Moehrke (Jun 13 2019 at 13:07):
Which constraint is different?
John Moehrke (Jun 13 2019 at 13:13):
In the case of the pattern used (for example MedicationRequest.eventHistory), this is a sub-set of the Provenance that the author of the MedicationRequest 'feels' is most relevant. There will be many other Provenance instances, and ALL of the Provenance instances are discoverable by just looking for Provenance resources with target equal to the MedicationRequest id. The fact that the 'last' Provenance is not included is simply because the Provenance can't exist before it exists, and the last Provenance is discoverable as I mentioned above. So there is easy access to the last one, and the list found in eventHistory.
I was not involved in the creation of this eventHistory mechanism, and just found out about it a month ago. I have questions and concerns about it.
Are you trying to do something like is defined in eventHistory?
Jay Lyle (Jun 13 2019 at 21:41):
Sort of. What I'm suggesting is a way around a design constraint I believe the integration tool is imposing, but let me re-confirm my understanding before spending more of your time.
Jay Lyle (Jun 13 2019 at 21:43):
Regarding different constraints, Provenance has target min cardinality of 1; AuditEvent doesn't.
John Moehrke (Jun 14 2019 at 12:40):
This is because AuditEvent is intended to be used to record things like "User Login successful", etc... it is about an event... Where as Provenance is about a Create or Update of some Resource. And this C/R has been updated a bit to include some modifiers such as Verify or Sign (the addition of .activity vocabulary from EHR Lifecycle events is approved but not yet applied to the current build). But always there is a target that is being addressed. Yes, this is a difference. But in the use-cases you have expressed here, there was a target resource. So this is why I am confused.
Jay Lyle (Jun 18 2019 at 17:05):
OK, constraint confirmed. We'd like to use Provenance or AuditEvent as designed, but right now the tooling does not support that. We cannot implement as designed. But we still have all this log data to handle.
I understand that AuditEvent is intended to refer to its target when it has one. But the fact that there's no conformance requirement for that makes it handy.
I think it would be preferable to write an extension that leverages the AuditEvent design in a way that will make the AuditEvents recognizable in the near term and easier to migrate to the correct design in the long term, than to write a bunch of extensions that won't do either. Am I wrong?
John Moehrke (Jun 19 2019 at 16:29):
I am still very confused on what it is that you are struggling with. Lets work backward from the best-case... Given the current build of FHIR, what changes are you thinking are needed on Provenance to enable it to be used as you desire?
Jay Lyle (Jun 19 2019 at 17:13):
One: is the appropriate resource Provenance or AuditEvent? I still don't see any explanation of the distinction that's clear enough for me to assign our cases.
Two: I'm not proposing changing any existing specification designs. And I have not given up on getting the tools to support the intended design, but that might not work.
So, if it doesn't (because the data container has to contain ancillary objects; it can't refer to independent objects) , what are the implications of implementing a modified design that is conformant but not identical to the design intent (and should support migration to the intended design in the future), versus just creating a bunch of extensions. For the former, AuditEvent does the trick: I can put an extension on a resource and contain those events.
John Moehrke (Jun 19 2019 at 17:17):
I would really like to understand the problem that you are having.
I get the impression that your problem might be being caused by your tool? What tool? What problem is it causing?
But I also get the impression that you are thinking of some modifications... what are those modifications? If I could understand these modifications, then I might be able to understand the problem you are having.
John Moehrke (Jun 19 2019 at 17:19):
does this article help you understand Provenance vs AuditEvent? https://healthcaresecprivacy.blogspot.com/2016/03/provenance-vs-audit-it-is-not.html
Last updated: Apr 12 2022 at 19:14 UTC
