/> FHIR Policy Workgroup - Carequality

Policy Workgroup

The Policy Workgroup addresses the business and policy requirements involved in enabling a single on-ramp for FHIR-based exchange. The group’s work will include addressing Carequality’s core Principles of Trust, such as non-discrimination, full participation, and permitted purposes of use.


Member NameOrganization
AJ Peterson ** Co-ChairNetsmart
Alan SwensonKno2
Amul PatelBlue Shield CA
Andrei AzudinHealth Gorilla
Brett MarquardWave One Associates
Caroline BrozakChildren’s National Health Systems
Didi DavisThe Sequoia Project
Doc DevoreMatrixCare
Douglas DeShazoCognizant
Elaine BlechmanSmart health Records, Inc. (SHARE)
Ganesh PersadMemorial Healthcare Systems
Genevieve Morris ** Co-ChairIntregral Health Strategies
Gurbinder SinghSymcore Solutions
Hans BuitendijkCerner
Jason VogtMeditech/Commonwell
Jim TaylorTIPCO
Joan RobinsonBCBS
Kalyani YerraPremier Inc
Kedar GantaGE
Kyle ZumsteinAvaility
Lauren Gardanierathenahealth
Lisa MoonAdvocate Consulting
Marty PrahlSSA
Meryl BloomrosenPremier healthcare alliance
Micky TripathiMA eHealth Collaborative
Navi GadhiokeCW
Prathib SkandakumaranSurescripts
Rhonda ScottConduent
Rob KlootwykEpic
Ron ShapiroQvera
Santosh JamiSAFE Health
Sheryl TurnerAnthem
Susie FloresCare Directives
Tashfeen Ekram Luma Health
Thomas HalliseyHealthcare Association of New York State (HANYS)
Tushar MalhotraeCW


January 17th 2019

The group spent more time discussing whether or not to Implement SLAs or just Best Practices. In either case, we will begin compiling a list that will be categorized as one or the other down the road.

The first topic of discussion related to how to best respond with an error by a receiving system in response to transaction received that they are unable to process. Generally speaking, we agreed that the most useful and descriptive response so that a correction could be made was the best response.

The following Straw Proposal will be put to the group for the next meeting:

  • FHIR errors should use the OperationOutcome capability to return both human readable and machine processable information with sufficient detail to allow the client to determine if the error can be corrected at the client side, such as a retry operation due to the resource being busy, or is a fatal error. And due to security reasons, it might be wise to obscure some of these details.


We also discussed needing to implement policy requirement around authorization and identity proofing levels. Specifically, we talked about the following 2 questions:


1.) Should we deploy “old” NIST standards or “new” NIST standards.

2.) What level of NIST should we deploy?


We also talked about backwards compatibility and the best way to deploy it. The group suggested having a separate URL for different versions. It was stated that Implementers should definitely list what version(s) they support in their Capability Statement.

January 10, 2019

We continued our discussion about whether or not to incorporate any specific Service Level Agreements (SLAs.) The group continue to struggle to find a balance between what is practical/doable and what is fair to our Implementers community & their end users. At this time, we are concentrating on defining some Best Practices in the hopes that they can one day become actual SLAs. We would also like to create an appropriate adjudication process (Dispute Resolution) for complaints.


We asked for responses from the group regarding Interoperability Best Practices in lieu of creating SLAs at this time. An example of a best practice, is not having a maintenance window every business day. We are looking for examples of both Encouraged and Discouraged Behaviors. This feedback will be disseminated to the workgroup for the next meeting and analyzed by the group.


We will also continue talking about Provenance (describes the metadata, or extra information about data, that

can help answer questions such as when and who created the data) at a future meeting. We will be exploring putting Policy requirements around this as described in USCDI here.  Putting specific policy guidelines around Data Provenance will cut down on duplicative data.

December 20, 2018

** What Network Hygiene / SLAs should we consider?

The group was hesitant to establish definitive metrics. Instead we focused on considering defining what the “best practices” are for an Implementer. Specifically:

· Policy for notifications around vendors discovering that they are down or a connection is down

· Policy for planned maintenance windows to put into the Directory

        – Agreed to Use the Conformance Statement for this

Also discussed the challenges associated with implementing uptime metrics. However, we did think it would be wise to explore operational and technical challenges associated with being an Implementer and trying to associated data with said challenges. Because the data would have to be identified, collected over a period of time, and reviewed – a phased approach would be necessary if we were to travel down this path.

In the end, we agreed to start with a “best practices” approach (e.g. do not “turn off” system every night) and Rob from Epic would have his team forward us other examples of best practices. 

** Hit Rates – identified the need to control volume (no query blasting all patients every day) and efficiency of the network.

Perhaps we can deploy hit rate metrics by Implementer (a reporting requirement) that allows each Implementer to report on how many hits/day/Implementer they are seeing. 

We agreed to parking lot SLAs for Implementers and RLS (but should explore after TEF is released and we have a chance to digest its meaning/implications):

1.) SLAs for response times for real time queries

2.) SLAs for response times for planned queries

3.) SLAs for query initiators  

4.) SLAs for query responders

5.) SLAs for RLS

December 13, 2018

Consensus from the group that the Policy Assertions listed on pages 15-22 of the Query Based Document Exchange IG are fine and the list does not need editing for creating a Carequality FHIR Ecosystem at this time. The caveat being, we may need to circle back this list pending the outcomes of the TEF and SMARTonFHIR. Marty Prahl (SSA) informed that his organization needs specific authorizations and have many requirements as it relates to consent. 

Lisa Moon (Advocate Consulting) expressed concerns over the patient access policy education for organizations who are on framework. As we expand the Use Cases beyond treatment, payment, and operations, we may need more guardrails with respect to consent in order to make queries.

We may need to flesh out section 3.5  SLAs: What are best practices and good network behavior. Hans

Buitendijk stated that we may be able to deploy something around volume/time units (e.g., not every 2 seconds.) We may start with a recommendation then implement a rule. Dave Cassel stated we should circle back with straw proposals at next co-chair meeting on this topic.

December 6, 2018

We agreed to the following order for our Draft Goals:

1. Principles of Trust

    • Patient Permission
    • Permitted Purposes in alignment with the draft TEF and ongoing alignment, to the extent possible, with future iterations of the TEF. 
    • Permitted Users
    • Data Integrity
    • SLAs
    • Policy Assertions
    • Non Discrimination – Policy Assertion Acceptance
    • Non Discrimination – Access Policies
    • Responses for “Access Denials”

2. Access controls

    • Workflows around defining specific users
    • Workflows around defining originating system

3. Consider federal initiatives such as TEFCA and 21st Century Cures, and, to the extent reasonable, align Carequality policies with these initiatives to avoid later re-work.

4. Develop specific policy requirements around Evidence of Compliance

    • Considerations for non-production testing and validation
    • Pre-production validation
    • Quarterly and ongoing interoperability confirmation

5. Consider defining the minimum Resources supported for each Permitted Purpose deployed by a group of Implementers.

    • Example – if you’re a payer, who wants to exchange data for Permitted Purpose “A”, then you need to support, at a minimum, Resources “X, Y, and Z” in order to participate in the Carequality ecosystem. 
    • Responses to Unsupported Resources

For the next meeting on Dec 13, we’ll be referring back to the current IG, looking at the Policy Assertions listed on pages 15-22, and applying them to a FHIR Ecosystem.

November 15, 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 29, 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.