Data Element Based Query for Clinical Health Information

Printer Friendly, PDF & Email

Comment

UDAP for Client App Registration, Authentication & Authorization

Since FHIR transactions require the use of a FHIR client, client application registration and management is an integral component of query using FHIR. With regards to system authentication for this use case, UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the registration and use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to manually re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of apps to clinical FHIR servers without manual pre-registration. This can be used together with UDAP JWT-based Client Authentication to support reusable client identity for authentication and authorization, to help scale the use of client credentials or authorization code flow, and UDAP JWT-based Client Authorization Grants can be used to transmit Purpose of Use and Consent Information.             UDAP is an open collaborative developing profiles to increase scalability, confidence, security, and trust in Open API ecosystems, and allows the re-use of identity proofing and credentialing processes already in place in existing national health information networks. These profiles are in draft status and are in pilot stage. UDAP DCR and Authentication/Authorization have been tested successfully at several HL7 FHIR connectathons and have received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, patient privacy rights advocates, and app developers. These profiles are also compatible with SMART App Launch and UMA.         We recommend that this be listed as a separate interoperability need sub-section of Query or possibly as a new top-level entry in Section III (e.g. Client Application Management), as it potentially overlaps with many of the other existing sub-sections where FHIR is used, including Query, Consumer Access, and Push.         Julie Maas, CEO, EMR Direct