Stream: implementers
Topic: Appointment - Account
Bo Pritchard (Jul 25 2018 at 20:59):
At Appointment creation, I need to know the Account so that Coverage can be verified.
But it looks like Account doesn't exist at Appointment. Only at the Encounter.
Is there no tie between the Appointment and Account?
Brian Postlethwaite (Jul 25 2018 at 21:27):
The account(s) are linked to the patient directly. There can be multiple of these, and multiple coverages (which is what you're really looking for)
Not sure if when making the appointment you'd be doing much here other than verifying that they had one (not pre-auths etc) and when admitting (begining the encounter) the actual account/coverage selection would be finalised and created/assigned as needed
Bo Pritchard (Aug 01 2018 at 17:07):
@Brian Postlethwaite at Appointment creation I'd need coverage to check eligibility.
I don't see how to get from Appointment -> Coverage(s)
Bo Pritchard (Aug 01 2018 at 17:30):
At Appointment creation I need Account.Coverage so eligibility can be checked.
But I can't see how to get there from Appointment. Encounter has Account, why doesn't Appointment?
Lloyd McKenzie (Aug 01 2018 at 21:53):
Appointment -> Patient, Coverage -> Patient, so Patient is your linkage point. If you want filtered coverages specific for an Appointment, that would be an extension I think.
Lloyd McKenzie (Aug 01 2018 at 21:54):
Rationale for difference is that the decision of what coverages to use is typically made at the time the encounter starts because what coverages the patient has might change between when the appointment is made and when the encounter starts.
Bo Pritchard (Aug 02 2018 at 13:13):
Appointment -> Patient, Coverage -> Patient, so Patient is your linkage point. If you want filtered coverages specific for an Appointment, that would be an extension I think.
@Lloyd McKenzie I understand that you can get from Coverage -> Patient, but is there a way to get from Patient ->Coverage(s)?
Bo Pritchard (Aug 02 2018 at 13:17):
Rationale for difference is that the decision of what coverages to use is typically made at the time the encounter starts because what coverages the patient has might change between when the appointment is made and when the encounter starts.
@Lloyd McKenzie I understand what you're saying, but the use case would be:
Front desk person creates Appointment with Coverage. 3 days before appointment an eligibility check runs to verify coverage for said appointment. That way the practice has an opportunity to interact with patient about financial arrangements if ineligible. Make sense? Encounter time is too late.
Lloyd McKenzie (Aug 02 2018 at 14:08):
Patient doesn't point to Coverage. Coverage points to Patient. However, that should still let you find the Coverages for the Patient.
Lloyd McKenzie (Aug 02 2018 at 14:08):
The use-case makes sense. And you can propose a change request for a standard extension and an evaluation of whether this capability is sufficiently common to justify including in core.
Bo Pritchard (Aug 02 2018 at 14:36):
Patient doesn't point to Coverage. Coverage points to Patient. However, that should still let you find the Coverages for the Patient.
@Lloyd McKenzie So there is currently no way (extension or otherwise) to include an Account or Coverage within the Patient resource?
Brian Postlethwaite (Aug 02 2018 at 22:23):
You just query for the coverages associated with the patient (and you have the patient ID) so it looks like this
http://sqlonfhir-stu3.azurewebsites.net/fhir/Coverage?patient=5
Hélder Cunha (Jan 28 2019 at 18:07):
1. The doctor has agrees with some Insurer Companys, not all, and this create constrainst on scheduling
2. Customers can have various insurance plans, actives at the same date, and choose to use what is most conveniente in that moment
3. To refer to what insurer plan, i need to use an extension of the resource? Or i sould create a Bundle with resources Patient and Coverage?
Lloyd McKenzie (Jan 28 2019 at 21:26):
Extension to which resource? Once the visit starts, you'll have an Account to track the charges for the encounter and that Account will be tied to the relevant/selected Coverage(s).
Hélder Cunha (Jan 28 2019 at 22:30):
Extension to resource appointment. It’s before visit starts. Refer to the insurance plan on the appointment.
Martin Grundberg (Jan 29 2019 at 16:05):
Just a comment...
In our EHR we also have the ability to set an Account for who will be paying for an Encounter and the services provided within them. This can be done at the booking stage, i.e. when arranging the Appointment. Some appointments are not allowed to be made without the Account details set.
It sounds like there is a common requirement for capturing Account details on Appointment? Going through the patient is not a sufficient solution as it can be associated with multiple accounts.
Is there maybe a need for a standard extension here? Or even better, can an Account reference be included in the Appointment resource?
Lloyd McKenzie (Jan 29 2019 at 16:23):
That sounds like a good thing to submit as a change proposal - either a core element or a standard extension sounds like a good idea. @Martin Grundberg can you submit a change request?
Martin Grundberg (Jan 30 2019 at 09:51):
@Lloyd McKenzie , sure, is this the correct place? https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677
Lloyd McKenzie (Jan 30 2019 at 15:42):
Yes
vania manzelli (Feb 01 2019 at 17:04):
Hi Martin, also in our Italian scenario we need to track the kind of Payment for the encounter (Patient's Private Insurance or some NationalProgramme), which is the old HL7 v2.x field FinancialClass. This information, as well as the Nhspriority and the prescriptiontype impacts in the scheduling business logic 'cause they can enable some "reserved" availabilities in slots. For this reason in our FHIR server we added FinancialClass, NhsPriority and NhsPrescriptionType as extensions for Encounters and ServiceRequest. We hope this suggests will be accepted and integrated in the canonical resource and in case it will not we will try to define an Italian Profile in order to include this attributes.
Last updated: Apr 12 2022 at 19:14 UTC
