Stream: implementers
Topic: Expressing CareRelation in AuditEvent
Øyvind Aassve (Jun 16 2021 at 14:05):
Hi, in relation with implementing an autentication lookup service in a regional EHR from a national service, we need to expose an attribute in the regional EHR that describes the reason/ authorization a clinician has to access the patient in this specific instance. The attribute is logged in the EHR for every time a clinician accesses a new patient has a around 15 values – for example «patient visiting own unit», «delivering anastetics» etc.
As this is information related to the EHRs audit log, we have been thinking AuditEvent sounds like a good candidate resource. But we struggle with how to best express that this is a relation between the patient and the practitioner. A couple of alternatives we have been discussing is to include the 15 codes in the extensible value set AuditEvent.agent.purposeOfUse for example in the TREAT-hiearcy, or to add a coded element with the 15 codes as an extension. Any thoughts?
John Moehrke (Jun 17 2021 at 19:34):
excellent. so these codes are an indication of why the clinician was authorized? if so then I think that would go into AuditEvent.agent.policy. This element is a URI, but you can easily make a URI encoding out of a code (system#code).
John Moehrke (Jun 17 2021 at 19:35):
the purpose of use would not be right, as that is the activities that are authorized, not the reason they were authorized.
Øyvind Aassve (Jun 18 2021 at 13:58):
Thank you @John Moehrke that seesm to fit very well. I'll take it back to the project and come back to you if there are any follow-up questions. Cheers
Trond Elde (Jul 03 2021 at 14:38):
Hi, @John Moehrke . I am working in the same project together with @Øyvind Aassve and have a couple of follow up questions.
1) As far I can see, the Auditevent.agent.policy is a rather generic structure that can hold a list of URL-encoded attributes from an OAuth2 JSON Web token (JWT) which describes an authorization context for the event. Do you agree on that?
2) I am not sure I understand the last sentence "the purpose of use would not be right, as that is the activities that are authorized, not the reason they were authorized." When I check out the terminology binding for https://www.hl7.org/fhir/auditevent-definitions.html#AuditEvent.agent.purposeOfUse, then I see codes that we are looking for e.g. TREAT and Break the glass (BTG). The definition / comment fits to: "The reason (purpose of use), specific to this agent, that was used during the event being recorded" / "Use AuditEvent.agent.purposeOfUse when you know that is specific to the agent,...". Maybe you can elaborate on that?
Lloyd McKenzie (Jul 03 2021 at 22:37):
@John Moehrke
John Moehrke (Jul 06 2021 at 11:19):
Sorry for the delay, vacation. Realistically you can put anything into any element. I can't stop you. I am just trying to express the intention of the design.
John Moehrke (Jul 06 2021 at 11:23):
Are you looking to create an AuditEvent when a token is issued? If so, then why not record the JWT content in the AuditEvent as an AuditEvent.entity? This is to say that the AuditEvent is created because the token was issued, and records the issuance of that token. You could either just encode the JWT (json) into the AuditEvent.entity.description; or you could split out the elements into AuditEvent.entry.detail value pairs. There is a jira ticket asking for this to be shown in a example, so I would very much like to work with you to get this jira ticket resolved with an example.
Trond Elde (Aug 22 2021 at 07:47):
Thank you @John Moehrke I am back after a long summer holiday, so no problem with a couple of days of delay.
No, we are not looking for audit event for issuing of JWT tokens, but the underlying reason for access that this specific agent accessed the patient EHR, e.g. CRUD on EHR documents. The JWT is just a carrier of information, and not interesting in itself.
And yes, we want to comply with intention of the design. The challenge is that the description is rather sparse and no relevant examples to study as far I can see. If you have time, you can take at look at Incident registration and follow up document (code of conduct document) from Norwegian authorities and especially
4 The incident register must, at minimum, contain
a) For authorized use:
....
The reason for access (e.g. medical care, principle of necessity access, administrative
use)
"Principle of necessity access" = break the glass (BTG)
John Moehrke (Aug 23 2021 at 12:00):
The reason for access -- this is what we call PurposeOfUse. The AuditEvent has a .purposeOfEvent to record the purposeOfUse at the event level, and also has .agent.purposeOfUse when an event has multiple agents with different purposeOfUse.
Last updated: Apr 12 2022 at 19:14 UTC
