Add support for Medipass RefID

[gittycat]

The current Patient, Practitioner and other resources have only your db assigned "id". There is a need for these resources (and possibly others) to hold other types of identifiers so that they can be matched across systems.

Use Case: We have a system that will get customers to enter their CC payment info into Medipass. Medipass returns us a RefID to uniquely identify the customer in their system. By being able to pass this RefID to Cliniko using your patient API, and Cliniko using it with Medipass, the practitioner wouldn't have to enter the CC data manually a second time. Attempting to match Medipass customers using fuzzy searches on names, dob, medicare number is fraught with errors (that's coming from Pete Williams at Medipass btw).

FHIR supports multiple Identifiers for their resources using an array.

Thanks Bernard Duchesne Healthe Care

[bpinto]

Hey @gittycat,

we have been working on the medipass integration for some time now, and if I understood correctly, we cannot support what you want at this moment.

For the same reasons you mentioned (matching customers by names, dob, etc) we built our integration with medipass by having Cliniko as the source of truth. In addition to that, we have not worked on integrating payments with medipass yet.

[gittycat]

Hi @bpinto, Yes, I'm aware that you were working on your Medipass integration. That's partly why I posted this.

I've had a talk with Peter over at Medipass (tech co-founder) and the only reliable way to match the same customer entered through different means in Medipass is through their "RefID". Cliniko doesn't store credit card info, so in that respect Medipass or other payment gateways are the Source of Truth for some of a patient info.

We will have patients with payment info in Medipass already. We are searching for a PMS solution like Cliniko that integrates with Medipass by passing this RefID. That way, Medipass will match Cliniko's patient with an existing customer payment info. The end result is no need for the practitioner to ask the customer a second time for payment info when billing in Cliniko via Medipass. I hope this makes sense.

On you end, this would require adding a field to your Patient API. Or if you want to be more flexible and do like FHIR did, make it an key/value pair that can accept multiple Id's for different systems. It is a flexible pattern when integrating different systems which each create their own ID's. It would also require you to pass that RefID to Medipass when a request is made, if it is present in the patient resource.

I realise that this requires a db schema change on your side, so it would need to be planned for a database migration release.

[bpinto]

I understand your use case, but by opening up our medipass integration with anyone that can use the API we are doing two things that I'm not sure we would want to:

1. By having a accessible API you can use, we have to avoid backwards incompatibility and since we would be working as a gateway, we can't really have control of that API. If I understood correctly, you only need the id, but not sure if that requirement wouldn't change or perhaps other integrators would want to have more access in the future.
2. Acting like a gateway to any integration we have, in this concrete case, acting as a gateway to medipass. That would open our integration to misuses and it would be our responsibility since we are the ones doing the call to medipass. For instance, an integrator could pass a wrong RefID and we incorrectly updated that record.

I'm going to invite @bart3k to this discussion since he's the one involved in the medipass integration and he certainly will have a better understanding of this.

[jfriedlaender]

Hi Bernard,

Right now when we create the patient record in Medipass, the RefID will be our patient ID. For records in Medipass we did not create, that will not be the case, and Cliniko would never update them.

So you could look up the records in our system easily, knowing that. However it comes with a couple of disclaimers:

• It's only for records created by Cliniko.
• We have not designed this intentionally for use via the API, so cannot guarantee it's the way we integrate with them indefinitely. Changes to their integration or ours, could result in us needing to change in future.

I see what you're asking for with storing a Medipass id in our database, currently we don't have plans to do so. I think the above is the best option for now, taking note of the disclaimers.

Joel

[gittycat]

Hi Joel, Ok, so you will use Medipass' RefID as your patient ID. That avoids having to do a db schema change. I presume then that every patient in cliniko will be assigned a Medipass RefID at creation. If that's the case, this would work on our side. a) Our system: Create a cliniko patient using the API b) Our system: Call Medipass with the cliniko patient ID (which is the Medipass RefID) c) Inside Cliniko UI: Later on, a practitioner brings up the pre-filled payment info within Cliniko.

I understand the caveat about possible API changes in the future. Versioning would help with future compatibility issues. I really do appreciate that you guys published your API in the first place.

[jfriedlaender]

Hi Bernard,

I may have been misunderstood. We have a patient ID for every patient record, it's our own ID, that's created with the record, like any database record. When we create a record for the patient in Medipass, we use our ID in their RefID field.

We do not create records in Medipass when the patient is created in Cliniko, only at the time of first transaction (when needed).

As I mentioned, we cannot guarantee our patient ID will always be used as the RefID in Medipass, however that's how it operates now, and no current plans for change. If this were to change, it wouldn't be an API version change, as it's unrelated to our API.

[gittycat]

Thanks for the clarification. That makes more sense too. I'll close this ticket.