Making the FHIR API accessible to Third Party Applications

EMR Direct offers the following options for data holders to enable third party access to APIs they enable using the phiQuery component of Interoperability Engine™:

1. Client app registers dynamically (through OAuth Dynamic Client Registration, in which registration attributes are not verified) and the client application is used much like a browser to access patient data through the patient's data holder-provided username and password (e.g. patient portal credentials). EMR Direct validates that the client_id exists and the correct secret is provided before passing the request through to the data holder. This workflow is supported by phiQuery by default, and is the "typical" OAuth flow for patient access.

Data holders utilizing this workflow establish usernames and passwords for access to patient data as appropriate within their enterprise. phiQuery's authenticateAPIUser method is used along with the usual OAuth sign in page for the user to type in a username and password.

In general, the FHIR RESTful API is optimized for ONC certification requirements where the typical use case is a user-facing application in which the user signs in to access data for a single patient at a time. This is especially true when the phiQuery CCDA-to-FHIR parser configuration is used. EMR Direct also offers its HealthToGo client app for use in production; contact support@emrdirect.com for current pricing information or to activate HealthToGo for your datasources.

2. A human representative of the client registers on the EMR Direct website through a form page and obtains client_id and secret much like in the step above but not requiring that the client app supports OAuth Dynamic Client Registration. This only affects the client registration workflow; the OAuth sign in requirements for the client app to use the API once it has obtained a client_id are still the same.

3. A human representative of the client registers on the EMR Direct website and obtains a UDAP digital certificate, if they are able to secure it (e.g. the app can protect a private cryptographic key). Obtaining a production certificate requires identity verification of the human person or organization taking responsibility for the certificate and the associated private key. The certificate is used by the client app to make a token request using UDAP JWT-based (JSON Web Token) authentication. EMR Direct's token service validates the certificate and token request on the server side and, if trust is validated, passes the client_id to the data holder through phiQuery so the data holder can use that information in making its authorization decision. client_ids so verified may be listed on the App Studio website. Client apps authenticating with certificates can be authorized to use the client credentials OAuth workflow (which does not require a user sign in). In that case, basic authorization of the client is enabled via the phiQuery SDK using the authorizeAPIClientApp method.

Data holders utilizing this workflow establish appropriate access by each such client_id to patient data within their enterprise. Then, when a request from that client_id appears through phiQuery's authorizeAPIClientApp method, the data holder can authorize the client app's access to data accordingly; the phiQuery documentation also requires that data holders invoke a specific command through the phiQuery listener to activate client credentials grant since it is not active by default.

Additional documentation on UDAP JWT-based Authentication can be found here:

https://www.udap.org/udap-jwt-client-auth.html

Did this article answer your question? If not, please contact us.