Facility, Billing location and POS Issues

[sjpadgett]

Describe the bug

see forum https://community.open-emr.org/t/pos-problem/9468/

This entire process is off imo, which I want to see fixed once and for all time.

• Default facility should be users assigned facility else error and force facility assignment in Users.
• Billing facility should default to user facility if a billing location else first facility flagged as business entity.

Expected behavior

Currently unsure! Big question is should POS track with selected facility or selected billing facility???

Client configuration

• Browser:
• Operating system:

[stephenwaite]

thank you @sjpadgett ,will be playing with both the latest 5.0.2 and dev demos and will be glad to help you define these properties so can make sense of the situation for billing purposes

The most common situation is 1 facility but also very likely many have a billing group that would be the Primary Business Entity.

Accepts Assignment should be triggered when slide the toggle on Billing Location.

POS Code should only be for service facility so should not be looking at Billing Location.

[sjpadgett]

Okay so Accept Assignment is broken from POV it is allowed in UI if a billing location is not selected. Should grey out otherwise. Default billing location in order of precedence should be:

• Users facility if billing facility
• then billing facility marked as PBE.
• else first billing facility
• else selected facility

Otherwise current workflow works as needed. E.g POS tracks with selected facility, ageed?

[stephenwaite]

Billing Location is given to much prominence. Should use Primary Business Entity instead. Billing Location should only be used when there's a billing office that has a PO Box where they would like to receive mail. This is all coming from my understanding of X12837. The Primary Business Entity should have to be selected (an actual address would have to used, not a PO Box) and then could remove any mention of billing from the encounter. What should be on the encounter page is the rendering provider.

[stephenwaite]

Following up on this is that if a provider does not create the encounter then there's no way to assign a provider to the encounter without going to the db. The work around for billing is to select it in the fee sheet.

So a service facility could be selected based on the rendering provider's (user's facility) but should default to the appointment facility.

[sjpadgett]

Very useful! Thank you...

[stephenwaite]

Finally, without creating to huge of a :mount_fuji: for you to climb, a service location when created could be tied to the primary business entity and optionally a billing location.

[sjpadgett]

Finally, without creating to huge of a 🗻

I carry a step stool around for this purpose.:)

We're here to finally get this workflow correct for our current day requirement so, we expect 🗻

[sjpadgett]

So a service facility could be selected based on the rendering provider's

yep, this has always been an issue. Good solution!

[sjpadgett]

Can anybody tell me if there was a legal issue with not allowing a provider/user selection in encounter creation?

[sjpadgett]

@stephenwaite I'm looking to put this in patch(3) then circle back to v5.0.3.

I just finished adding following work flows:

• On auto encounters create, the selected appt fac POS is now set in encounter
• Same with user where previously we set encounter provider to logged in userauthorized. Now is set to appt provider(if authorized and active).
• On new encounter create, user can now select the provider responsible for encounter.(only way I could think of to get close to rendering provider)
• Default Billing Location sets to Primary Business Entity if not, then first billing location. (will qualify first with P.O box). Globals dictate to use accept assignment(legacy).
• For manual encounters, POS tracks with selected service facility or default user facility.
• log any user provider changes in encounter. ie implement better logging for encounters both, JS or PHP changes. I'm surprised we haven't been called out on this but, I believe @robertdown attempted to point this out in past. I'm unsure how detailed encounter history needs to be ie audits etc!

for you to climb, a service location when created could be tied to the primary business entity and optionally a billing location.

This i'm mulling over. For patch 3, would require several table changes which i'm not sure I want a patch to be that disruptive. However, if deemed important by our users, i'd give it a shot. For sure will get in v5.0.3.

Hope i'm not bugging ya to much with this but, I can only use deductive reasoning as to how these workflows should work in real world.

[stephenwaite]

sounds terrific @sjpadgett , be glad to assist, thank you

[sjpadgett]

@stephenwaite I've tested on demo and i'm happy with this PR #3505 for patch 3 and will continue further enhancements in 5.0.3. I may sneak in another forum request while here. I've setup some demo data in up for grab for testing if you want to check out.

At least this addresses setting the provider for encounter which has bugged many for awhile...

[stephenwaite]

thanks again @sjpadgett , this is testing very well, great job

[sjpadgett]

No problem. Closing this as fixed in PR once in. Thanks for your help....

[sjpadgett]

@stephenwaite @bradymiller or any clinician, Now we are selecting PBE for default billing facility, can I assume it has to be a billing facility also? Also, Should we force practice to have a PBE and if so, should there only be one PBE?(actually dumb question!)

[stephenwaite]

hi @sjpadgett , can you help me figure out how the Encounter Provider gets selected? Am seeing a non-provider get selected in the encounter form

if a non provider creates an encounter without using the calendar it looks like it's grabbing the first user alphabetically

[stephenwaite]

i've got this setup on https://seven.openemr.io/f/openemr/interface/login/login.php?site=default with admin user test, pw test

ideally only users who are providers should be selected for encounter providers

also looks like when you save the encounter provider it's not actually being saved as in doesn't display when reopened

thank you jerry

[sjpadgett]

@stephenwaite First, I used UserService in newpatient $userService = new UserService(); $users = $userService->getActiveUsers(); foreach ($users as $activeUser) { But did not check for authorized flag. oops thought returned auth users. Second. Provider save works for me on 5.0.2 but got lost on 5.0.3 so i'm baffled. This worked on up for grab testing!

[sjpadgett]

Okay found not save issue. If POS is turned off in Billing I try to set a undefined to non exist control. lol I test with everything turned on. Never think about turning stuff off! I'll fix and slip into the patch 3. Then back to calendar.

[stephenwaite]

thanks, funny, had POS turned on :)

[sjpadgett]

I turned it on.:) I somewhat pay attention....

[stephenwaite]

hmm, what if there are 2 admins? only one is a provider, yep, won't save even with POS turned on

[stephenwaite]

it's when you're logged in as an admin who's not authorized, weird scenario

[sjpadgett]

Thats because userauthorized is checked on save. I may have to go with ACL

[stephenwaite]

ok, thanks, so there's no getauthuser function in user service? or does this do the trick?

    /**
     * Centralized holder of the `authProvider` session
     * value to encourage service ownership of global
     * session values.
     *
     * @return String of the current user group.
     */
    public function getCurrentlyLoggedInUserGroup()
    {
        return $_SESSION['authProvider'];
    }

states user group so guess not

does the class need another method?

[sjpadgett]

umm I don't know how best to handle this. Big question is; do we want to allow non providers from users that are ACL admins or encounter to be in encounter provider pull down? Really if they made it to create/edit encounter they already have permissions so maybe I fix save and only list those active users that have the right acl permisions.

[sjpadgett]

Decided to only allow authorized providers in encounter provider pull down and for save will ignore userauthorized because if user is saving then they already have permissions. Settled @stephenwaite ?

[sjpadgett]

Closing fixed