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.
|Aditya Bansod||Luma Health|
|Andrei Azudin||Health Gorilla|
|Aris Kouvaros||Mount Sinai Health System|
|Brett Marquard||Wave One Associates|
|Caroline Brozak||Children’s National Health Systems|
|Didi Davis||The Sequoia Project|
|Ganesh Persad||Memorial Healthcare Systems|
|Gurbinder Singh||Symcore Solutions|
|Hans Buitendijk ** Co-Chair||Cerner|
|John Novack||New Jersey Innovation Institute|
|Kalyani Yerra||Premier Inc|
|Michael Marchant||UC Davis Health System|
|Micky Tripathi ** Co-Chair||MA eHealth Collaborative|
|Santosh Jami||SAFE Health|
|Tony Mallia||Edmond Scientific Co (ESC)|
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
- 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?