201901 Direct/Certificates Track

Return to January 2019 Proposals

Direct/Certificates

FHIR is a standard that defines a data format and API for health data exchange. X.509 Digital Certificates are widely used for client and server authentication in the internet ecosystem. Direct is an existing federal standard that is widely used in the USA for the exchange of healthcare data, backed by X.509 Certificates for digital signatures and encryption. Within the Direct community, DirectTrust provides scalable security and a trust framework through a single Federated Services Agreement, formal policies, accreditation, and a source of a bundle of trusted CA certificates. Because there is such expenditure involved in planning, setting up and maintaining trusted distribution networks, there is strong incentive to leverage existing networks as much as possible. Therefore, this track will explore two possible models of leveraging existing trust frameworks.

They are:

• Sending FHIR resources within a Direct Message as an attachment
• Utilizing Direct certificates with the FHIR RESTful API to enable trust relationships to scale

Pre-Requisites

For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.

Track Administration

• Coordinator: Luis Maas, EMR Direct - lcmaas at emrdirect dot com
• Coordinator: Calvin Beebe, Mayo Clinic - cbeebe@mayo.edu

Confirmed Participants

Participant	Scenario 1	Scenario 2
EMR Direct	S+/R+	A1(C/S) A2(C/S) B(C/S) C(C/S) D(C/S)
MaxMD	S+/R+	A1(C/S) A2(C)
Janie Appleseed	S+	.

For Scenario 1, list role (S=Sender R=Recipient) and (+) if IG for Context v1.1 compliant
For Scenario 2, list use cases and role (C=Client S=Server) for participation
See table of addresses and servers below for endpoint information

Scenario Overviews

The following scenarios will be the primary focus within the track for this Connectathon:

Scenario 1: Information Exchange using FHIR API via Direct Messaging with message context.
(Note that this scenario, participants will need a Direct implementation that can send / receive Direct messages with context-enabled attachments as per the Implementation Guide for Expressing Context in Direct Messaging.

A. FHIR Query (Use Case 1 A). Patient or provider will query a medical record simply by sending a Direct Message to a Direct Address associated with a FHIR interface.
TODO: whose responsibility is it to authorize the query? how are the identity assertions carried in the message validated and secured?
Case 1: Patient queries for his or her self. System A must assert the patient is who they say they are and make the query on behalf of the patient. Every patient has the right to retrieve their own health data according to the Office of Civil Rights. No further authorization is necessary.
Case 2 (TPO): Provider queries for his or her patient's data. If the provider is from a known domain and the domain has privileges at the hospital then the provider is presumed to have the authorization to access the patient's record. Provider is subject to follow-up auditing should the access be challenged. It is the responsibility of System A to validate the provider. The provider is responsible for his or her own assertions about authorization to retrieve a patient's record. System B maintains a list of trusted Direct domains that have access privileges on the server and allows providers from those domains to query for patients they assert they are authorized to access.

B. Unsolicited Communication (Use Case 1 B). Patient or Provider transmits clinical information as FHIR resources or CDA documents from an edge system to another system with a FHIR API. See Sending FHIR resources in Direct Messages and previous connectathon. Note: Information is stored in appropriate FHIR Resources. For a CDA Document, this could be a Binary Resource and DocumentReference that points to the Binary Resource, or a Composition Resource and a DocumentReference. (Storing of CDA entries is out of scope for this use Case.)

C. Solicited Communication (Use Case 1 C). A two-step use case that involves one system sending a CommunicationRequest to another system and then the request receiver sends the requested information to the receiver identified in the communication request.

Scenario 2: Utilizing X.509 certificates with the FHIR RESTful API to enable trust relationships to scale
A1. (Use Case 2 A1)
A2. (Use Case 2 A2)
B. Client authentication & authorization for backend services (Use Case 2 B)
C. (Use Case 2 C)
D. Dynamic client registration (Use Case 2 D)

Scenario 1

Use Case 1 A. FHIR Query executed using Direct Messaging with Context

Roles

• System A (Client) – the system that performs the query
• System A’s HISP – a HISP supporting messaging context, used by System A
• System B’s HISP – a FHIR enabled HISP (implements FHIR as an edge protocol) used by System B
• System B (Server) – a system that receives a query via FHIR API and produces the query results

Steps

1. System A interacts with HISP A to establish message context and formulate a desired query for data or documents.
2. HISP A sends via DSM the query to the system being queried (System B) via that system’s HISP (HISP B).
3. HISP B receives and brokers the query. It executes RESTful transactions to query against System B via System B’s FHIR API and develops the transaction using the FHIR transaction paradigm.
4. System B receives the in-coming query and returns the information for the query to System B’s HISP.
5. System B’s HISP packages the transaction-response from System B into a DSM with message context.
6. System B returns the transaction-response to System A via System A’s HISP (HISP A).
7. HISP A receives the message.
8. System A receives the message. (Renders and stores the response.)

Examples

• A patient queries her PCP’s EMR to get a copy of her current medication list, or her prior procedure information.
• A patient queries a local hospital’s ED system to get a copy of her documentation from a recent ER visit.
• A provider in the ED queries the person’s health plan for his or her Payer-based health record to learn more about any relevant medical history for the patient.
• A person’s PCP queries the EMR of the person’s OB/GYN to see when her last pap smear was performed.

Use Case 1 B. Unsolicited Communication of a document payload using Direct Messaging with Context

Roles

• System A (Message Sender) – the system that sends a Communication message with a document payload
• System A’s HISP – a HISP supporting messaging context, used by System A
• System B’s HISP – a FHIR enabled HISP (implements FHIR as an edge protocol) used by System B
• System B (Message Receiver) – a system that receives a Communication message with a document payload via FHIR API

Steps

1. System A interacts with HISP A to establish message context and a attach document payload. Documents can be non-C-CDA documents, C-CDA documents with structured-body or non-xml body. (note: scope is limited to Level-2 CDA documents for case of structured-body).
2. HISP A sends the message (with context info) to the message recipient (System B) via that system’s HISP (HISP B) using DSM. The message may have multiple recipients (more than just System B).
3. HISP B receives the message, transforms it to use the FHIR Messaging paradigm, and posts it to System B via System B’s FHIR API.
4. System B receives and processes the in-coming documents. (Processing by System B is out of scope.)

Examples

• A provider sends a Referral Note, Discharge Summary, or Progress Note to another Provider. The document may be a structured C-CDA, an unstructured C-CDA, or a PDF document. The document may be signed or unsigned.
• Provider sends information to a Payor that the Provider knows is required to authorize a treatment.
• A provider sends a Discharge Summary to a patient’s PCP. (note: the sending HISP or the receiving HISP may have permission/instructions to simultaneously “cc” other message recipients whenever a message is sent/received regarding that patient. For example, the HISP may be instructed to send a copy of the message to the patient’s daughter, a nurse at the Assisted Living Center where the patient resides, the patient’s care manager at the patient’s health plan, or a public health department focused on serving a population encompassing the patient. The HISP sends the message in the format preferred by the recipient. For example, a nurse at the assisted living center prefers to receive all documents as pdfs. The patient’s daughter uses a PHR to manage health information for all members of her family. She prefers to receive C-CDA documents.)
• A patient downloads her CCD from a Patient Portal, notices some needed updates/corrections, annotates the CCD (saving it with appropriate data provenance), then sends the annotated CCD to the original source. One of the updates includes information about where to find her advance directives.

Use Case 1 C. Solicited Communication of a document payload using Direct Messaging with Context

Roles

• System B (Communication Request Sender) - the system that sends a Communication Request message
• System A (Communication Request Receiver) - the system that receives a Communication Request message
• System A (Message Sender) – the system that sends a Communication message with a document payload which references a previously received Communication Request
• System A’s HISP – a HISP supporting messaging context, used by System A
• System B’s HISP – a FHIR enabled HISP (implements FHIR as an edge protocol) used by System B
• System B (Message Receiver) – a system that receives a Communication message with a document payload via FHIR API

Steps

1. System B interacts with HISP B using the FHIR messaging paradigm to post a message with a communication request asking the receiver to return a certain type of document. HISP B transforms the information and establishes the message context and includes the communication resource as the message payload. (The LOINC document ontology is used to describe the type of document requested). The message includes a bundle where the first resource is a communication request is for a specific subject and may include instructions. The communication request may include a document or set of documents in its payload.
2. HISP B receives the message from System B via a FHIR API. HISP B formulates the DSM message with the message context and includes the communicationRequest and the communicationRequest payload as the payload of the DSM. HISP B the sends the message recipient (System A) via their HISP (HISP A) using DSM.
3. HISP A receives the message and makes it available to System A.
4. System A processes the communication request. (Renders it, stores it, etc.) NOTE: System A may not have the requested information at the time the request comes in. The request may be for information that will be produced in the future. If and when System A sends the requested information, the original CommunicationRequest is used to track and identify the materials by the receiving system. The prior CommunicationRequest set the stage for the “closed loop” communication.
5. System A attaches the requested information to a Communication message, directing it to the intended recipient and includes the CommunicationRequest as an attachment.
6. HISP A formulates the message context, replacing the original CommunicationRequest with the Communication “response”, and sends the message to (in this example) HISP B using DSM.
7. HISP B receives the message, transforms it to use the FHIR Messaging paradigm, and posts it to System B via System B’s FHIR API.
8. System B receives and processes the in-coming documents. (Processing by System B is out of scope.) System B uses the include the request identifier to identify and process the received materials accordingly.

Examples

• A Payor sends a request for certain types of document to be sent following a planned encounter for a patient. The Provider receiving the request, when the documentation is eventually createdincludes the identifier in the CommunicationRequest, making it easier for the Payor to route and record the provided information.
• A Provider sends a CommunicationRequest to a patient, including some documents the Provider would like the Patient to fill out and return prior to an upcoming appointment. The Patient eventually completes the documents and returns them, referencing the identifier of the original communication request to make it easier for the Provider to process the returned information.
• A Physical Therapist sends a Physical Therapy Plan of Care document to a patient’s PCP requesting for the plan to be reviewed, signed, and returned.
• A computer-based decision-support system requests an event notification or reminder alert to be delivered to a responsible provider when a triggering event occurs.
• A physician requests a notification from the home health nurse if a patient's temperature exceeds a certain value
• A monitoring system or a provider requests a staff member or care organization to notify a public health agency when a patient presents with a reportable communicable disease.
• Triggered by a patient receiving a new diagnosis, a computer-based decision-support system requests educational material to be sent to the patient.

Background

• A FHIR Query behaves as a synchronous transaction while a Solicited Communication is asynchronous. The timing for the communication that is performed in response to a communication request is dependent on business rules, not technology processing speed. The response could be supplied within 24 hours or within 3 business days. It is not an "immediate" response. Also, a communication request supports "asking" for information that may become available in the future. It also supports requesting information to be sent to another party, different from the one issuing the communication request. A FHIR Query only queries for and returns information that is available at the time of the query. The query response is always returned to the entity executing the query.
• A CommunicationRequest is a record of a request for a communication to be performed. A communication is a conveyance of information from one entity (sender) to another entity or entities (receiver(s)). The sender and receivers may be patients, practitioners, related persons, organizations, and devices. Uses of communication request include:

Reference Documentation

Message Context for Direct Messaging: Implementation Guide for Expressing Context in Direct Messaging

Sending FHIR Resources in Direct Messages: Sending FHIR resources in Direct Messages.

Overview of Scenario 2

The following use cases will be backed by a trusted certificate ecosystem:

A. Mutual TLS client-server authentication/authorization
B. Authentication and Authorization JWTs for backend services
C. Authentication JWTs for authorization code grant
D. Dynamic client registration

Preconditions:

• The DirectTrust Interoperability Testing Bundle will be used as the trust bundle to establish trust for the connectathon.
• Each client will obtain or generate suitable device certificates chaining to a certificate in this bundle. EMR Direct can provide test certificates to interested parties who do not operate their own CA.

Scenario 2 - Use Case A1 - Mutual TLS with FHIR Server (Full Read Access)

1. FHIR client presents a client certificate to Resource Server during SSL handshake in place of a conventional OAuth Bearer Access Token.
2. RS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the FHIR request is denied.
4. If certificate is valid and trusted, RS allows read access to resources.

Note: For purposes of this use case, successfully authenticated clients are authorized for full read access.

Comments: This authentication method is useful in applications where mutual TLS authentication is already well understood and organization- or individual-level credentials are availalbe for use in lieu of building in an OAuth flow where it didn't already exist. The most likely application of this use case would be automated backend services. Examples include both highly-privileged applications within an organization and cross-organizational queries. For this use case, Authorization and authentication are based on attributes such as identity and permitted uses (if expressed in the certificate) and trustworthiness of the Certification Authority. This workflow corresponds to the alternative workflow described in Section 8.1 of UDAP Mutual TLS Client Authentication (Draft 2018-08-14).

Scenario 2 - Use Case A2 – Mutual TLS with OAuth Server

1. FHIR client presents a client certificate to Authentication Server token endpoint during SSL handshake in place of a client secret for client_credentials grant workflow.
2. AS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the request is denied.
4. If certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token to client.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: The benefits of this use case (as compared to A1) are that no changes to the RS are necessary to support mutual TLS as "standard" bearer tokens are used to access the RS. The modifications are limited to the AS to allow it to recognize and accept credentials from a trusted party. This workflow corresponds to the standard workflow described in UDAP Mutual TLS Client Authentication (Draft 2018-08-14).

Scenario 2 - Use Case B – Backend client authentication & authorization backed by trusted certificates

Authorization can be based on pre-existing relationships or as directed by a patient.

1. FHIR client presents signed JWT to AS token endpoint for client_credentials grant workflow, using the client_assertion and client_assertion_type parameters as per UDAP OAuth profile.
2. The AS validates the signature on the JWT, and validates the certificate backing the signature using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If signature is invalid, or certificate is invalid or untrusted, the request is denied.
4. If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: This use case lends itself well to a situation in which, as in A, there is no end user (e.g. automated backend services) or the end user does not have an account on the local system. The client_credential flow is used, but rather than authenticating the client app with a client secret, a JWT signed with the client app's private key is used instead. This allows for a network of trusted clients that can be recognized by an AS through minor enhancements to the AS and a standard set of requirements to participate in the network, helping to scale app deployment. This workflow corresponds to the client credentials workflow described in UDAP JWT-Based Client Authentication (Draft 2018-08-14).

Scenario 2 - Use Case C – Client authentication for authorization code grant backed by trusted certificates

1. FHIR client presents a valid authorization code and a signed JWT to AS token endpoint for authorization_code grant workflow, using the client_assertion and client_assertion_type parameters as per UDAP OAuth profile.
2. The AS validates the signature on the JWT, and validates the certificate backing the signature using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If signature is invalid, or certificate is invalid or untrusted, the request is denied.
4. If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: This use case is included in order to demonstrate how certificate-based authentication and authorization code flow can be layered to achieve higher levels of security. This can be added-on to "standard" or SMART on FHIR authorization code flow where there is end user interaction, except that when the client app exchanges the authorization code for an access token, the client app authentication is performed as in B using a JWT signed with the app's private key instead of a client secret. The corresponding public key is validated by the AS to confirm that it is part of a trusted network of applications (at a minimum). This workflow corresponds to the authorization code workflow described in UDAP JWT-Based Client Authentication (Draft 2018-08-14).

All of the above use cases eliminate the need for pairwise key exchange, and enhance security through the use of digital certificates rather than shared secrets by relying on trusted CAs and certificate validation instead.

Scenario 2 - Use Case D – Dynamic client registration backed by trusted certificates

One of the goals of this scenario will be to discuss candidate app registration profiles.

1. FHIR client includes signed software statement as part of registration request to AS registration endpoint.
2. The AS validates the signing certificate and determines whether it chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the request is denied.
4. If certificate is valid and trusted, the AS processes the registration and issues a client_id.
5. Client uses this client_id for subsequent interactions with AS.

Comments: This workflow corresponds to the workflow described in UDAP Dynamic Client Registration (Draft 2018-07-14).

Endpoints Available During Connectathon

Scenario	Use Case	Direct Address	FHIR Server linked to this address (do not call the FHIR server directly for Scenario 1)	_________________Notes_______________
1	A	fhir@test.directproject.net	EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)	Direct endpoint accepts encapsulated FHIR requests formatted per Implementation Guide for Expressing Context in Direct Messaging; responds back to sender with encapsulated FHIR server response
1		maxmd@fhir.eval.md	MaxMD Endpoint (https://sandbox.directmdemail.com/fhir/baseDstu3 )	This server is extended from HAPI-FHIR, a 100% open-source Java implementation of the FHIR specification. This is not a production server! Do not store any information here that contains personal health information or any other confidential information. This server will be regularly purged and reloaded with fixed test data.
1		telstra@fhir.eval.md	Teltra Endpoint (http://sqlonfhir-stu3.azurewebsites.net/fhir)	No Notes
1		healthintersections@fhir.eval.md	healthintersections Endpoint (http://fhir3.healthintersections.com.au/open)	No Notes
1		hapi@fhir.eval.md	HAPI Endpoint (http://fhirtest.uhn.ca/baseDstu3)	No Notes

Scenario	Use Case	FHIR Server Base URL	_________________Notes_______________
2	A1	EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)	FHIR client authenticates to FHIR server using trusted client authentication certificate (mutual TLS)
2	A2	EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)	FHIR client authenticates to OAuth token endpoint using trusted client authentication certificate (mutual TLS)
2	B,C	EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)	FHIR client authenticates to OAuth token endpoint using JWT, signature is backed by trusted client signing certificate

Help Links

Here are some links to assist implementers:

Results

FHIR Connectathon 20 will be held on January 12 - 13, 2019 in San Antonio, TX. A link to download the report will be available after the conclusion of the Connectathon.

Governance Questions

This section will identify any governance issues or questions that arise from the Direct/Certificates Track

References

Direct, DirectTrust, and FHIR: A Value Proposition

Unified Data Access Profiles (UDAP)