/> FHIR Technical Workgroup - Carequality

Technical Workgroup

The Technical Workgroup addresses the technical and operational elements needed to enable a single on-ramp for FHIR-based exchange. These elements include patient identification and matching, technical security and authentication, and directory services. Wherever possible, the group will refer to existing work for FHIR resource specifications, themselves, and will not address development of the FHIR standard, itself, except to the extent that it may provide feedback to the HL7 standards process.


Member NameOrganization
Aditya Bansod Luma Health
Alan SwensonKno2
Andrei AzudinHealth Gorilla
Aris KouvarosMount Sinai Health System
Brett MarquardWave One Associates
Caroline BrozakChildren’s National Health Systems
Danielle FriendEpic
Didi DavisThe Sequoia Project
Douglas DeShazoCognizant
Ed VanBaakAinq
Ganesh PersadMemorial Healthcare Systems
Gurbinder SinghSymcore Solutions
Hans Buitendijk ** Co-ChairCerner
Henry MeyneAvaility
Jack PowrieEngage
Jason Storerathenahealth
Jeff TaylorSurescripts
John NovackNew Jersey Innovation Institute
Kalyani YerraPremier Inc
Kedar GantaGE
Kevin MaloyMedstar
Madhav DarjieCW
Marty PrahlSSA
Matt WilkinsonNetsmart
Michael MarchantUC Davis Health System
Micky Tripathi ** Co-ChairMA eHealth Collaborative
Rashid KhanConsultant
Santosh JamiSAFE Health
Savannah DearingMEDENT
Tony MalliaEdmond Scientific Co (ESC)
Tushar MalhotraeCW


February 5, 2019

We largely talked about whether to deploy a Carequality Centralized Authentication Server or have a Distributed Architecture that is run by respective Implementers.


At a high level, Centralized security solutions make system management simpler and enable agile responses to needs/desires to evolve, while having a single point of failure and making it challenging to scale. Solutions based on distributed trust are more resilient and scalable, but they increase each entity’s overhead and are more difficult to manage.


Should we talk flesh out more of the positives and negatives with the group? Internally speaking, Carequality isn’t necessarily against the idea of a Central architecture if the group decides that’s the best approach, however, we’d want to investigate this further before committing to this.


As a reminder, we’re still in the midst of these talking points:


·        Authentication/Trust – ensure the connection is secure, authorized, etc. When you “receive” a possible endpoint connection, how do you authenticate/trust it?

o   Certificates/Tokens


o   Security

January 29, 2019

The group focused on 3 submissions from the team on the topic of Authentication/Trust.

1.) Jennifer Blumenthal (OneRecord):



In my opinion, an ideal flow is authentication using OAuth 2.0 (Smart on FHIR) AND the published FHIR endpoints directory that participants could query dynamically.


Carequality builds and maintains the OAuth server.


All systems making queries for FHIR data are registered as Apps within this server.


To obtain an authorization token the querying system authenticates with the CareQuality hosted OAuth 2.0 server.


When querying for FHIR data the token is passed to the system being queried. That system must validate the token against the CareQuality OAuth server before returning data.


Please see the following reference; specifically 7.1




Someone has to build and maintain the Auth server for Carequality

All of the vendors need to be able to talk to it to validate the token




Vendors may push back because it may require them to query out to validate the token and I am not sure how much work that is.


2.) From Savannah Dearing (MEDENT):


Smart on FHIR is OAuth2 based authentication, with some additional constraints.  This is described as Scoping, which it does in several ways:


1)  Access Scopes:

User – A practitioner or system user logging into the system to access information

Patient – A patient logging in to view their own information [think Patient Portal]

System – A system accessing information from another system.


2) Read and Write scopes – with this you can request or give Read and/or Write permissions per resource.  This would help differentiate with your different use cases, where some actors were pushing data, and some were querying data.


3) Resource scopes – With Smart on FHIR you can give permission to read or write to each individual resource.  So, for example, if you are registered to Carequality as a billing company, you would not have access to patient medical information per the resources that contain it.



It sounds like most people in the meeting are familiar with the User scope.  This is where OpenID comes into play, though it is not required by the Smart on FHIR Specs to specifically use OpenID: http://hl7.org/fhir/smart-app-launch/


The scope I would suggest looking into is a system level scope.  These are not finalized specifications, but here are two:




I think the first one is more reflective of a true ‘system level scope’ since the second one requires a “requesting_practitioner” field, although the second one also includes “reason_for_request” which is like the IHE “purpose of use” which sounded useful to this group in meetings previously.


Similarly to the User level scope, if Carequality could take the role of the Authorization server, that would make the most sense, but require a certain level of development.



3.) Jack Powrie (Think Engage):


My initial thought is to have a initiating system authenticate with their identity provider via Oath2, and retrieve a token from the initiating system’s token provider. The initiating systems token provider must be trusted by the other participating FHIR gateways. The JWT token created by the initiating system will contain an assertion that can be trusted by other participating FHIR gateways. The trust is handled by using PKI to digitally sign the Oath2 JWT token. information in the JWT token could be similar to the values used in a NwHIN assertion; containing organization, user role, purpose of use, etc.


I have read the SMART on FHIR Authorization guide from HL7 http://hl7.org/fhir/smart-app-launch/ and pulled out the information in my notes below.


I have also read the Commonwell Service Specification on how they handle JWT tokens for FHIR brokerage https://www.commonwellalliance.org/wp-content/uploads/2019/01/CommonWell-Services-Specification_2.10.pdf.  Below is some notes that could help in discussion.





App Launch Framework Use cases


  1. Patients app that launch standalone
  2. Patient apps that launch from a portal
  3. Provider apps that launch standalone
  4. Provider apps that launch from a portal



Public vs. Confidential Applications


Public Application 

  • App is an HTML5 or JS in-browser app that would expose the secret in user space
  • App is a native app that can only distribute a client_secret statically


Confidential Application – 

  • Application runs on a trusted server with only server side access to the secret
  • App is a native app that uses additional technology (such as dynamic client registration or universal redirect_uris) to protect the client_secret



EHR Launch Sequence 

  1. redirect from the EMR to the application launch endpoint with the FHIR gateway as a parameter
  2. Application will retrieve the conformance statement from the FHIR endpoint
    1. Conformance statement will include OAuth 2.0 Endpoints
  3. Application will redirect user to the Oath2 authorization endpoint to get a authorization code
    1. The Application must be registered with the EHR Oath Authorization Server
    2. The Application is authorized for access via the EHR Authorization Server
  4. Upon approval the user is redirected back to the application
  5. For Confidential applications, the application then will request a token from the token issuer endpoint, using the authorization code provided by the authorization server
  6. The token is used to access the FHIR endpoint for resources.


Standalone Launch Sequence

  1. Application will retrieve the conformance statement from the FHIR endpoint
    1. Conformance statement will include OAuth 2.0 Endpoints (Authorization and Token Issuer)
  2. Application will redirect user to the Oath2 authorization endpoint to get a authorization code
    1. The Application must be registered with the EHR Oath Authorization Server
    2. The Application is authorized for access via the EHR Authorization Server
  3. Upon approval the user is redirected back to the application
  4. For Confidential applications, the application then will request a token from the token issuer endpoint, using the authorization code provided by the authorization server
  5. The token is used to access the FHIR endpoint for resources.


 Commonwell handling of Tokens for FHIR (RESTful) Endpoints


The following information has been pulled from the Commonwell Services Specification – Section 7 – API Security


X.509 Certificates are used for authentication of all transactions described in this specification (including authenticating to the MLLP‐based CommonWell Patient Identity Management service). In addition, SAML/JWT authorization tokens included in HTTP‐based transactions should be signed using an X.509 Certificate.  


Requests sent from an Edge System to CommonWell MUST use an X.509 Certificate maintained by the Edge System for authentication and for digitally signing the SAML/JWT authorization token included in the request. An Organization may use the same certificate for both authentication and signing or a different certificate for each. The Organization provides the associated public key(s) to CommonWell as part of the Organization registration process.  


Commonwell  Services Specification – 7.5 JSON Web Token (JWT) for RESTbased services 


When making REST‐based requests to the CommonWell server, an Edge System MUST include authorization claims in the form of a JWT bearer token in the Authorization HTTP Header of the request. JSON Web Token (http://tools.ietf.org/html/draft‐ietf‐oauth‐json‐web‐token‐08) (JWT) is a compact URL‐safe means of representing and transferring claims from an Edge System to the CommonWell server. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object and added to the payload of a JSON Web Signature (JWS) structure. The JWT is digitally signed and encrypted. Below is an example of a request with a message authentication code (MAC) encrypted, base64url encoded JWT token in the HTTP Authorization header. Note that the names of the claims observe the same convention described in the NHIN authorization framework.  

January 22, 2019
  • For how to deploy the Capability Statement, the group settled on “Describe an Actual Implementation” instance including URL and endpoints.


  • We discussed Provenance vs Pedigree as a means of determining the history/context of data being exchange. We concluded that Provenance has the actual created data as part of this resource, so there’s no need to utilize Pedigree as a means to defining history of the data.


  • We discussed methods of getting data:
    1. Ask for data in traditional manner. This is what Carequality’s Query Based Document Exchange Use Case is based on
    2. CDS Hooks – this specification describes a “hook”- based pattern for invoking decision support from within a clinician’s workflow


And agreed to leave out CDS hooks from conversation (for now.)

January 8, 2019

We got consensus that the Capability Statement should be accessible without limitations, i.e., one should not need a Cert or pass other security measures in order to access it.

We respect to level of detail, there are generally 3 options to choose from for a Capability Statement according to HL7/FHIR:

1.            Describe an actual implementation

2.            Describe software solution capabilities

3.            Describe a desired solution

The group settled on (2) ‘Describe software solution capabilities.’  Because it is not dependent on any particular implementation, the profile cannot provide specific details such as endpoint addresses. It may also document various configurations, in which the application can be set up, or describe the degree of customizability associated with the solution. 


The implications of the above decision are as follows; we are just choosing (for now) to include just the Capability Statement endpoint in the Directory and any other endpoints must be hit using a TBD security mechanism

It should be noted that all 3 versions of the Capability Statement can be used simultaneously, so this allows us the flexibility of adding additional versions of the Capability Statement, should this topic be revisited.

December 18, 2018

We continued the discussion from the previous week about deploying JUST ONE Directory that supported both the use:

· SOAP web service transactions

· FHIR transactions

The group is undecided about the level of detailed needed to be added for FHIR. The choices are:

· have one FHIR endpoint listed and move on to the Capability Statement

· create additional FHIR endpoints because the Capability Statement doesn’t support the level of detail needed

Ultimately, it appears this may be dependent upon the specific Use Case in question and the Policy Group would likely be asked to help flesh this out.

We talked about defining what the API to the Directory is in terms of FHIR; because we will need to define what the API is if vendors are to test against it later. We also discussed how to define what the capabilities of the Carequality Implementers are and to funnel the exact requirements to the Policy Workgroup. Moreover, we stated that we should establish a baseline of capabilities if you’re to participate in the Carequality FHIR Ecosystem.  Example: “I support US Core V2 and can exchange medication data.” The exact details of this may not happen until we establish specific Use Cases.

The last topic was about whether or not you need a Cert to hit an Implementer’s Capability Statement. Most of the group leaned towards making it public, but there was a small faction who wanted to discuss this further. This will be an agenda item at the next WG meeting. 

December 11, 2018

There was a consensus from the group that we should use ONE Carequality Directory for both FHIR and IHE, instead of spinning up a brand new directory for FHIR. We should be able to add a field named “Endpoint Connection Type” to the existing Directory that would allow Implementers to distinguish between the two profiles.


This would allow Implementers who support either IHE or FHIR to utilize the same Carequality Directory. And that makes it easier/less costly for our Implementer community.

The group also believed that we should utilize the Capability Statement as the source of truth for any details behind the endpoint. The emphasis here was that the Directory should not be turned into a one stop shop for everything, including what resources/functions/etc are supported. Otherwise, it could become too cumbersome and decrease its value proposition. 

The group also was not aware of any profiling of the Capability Statement beyond the standard US Core version. However, we did agree to leave this an open-ended question. In other words, if the need arises to make the FHIR Ecosystem less ambiguous beyond the Capability Statement, we left open the possibility of having to define:

  • What this is
  • How to bridge this gap

But for now, we’ll stick to the US Core resource and see where that takes us.

December 4, 2018


We agreed to the following outline for our goals:

Rough expectation of one month each bullet below – Which would take us through approximately April 2019 for this 1st bullet

  • Directory of FHIR end-points – how to make endpoints known
  • Discovery of capabilities for these end-points
  • Authorization/Certification/Trust/Security/B2B/SMART/etc. – ensure the connection is secure, authorized, etc.
  • Record Location Service – know where the patient’s “active” endpoints are interacting with an RLS

Use Cases/Work flows

How flexible/specific should we be with regard to minimum capabilities available through Carequality?

  • Single Patient
  • Rely on capabilities statements and call it a day?
  • Agree to a minimum FHIR version, e.g., minimum for FHIR DSTU R2 for defined number of resources.
  • Agree to an implementation guide, e.g., US Core
  • How to stratify e.g., provider vs. payer (today may be US Core vs. BB 2.9)
  • Agree to specific flows, e.g., Da Vinci Pre/Prior Authorization
  • Other
  • Multiple Patients/Bulk


Refer back to single patient above

  •  Targeting May 2019 to kick this off.
November 13, 2018

This was the kick-off meeting where the group introduced themselves to each other. We also discussed what role Carequality plays in the interoperability world and distributed the Workgroup Charter and FHIR Use Case proposal to the group.

November 27, 2018

The Workgroup reconvened after not meeting during the week of Thanksgiving. The group officially gave its blessing to the Use Case Proposal and Charter. We also prioritized the draft goals as outlined in the charter. We decided to strive for consistency, whenever possible, across the IHE and FHIR profiles. We also discussed the best way to architect this offering and the best way to approach adding a FHIR Use Case. Among the topics to flesh out for future meetings are: 1.) Would we overlay FHIR on top of existing IHE profile or other? 2.) Would future Implementers need to support both IHE and FHIR or either – Policy Decision? 3.) How will we treat ability of FHIR to exchange documents given Carequality’s current Query Based Document Exchange use case?