Place of Service and SNF/Nursing Fac

OpenEMR Development
1

tmccormi wrote on Friday, April 27, 2012:

There is a question on how to handle the POS codes for Short Term Nursing versus Long Term in the transition from < 100 days to greater >100 days.   A facility can only have one code right now, and while you could create duplicate facilities it would be hard to tell which was which when doing billing tasks.

The solution, I think, is to provide a ‘default’ POS, but allow it to be overridden at the encounter billing level (fee sheet).

Any other ideas or thoughts on this?

-Tony

2

yehster wrote on Friday, April 27, 2012:

Is there enough data in the encounter (based on Date of Service, Onset/hospitlalization, etc) to determine which facillity code is appropriate?  A more automatic, but more complicated mechanism by that happened at x12 generation time might be possible.

3

sunsetsystems wrote on Friday, April 27, 2012:

Features that affect claim generation should generally have some documented foundation, as there tends to be a lot of confusion in this area that comes from payers not always being helpful.  I was under the impression that the POS code is an attribute of the facility and not of the patient’s visit…?

Rod
www.sunsetsystems.com

4

tmccormi wrote on Friday, April 27, 2012:

It is an attribute of the length of stay, in the case of a facility that has multiple services,  a Short Term Nursing Facility and Standard Nursing Facility.   The barrier appears to be 100 days (with Medicare) for a doctor doing work at that facility (ENT in this case) to switch from billing under POS=31 to POS=32.  The facility did not change, just the type code.  Claims are rejected if the code is not correct,  Date of Onset might be a good way to do this.
-Tony

-Tony

5

sunsetsystems wrote on Friday, April 27, 2012:

From http://www.cms.gov/manuals/downloads/clm104c26.pdf :

31 Skilled Nursing Facility

A facility which primarily provides inpatient skilled nursing care and
related services to patients who require medical, nursing, or rehabilitative
services but does not provide the level of care or treatment available in a
hospital.

32 Nursing Facility

A facility which primarily provides to residents skilled nursing care and
related services for the rehabilitation of injured, disabled, or sick persons,
or, on a regular basis, health-related care services above the level of
custodial care to other than mentally retarded individuals.

I would complain that those rejections are improper.  To say that a facility does something “primarily” does not mean that it cannot do something else less often.  If they won’t budge, ask for a written statement as to the policy so the code change can reference something to justify its existence.

Rod
www.sunsetsystems.com

6

tmccormi wrote on Friday, April 27, 2012:

Rod,
  Have you ever been successful complaining to the CMS or getting a formal statement from them that wasn’t a reference to the website (like you already found)?.    I’m curious, I’ve never gotten an payor to concede to anything, they always says “That’s the way our system works”.
-Tony

7

sunsetsystems wrote on Friday, April 27, 2012:

Tony, honestly I think it’s more likely that someone is giving you bad information about the reason for rejection.  I could be wrong but it does happen.  Just ask where it’s documented.  I’ll be interested to know the answer.

Where I’m coming from is a desire to avoid adding code based on misconceptions.

Rod
www.sunsetsystems.com

8

tmccormi wrote on Friday, April 27, 2012:

Understood,  the customer could care less though :slight_smile: he just wants a code change so he can select the correct POS along with the facility on the encounter page.  
-Tony

9

tmccormi wrote on Monday, April 30, 2012:

The ‘I’ below is my customer speaking, not me … -Tony

I researched a little more on POS 31vs 32. If the patient services are billed by the facility under Part A of the Medicare insurance the physician/ specialist has to bill with POS 31 even though the physician is always covered under Part B of the patient insurance. If the patient has only Part B coverage and the facility is also billing Medicare under Part B the provider can bill under POS 32. This  will probably be true only if the facility is classified as SNF and NF. We need to know from the facility in question whether they are billing Medicare under Part A or Part B for the respective patient.  Does the nursing home define whether it is a SNF, NF or both?

I found this in a document on www.cms.gov  site- cms manual system

"CPT Nursing Facility Services codes shall be used with place of service (POS) 31 (SNF) if the patient is in a Part A SNF stay. They shall be used with POS 32 (nursing facility) if the patient does not have Part A SNF benefits or if the patient is in a NF or in a non-covered SNF stay (e.g., there was no preceding 3 day hospital stay. "

Me again -

He also says the the MD and NPs get paid $100-$200 more per visit if the patient is Part B (> 100 days) in a facility.  There are lots of rules about leaving and coming back and whether that resets the 100 day count.   Apparently some facilities are SNF until the aren’t any more.

-Tony

10

sunsetsystems wrote on Monday, April 30, 2012:

Thanks Tony.  I found a link:

http://www.cms.hhs.gov/transmittals/downloads/R1875CP.pdf

What a mess.  Perhaps a reasonable place for this is the “Misc Billing Options” form, adding an optional override for the POS code?  I’d rather keep little-used things like this out of the Fee Sheet, which is cluttered enough already.

Rod
www.sunsetsystems.com

11

tmccormi wrote on Monday, April 30, 2012:

Yes, it’s a mess.   It think the misc billing options will be deemed, very quickly, as “too many clicks”, but the users that need it.  I think it should be a globals option and display as a pull down next to the Facility selector on the new encounter (Reason for Consultation/Visit Form).

Sexier would be to allow facilities to have more than one associated POS code and have the pick list in the encounter only show those next to the facility…  :slight_smile:

-Tony

12

tmccormi wrote on Monday, April 30, 2012:

Errata: … by the users that need it ….
-Tony

13

sunsetsystems wrote on Monday, April 30, 2012:

Those would also be OK with me.

Rod
www.sunsetsystems.com

14

aethelwulffe wrote on Tuesday, May 01, 2012:

Been dealing with this since day one.  Jeff’s issue is minor compared to what we deal with.
We have four different programs:  that’s four different group NPI’s, each for a different variety of Govt. Cheese, each with Home, Office, School, Other, and I think maybe one more POS code with 2-5 POS codes under each NPI.  That’s like 13 different “facilities” as OpenEMR thinks about it.  One of those many things that the system design never really took in account.  This means we have ARS_Home, FES_Home, TPI_Home, CBHA_Home, and the same for Office etc…
This was a serious issue until the “multiple billing facilities” option came into being.

  Rod mentioned the “avoid the noid” with petulant practitioners whining “Tooo maaany Cliiiicks! ……Waaaaaa!”  Yes, please, for chrissakes let’s avoid this.  The extant issue is that the work-around for this has been in place for many years by now.  This means that if we change this, we directly affect the encounter configuration interface, and the whole workflow experiences a change.  “You keep chaaaaanging thiiiings!  Waaaaaaaa!”.

  If we add the ability to choose different POS for a given facility, and don’t change anything else, it needs to be on the encounter form.  That is where the facility has always been selected.   There will be some re-configuration required on the part of the users (for hosts/vendors, this might be some work), and user training will need to happen.  Seems a minor change, a big help, and easy to do and re-configure for.  It would be.  Doesn’t mean that the users won’t be a pain in the ass about it.
  It is too bad about how the encounter form, fee sheet, and mic bill options each gather bits, yet have never been fully connected.  Billing information comes from all over the place.  To track unit usage for each patient by payer/program/code/eligibility, track contract provider pay, track travel, track reviewer/peer reviewer/pay (basically additional billing for another billing provider, but on the same encounter), and 3-4 other items l, I have had to add a crapload of stuff to the fee sheet.  I just wish that EVERYTHING that ultimately concerns billing (facility, billing provider, POS, mid-level non-billing providers, and all kinds of other stuff) was ALL on the fee sheet, and billing configuration was arranged in sequential input mode.  I would love a “20 questions” interface option (“beginners mode” user setting) to ask questions one at a time with a fancybox to make sure the user inputs the data, and has an understanding of what/why they are entering the data.

  All that aside, please explain to me why it would be bad to consolidate all the billing parameters to a single interface.

15

aethelwulffe wrote on Tuesday, May 01, 2012:

errata:
In Jeff’s situation, where compensation is increase dependent on the location code, yet the billing facility/NPI does not change, is there not also a need to include situational checks for the amount billed for a given service?  Would this not be an additional layer of data in the Services list, since two versions of the same billing code would not be advisable?  Oft requested future Practice Management features like the tracking of negotiated rates might be affected.

16

sunsetsystems wrote on Tuesday, May 01, 2012:

All that aside, please explain to me why it would be bad to consolidate all the billing parameters to a single interface.

That sounds great if something like tabs are used to de-clutter.  But it would take quite a bit of discussion and work, and I try not to get dragged into these conversations until someone until someone is actually ready to do something.  :slight_smile:

Rod
www.sunsetsystems.com

17

kevmccor wrote on Tuesday, May 01, 2012:

The link above http://www.cms.hhs.gov/transmittals/downloads/R1875CP.pdf gets us into the Medicare operations manual.  You will find that specific CPT codes are associated with specific places of service.  While it is probable that this is not foolproof, it is possible to check CPT codes against place of service codes and at least have a suggestion of the proper place of service code.  I believe right now the place of service code is part of the ‘facility’ database row and effectively ‘hardcoded’ into the claim generation process. 

I put the below function in my statement script to get a more descriptive item,but the concept could apply to checking the place of service.

function check_proc_code($prc_code){
	    // set $descr to empty string
	    $descr = '';
		// arays of procedure codes, by type
		$STMT_OFFC_LIST = array("99201","99202","99203","99204","99205","99211","99212","99213","99214","99215");
		$STMT_OFFCCONS_LIST = array("99241", "99242", "99243", "99244", "99245");
		$STMT_PREV_LIST = array("99384", "99385", "99386", "99387", "99394", "99395", "99396", "99397");
		$STMT_HOSP_LIST = array("99231", "99232", "99233");
		$STMT_SNF_LIST = array("99307", "99308", "99309", "99310");
		$STMT_HOSPADM_LIST = array("99221", "99222", "99223");
		$STMT_HOSPDSCHG_LIST = array("99238", "99239");
		$STMT_HOSPADMDSCHG_LIST = array("99234", "99235", "99236");
		$STMT_HOSPOBS_LIST = array("99217", "99218", "99219", "99220");
			 
		// check for values -- there should be no duplicates in the code arrays
		if (in_array($prc_code, $STMT_OFFC_LIST, true)) $descr = "Office Visit";
		if (in_array($prc_code, $STMT_OFFCCONS_LIST, true)) $descr = "Office Consult";
		if (in_array($prc_code, $STMT_PREV_LIST, true)) $descr = "Preventive Care Visit";
		if (in_array($prc_code, $STMT_HOSP_LIST)) $descr = "Hospital Visit";
		if (in_array($prc_code, $STMT_SNF_LIST)) $descr = "Skilled Nursing Facility Visit";
		if (in_array($prc_code, $STMT_HOSPADM_LIST)) $descr = "Hospital Admission";
		if (in_array($prc_code, $STMT_HOSPDSCHG_LIST)) $descr = "Hospital Discharge";
		if (in_array($prc_code, $STMT_HOSPADMDSCHG_LIST)) $descr = "Hospital Admit/Discharge";
		if (in_array($prc_code, $STMT_HOSPOBS_LIST)) $descr = "Hospital Observation";
		//
		return $descr;
	} // end function
18

tmccormi wrote on Tuesday, July 17, 2012:

I have code from Ensoftek for this ready for review.  I’m still testing it, but some early eyes on the code would be a good thing.  Thanks

https://github.com/anilnakkani/openemr/compare/master…pos-selectors

Tony

19

bradymiller wrote on Wednesday, July 18, 2012:

Hi Tony and anilnakkani,

Can’t do a review on the github comparison screen. The best thing to do now is to create another branch, called pos-selectors_2 off the current pos-selectors branch. Then rebase all of your commits on the pos-selectors_2 branch into one commit and then push this branch to github.

Let me know when this is done and I’d be happy to review/test the code.

thanks,
-brady
OpenEMR

20

ensoftek wrote on Thursday, July 19, 2012:

Hi Brady,

Thanks for your suggestion. I was bit confused whether to rebase with master or pos-selectors branch and so, i did both.
Here are the sets i followed. (pos-selector_2 is rebased with master and pos-selector_3 is rebased with pos-selectors)

git checkout pos-selectors
git branch pos-selectors_2
git rebase master
git push origin pos-selectors_2

git checkout pos-selectors
git checkout -b pos-selectors_3
git rebase pos-selectors
git push origin pos-selectors_3

https://github.com/anilnakkani/openemr/tree/pos-selectors_2
https://github.com/anilnakkani/openemr/tree/pos-selectors_3

Kindly let us know which one is correct.