There has been substantial effort over the last few years to deploy digital tools to the healthcare setting, so that medical records are more computable both in-place and when shared (think decision support for now, evolving to advanced data processing tools, enabled with artificial intelligence). Dozens of health IT service provider organizations have collaborated to better secure this data both at rest and in transit. The biggest mandate we hear from our customers and from regulators is that they don't want to have extra friction dragging down operations in healthcare IT, but rather health data exchange should operate more like in other sectors. Not to mention the obvious financial savings in eliminating unnecessary procedures for the most expensive patients and avoiding unnecessary IT expense outlays from the hardworking providers who deliver care across the country. For these reasons, we spend time at EMR Direct thinking about how our customers, and providers in general, can have better access to the patient data they need, while maintaining privacy and security, and without adding to the list of tools they need to purchase to get their work done.

One concept on which we've been collaborating with our industry peers is the ability to do more with the digital certificates most healthcare organizations already manage today. Certificates provide a way for a third party to link validated attributes about a key holder to that key. Dynamic client registration requires a key holder to provide their key and some other information about themselves which is essentially self-asserted. Coupling these two concepts allows for Dynamic Client Registration with validated attributes.

Typically with Dynamic Client Registration, the goal is to provide a client ID to client software that will be used by a user who has their own separate credentials to access protected resources. But what about background services where there is no user involvement? Generally, credentials allowing the client direct access to the resources without user authorization would not be granted to client software during dynamic registration because the data provided by the client is self-asserted.

It's important to have a way to validate that the client is legitimate, and PKI and digital certificates provide a mechanism to do this that is well-established for other purposes: securing websites, internet-based financial transactions and ecommerce, etc. Similarly, certificates can be used to validate the identity of the operator of the client software seeking access to systems outside of a user-initiated context, such as smart background services or other transactions leveraging OAuth client credentials or their equivalent.

A first-pass approach to this is to use certificates directly in a mutual TLS handshake at the time a client connects to a resource server, in place of conventional OAuth access tokens. The resource server extracts the relevant client identity information from the certificate, after confirming that it has been signed by a trusted party and evaluating other assertions within the certificate according to the directives of a local policy engine. This assumes that the authentication and authorization can both be determined from the identity attributes in the certificate, and that the resource server has the ability to process and validate certificates.

A second variation on this theme is provided by a token endpoint at an OAuth authorization server that issues client credentials in response to requests over a connection that is first established with mutual TLS, where the certificate information and the successful TLS handshake itself are used in place of the more conventional OAuth client ID and secret. In this scenario, the authorization server can issue the client a conventional access token for use by the resource server so that any certificate-based logic can be moved entirely to the authorization server and the resource server only needs to understand one type of access token that may be issued by the authorization server via several different pathways.

Beyond these two examples, PKI-based approaches can also be used to authenticate individual users, not just systems, replacing or supplementing the traditional username/password interaction. We've established how this might be done in our work with ONC's Move Health Data Forward Challenge last year. More on that to follow!

At the upcoming HL7 FHIR connectathon in New Orleans, we hope to see clients requesting FHIR resources or dynamic client registration using a digital certificate, and servers able to respond to such requests. EMR Direct will have such a client and server available for testing at the connectathon.

Acknowledgements: Thanks to Luis Maas, MD, PhD for his technical input.