/> 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.

Participants

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

Updates

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.

http://build.fhir.org/valueset-endpoint-connection-type.html

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

Infrastructure

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

Piloting/testing

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?