Created by David McKillop, last modified by Rob Eastwood on 29 Jan, 2020

Date

Attendees

Minutes

  • Practitioner Qualifications working session, review the drafts worked on by Jane Gilbert, Brian Postlethwaite, Rob Eastwood and Uday - see https://github.com/hl7au/au-fhir-base/pull/324
  • New - Agency is reviewing "AU Base Address", should it be visible from the AU Base IG somewhere?
    Yes, include in the data types extensions (it is a best practice for AU addresses)
  • New - AU Base Organization: Australian localised terminology for au-organization.type: Currently has "Binding: OrganizationType (example)".  Refer to GitHub:  #333
    Note: Provider Directory (StructureDefinition-au-pd-organisation ) uses the default Binding: OrganizationType (example).
    Valueset not currently expanding, this seems like the correct path to be taking, and propose updating the binding strength to preferred or extensible if the values appear to cover the scope adequately and should be able to get wide support for them - the au-pd example set has other in it, which makes it problematic for an extensible binding. Would be good to walk through in Sydney at WGM
  • New - AU Base Organization: Australian localised terminology for au-organization.contact.purpose.  Current valueset (http://hl7.org/fhir/R4/valueset-contactentity-type.html) seems insufficient - would like to accommodate "emergency contact", "Out of hours". (GitHub issue #334)
    would be good to get more clarification on the definition of "emergency contact", and "out-of-hours" is more of an availability field rather than purpose, and also requires the context of what the hours are, which is possibly a location based thing... VhDir defined a complex extension http://build.fhir.org/ig/HL7/VhDir/StructureDefinition-contactpoint-availabletime.html, may consider this, or something a similar way.
  • New - AU Base Organization: NATA identifier has no invariant(s) controlling the quality of the value, whereas all other identifiers do. GitHub #335
    Makes sense, please gather the details (wink)
  • New - AU Base Practitioner Role: identifier:nationalProviderAtOrganisation has the format of "HPI-I@HPI-O", but currently has the constraint of "inv-npio-0: NPIO length is exactly 33 characters" which would allow any 33 characters.  Should there be further constraints such that characters 1-16 should conform to HPI-I, character 17 = "@" and characters 18 to 33 should conform to a HPI-O?
  • New - AU Base Practitioner Role profile: minor detail - identifier:nationalProviderAtOrganisation.type.text is "NPIO" where as the text in other identifier slices is the display content of table 0203 and hence should identifier:nationalProviderAtOrganisation.type.text be "National provider at organisation identifier" rather than "NPIO"?
    Yes, this makes sense, we should consider if there is any meaningful shortening of the above, but probably not.
  • New - AU Base Organization: remove max length constraints as invariants perform this check. GitHub #336
    Agreed, however think that a min length and max length would be preferred, as these can be used in user interfaces too, and remove the invariant for the length. (and any other identifiers with this type of restriction)
  • New - AU Base Address profile - being generated but not linked in IG (still has some STU3 references)
    Agreed - take out the STU3, as these are all version agnostic extensions. Updating some of the examples to check the validation rules (expected failing ones don't fail).

Discussion on securing FHIR Servers with NASH certificates and OAuth JWTs

ADHA late in 2019 circulated a document "Provider Addressing Service - Security Profile High Level Options Assessment" that shows several approaches that they presented as options when considering the Secure Messaging Industry offer.

When the industry offer came out, it supported the use of Mutual TLS (using NASH certificates, or secure messaging vendor created certificates), or api-keys.

The approach I'm going to present and discuss here covers the final option in more detail 4 - OAuth JWT with NASH Certs.

The primary driver to this approach is to leverage existing investment in the industry to provide authentication without requiring another layer of user credential managements, especially in the space of system to system communications across essentially the entire sector.

This is not a replacement of other approaches, but an alternative where the situation enables it. Since NASH certificates are not likely to be used available on mobile devices, it may not be used in that space, however could be used in backend services serving mobile applications.

This is only intended to cover the Authentication stage, not the authorization stage. That should still use the other defined approaches, such as the SMART on FHIR scopes, and potentially others such as HEART.

FHIR standards Background

(also noted in the ADHA document)

SMART on FHIR - suitable for cases where the user is managed by the system behind the FHIR server, and requires them to login using a known system.

SMART backend services authentication - suitable for system to system use cases, however currently requires public keys of all clients to be registered with the server (management difficulty increases with large sets of users, and clients)

FHIR Server Authentication Flow (for discussion only)

In essence it’s an authentication using a JWT assertion signed with the NASH cert exchanged for a bearer token that provides a SMART token for use in the FHIR server (with requested scopes).

  1. Client accesses the FHIR server, reads the capability statement to discover the location of the Identity Server's Token endpoint.
  2. Client creates a JWT identity token, signs this with the NASH organization certificate, then calls the Token endpoint with that token (along with the client ID and secret for the app) to retrieve an access token (bearer) - opaque reference, not JWT (which means it is smaller to transmit, and less susceptible to tampering)
    This call will use the NASH organization certificate as a client certificate to connect to the Identity Server
    The identity server checks that the client certificate is from a known/accepted CA (Medicare etc) and is the cert that was used to sign the JWT.
    Note: There could be 500 installations of the FHIR client app that share the same client ID/secret, however each installation is likely to have it's own NASH certificate
  3. Client calls the FHIR server as normal using the access token - bearer (opaque) in the Authentication header of each request. (noting that there is a small validity window for each token, defined by the identity server)
  4. The fhir server checks the bearer access token (as a reference) with the Identity Server's introspection endpoint to retrieve the actual token and claims that it can then use while serving up the data requested by the call in step 3.

Without using the NASH certificate (or one with a known/registered CA parent cert) we’re back to the problem of chasing the source of the public keys…
This approach means that the FHIR server itself only requires the bearer token, and doesn’t need to know anything about the digital certs.

This approach deviates from the SMART Backend services spec which requires the pre-registration of the public keys, potentially using Dynamic Client Registration, so I think we have something new here.

An example of this flow from a C# client's perspective has been created for feedback:

https://gist.github.com/brianpos/a4b95bedf06d2ba7789b055c92b92d0a

(haven't walked through the refresh token situations yet)


Next Meeting:

  • New -codesystem-au-hl7v2-0203: fix QA error but there are implications for implicit value set capability; see GitHub #327  ** Leave discussion til Feb 2020.
  • New - AU Base Organization: consider Organization.contact extension reference for 0..* locations; see GitHub #337   ** Leave til 2020.
  • Connectathon - update

Action items

  • Brett Esler to contact HISA to see if they have any informatics people that can assist in the review of the data elements and terminologies
  • Brett Esler to check if there is a contact in the College of General Practice that can assist
  • Jane Gilbert to check with AHPRA if they are able to assist with this
  • Brian Postlethwaite to check with the US ONC folks for some examples on their usage

Items for next meeting

4 Dev 2019 - Connectathon planning

Review HL7 International Encounter modelling issues

Review HL7 International Patient Merge draft


Attachments:

image2020-1-21_10-3-8.png (image/png)