GP Connect - Cross Organisation Audit & Provenance

FHIR
1

The latest spec it contains:

Consumer systems SHALL provided audit and provenance details in the HTTP authorization header as an oAuth bearer token (as outlined in RFC 6749) in the form of a JSON Web Token (JWT) as defined in RFC 7519

Important: Whilst the use of a JWT and the claims naming is inspired by the SMART on FHIR the GP Connect programme hasn’t commit to using the SMART on FHIR specification.

Is this going to use OAuth2? If so what kind of grant types would be supported?
I’d hope this access method would span other projects such as Record Locator Service and e-Referral Service api’s.

The reason I ask is this has implications which technology stack we would use. Our current tech for integration has some difficulty supporting (although our supplier would probably fix this) but we could go down another route and do this ourselves [Currently working with a large trust and we have staff who can do this].

2

No problem with JWT tokens but not convinced that SMART claims can map cleanly to services :frowning2:

3

As I understand we’d just need to build the token (no user authentication) and pass it in a request header (no authorisation server or grants).

Doesn’t sound that difficult, I’d be tempted to build the facade to the service ourselves (We’ve normally purchased this).

4

Is the JWT not digitally signed then?

5

No (it’s not).

6

If the requestor supplies unsigned audit and provenance details, how does the server establish trust with the requestor i.e. what prevents h4ck3r@dark.net from presenting audit and provenance details as, say, kev.mayfield@nhs.net?

7

The trust is down to PKI certificates with TLS Mutual Authentication (MA). Think I’m correct in saying the JWT is for audit purposes (and eventually RBAC).

We had a few issues with another system like this, we could only put iam.a.computer@abc.nhs.uk in the header and then had social services asking why Iama Computer was accessing records.

1 Like