Patient Identifiers

[Luke]

I saw in the "Sample Patient FIHR Resource" a hash of the patient's HIC number will be provided (http://bluebutton.cms.hhs.gov/identifier#hicnHash).

Knowing that HIC numbers can change over time, will the response include hash of previous HIC number as well, or only the hash of their current HIC?

Anything you can share regarding support of Medicare Beneficiary Identifier (MBI)?

Thank you!

[Karl Davis]

Luke,

Great questions!

I saw in the "Sample Patient FIHR Resource" a hash of the patient's HIC number will be provided (http://bluebutton.cms.hhs.gov/identifier#hicnHash).

Knowing that HIC numbers can change over time, will the response include hash of previous HIC number as well, or only the hash of their current HIC?

I'm actually thinking that including the HIC hashes at all in our API's responses was a mistake. Do you have a compelling use case or need for them that'd help me justify leaving them in? (We need them internally, and exposing them externally should be safe, but it doesn't sit quite right with me, either.)

Anything you can share regarding support of Medicare Beneficiary Identifier (MBI)?

The API should continue to work just fine throughout the transition that Medicare is making from HICs to MBIs. We don't have any plans to expose MBI's (or hashes thereof) to application developers. Again, please let us know if you have a compelling use case for this, so we can reconsider if needed.

(Apologies for the very delayed response. Things have been a bit... exciting with our production launch. ;-) )

Thanks for asking!
Karl M. Davis

[Luke]

No worries about the delayed response, I totally understand :)

My use case is for patient matching. I'm more in the context of Bundled Payments Programs (BPCI/BPCI-A and especially OCM).

For example, in OCM, figuring out exactly when an oncology episode start (and therefore the initiator of the episode) is very important.

CMS does provide patient claim data as part of the OCM (or any other Bundled Payments) program, but there's run-out, program specific delivery timeframes, and sometimes delays.

The benefits here for beneficiaries (under consent) are through helping care providers manage an accurate and up-to-date episode of care as part of those new CMS initiatives.

Blue Button seems like a good way to get more "real-time" patient claims to accomplish this. But if I can't match a Medicare beneficiary, I can't help providers in their respective bundled payments programs.

Does that make sense?

Thank you.

[Luke]

Any feedback on that? Will HIC/MBI still be part of the API response?

Thanks.

[Ma...@ekivemark.com]

The Hash value is only used internally for beneficiary matching. The HicnHash is planned to be removed from the Patient record and should not be relied upon as a method of matching beneficiaries outside of CMS. This is especially true since HICN and MBI numbers can change for a beneficiary over time.

[Luke]

So you're saying my use case is not compelling then and won't reconsider?

[Kelly Taylor]

Hey Luke,

I'll connect you to the team working with ACOs to go deeper on this thread.

[karl....@cms.hhs.gov]

Luke,

Also:

Since you can't go from HICN-hash --> HICN, and since that value won't be available in any other systems, I don't know think they're a great choice for patient matching across systems.

If, however, all you need is a stable identifier for each beneficiary in our system, you can and should use the Patient.id field. Unlike HICNs/MBIs, this should be stable over time for any given beneficiary. (It turns out that HICNs and MBIs actually change surprisingly often.)

Just a suggestion, though.

Best regards,
Karl M. Davis

[Luke]

Thank you both.

While we can't go hash --> original, we can hash HIC we have (when/if we have them) and match the hash values (and when allowed to, DUA-wise). We would need to know the hash function though. We do have a problem of "universal patient id" (who doesn't?), or even identifier consistencies (HIC in someone's EMR may not be the same as the HIC coming from claims from CMS for some time for example). Just trying to do our best with what we have :)

This is very much in early stage on our side, still need to flush things out, so I'll be happy to connect with the team working with ACOs.

[Luke]

Karl, you mentioned Patient.id field.

Would that value be the BENE_ID from CCW (https://www.ccwdata.org/web/guest/faq) or something internal to BlueButton?

[Modi Boutrs]

Seeing the thread, we are looking to do patient matching with our EHR system. Since our app facing is patient portal and we like to do SSO within the portal and CMS site after doing a check.  Since HICN is not included. Do you recommend we just do first name, last name, gender, dob ?  is that sufficient?

On Wednesday, April 4, 2018 at 12:30:11 PM UTC-4, Luke wrote:

[karl....@cms.hhs.gov]

Luke,

> We would need to know the hash function though.

Our hash is salted, so you would not be able to reproduce it.

> Would that value be the BENE_ID from CCW (https://www.ccwdata.org/web/guest/faq) or something internal to BlueButton?

Yes.

Best regards,

Karl

[karl....@cms.hhs.gov]

Modi,

I'm not sure I correctly follow how your proposed use case would work, but regardless, no: you cannot assume that a patient's name+gender+DOB represents a unique identifier. A surprisingly large number of folks share the same values for those things.

I'd suggest you read up on "patient matching" and approaches to it. I am not in any way an expert on that subject, myself, but I do know that it's a well-studied problem.

Best regards,

Karl

[Ma...@ekivemark.com]

Modi,

Forgive me if this is a dumb question....

If in your app the beneficiary is connecting to Blue Button and authenticating with Medicare. You can obtain the FHIR Patient ID. As Karl Davis points out, that should be stable in our system. If your users are also connecting to your Patient Portal and authenticating there can't you register the FHIR ID in the patient's portal account? ie. Let the patient help you with the matching.

Regards

- Mark Scrimshire

Blue Button 2.0 Team

On Thursday, August 16, 2018 at 12:39:20 PM UTC-4, Modi Boutrs wrote:

[Modi Boutrs]

Before I link the account fhir id from CMS and Patient ID from Portal, i need to ensure patient returned demographics are same as patient logged in the portal. Otherwise, I risk linking to wrong account.

[karl....@cms.hhs.gov]

Modi,

I feel like I'm missing something here. Here's the workflow it sounds like you're describing:

1. Patient logs into your portal as themself.
2. Patient clicks the "Connect with Blue Button 2.0" (or whatever) button that you're adding to that portal.
3. Patient logs in to MyMedicare.gov using their login and consents your portal to access the BB2 API on their behalf.
4. You then want to verify that you got the data for that patient and not some other patient?

Step #4 doesn't make much sense to me: the patient logged into both your portal and BB2/MyMedicare as themselves. So why not trust that they are themselves and linked up the right data?

Apologies if I'm misunderstanding here: please help me understand.

Best regards,

Karl M. Davis

Blue Button 2.0 API, Engineering Lead

[dan.si...@cloverhealth.com]

Hi Karl, I'm not the original poster, but I have the same concern, and perhaps I can clarify what I think Modi was worried about.

The 4-step process you outline above would be the happy path, but what if there's a different person who completes step 3.

ie:

1. Patient logs into my portal as themself

2. Patient clicks the "Connect with Blue Button 2.0" (or whatever) button that you're adding to that portal.

3. **** Another patient logs in to MyMedicare.gov (perhaps their spouse for example), and consents my portal to access the BB2 API

4. Since there's no way to verify the code we get back is related to a particular patient's data (via HICN or something), in this case we would wrongly attribute one patient's claims with a different person.

Hope that makes sense, happy to clarify further.

thanks!

Dan