FHIR Chat · API and Search Params · CARIN IG for Blue Button®

Stream: CARIN IG for Blue Button®

Topic: API and Search Params

---

Josh Lamb (Nov 20 2019 at 16:27):

I may have missed the documentation but is there anything published on the required and suggested search parameters for the Coverage, ExplanationOfBenefit, and Patient endpoints? I am expecting to find similar guidance as was published for USCore: https://www.hl7.org/fhir/us/core/searchparameters.html. At a minimum I would imagine that we would support searches based upon the patient identifier for all resources.

Also is there any best practice on how to ensure that client apps are not having to retrieve the patients full EOB and coverage history each time they need an update?

Paul Church (Nov 20 2019 at 17:28):

I'm not aware of such guidance and I agree that it is needed. At the Atlanta connectathon servers supported various subsets of search parameters.

re: best practices on incremental data retrieval, perhaps Patient $everything with the _since parameter.

Amol Vyas (Dec 08 2019 at 16:13):

@josh lamb , @Paul Church : Thanks. We are working on incorporating a Search Parameters spec for the IG which would allow for retrieval of EOBs since lastUpdated. Not sure if we would need an explicit lookup based on patient id in the IG, since this IG is for a consumer-facing, Individual Right to Access, EOB History API. I can definitely see an IG leveraging the same CARIN BB profiles for a provider-facing API that allows for patient id or group id Search Parameters. Thoughts?

Michele Mottini (Dec 08 2019 at 16:38):

If it is patient facing you need the search by patient id - SMART auth sequence will give the client the paitent id, then the client has to use that to get the ExplanationOfBenefit, so it needs search by patient id

Amol Vyas (Dec 10 2019 at 18:55):

@James Agnew, Could you please comment on above based on our discussion at Baltimore CARIN Connectathon?

Josh Lamb (Dec 20 2019 at 14:43):

@Amol Vyas and @Paul Church and @Michele Mottini , Here is my suggestion for the search parameters for the three resources:

Patient
SHALL GET [base]/Patient/{id}
SHOULD GET [base]/Patient/{id}/everything
SHOULD GET [base]/Patient/{id}/everything?_since={date}
SHOULD GET [base]/Patient/{id}/everything?_since={date}&_type=Patient,Coverage,ExplanationOfBenefit

Coverage
SHALL GET [base]/Coverage/{id}
SHALL GET [base]/Coverage?beneficiary=Patient/{id}

ExplanationOFBenefit
SHALL GET [base]/ExplanationOfBenefit/{id}
SHALL GET [base]/ExplanationOfBenefit?patient=Patient/{id}
SHOULD GET [base]/ExplanationOfBenefit?patient=Patient/{id}&_lastUpdated=gt{date}

Michele Mottini (Dec 20 2019 at 15:29):

I would avoid $everything: the guide is about getting claims data, but $everything will return all the data the server has for that patient, that can vary a lot. If we want a single call to get all data: SHOULD GET [base]/Patient?_id={id}&_revinclude=ExplanationOfBenefit:patient&_revinclude=Coverage:patient

Josh Lamb (Dec 20 2019 at 15:39):

Thanks @Michele Mottini , I was worried about this too. I am not very family with the smart auth process, but wouldn't we assign resource scopes to apps that would determine the allowed resources? _revInclude does seem more explicit so it is probably better in either event. My only concern is that the number of explanationOfBenefit resources will be very large for some patients. I have not seen an example of applying a filter on a revinclude (to filter on dateUpdated).

Paul Church (Dec 20 2019 at 15:55):

We could use the _type param on $everything to limit to these three. I think the key shortcoming with revinclude is that you can't do anything like _since.

Michele Mottini (Dec 20 2019 at 15:58):

Oh yes, _type will work - I did not know that it was added to $everything

Josh Lamb (Dec 20 2019 at 16:07):

So this: SHOULD GET [base]/Patient/{id}/everything?_since={date}&_type=Patient,Coverage,ExplanationOfBenefit ?

Elkhan Yusubov (Dec 20 2019 at 16:17):

@josh lamb - would you add other profiles search parameters as well?
The missing once are RelatedPerson, Organization, PractitionerRole :|

Elkhan Yusubov (Dec 20 2019 at 16:29):

Probably, we also need to suggest a new search param for "eob-type" by asking FM HL7 WG to consider our request.
We need to empower Patient with ability to share only type of EOBs that s/he would like to.
Any other thoughts @Amol Vyas @josh lamb @Mark Scrimshire ?

Josh Lamb (Dec 20 2019 at 16:37):

@Elkhan Yusubov good point. My assumption is that anything referenced should be found at the reference location. For RelatedPerson, Organization, and PractitionerRole the searches would be referenced by Patient, Coverage, and ExplanationOfBenefit. So these should all be found at [base]/{resource}/{id} as indicated by Resource References. Ill include these in my initial suggestion and we can get more feedback during meeting.

I am not sure about searching on eob-type and other consumer focused use cases. It could be that this is enabled through the applications that are serving up this data. I would be interested to hear what everything thinks about this.

Mark Scrimshire (Dec 20 2019 at 18:50):

CMS BB2.0 is moving to offer search by claim type. e.g. carrier, pde etc. This needs to allow multiple claim types to be requested.

Josh Mandel (Dec 21 2019 at 15:32):

If we want a single call to get all data: SHOULD GET [base]/Patient?_id={id}&_revinclude=ExplanationOfBenefit:patient&_revinclude=Coverage:patient

@Michele Mottini posed this as a condition ("if we want...") Do we? Is this a requirement? Given where we are in the ballot cycle and what's been tested at Connectathon, I'd be very cautious about adding new requirements.

Josh Lamb (Dec 23 2019 at 13:50):

@Josh Mandel there is a call scheduled today with the goal of selecting the required and suggested search criteria that should be supported. The current documentation in the IG is lacking.That being said, i am inclined to agree that patient Everything and _revInclude do not provide much benefit since there are only 3 endpoints that can all be searched by using the patient id that will be provided through the SMART app flow.

Josh Mandel (Dec 23 2019 at 14:07):

Thanks. Not sure if I can join, but are you able to share the dial-in details here? Basically I'd recommend supporting

• Patient read;

• EoB search by patient, type, _lastUpdated;

• Coverage search by patient, _lastUpdated.

Elkhan Yusubov (Dec 23 2019 at 14:24):

Good suggestion @Josh Mandel
Adding details of the call, for community members to join:

Join from PC, Mac, Linux, iOS or Android: https://leavittpartners.zoom.us/j/342513194
Or iPhone one-tap (US Toll): +16468769923,,,342513194# or +16699006833,,,342513194#
Or Telephone:
Dial:
+1 646 876 9923 (US Toll)
+1 669 900 6833 (US Toll)
Meeting ID: 342 513 194
International numbers available: https://leavittpartners.zoom.us/u/asP88u56n
Or an H.323/SIP room system:
H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East)
Meeting ID: 342 513 194
SIP: 342513194@zoomcrc.com
Or Skype for Business (Lync):
SIP:342513194@lync.zoom.us

Igor Sirkovich (Dec 23 2019 at 15:06):

• Patient read;

• EoB search by patient, type, _lastUpdated;

• Coverage search by patient, _lastUpdated.

@Josh Mandel, I'm wondering whether insurance companies ever update EOBs once these get created and whether all companies store the last updated date and would support search by _lastUpdated. The alternative we had discussed was to use search by "created", which is a required element in EOB, but likely, doesn't get updated in case insurance companies do perform updates.

Josh Lamb (Dec 23 2019 at 15:19):

Throughout the adjudication process we do update the EOBs. There is also the possibility of corrections to be made. Search by _lastUpdated (property on meta) would return EOBs that have been modified. Last updated would be optional but data holders that wish to limit the amount of data they are sending would have an incentive to make this option available.

Igor Sirkovich (Dec 23 2019 at 15:24):

Thank you @josh lamb. Do you think there is any benefit to support search by "created" in addition to search by "_lastUpdated"?

Josh Lamb (Dec 23 2019 at 15:33):

Seems like searching on "created" would omit updates. The use case that I am imagining for _lastUpdated is that an app developer will query our endpoints for only things that have been updated since the last call. If created was used for this things would be missed.

Igor Sirkovich (Dec 23 2019 at 15:46):

Thank you Josh. I agree that searching on "created" would omit updates. This was the reason I had asked whether EOB records ever get updated. Also, technically, it's possible to create new EOBs with the created date in the past (e.g. when loading historical paper records into the database). I think the use case is clear now. To use this parameter, 3rd party apps would need to store the timestamp of their last call to get the patient's data from each API and to use this stored timestamp with the _lastUpdated parameter to get all the new and updated EOB resources.

Josh Mandel (Dec 23 2019 at 16:11):

Re: _lastUpdated, my recommendation is to put it on the required list and ensure that at least all API providers can tolerate the presence of this search parameter (i.e., if you don't want to allow searching by last updated, just ignore the param -- but don't refuse the query). This allows consistent client behavior, and allows servers that care about efficiency to remain efficient. (This behavior of "ignore search params you can't process" is standard for FHIR.)

Paul Church (Dec 23 2019 at 16:54):

Do we expect that obtaining a patient ID from the SMART context is the primary or only way that clients find a patient? I'm not sure how this interacts with access to data on spouses, dependents, etc.

Lloyd McKenzie (Dec 23 2019 at 17:13):

There's an extension that allows linking a RelatedPerson to their Patient. However there's no expectation SMART systems will support it. It also raises some tricky privacy issues.

Josh Lamb (Dec 23 2019 at 17:16):

@Paul Church I am curious about this too. Would be good to ask on call if family members are within scope since this is supposed to deal with an individuals right of access. It could be that a member would need to enter their dependents/spouses credentials to obtain their information. Somewhat off topic and out of scope, but to add to what @Lloyd McKenzie is saying maybe a resource like FamilyMemberHistory could achieve this as well.

Paul Church (Dec 23 2019 at 17:24):

In general I'd like to hear from the app developers about what API functionality they need. It's easy for me to just suggest supporting everything, I have a general-purpose FHIR server. I think @Josh Mandel suggestions above make sense as a minimum but it's not hard to make a case for several other search parameters on EoB like created, status, provider...

Michele Mottini (Dec 23 2019 at 17:29):

If a user has access to multiple records - eg family members - he/she will pick up the one they want to connect to during the authentication sequence and the corresponding patient id is returned to the app

Paul Church (Dec 23 2019 at 17:33):

If the relationship the app wants to have with the server is that it just makes an occasional Patient $everything call with _since and _type and syncs the results into its own storage, that's a very different model than one where the app is hitting the server with searches on EoB during user interaction.

Josh Lamb (Dec 23 2019 at 17:35):

@Michele Mottini in this case would they be accessing the patient's data as if they were that patient? i.e., entering the patients credentials that they want to access?

Michele Mottini (Dec 23 2019 at 17:41):

yes, the client would access the data as if that patient logged in - but it is the user (using his / her own credential) that selected that

Josh Lamb (Dec 23 2019 at 17:42):

@Paul Church the app developer capability statement is silent on this. I was actually considering rate limiting the frequency that an app can hit our endpoints. The CMS bluebutton has guidance that suggests hitting their endpoints one time a day, from https://bluebutton.cms.gov/developers/#developer-guidelines: "We recommend you have a daily or weekly job to fetch new claims data for your users. Please be responsible with your API usage and comply with the Service Management Rights to Limit conditions in the Blue Button API Terms of Service."

Michele Mottini (Dec 23 2019 at 17:43):

This is Epic for example:
pasted image
Logged in as Jason Argonaut, that have access to both his record and Jessica's one - so I am prompted to choose one and that's the patient id that get returned to the client

Josh Lamb (Dec 23 2019 at 17:45):

@Michele Mottini, this makes me a bit worried about sensitive information, such as infectious diseases, pregnancy screenings, and mental health claims. Hopefully this process grants full access (falls outside of HIPPA under individual right to access).

Ricky Bloomfield (Dec 23 2019 at 20:10):

@Michele Mottini @josh lamb Sorry to join this conversation late. I think we're generally on the same page here re: minimum requirements. Proxy access is something that we've brought up before, and I agree that we should have a patient picker in the OAuth flow like other EHR vendors have and then the user is connected to one patient at a time.

Josh Mandel (Dec 23 2019 at 20:24):

Good! (And sorry I couldn't join the call today). Yes, basic SMART support should mean supporting the launch/patient context, with a patient picker when needed.

Ricky Bloomfield (Dec 23 2019 at 20:25):

Thanks, @Josh Mandel. There was a question about server support for the user scope to be able to download all data at once, but EHRs don't currently follow this pattern for client apps and I think it could result in some ambiguity and safety issues.

Josh Lamb (Dec 27 2019 at 14:22):

Based upon Monday's meeting it sounds like the primary use case that we are supporting is similar to the CMS bluebutton flow, where an app developer will pull all data for a single patient onto the users device and will periodically poll the FHIR server for updates, using the _lastUpdated param to get updates. There was also a use case for apps that will not display all EOB types, which necessitates the use of an EOB type param.

Here is my attempt at recapping the searches we discussed on Monday's call:
GET [base]/Patient/{id}
GET [base]/Coverage/{id}
GET [base]/Coverage?beneficiary=Patient/{id}&_lastUpdated=gt{date}
GET [base]/ExplanationOfBenefit/{id}
GET [base]/ExplanationOfBenefit?patient=Patient/{id}&type=[system]|[code] &_lastUpdated=gt{date}

There was also talk of supporting includes (not revInclude), but we did not get into details. Here is my best guess:
Coverage:
_include=Coverage:beneficiary
_include=Coverage:payor
ExplanationOfBenefit:
_include=ExplanationOfBenefit:patient
_include=ExplanationOfBenefit:insurer
_include=ExplanationOfBenefit:provider

Josh Mandel (Dec 28 2019 at 02:41):

Quick feedback: it'd be good to ensure that queries without lastupdated are also supported (it's worth mentioning these explicitly). That's important for initial backfill / one-shot queries.

Josh Lamb (Dec 31 2019 at 17:51):

@Josh Mandel and @Ricky Bloomfield thanks for the input, this is very informative. Based upon what I am reading User context does not seem appropriate for our use case, since it seems geared more toward resource specific access rather than patient access.

I am confused about how the patient selection process will function. Is the basic idea that we will provide a widget, using HTML, that will have click events tied to the available patients and on click we will redirect to an authorization URL? I am having a hard time finding examples of this.

Josh Mandel (Dec 31 2019 at 18:29):

For single patient access, The expectation is that the redirect to the authorization server happens first, and then the authorization server is responsible for any context gathering required (For example, signing in a user and presenting any patient selection screens necessary).

Josh Mandel (Dec 31 2019 at 18:34):

The authorization tests at https://inferno.healthit.gov are probably a good source for testing the expected behavior

Josh Lamb (Dec 31 2019 at 18:41):

@Josh Mandel , thanks, this clears things up. It sounds like the client app will not even be aware that a patient selection occurred, it will only know which patient is in scope.

Josh Mandel (Dec 31 2019 at 18:45):

That's right! (And this is by design, since until authorization is provided, the client app has no business knowing anything.)

Ricky Bloomfield (Dec 31 2019 at 21:11):

@josh lamb I don't have much to add here. Thanks, Josh M! FYI, there are a number of EHR sandboxes that allow you to test out an E2E flow where you can see how the auth works for patient selection.

Ricky Bloomfield (Jan 01 2020 at 00:56):

FYI, you can see Epic's auth flow as part of their Patient Authentication tutorial their open.epic site, including the user selection as part of that flow: https://open.epic.com/Tutorial/PatientAuthentication. The content of this flow is up to the health organization.

Josh Lamb (Jan 13 2020 at 21:32):

@Josh Mandel , thanks for being on the call today. After you dropped off there were more discussions on if we should support Coverage search. There seems to be some confusion regarding how resource references are resolved, e.g. that supporting search on referenced resources by resource Id would result in a scope change. It sounds as if some servers are leaning toward using contained resources for Coverage, Patient, Organization, etc. My concern is that this will limit our ability to adopt future IGs and that we are deviating from FHIR norms.

Josh Mandel (Jan 13 2020 at 21:35):

Thanks! Please note that It's not an appropriate use of contained resources if the coverage and patient and organization can be properly identified. This isn't a grey area; an IG won't make it through a ballot that way.

Josh Mandel (Jan 13 2020 at 21:37):

I'd basically recommend following the straightforward pattern for resource access set up in US Core, including "read" (if you know a FHIR id) and "search" (by id, identifier, patient, or other relevant parameters).

Josh Mandel (Jan 13 2020 at 21:37):

I think there's probably some kind of misunderstanding leading to more complex proposals.

Josh Mandel (Jan 13 2020 at 21:38):

It'd be great to explain here what the issue is with CARIN following US Core practices (and letting servers support extra/fancy API features if they like)

Josh Lamb (Jan 13 2020 at 21:39):

Thanks for providing more details. I agree that there seems to be some confusion. Search of Patient, Coverage, and EOB by PatientId does follow US Core and makes logical sense to me. Additionally if we could include a SHOULD guidance on _lastUpdated it may alleviate server strain.

Josh Mandel (Jan 13 2020 at 21:40):

That sounds just right to me. If someone disagrees, it'd be great to articulate the reasoning here.

Elkhan Yusubov (Jan 17 2020 at 15:42):

@Amol Vyas @Mark Roberts @josh lamb - is CARIN Health Plan Workgroup call for upcoming Monday cancelled?

Josh Lamb (Jan 17 2020 at 16:12):

I think most offices will be closed, including mine.

Amol Vyas (Jan 17 2020 at 22:49):

Good question, Elkhan. 1/20 is a working day for me. Considering that 1/27 is ONC Annual Meeting, and several of us (including me) will be attending, we may need to move next week's meeting instead of cancelling it. @Ryan Howells ?

Ricky Bloomfield (Jan 20 2020 at 20:14):

Hi, everyone! The latest draft of the CARIN BB RESTful API document was reviewed today during our weekly call. We would love for this group to take a look and provide feedback in advance of the comment period closing on Monday, 1/27. @Josh Mandel @josh lamb @Pat Taylor @Mark Scrimshire @Amol Vyas @Lisa Nelson @Pascal Pfiffner @Amy Ballard CARIN-BB-RESTful-API-Draft-v4.1.docx

Pat Taylor (Jan 21 2020 at 13:15):

Hi everyone, as context to the document that Ricky shared, assumptions are that the scope of this version of the CARIN BB API service is an EOB service, not a Coverage or Patient service that are independent of the EOB.

EOBs may be returned for a five year span of time. EOB.insurance.coverage resolves the question of, “What insurance covered this claim as of date the service took place?”   The Implementation Guide assumes that Coverage, Patient and other supporting resources will be that effective as of the service date of the claim. @Igor Sirkovich @James Agnew

Josh Lamb (Jan 21 2020 at 15:06):

@Pat Taylor and @Ricky Bloomfield I think we have come a long way toward consensus on search Params. My only suggestion is that the additional search params for ExplanationOfBenefit be moved to the optional column. These include insurer, identifier, and eob-date. We should also consider adding an optional search param for Coverage:Subscriber (the patient that has coverage).

We should also define the app / server interactions. Right now my assumption is that we will define "responsible" API useage that mirrors the CMS Bluebutton. This will involve applications persisting retrieved data on the users device and polling for updates, using the _lastUpdated param.

Paul Church (Jan 21 2020 at 15:26):

As a matter of style, I suggest that the eob-date search parameter be named just 'date', or something like 'service-date' if applicable. Search parameters are attached to specific resources, so it would be against the general pattern of FHIR to put the resource name in the param name.

Elkhan Yusubov (Jan 21 2020 at 17:01):

+1 for the service-date search param on EOB resource.

Igor Sirkovich (Jan 21 2020 at 19:20):

I think service-date is a good name. My only concern is that this name might make an impression that this search parameter applies only on a servicedDate element, while in practice, the search would be performed against both serviced (servicedDate, servicedPeriod) and billablePeriod.

Pat Taylor (Jan 22 2020 at 15:35):

+1 for service-date given Igor's clarification

Pat Taylor (Jan 22 2020 at 15:38):

@josh lamb The API document shared by Ricky defines a Coverage:subscriber parameter for include, i.e. when searching for EOBs, a consumer app can request to include (iterate) Coverage:subscriber, which can be either RelatedPerson or Patient resource. Also, when searching for Coverage by its resource _id, a consumer app can request to include subscriber.

Or, are you requesting support searching for Coverage by subscriber id. If so, I believe there was agreement that only search by _id would be in the current scope.

Josh Lamb (Jan 22 2020 at 16:21):

@Pat Taylor and @Ricky Bloomfield , its actually Coverage:Beneficiary that I suggest we include as an optional search param. I misspoke earlier. The Coverage:Beneficiary is the individual who is receiving benefits from a coverage and this will be the same individual that is referenced in the EOB. Coverage:Beneficiary will always reference a Patient resource.

Since we are doing patient scope it does not make much sense to support Includes or Search on Coverage:Subscriber. The subscriber referenced may be different than the beneficiary. Using launch/patient scope the subscriber would only be accessible if the current scope was for the subscriber. Coverage:Beneficiary is also mandatory while Coverage:Subscriber is optional within the IG and does not contain a "must support" flag.

My suggestion is to remove references to Coverage:Subscriber in the Word document posted by Ricky and replace them with Coverage:Beneficiary. I am also suggesting that we include optional support for search on Coverage:Subscriber. Supporting search on Coverage, EOB, and Patient by FHIR Patient Id seems more in line with CMS Bluebutton and the US Core IG.

Michele Mottini (Jan 22 2020 at 17:20):

Yes, to got all data for a patient (that is the main use case) we need the Coverage.patient (beneficiary) search parameter

Michele Mottini (Jan 22 2020 at 17:23):

Ditto for RelatedPerson: we need the patient search parameter

Pat Taylor (Jan 22 2020 at 17:35):

@Lenel James

Igor Sirkovich (Jan 22 2020 at 20:04):

@josh lamb, @Michele Mottini, A consumer should be able to requests to include Coverage:subscriber (who might be Patient or RelatedPerson), assuming both API and consumer app support includes.

On the other hand, requesting Coverage:beneficiary would be redundant as it would always point to the same Patient resource that can be requested to be included using _include=ExplanationOfBenefit:patient, e.g. in the following example, Coverage:beneficiary would be redundant:
GET [base]/ExplanationOfBenefit?patient=[id]&_include=ExplanationOfBenefit:patient&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:beneficiary

If an API and/or app doesn't support or doesn't use includes and assuming there is an agreement that for the supporting (non-EOB) resources, CARIN BB allows search/read by resource id only, I believe the following workflow would apply:

1. a consumer searches for EOBs
2. a consumer searches/reads Patient by resource id (this might actually be done before searching EOBs)
3. a consumer gets Coverage id of a specific EOB from the list of returned EOBs
4. a consumer searches/reads Coverage by resource id
5. a consumer gets RelatedPerson id from the returned Coverage resource (if this patient is not the subscriber)
6. a consumer searches/reads RelatedPerson by resource id

Just to summarize, if there is an agreement that EOB is always an entry point for consumer queries and that for non-EOB resources CARIN BB allows search/read by resource id only, I believe there is no need for Coverage:beneficiary or RelatedPerson:patient search parameters.

Elkhan Yusubov (Jan 22 2020 at 20:57):

Agree with @Igor Sirkovich on supporting use case, where Server does not have a support for "_include" expression.

Josh Lamb (Jan 22 2020 at 22:19):

@Igor Sirkovich If our only entry point is EOB then I am okay with just these two searches:
GET [base]/ExplanationOfBenefit?patient=[patient]
GET [base]/ExplanationOfBenefit?patient=[patient]&_lastUpdated

If we support standalone search of coverage (outside of Id) then my suggestion was to also include "GET [base]/Coverage?Beneficiary=[patient]".

In either event I think we want to avoid the complex queries included in the above Word document. The doc that was posted by Ricky has this example query:
GET /ExplanationOfBenefit?patient=[id]&_lastUpdated=[prefix][date] &_include=ExlanationOfBenefit:care-team&_include=ExlanationOfBenefit:patient&_include=ExlanationOfBenefit:provider&_include=ExlanationOfBenefit:insurer&_include=ExlanationOfBenefit:coverage&_include:iterate=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization&_include:iterate=Coverage:payor&_include:iterate=Coverage:subscirber

I am not sure if the IG has to call this out, but i think its a fair assumption that any resource references should be searchable by the referenced Id.

Paul Church (Jan 22 2020 at 22:41):

These complex chains of _include are motivated by a client that wants to get all relevant resources in a single query.

There are a few alternatives:

• insist that the client may have to make numerous search or read calls, which has performance implications for many more round-trip queries - but as a lowest common denominator perhaps acceptable?
• the IG could require the Patient/$everything operation, but this only covers the case of getting all EoBs under a patient
• the GraphDefinition resource and $graph operation provide a generalized way of gathering a linked collection of resources (the description at http://hl7.org/fhir/graphdefinition.html specifically describes this use case as motivation) but I don't think this is widely implemented
• similarly, graphQL could be used but it's not in the spec

Paul Church (Jan 22 2020 at 23:07):

These are not particularly good alternatives - I think the future development and adoption of GraphDefinition would be very useful but we're not there today. Not to speak for everyone, but my impression is that most implementers consider _include to be the best option even if it leads to such elaborate queries as the one quoted above.

Igor Sirkovich (Jan 22 2020 at 23:34):

I agree with Paul. I would like to use GraphDefinition or graphQL, but we are not there yet from the development & adoption perspective. I would prefer to avoid using Patient/$everything as this might have too many implications and expectation gaps. Multiple "_include"s is not pretty and not perfect, but I believe it's the most practical option at this point and is supported by most open source libraries.

Michele Mottini (Jan 23 2020 at 04:59):

Most existing servers do not support _include, so clients (like ours myFHR app) are not designed to use it and rely on doing search by patient - so having a search by patient for all resources would be better, it would match what existing servers do for other resources

Josh Mandel (Jan 23 2020 at 05:02):

I strongly agree with Michele's perspective on this. Define a "basic" approach with limited API surface area, similar to US Core. Then (or optionally) define support for Batch or _include or _graph etc, as a performance enhancement.

Josh Mandel (Jan 23 2020 at 05:03):

But let's make sure the simple thing works.

Igor Sirkovich (Jan 23 2020 at 06:49):

@Josh Mandel @Michele Mottini, my concern is that defining Coverage search for the current release at this stage might complicate things rather than simplify them. Technically, from the FHIR perspective, it's a minor update - just declare support for an existing search parameter in the CapabilityStatement. But my understanding is that the use cases for searching Coverage independent of EOB are not defined for the current scope of CARIN BB.
Do we know what would be the expectation of a consumer app? Some app developers might assume they get just one Coverage for a Patient, but a Patient might have one current personal coverage, one current spouse's coverage and multiple historical personal and spouse's coverages.
On the other end, health plans might not currently store all the historical coverages in a retrievable form - these might be stored in the context of the adjudicated claims / EOBs. But even health plans that do have easy access to historical coverage, might not know the current coverage if no claims have been adjudicated against this coverage yet.
Just to clarify - I don't say that CARIN BB shouldn't support searching Coverage by patient. I just think that this might need to be addressed in the next release to allow more time for proper analysis and consultations.

Michele Mottini (Jan 23 2020 at 06:56):

The existing CMS BlueButton supports it: https://bluebutton.cms.gov/developers/#core-resources - that likely means that existing apps rely on it

Michele Mottini (Jan 23 2020 at 06:58):

(deleted)

Igor Sirkovich (Jan 23 2020 at 08:07):

My understanding is that the definition and management of coverage by health plans is different from CMS. So this probably emphasizes my concern about app's expectations.

Pat Taylor (Jan 23 2020 at 14:59):

The scope defined Monday is that the CARIN BB API service is an EOB service, not a Coverage or Patient service that are independent of the EOB. Providing an independent Coverage or Patient service would expand the scope; these capabilities can be addressed in future CARIN releases.

The requirement is that EOBs should be returned for a five year span of time. EOB.insurance.coverage resolves the question of, “What insurance covered this claim as of date the service took place?” 

The question, “what is your insurance coverage?” is a different question and one that results in an answer that spans and may change over time. Various scenarios need to be considered. Commercial Payer’s coverage data may span several employers or there may be gaps if an employer uses a different payer.

Patients may span multiple Subscribers in Coordination of Benefits situations, or have multiple employers over time and therefore have multiple Subscriber IDs with different coverages, or move from a dependent to a subscriber when they turn 18 and get a job. Patients transition from employer coverage to individual policies or Medicaid, or from commercial coverage to Medicare Advantage or Medicare / Medicare Gap. These situations would need to be considered when designing a Coverage or Patient search independent of the EOB.

@John Kelly

Josh Lamb (Jan 23 2020 at 16:08):

What is the consensus on includes for the resources that support EOB? Should these be mandatory, optional, or not not mentioned in IG? The US Core IG only requires support for revInclude on Provenance:target, but it does specify some SHOULD includes for other resource types.

Think most of the debate of support for Coverage search is based upon the CMS bluebutton implimentation, where they support 3 searches (https://sandbox.bluebutton.cms.gov/testclient/). The ability to search Patient should not be up for debate since its an id search, e.g. Patient/123, and it will be required since it will be referenced within EOB directly.

What about defining client / server interactions in terms of persisting data on the users device and responsible API usage, here is the guidance from CMS bluebutton:
"Your use of the Blue Button 2.0 APIs will be subject to certain limitations on access, calls, or use as set forth within these Terms or otherwise provided by CMS. These limitations are designed to manage the load on the system, promote equitable access, and prevent abuse, and these limitations may be adjusted without notice, as deemed necessary by CMS. If CMS reasonably believes that you have attempted to exceed or circumvent these limits, your ability to use the Blue Button 2.0 APIs may be temporarily or permanently blocked. CMS may monitor your use of the Blue Button 2.0 APIs to, for example, improve the service or to ensure compliance with these Terms."

Igor Sirkovich (Jan 23 2020 at 16:36):

@josh lamb , I think this would be helpful to have a performance recommendation (best practices) in the IG. However, I'm not sure if this should be as prescriptive as the CMS one. The main difference is that CMS spec is tightly tied to one API implementation while CARIN BB is a more broad spec that is supposed to be used by many different API implementations, which might have varying degree of scalability and performance capacity.

Pat Taylor (Jan 23 2020 at 19:13):

@josh lamb , To your point, the ability to search Patient is not up for debate since its an id search, e.g. Patient/123, and it will be required since it will be referenced within EOB directly. The push back is a search for Patient outside of the EOB.

Josh Mandel (Jan 23 2020 at 20:36):

Technically you can simply read a patient without having to be able to search (e.g., GET /Patient/123 is a FHIR read interaction, not a search interaction; a search would be GET /Patient?_id=123)

Josh Mandel (Jan 23 2020 at 20:37):

Definitely should define support for read, and I would recommend including search as well.

Josh Mandel (Jan 23 2020 at 20:39):

regarding coverage search, I feel like I must be missing something. Searching for the coverage resource by patient would be a way to answer the question "what coverages has this patient had, now and in the past"?

Josh Lamb (Jan 23 2020 at 22:59):

@Josh Mandel , i think the hesitance to include patient and coverage not tied to an EOB is related to the CURES act proposed rule. The section of the rule that I think this IG is meant to address does not mention patient or coverage data. Section III of the CURES act specifies the following:
"Under our proposal, the scope and volume of the information to be provided or made accessible through the open API would include: Adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where available). ". Someone please correct me if I am wrong.

Ricky Bloomfield (Jan 24 2020 at 00:25):

@josh lamb @Josh Mandel That may be true, but as we've discussed, this guide will need to be flexible enough to handle use cases that may not be explicitly defined by Cures or anywhere else. Defining these basic server interactions will set the foundation for the experiences. We've discussed in our meetings that while support for standalone Coverage isn't an explicit goal, this guide should also not prohibit it by payers who are interested in making it available.

Paul Bastide (May 27 2020 at 15:38):

Hi, I've been using Carin BB Profile for a bit, and notice a a conflict with the profile specific search parameter with code status and the base search spec ExplanationOfBenefit status, one uses data, and the other uses token. Is this as expected? it seems a strange mutation of the type. I also created https://jira.hl7.org/browse/FHIR-27738 (just in case)...

Igor Sirkovich (May 27 2020 at 15:56):

This Search Parameter is for "created", not for "status", but it has a typo: "code": "status" should actually be "code": "created". I've added a comment in JIRA, even though all search parameters are going to change in a new version of CARIN BB IG.

Paul Bastide (May 27 2020 at 15:59):

Thanks Igor for the insight

Lee Surprenant (May 27 2020 at 17:28):

@Igor Sirkovich I'm confused about why this IG is re-defining/re-distributing SearchParameters that are already in the base spec. Can it just point to the SearchParameter uris from its CapabilityStatement instead of repackaging them?

Igor Sirkovich (May 27 2020 at 17:31):

My understanding is that the goal was to just show a couple of examples of search parameters as a placeholder for the real search parameters expected in the next version.

Jason Teeple (May 28 2020 at 14:48):

Is there a pre-read on the "new" search parameters? I remember this document from the connectathon:
https://confluence.hl7.org/pages/viewpage.action?pageId=82911348&preview=/82911348/82911352/CARIN%20BB%20RESTful%20API%20Combined%20-%20FHIR-26702%20-%20FHIR-26693%200513%202020.docx

Jason Teeple (Jun 02 2020 at 00:46):

Jason Teeple said:

Is there a pre-read on the "new" search parameters? I remember this document from the connectathon:
https://confluence.hl7.org/pages/viewpage.action?pageId=82911348&preview=/82911348/82911352/CARIN%20BB%20RESTful%20API%20Combined%20-%20FHIR-26702%20-%20FHIR-26693%200513%202020.docx

@Ryan Howells sorry that I keep tagging you - but would you be able to help provide an answer?

Josh Lamb (Jun 02 2020 at 13:23):

@Jason Teeple The document you linked is not yet reflected in the IG. We are in the process of finalizing the details surrounding search but that document still reflects the current intent.

Lloyd McKenzie (Jun 02 2020 at 13:51):

Can someone here please respond to this Stack Overflow query (which is search parameter related): https://stackoverflow.com/questions/62144768/fhir-coverage-resource? In general, when skimming through the IG, it seems to be missing CapabilityStatements for client and server and a clear description of the interactions and search parameters to be supported as well as an explicit description and examples of the business flow.

As an aside, best practice for IGs is to support navigation via hyperlinks within the narrative of the IG (especially from the home page). Readers should not have to click 'next' and 'previous' or use the ToC to navigate through the IG as though it were a PDF.

Lloyd McKenzie (Jun 02 2020 at 13:52):

(i.e. it should still be possible to navigate the IG if the next/previous links and ToC link were removed.)

Amol Vyas (Jun 02 2020 at 14:35):

Lloyd McKenzie said:

Can someone here please respond to this Stack Overflow query (which is search parameter related): https://stackoverflow.com/questions/62144768/fhir-coverage-resource?

Thanks for letting us know, Lloyd. I have responded to that Medicare-related question.

Jason Teeple (Jun 02 2020 at 14:42):

@josh lamb Is the previously linked document the best source for search, instead of using the IG?

Josh Lamb (Jun 02 2020 at 14:47):

@Jason Teeple the linked document is more of an FYI to garner feedback until the IG is updated with the workgroups decisions on how search will function. I would not finalize a search implementation until the IG is published.

Jason Teeple (Jun 02 2020 at 15:00):

When is the next IG going to be published?

Michele Mottini (Jun 02 2020 at 16:38):

@Jason Teeple are you implementing a server? If so - start implementing just the patient (and possibly _lastUpdated) search parameter, those are going to stay and is what most app will use

Jason Teeple (Jun 02 2020 at 17:08):

This is all tied to the Patient Access regulations. We have a team building out the server and we are getting hung up on the search features.

Bhanu Vemuri (Jun 03 2020 at 20:34):

Do any know patient access API require payers to send claims/encounter data with date of service from 01/01/2016 to the current date of request? or CMS meant to say only last 5 years from current date? Final rule does have hard coded date as "on or after 01/01/2016" and not any reference to last 5 years. We are concerned about size of data over time that we need to exchange and would like to hear from what others planning to implement.

Below is the excerpt from CMS patient access final rule.

"Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. We are requiring that beginning January 1, 2021, impacted payers make available through the Patient Access API the specified data they maintain with a date of service on or after January 1, 2016. This is consistent with the requirements for the payer-to-payer data exchange detailed in section V. of this final rule. Together these policies facilitate the creation and maintenance of a patient’s cumulative health record with their current payer."

Ryan Howells (Jun 03 2020 at 21:55):

Hi @Bhanu Vemuri : On our last CARIN community call on 5/28, CMS verbally confirmed health plans must provide claims data to their member via the Patient Access API with DOS of 1/1/2016 up to the current date of the request via the Patient Access API. Reference Slides 8-12 in the attached presentation for this clarification. We've also addressed other misconceptions we've heard from health plans in the slide deck. We will be posting this deck on our website in the days ahead. CARIN_community_meeting_05282020_v3.pdf

Bhanu Vemuri (Jun 04 2020 at 12:40):

Thank you, Ryan. It's very helpful. One last question on this particular topic.

Payers historically required to maintain claims data for 11 years only for non-repudiation purposes. Based on above clarification, It does require payers to keep data forever to support patient data access API. is this correct? We are planning to rely on existing operational services but those services have limitations on how far back it can extract EOB information (4 years currently) . I assume, it's a challenge for those that planning to do run-time FHIR transformation/Facade pattern. Thoughts?

Ryan Howells (Jun 16 2020 at 18:05):

It's a nuanced question. A member can request the claims and clinical information their current payer has stored in their system back to a DOS of 1/1/2016 (or for as long as that member has been a member). A member can only request their USCDI clinical data from a previous payer (payer-to-payer) for up to 5 years from the time the member disenrolls in their previous payer's plan. So technically, a payer could delete the USCDI clinical data they have stored in their system once a member has been disenrolled for 5 years but we (CARIN) hope they don't do that. Having the data available to the consumer forever, as you indicate, is clearly better for the individual.

Bhanu Vemuri (Jun 18 2020 at 12:28):

Below is the additional clarity provided by Denise St Clair (CMS Health Policy Team)

"If a member stays with an insurer until 2030 and requests their data via the Patient Access API in 2030, and has been a member since 2014, the expectation is the insurer would make the patient's data from 2016 through 2030 available. "

Mark Roberts (Jun 18 2020 at 22:07):

The below search parameter document represents the agreement of the CARIN Workgroup and FM co-chairs regarding the search parameters, payer requirements to provide data for reference resources (i.e., is it to be provided as of the date or service or as of the current date), and how payers will return data bundles in response to requests.

CARIN-BB-RESTful-API-Combined-FHIR-26702-FHIR-26693-0617-2020.docx

Paul Church (Jun 18 2020 at 23:51):

Note that service-date is not the only additional search parameter defined by this IG - EoB.type is also not a standard search parameter.

Abhishek (Mar 01 2021 at 19:42):

Pat Taylor said:

The scope defined Monday is that the CARIN BB API service is an EOB service, not a Coverage or Patient service that are independent of the EOB. Providing an independent Coverage or Patient service would expand the scope; these capabilities can be addressed in future CARIN releases.

Is the above comment explicitly stated anywhere in the IG or any other official channel? Looking for something to reference in our documentation that justifies why we implemented this way.

Also, does this mean that endpoints like the following don't need to be supported?

GET [base]/Coverage
GET [base]/Patient

@Pat Taylor

Michele Mottini (Mar 01 2021 at 19:55):

They need to be supported but without search - they are used only to access resources by id

Abhishek (Mar 01 2021 at 20:05):

Michele Mottini said:

They need to be supported but without search - they are used only to access resources by id

@Michele Mottini thanks so to be more explicit:

GET [base]/Coverage/[id] but NOT GET [base]/Coverage
GET [base]/Patient/[id] but NOT GET [base]/Patient

right? We do not have to support endpoints without an identifier?

Michele Mottini (Mar 01 2021 at 20:16):

Correct - nor you have to support any other search parameter (note that that's called an id, not an identifier)

Abhishek (Mar 02 2021 at 21:51):

Gotcha, thanks @Michele Mottini !

Pat Taylor (Mar 02 2021 at 22:03):

@Abhishek see http://hl7.org/fhir/us/carin-bb/Background.html#us-core; http://hl7.org/fhir/us/carin-bb/CapabilityStatement-c4bb.html

Abhishek (Mar 02 2021 at 22:47):

Thanks @Pat Taylor !

Caitlin Ryan (May 12 2021 at 21:45):

@Pat Taylor @Michele Mottini
The language below is listed on the Guidance page under section 4.5:
"Conformance to US Core Profiles

Any actor acting as a Health Plan API actor in this IG SHALL:
(bullet 2) Conform to the US Core Server Capability Statement expectations for that profile's type."

It says the same for actors acting as a FHIR Client.

The way I am reading that implies that the C4BB profiles (Organization, Patient and Practitioner) would inherit the same search parameters as US Core profiles of the same type. That seems to be contradictory to the use cases and the discussions on this string. Can you please provide some clarification. TIA!

Michele Mottini (May 13 2021 at 13:44):

The US core search parameters are designed to cover various use cases, including providers app. For pure patient apps what's needed is to be able to get the core resources (eg ExplanationOfBenefit) by patient and then the referenced resource, you do not really need any search capability on things like Organization, Practitioner, Location etc.

Michele Mottini (May 13 2021 at 13:44):

The US core search parameters are designed to cover various use cases, including providers app. For pure patient apps what's needed is to be able to get the core resources (eg ExplanationOfBenefit) by patient and then the referenced resource, you do not really need any search capability on things like Organization, Practitioner, Location etc.

Corey Spears (May 14 2021 at 14:00):

@Michele Mottini is correct about the scope and intent. The CARIN BB IG is centered around the EoB. The other information is referenced from there and only has meaning (in the IG) as it relates to the EoB.

Tone Southerland (May 17 2021 at 19:57):

Check out our white paper on Health Plan Directory! This is based on what we discussed at the last CARIN connectathon in April. Let us know your feedback, or ideas to improve so we can continue to move the needle on health plan members getting access to their data. Health-Plan-Directory-for-Consumer-Apps-Final.pdf

Pat Taylor (Jun 01 2021 at 11:45):

The CARIN BB IG speaks to this. see "Since these are supporting / reference profiles (rather than a focus profile) in CARIN IG for Blue Button®, the alignment with the US Core is on the content of these profiles, but not on the search parameters. " https://build.fhir.org/ig/HL7/carin-bb/1_Background.html#relation-to-other-IGs

---

Last updated: Apr 12 2022 at 19:14 UTC