FHIR Chat · Example API Call · CARIN Benefit Check IG

Stream: CARIN Benefit Check IG

Topic: Example API Call

Notification Bot (Sep 11 2019 at 18:03):

Josh Mandel renamed stream #CARIN Real-time Pharmacy Benefit Check IG to CARIN Real-time Pharmacy Benefit Check IG.

Josh Mandel (Sep 12 2019 at 16:45):

For this weekend, here's an example of how @Patrick Murta's server at Humana is looking for inputs:

https://gist.github.com/jmandel/5f0f5a6e7967f4a3319f4e0906a9a623

Josh Mandel (Sep 12 2019 at 16:47):

(OK, I udated that gist with a full API call -- request + response).

Josh Mandel (Sep 12 2019 at 17:00):

Reviewing this request, it seems to have a lot of information (E.g., pricing, coverage) that a client app wouldn't likely know. And on the response: I can't tell where/how multiple fulfillment options would be represented (e.g., different pharmacies, or alternative meds).

Josh Mandel (Sep 12 2019 at 17:01):

It's also not clear to me how the actual prescription details would be conveyed (e.g., the prescription.reference in the request assumes there's a web-hosted copy of the prescription somewhere, but who'd be hosting that in real life?

Josh Mandel (Sep 12 2019 at 17:02):

(Also note there's a Coding in the request that's probably supposed to be labeled as NDC, not RxNorm:

{
  "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
  "code": "51079-456-20",
  "display": "Alprazolam 0.25mg (Xanax)"
}

Josh Mandel (Sep 12 2019 at 17:04):

The massive flexibility of these resources (and the $submit operation, which can take bundles or Claims, or Bundles of Bundles.... and can return ClaimResponses or Bundles, or Bundles of Bundles) worries me re: consistency of support, so it'll be important to have super clear IG constraints. (I also think it's worth exploring a more specific $rx-pricing operation like this mock-up).

Philips Johnson (Sep 12 2019 at 17:19):

rtpbc-request-example.json

Josh Mandel (Sep 12 2019 at 17:19):

@Lloyd McKenzie for your take on contained resources: per example from @Philips Johnson above: if a FHIR API client is making a call to an operation like $submit, and the client knows some details like a prescription or a set of patient demographics (but the client doesn't host a FHIR endpoint of its own): is it okay to use contained to capture these details, linked to from the Claim? Or better to make them siblings in a Bundle? Or would you force the client to somehow "create" them with a server, first, and then link to those freshly-created resources from the $submit query?

Philips Johnson (Sep 12 2019 at 17:19):

Above example is what we had originally put together on our side as what we expected a sample request to look like

Josh Mandel (Sep 12 2019 at 17:24):

One question that comes up comparing the dispense request: the price depends on some notion of how much stuff is being dispensed. This can be captured via NDC + quantity(e.g., for NDC code 51079-456-20, that's a 100-pill blisterpack of Simvastatin; so a quantity of 2 would be 200 pills), or by tablet quantity (e.g., you could specify a number of pills) or by days supply -- and we've seen a combination of all of these in the two example requests so far. What's most important? Do we want a standardized way to convey all three?

Josh Mandel (Sep 12 2019 at 17:27):

My preference would be to rely on the MedicationRequest to convey this information, since it has a nice way to model product + dispense quantity + expected days supply.

Josh Mandel (Sep 12 2019 at 17:28):

Though even this doesn't quite get at the distinction between # of packs/bottles of pills vs # of tabs -- like for

      "medicationCodeableConcept": {
        "coding": [{
          "system": "http://hl7.org/fhir/sid/ndc",
          "code": "51079-456-20",
          "display": "Simvastatin 40mg tablet 100 blister pack"
        }]
      },

You can specify either TAB or else (presumably) # packs, but you have to pick just one of those for your dispenseRequest:

      "dispenseRequest": {
        "quantity": {
          "value": 100,
          "unit": "tablets",
          "system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
          "code": "TAB"
        },

Philips Johnson (Sep 12 2019 at 17:30):

I agree w/ @Josh Mandel that piggy backing the MedicationRequest object is probably best here

Josh Mandel (Sep 12 2019 at 17:33):

And generally when I look at a block of supportingInfo like this -- I see an ad-hoc data model creeping into the Claim (challenges: it's verbose and also hard to express constraints to pin this down). I suspect it'd be better to re-use existing resource definitions, or call out these parameters explicitly in the operation itself, rather than baking into Claim.

Lloyd McKenzie (Sep 12 2019 at 21:33):

"contained" resources are not for packaging. So the question is: Would you expect the resources to be represented as 'contained' if the resource was stored on a server somewhere? For a patient to be 'contained', it would mean that you don't have enough information to point to a specific patient in a registry somewhere (e.g. all you've got is a gender and birth year). In the case of doing claims processing, that should presumably never be the case. (Unless you have payers who pay for coverage for anonymous patients maybe?).

The 'pure' RESTful way to handle this related data scenario is either:
a) first look up the patient on the payer system and then point to the payer's patient record as part of the claim; or
b) point to the provider's patient and the payer can come query it if they don't recognize the URL (a one-time process where they establish the link to the provider's id)

An alternative (and slightly harder/clunkier) but still valid RESTful way of doing this is to send the claim as part of a "transaction" bundle where the reference to the Patient (or other resources) are expressed as a conditional link - which is essentially a query.

However, if you're doing an operation, then the simplest think is to just package everything into a Bundle and define the semantics of the $submit operation to be that you should 'match' on the referenced subject and practitioner records and 'create' the supporting info and other information.

Josh Mandel (Sep 12 2019 at 23:36):

first look up the patient on the payer system and then point to the payer's patient record as part of the claim; or

For the patient, this might be possible; for the "prescription" (drug/dose in question, and dispense quantities, etc), it doesn't exist in the payer's registry anywhere. And what you call the "provider" isn't an actor in this exchange (it's just a client-side-only consumer app making the request), so we can't necessarily look things up in the "provider's system".

Josh Mandel (Sep 12 2019 at 23:36):

Also for an operation, why do you say Bundle @Lloyd McKenzie rather than named resource-type parameters?

Josh Mandel (Sep 12 2019 at 23:37):

(I don't think any "creation" is expected here on the side of the service providing pricing information. It's just a transient query and from the perspective of data minimzation, it'd be better not to store information beyond the scope of the query.)

Lloyd McKenzie (Sep 13 2019 at 00:25):

I believe the Claim/$submit operation is set to process a Bundle that contains a claim and related information. Given that the relationships are asserted by the claim, breaking them into separate parameters seems unnecessary (and a bit heavier too). If you're not using that and don't have a single resource that ties everything together, separate parameters are appropriate.

Josh Mandel (Sep 13 2019 at 01:56):

Cool, okay -- that's consistent with how I was looking at things. (I am thinking the existing $submit operation kind of obscures what's going on.)

Matt Printz (Sep 13 2019 at 13:22):

From the above, I'm reading that the plan going forward will be that the request from b.well will be a bundle that includes a single claim and whatever related objects are needed as part of the bundle and that the contained parameter won't be used. (That was my initial inclination, but from the documentation I saw it was not clear how/if Claim/$submithandles bundles.)
Does that sound right to everyone?

Patrick Murta (Sep 13 2019 at 13:23):

We can discuss the use of medicationrequest and other resources during our sessions in Atlanta. We are ready to continue with claim and claims response with updated logic. All 5 scenarios per the spreadsheet are ready with the previously submitted $claim Humana endpoint.

We have provided a simplified request example since most of the information in the original one posted is not used in the processing and seemed to imply that we needed it. We are really only using patient, provider, pharmacy, and NDC. Example request and response for scenario 1 is attached.

claimresponse.txt claim.txt

Patrick Murta (Sep 13 2019 at 13:25):

Seems like operationoutcome is the appropriate response for member not found so we plan to implement that today.

Matt Printz (Sep 13 2019 at 13:28):

@Patrick Murta Thanks for the updated documents. In claimresponse.txt I'm not seeing the GoodRx cash pricing included. Is it still part of the plan to include that info?

Patrick Murta (Sep 13 2019 at 13:37):

That information should come from the GoodRx service, I believe. Spoke with Philips and Kristen a bit on that yesterday. Also, I have attached the updated Pooja spreadsheet to include member ids on our FHIR server so that you don't get a patient not found error. Column G in spreadsheet.
Sample-Data-for-Consumer-RTPBC-Transaction-with-Payer-Member-IDs.xlsx

Josh Mandel (Sep 13 2019 at 13:58):

Can someone help me understand the difference between items and addItems? In the example claim response I see a $25 copay in each.

Josh Mandel (Sep 13 2019 at 13:58):

(Also for spreadsheets that might change over time, It would be good to put them in a collaborative editor so people are always looking at the latest.)

Matt Printz (Sep 13 2019 at 13:58):

@Patrick Murta I'm a little confused by something. In our system we created two users, John and Jane Doe, and the expectation in our system is that they'll have a single external member id per the patient, not per the medication. So we were expecting to have just, say, id1 and id2 and with the 2 RXs for id1 and 3 RXs for id2. Instead it looks like the member id changes for each RX. Can you confirm?

Matt Printz (Sep 13 2019 at 15:04):

@Patrick Murta I'm getting a "NDC Not Found" operation outcome response when trying to look up Repatha. So far, this is the only drug I've seen this for. I've confirmed that the NDC I'm sending matches the spreadsheet and the actual NDC for Repatha.
Request and response attached.
Repatha_request.txt Repatha_response.txt

Pooja Babbrah (Sep 14 2019 at 13:23):

@Patrick Murta This is a biologic/biosimilar. I was curious what the response would be with these types of drugs which is why I chose this one. Any additional feedback on this one from your end yet?

Patrick Murta (Sep 14 2019 at 13:32):

Just talked to Philips and we are going to go through each issue at table 10. We are talking now if you want to join..

Philips Johnson (Sep 14 2019 at 13:54):

All - We're going to use NDC 55513-760-02 for Repatha

Patrick Murta (Sep 14 2019 at 14:06):

Thanks Philips. Here are the updated Member IDs correcting the issue with the same member having multiple IDs in the spreadsheet:
FN LN DOB Gender Zip Member Id
Jane Doe 7/15/1935 F 85251 Id1
Jane Doe 7/15/1935 F 85251 Id1
John Doe 7/15/1935 M 85251 Id2
John Doe 7/15/1935 M 85260 Id2
John Doe 7/15/1935 M 85260 Id2

Mike Berkman (Sep 14 2019 at 15:04):

@Patrick Murta it looks like your validation of the NDC requires dashes. we dont typically see the NDCs coming in with dashes. is this something that could be relaxed? are you doing an exact match in this example api?

Douglas DeShazo (Sep 14 2019 at 15:53):

@Mike Berkman Hi Mike, we are using the actual NDC codes themselves which do include the dashes.

Patrick Murta (Sep 14 2019 at 17:33):

Hey @Mike Berkman , per Doug's note, we use the dashes since those are the official representation. Hopefully, that is not a big issue for you.

Patrick Murta (Sep 14 2019 at 18:09):

The follow items have been mitigated and deployed to the Humana testing endpoint:

Patrick Murta (Sep 14 2019 at 18:11):

Connectathon22FHIRIssues.xlsx

Mike Berkman (Sep 14 2019 at 18:53):

all good, thx!

Last updated: Apr 12 2022 at 19:14 UTC