This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Direct Track"

From HL7Wiki
Jump to navigation Jump to search
 
(50 intermediate revisions by 5 users not shown)
Line 3: Line 3:
  
 
=Direct=
 
=Direct=
−
FHIR is a [https://www.hl7.org/fhir/summary.html new standard] that defines a healthcare standards, web API and other related specifications for health data exchange. Direct is an existing federal standard that is widely used in the USA for the exchange of healthcare data. Within the Direct community, Direct Trust provides scalable security and a trust framework through a single Federated Services Agreement, formal policies, accreditation, and a PKI-based trust authority. 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 DirectTrust’s trust framework.
+
FHIR is a [https://www.hl7.org/fhir/summary.html new standard] that defines a healthcare standards, web API and other related specifications for health data exchange. Direct is an existing federal [https://www.healthit.gov/policy-researchers-implementers/direct-project#standard standard] that is widely used in the USA for the exchange of healthcare data. Within the Direct community, Direct Trust provides scalable security and a trust framework through a single Federated Services Agreement, formal policies, accreditation, and a PKI-based trust authority. 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 DirectTrust’s trust framework.
  
 
They are:
 
They are:
−
*Sending FHIR resources within a Direct Message as an attachment
+
*[http://wiki.hl7.org/index.php?title=Sending_FHIR_resources_in_Direct_Messages Sending FHIR resources within a Direct Message as an attachment]
 
*Utilizing DirectTrust certificates with the FHIR RESTful API to enable trust relationships to scale
 
*Utilizing DirectTrust certificates with the FHIR RESTful API to enable trust relationships to scale
  
Line 18: Line 18:
 
*Coordinator: Calvin Beebe, Mayo Clinic - cbeebe@mayo.edu
 
*Coordinator: Calvin Beebe, Mayo Clinic - cbeebe@mayo.edu
 
*Management & Communications: Dr. David Kibbe - DirectTrust President and CEO - david.kibbe@directtrust.org
 
*Management & Communications: Dr. David Kibbe - DirectTrust President and CEO - david.kibbe@directtrust.org
 +
*[https://drive.google.com/open?id=1v3wLd_l2DkcjGKf1ZPq_IKNKfoIyi1xt Direct Track Orientation Slides]
  
 
==Expected participants==
 
==Expected participants==
Line 25: Line 26:
 
*Don Jorgenson -  Inpriva
 
*Don Jorgenson -  Inpriva
 
*Jim Fisher — MedAllies
 
*Jim Fisher — MedAllies
−
*Michael Mall — iShare
+
*Lisa Nelson - Life Over Time Solutions
  
 
==Scenarios==
 
==Scenarios==
Line 33: Line 34:
 
## Suggested workflow #2: standardized message structure to trigger a FHIR query at receiving end and return result
 
## Suggested workflow #2: standardized message structure to trigger a FHIR query at receiving end and return result
 
## Suggested workflow #3: encapsulated FHIR queries using Context IG
 
## Suggested workflow #3: encapsulated FHIR queries using Context IG
−
## Tasks will be documented after approval of use case
+
## Tasks will be documented after approval of use case - [Lisa/Bruce to detail]
 
#Utilizing Direct Trust certificates with the FHIR RESTful API to enable trust relationships to scale
 
#Utilizing Direct Trust certificates with the FHIR RESTful API to enable trust relationships to scale
 
## Tasks will be documented after approval of use case
 
## Tasks will be documented after approval of use case
  
−
==Use Cases for Scenario 1 ==
+
==Overview of Scenario 1 ==
−
#A simple use case that includes pouring clinical information into a workflow using FHIR as a resource. Specifically, state – FHIR Resources (give the names), problem list, medication list, allergies – and transport these as attachments.  Grahame has already demonstrated this use case - [[Sending FHIR resources in Direct Messages]].
+
#A simple use case that includes transmitting clinical information via a workflow using FHIR resources. Specifically, state – FHIR Resources (give the names), problem list, medication list, allergies – and transport these as attachments.  Grahame has already demonstrated this use case - [[Sending FHIR resources in Direct Messages]].
 
# By law every patient has a right to receive their medical record. To support this, Stage 3 of the CMS Meaningful Use program is further expanding how a patient can gain electronic access to their health information. In addition to view/download/transmit through patient portals, the measure can be fulfilled by patients retrieving their record within 24 hours of its availability via ONC-certified API in a third party application.
 
# By law every patient has a right to receive their medical record. To support this, Stage 3 of the CMS Meaningful Use program is further expanding how a patient can gain electronic access to their health information. In addition to view/download/transmit through patient portals, the measure can be fulfilled by patients retrieving their record within 24 hours of its availability via ONC-certified API in a third party application.
 
##A patient will query their medical record simply by sending a Direct Message to a Direct Address associated with a FHIR interface. Therefore any hospital or provider organization utilizing a FHIR enabled EHR can meet the MU3 requirement by implementing this solution and providing Direct Addresses to their patients. Consolidation of login credentials from multiple patient portals to a singular Direct Address with a familiar mail interface could help overcome adoption challenges.
 
##A patient will query their medical record simply by sending a Direct Message to a Direct Address associated with a FHIR interface. Therefore any hospital or provider organization utilizing a FHIR enabled EHR can meet the MU3 requirement by implementing this solution and providing Direct Addresses to their patients. Consolidation of login credentials from multiple patient portals to a singular Direct Address with a familiar mail interface could help overcome adoption challenges.
Line 44: Line 45:
 
##Applications for this patient and consumer Direct Messaging extend use cases beyond the new Stage 3 measure. Patient Direct Addresses also open up a secure and scalable channel for chronic disease management, medication reminders, and most importantly it empowers patients to manage their health electronically.
 
##Applications for this patient and consumer Direct Messaging extend use cases beyond the new Stage 3 measure. Patient Direct Addresses also open up a secure and scalable channel for chronic disease management, medication reminders, and most importantly it empowers patients to manage their health electronically.
  
 +
===Scenario 1 - Use Case #1===
 +
 +
'''narrative of real world problem''' - e.g. Physician wanting to transmit lab results about patient to referring physician.
 +
 +
===Roles===
 +
Source FHIR Server
 +
 +
Source EMR
 +
 +
Target FHIR Server
 +
 +
Target EMR
 +
 +
===Steps for Direct Transfer===
 +
 +
[[Sending FHIR resources in Direct Messages]].
 +
 +
===Scenario 1 - Use Case #2 ===
 +
 +
Patient wants to collect her/his health information. The patient queries the provider organization to collect available clinical information. Patient’s identity is determined from the LOA3 verified identity of their DirectTrust address. Requested types of clinical information are selected by the patient as the request is initiated. Information supplied by the provider organization is returned as FHIR Resources.
 +
 +
===Roles===
 +
[[File:Role Overview.JPG]]
 +
====Pt. FHIR Webmail Client====
 +
A system playing this role will create an SMTP message from a patient's Direct Address with two attachments:
 +
*a Patient Identification Record text file containing verified patient identifying information associated with this Direct Address formatted according to the Implementation Guide for Expressing Context in Direct Messaging
 +
*a FHIR Query
 +
It also will recieve a SMTP message containing JSON FHIR resources returned from the FHIR API/Edge System. It may support a stylesheet (based on the file type) for rendering the results in a human-readable format.
 +
 +
====Sender's HISP====
 +
A system playing this role acts as the outgoing Direct Secure Message (DSM) relay.
 +
It decripts the response messages and delivers it to the Pt. FHIR Webmail Client.
 +
 +
====FHIR Enabled Receiving HISP====
 +
A system playing this role recieves DSMs. When the edge system is a FHIR API system, it executes mailette functions necessary to query the edge system. This is a multi-step process:</br>
 +
<ol>
 +
<li>the local patient ID (PID) is retrieved.</li>
 +
<li>the PID is inserted into the JSON query and then the query is posted to the edge system API and the response from the edge system is received.</li>
 +
<li>the JSON formatted response from the FHIR API/Edge system is attached to a Direct Secure Message and sent to the Pt. Direct Address.</li>
 +
</ol>
 +
 +
====FHIR API/Edge System====
 +
A system playing this role will provide an authentication mechanism to the FHIR Enabled Receiving HISP.  It also will assume the requesting patient (as identified in the Patient Identification Record) is authorized to receive her/his medical information.  This system has a single Direct Address. It responds to JSON queries.
 +
 +
===Testing Requirements===
 +
*The test patient needs to have an associated Direct Address.
 +
*The FHIR API/Edge System needs to have clinical information loaded in the queried resources for the patient performing the query
 +
 +
===Relevant Specs, Documentation and Test Servers===
 +
 +
*Sending FHIR resources in Direct Messages: [[Sending FHIR resources in Direct Messages]].
 +
*Publicly Available FHIR Servers for testing: [[Publicly_Available_FHIR_Servers_for_testing]]
 +
*Open source FHIR Implmentations: [[Open_Source_FHIR_implementations]]
 +
*Implementation Guide for Expressing Context in Direct Messaging: [http://wiki.directproject.org/file/view/Implementation+Guide+for+Expressing+Context+in+Direct+Messaging+v1.0-DRAFT-2016122901.docx/602899718/Implementation%20Guide%20for%20Expressing%20Context%20in%20Direct%20Messaging%20v1.0-DRAFT-2016122901.docx Implementation Guide]
 +
 +
'''Other references'''
 
Links from previous event: [http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange Consumer Centered Data Exchange]
 
Links from previous event: [http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange Consumer Centered Data Exchange]
  
−
[http://wiki.hl7.org/index.php?title=Sending_FHIR_resources_in_Direct_Messages FHIR Resources in Direct Messages]
+
Work on Advanced Directives: [http://wiki.hl7.org/index.php?title=201701_C-CDA_on_FHIR C-CDA on FHIR]
  
−
Work on Advanced Directives: [http://wiki.hl7.org/index.php?title=201701_C-CDA_on_FHIR C-CDA on FHIR]
+
==Overview of Scenario 2==
 +
The following use cases will be backed by a trusted certificate ecosystem:
 +
<br />
 +
<br /><B>A. Mutual TLS client-server authentication/authorization</B>
 +
<br /><B>B. Authentication and Authorization JWTs backed by trusted certificate ecosystem</B>
 +
===Preconditions:===
 +
*The DirectTrust Interoperability Testing Bundle will be used as the trust bundle to establish trust for the connect-a-thon.
 +
*Each client will obtain or generate suitable certificates chaining to a certificate in this bundle. EMR Direct can provide test certificates to interested parties who do not operate their own CA.
 +
*For Use Cases #A2 and #B1, the AS will grant tokens with full read access to demographic, immunization, and allergy data.
 +
*For Use Cases #A2 and #B1, how the client is registered with the AS is currently out of scope (e.g. dynamic or manual registration)
 +
 
 +
===Scenario 2 - Use Case #3 <span style="font-size:77%">(A1)</span> &nbsp;&nbsp;Mutual TLS with FHIR Server (Full Read Access)===
 +
#FHIR client presents a client certificate to Resource Server during SSL handshake in place of a conventional OAuth Bearer Access Token.
 +
#RS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
 +
#If certificate is invalid or untrusted, the FHIR request is denied.
 +
#If certificate is valid and trusted, RS allows read access to resources.
 +
Note: For purposes of this use case, successfully authenticated client are authorized for full read access.
 +
 
 +
===Scenario 2 - Use Case #4 <span style="font-size:77%">(A2)</span> &nbsp;&nbsp;– Mutual TLS with OAuth Server===
 +
#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.
 +
#AS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
 +
#If certificate is invalid or untrusted, the request is denied.
 +
#If certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token to client.
 +
#Client presents access token to RS when making FHIR requests in the usual manner.
 +
 
 +
===Scenario 2 - Use Case #5 <span style="font-size:77%">(B1)</span> &nbsp;&nbsp; – Client authentication backed by trusted certificates===
 +
 
 +
#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.
 +
#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.
 +
#If signature is invalid, or certificate is invalid or untrusted, the request is denied.
 +
#If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
 +
#Client presents access token to RS when making FHIR requests in the usual manner.
 +
 
 +
[[File: Flowchart.png | 650px]]
 +
 
 +
===Types of Direct Certificates===
 +
 
 +
==Direct Connection Data for Use Cases==
  
−
==Use Cases for Scenario 2 ==
+
{| class="wikitable"
−
# DirectTrust’s Security Trust Framework and Certificates are used in the first step of identity verifications to the FHIR authorization servers (sign the JSON Web Token).
+
! style="text-align: center;" | Use Case
−
# Dynamic registration backed by trusted certificate ecosystem
+
! style="text-align: center;" | Direct Address
−
# Mutual TLS client-server authentication
+
! style="text-align: center;" | FHIR Server Used
 +
! colspan="2" style="text-align: center;" |_________________Notes_______________
 +
|-
 +
| #1 or #2
 +
| fhir@test.directproject.net
 +
| EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)
 +
| colspan="2" | 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
 +
|-
 +
| #2 (scenario 1)
 +
| maxmd@fhir.eval.md 
 +
| MaxMD Endpoint (https://sandbox.directmdemail.com/fhir/baseDstu3 )
 +
| colspan="2" | 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.
 +
|-
 +
| #2 (scenario 1)
 +
| telstra@fhir.eval.md 
 +
| Teltra Endpoint (http://sqlonfhir-stu3.azurewebsites.net/fhir)
 +
| colspan="2" | No Notes
 +
|-
 +
| #2 (scenario 1)
 +
| healthintersections@fhir.eval.md 
 +
| healthintersections Endpoint  (http://fhir3.healthintersections.com.au/open)
 +
| colspan="2" | No Notes
 +
|-
 +
| #2 (scenario 1)
 +
| hapi@fhir.eval.md 
 +
| HAPI Endpoint (http://fhirtest.uhn.ca/baseDstu3)
 +
| colspan="2" | No Notes
 +
|-
 +
| #2 (scenario 1)
 +
| jim@alpha.dirnet.net
 +
|
 +
| colspan="2" | HISP to which Direct Messages can be sent which contain a FHIR query. The HISP will call at least one FHIR server, make the FHIR request, and return the FHIR response in a Direct Message
 +
|-
 +
| #3
 +
| Not applicable
 +
| EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)
 +
| colspan="2" | FHIR client authenticates to FHIR server using trusted client authentication certificate (mutual TLS)
 +
|-
 +
| #4
 +
| Not applicable
 +
| EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)
 +
| colspan="2" | FHIR client authenticates to OAuth token endpoint using trusted client authentication certificate (mutual TLS)
 +
|-
 +
| #5
 +
| Not applicable
 +
| EMR Direct Stage Server (https://stage.healthtogo.me:8181/fhir-server-stu3/emrdirect-test-ehr)
 +
| colspan="2" | FHIR client authenticates to OAuth token endpoint using JWT, signature is backed by trusted client signing certificate
 +
|}
  
 
==Help Links==
 
==Help Links==
Line 59: Line 200:
  
 
==TestScript(s)==
 
==TestScript(s)==
−
TBD
+
N/A
  
 
==Results==
 
==Results==

Latest revision as of 03:26, 9 February 2018

Return to Jan 2018 Proposals

Direct

FHIR is a new standard that defines a healthcare standards, web API and other related specifications for health data exchange. Direct is an existing federal standard that is widely used in the USA for the exchange of healthcare data. Within the Direct community, Direct Trust provides scalable security and a trust framework through a single Federated Services Agreement, formal policies, accreditation, and a PKI-based trust authority. 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 DirectTrust’s trust framework.

They are:

Pre-Requisites

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

In addition for track 1, participants will need a Direct implementation that can send / receive direct messages with attachments.

Track Administration

  • Coordinator: Luis Maas, EMR Direct - lcmaas at emrdirect dot com
  • Coordinator: Calvin Beebe, Mayo Clinic - cbeebe@mayo.edu
  • Management & Communications: Dr. David Kibbe - DirectTrust President and CEO - david.kibbe@directtrust.org
  • Direct Track Orientation Slides

Expected participants

  • Luis Maas – EMR Direct
  • Bruce Schreiber – MaxMD
  • Don Jorgenson - Inpriva
  • Jim Fisher — MedAllies
  • Lisa Nelson - Life Over Time Solutions

Scenarios

The following scenarios will be exercised within the track:

  1. Sending FHIR resources within a Direct Message as an attachment
    1. Suggested workflow #1: FHIR bundles as content to be loaded by receiving FHIR server (as per FHIR Connectathon 16)
    2. Suggested workflow #2: standardized message structure to trigger a FHIR query at receiving end and return result
    3. Suggested workflow #3: encapsulated FHIR queries using Context IG
    4. Tasks will be documented after approval of use case - [Lisa/Bruce to detail]
  2. Utilizing Direct Trust certificates with the FHIR RESTful API to enable trust relationships to scale
    1. Tasks will be documented after approval of use case

Overview of Scenario 1

  1. A simple use case that includes transmitting clinical information via a workflow using FHIR resources. Specifically, state – FHIR Resources (give the names), problem list, medication list, allergies – and transport these as attachments. Grahame has already demonstrated this use case - Sending FHIR resources in Direct Messages.
  2. By law every patient has a right to receive their medical record. To support this, Stage 3 of the CMS Meaningful Use program is further expanding how a patient can gain electronic access to their health information. In addition to view/download/transmit through patient portals, the measure can be fulfilled by patients retrieving their record within 24 hours of its availability via ONC-certified API in a third party application.
    1. A patient will query their medical record simply by sending a Direct Message to a Direct Address associated with a FHIR interface. Therefore any hospital or provider organization utilizing a FHIR enabled EHR can meet the MU3 requirement by implementing this solution and providing Direct Addresses to their patients. Consolidation of login credentials from multiple patient portals to a singular Direct Address with a familiar mail interface could help overcome adoption challenges.
    2. TODO: whose responsibility is it to authorize the query? how are the identity assertions carried in the message validated and secured?
    3. Applications for this patient and consumer Direct Messaging extend use cases beyond the new Stage 3 measure. Patient Direct Addresses also open up a secure and scalable channel for chronic disease management, medication reminders, and most importantly it empowers patients to manage their health electronically.

Scenario 1 - Use Case #1

narrative of real world problem - e.g. Physician wanting to transmit lab results about patient to referring physician.

Roles

Source FHIR Server

Source EMR

Target FHIR Server

Target EMR

Steps for Direct Transfer

Sending FHIR resources in Direct Messages.

Scenario 1 - Use Case #2

Patient wants to collect her/his health information. The patient queries the provider organization to collect available clinical information. Patient’s identity is determined from the LOA3 verified identity of their DirectTrust address. Requested types of clinical information are selected by the patient as the request is initiated. Information supplied by the provider organization is returned as FHIR Resources.

Roles

Role Overview.JPG

Pt. FHIR Webmail Client

A system playing this role will create an SMTP message from a patient's Direct Address with two attachments:

  • a Patient Identification Record text file containing verified patient identifying information associated with this Direct Address formatted according to the Implementation Guide for Expressing Context in Direct Messaging
  • a FHIR Query

It also will recieve a SMTP message containing JSON FHIR resources returned from the FHIR API/Edge System. It may support a stylesheet (based on the file type) for rendering the results in a human-readable format.

Sender's HISP

A system playing this role acts as the outgoing Direct Secure Message (DSM) relay. It decripts the response messages and delivers it to the Pt. FHIR Webmail Client.

FHIR Enabled Receiving HISP

A system playing this role recieves DSMs. When the edge system is a FHIR API system, it executes mailette functions necessary to query the edge system. This is a multi-step process:

  1. the local patient ID (PID) is retrieved.
  2. the PID is inserted into the JSON query and then the query is posted to the edge system API and the response from the edge system is received.
  3. the JSON formatted response from the FHIR API/Edge system is attached to a Direct Secure Message and sent to the Pt. Direct Address.

FHIR API/Edge System

A system playing this role will provide an authentication mechanism to the FHIR Enabled Receiving HISP. It also will assume the requesting patient (as identified in the Patient Identification Record) is authorized to receive her/his medical information. This system has a single Direct Address. It responds to JSON queries.

Testing Requirements

  • The test patient needs to have an associated Direct Address.
  • The FHIR API/Edge System needs to have clinical information loaded in the queried resources for the patient performing the query

Relevant Specs, Documentation and Test Servers

Other references Links from previous event: Consumer Centered Data Exchange

Work on Advanced Directives: C-CDA on FHIR

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 backed by trusted certificate ecosystem

Preconditions:

  • The DirectTrust Interoperability Testing Bundle will be used as the trust bundle to establish trust for the connect-a-thon.
  • Each client will obtain or generate suitable certificates chaining to a certificate in this bundle. EMR Direct can provide test certificates to interested parties who do not operate their own CA.
  • For Use Cases #A2 and #B1, the AS will grant tokens with full read access to demographic, immunization, and allergy data.
  • For Use Cases #A2 and #B1, how the client is registered with the AS is currently out of scope (e.g. dynamic or manual registration)

Scenario 2 - Use Case #3 (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 client are authorized for full read access.

Scenario 2 - Use Case #4 (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.

Scenario 2 - Use Case #5 (B1)    – Client authentication backed by trusted certificates

  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.

Flowchart.png

Types of Direct Certificates

Direct Connection Data for Use Cases

Use Case Direct Address FHIR Server Used _________________Notes_______________
#1 or #2 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
#2 (scenario 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.
#2 (scenario 1) telstra@fhir.eval.md Teltra Endpoint (http://sqlonfhir-stu3.azurewebsites.net/fhir) No Notes
#2 (scenario 1) healthintersections@fhir.eval.md healthintersections Endpoint (http://fhir3.healthintersections.com.au/open) No Notes
#2 (scenario 1) hapi@fhir.eval.md HAPI Endpoint (http://fhirtest.uhn.ca/baseDstu3) No Notes
#2 (scenario 1) jim@alpha.dirnet.net HISP to which Direct Messages can be sent which contain a FHIR query. The HISP will call at least one FHIR server, make the FHIR request, and return the FHIR response in a Direct Message
#3 Not applicable 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)
#4 Not applicable 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)
#5 Not applicable 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:

TestScript(s)

N/A

Results

FHIR Connectathon 17 will be held on January 27-28, 2018 in New Orleans. 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 Track

References

Direct, DirectTrust, and FHIR: A Value Proposition

Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_Direct_Track&oldid=153249"