Stream: implementers
Topic: Patient Authentication
Brian Reinhold (Jul 09 2016 at 19:20):
In remote patient monitoring patient authentication is quite important. The only way I know how to represent this property in FHIR is via the AuditEvent. It has a user authentication type code. But the only option appears to be 'log in/out'. What if it is an Android or iOS device that provides facial or voice recognition, or fingerprint? How would I represent that in the AuditEvent?
John Moehrke (Jul 10 2016 at 18:12):
Brian, I am not clear on what you are wanting to put into the AuditEvent; but I am worried that you want to put the authentication credentials into the AuditEvent... Please don't ever put authentication credentials into ANY audit. What are you trying to accomplish? I would like to help understanding this so that I can help.
Grahame Grieve (Jul 10 2016 at 21:00):
I thought he referred to the method of authentication, not the credentials
Brian Postlethwaite (Jul 11 2016 at 00:26):
I meant the ID and name, not the password or whatever auth token was used.
That's the whole point of the Audit isn't it? To know who did what?
John Moehrke (Jul 11 2016 at 01:52):
There s an example for Login http://hl7-fhir.github.io/audit-event-example-login.html
John Moehrke (Jul 11 2016 at 01:56):
The AuditEvent.agent.userId would be the place to put the primary identifier for the user. The AuditEvent.agent.name can contain a descriptive text, although I would recommend against any unnecessary descriptive elements in AuditEvent. Where unnnecessary is something that can be discovered by the auditEvent analysis tool -- like looking up the name in a directory.
Brian Postlethwaite (Jul 11 2016 at 02:02):
Yes, in this example that you've provided we do have the username(userId.value) and the name which is the descriptive part.
Brian Postlethwaite (Jul 11 2016 at 02:06):
(sorry, cross posted. Wrong Brian here. Thought it was another thread discussion)
And yes, agree with Grahame's answer here.
Could either extend the valueset to include other authentication methods, or include an extension on the subtype element and when using the login value, to provide a more detailed auth type value.
John Moehrke (Jul 11 2016 at 12:39):
Need @Brian Reinhold to add clarity. The authentication is not something that we have heard is important in our auditEvent. Those federation systems (SAML, OAuth, Kerberos, etc) will typically do their own logging in their own system; it is this that one would go to for this deeper understanding. As @Brian Postlethwaite indicates, an extension could be used. It would however be good to present the need to see if committee finds it compelling to add as core, or even core extension.
Mohammad Jafari (Jul 11 2016 at 20:14):
@John Moehrke I'm wondering if this will get easier if the AuditEvent resource provides a generic vehicle for recording additional attributes. I think in the case of third-party authentication and authorization (e.g. OpenID Connect or UMA) where the authentication/authorization service doesn't necessarily belong to the same domain as the FHIR server, it is important for the FHIR server to autonomously record sufficient evidence that it has done its job in authenticating and ensuring authorization. So although the respective UMA/OpenID Connect services will do their own auditing, the FHIR server also needs to record enough information to provide the evidence for authentication/authorization and enable audit.
Robert Horn (Jul 11 2016 at 20:42):
I've seen patient id incorporate source ID system on a routine basis, e.g., "ID from state DMV". Would authentication source be a reasonable aspect of source of ID also?
John Moehrke (Jul 11 2016 at 20:45):
I have also seen implementations that serialize and base64 encode the SAML or JWT token, and save it in the altId which is an infinite size string. The problem with this is that you then end up with HUGE blot on the audit log service, thousands of exact copies of base64 blobs.
Robert Horn (Jul 11 2016 at 20:51):
Yes, that's a bad idea. I was thinking of something much shorter and more useful. Right now the IDs tend to be something like id^issuer-of-ID. I was considering ID^issuer-of-ID^authenticator or incorporating authenticator with issuer.
Another consideration is using DICOM's "authentication event" http://dicom.nema.org/medical/dicom/current/output/chtml/part15/sect_A.5.3.12.html. From an audit perspective I find tracking of the event of authenticating much more interesting than all the many places that the ID might then be used.
John Moehrke (Jul 11 2016 at 20:51):
Best to get ONE audit entry by the Authentication service that expresses the characteristics of the authenticaiton event. Then all the other audit events only need refer to the session authenticaiton identitifcaiton
Robert Horn (Jul 11 2016 at 20:52):
Right now the authentication event is described in terms of login and logout, but we tried to have it cover the other authentications.
John Moehrke (Jul 11 2016 at 20:52):
and this is already what authenticaiton services (saml, oauth, kerberos, etc) already do record in their own way. trying to get them to convert it to a FHIR specific format is hopeless
Robert Horn (Jul 11 2016 at 20:54):
Not just hopeless, a waste of resources. I was thinking for those cases where someone is looking for a format to use.
Grahame Grieve (Jul 11 2016 at 21:16):
" I'm wondering if this will get easier if the AuditEvent resource provides a generic vehicle for recording additional attributes" - that's called an extension
John Moehrke (Jul 12 2016 at 12:50):
@Mohammad Jafari -- FHIR already defines a well behaved extension mechanism. The parent standard in ATNA --- DICOM --- allows well-behaved xml based extension. So in either paradigm you have defined ways to extend. That said, the extension should be careful.
Brian Reinhold (Jul 16 2016 at 09:24):
Grahame, I did mean the method of authentication such as finger print, voice recognition, BTLE UDS, facail recongition, etc. It would mirror the content of the UAC segment in V2 messaging.
Brian Reinhold (Jul 16 2016 at 09:28):
John, Hope I clarified my question. Looks like there are two Brian's in this thread that got short-circuited!
Brian Reinhold (Jul 16 2016 at 09:28):
I DO like the value set idea.
John Moehrke (Jul 16 2016 at 13:41):
I really think that the authentication strength/method should be reported only by the Actor responsible for authenticating. In a Federated Identity model this is a third party. In SAML there is an element that carries the method used to authenticate. So Relying Parties can know. SAML has a vocabulary rooted at urn:oasis:names:tc:SAML:2.0:ac:classes. So there is a vocabulary already in existence. However when you look at it you see that this kind of a vocabulary is very hard to make and manage. Everyone reporting this will simply fill the audit log with unnecessary duplication. I recommend you record the unique instance identifier from the federation authority, and the user identity it claims. This way an audit log analysis can discover more from the log entries that the federation authority records. -- This is simply the principle I urge for all elements in the audit log, to record in the audit log identifiers, not data.
Last updated: Apr 12 2022 at 19:14 UTC
