Patient Discharge

kylenave wrote on Wednesday, October 28, 2015:

I have a provider who has requested a new discharge form. It is similar to the Transfer Summary so I’m just basing it on that form and modifying to suit the providers needs.

He would then like patients who have been discharged to be filtered out of the patient list by default. I’m guessing there would be a “Show Discharged” checkbox or something similar to allow the user to view them if needed. Could also be a GLOBALS setting whether or not to show Discharged.

There are a couple of problems with this setup. First, the Discharge form is attached to an encounter and not the patient. Initially one can assume that the final encounter has the discharge form attached however if the patient returns to the practice then it breaks that approach.

At the moment I’m thinking I would keep the discharge form as an encounter form but add a boolean to the patient table to indicate whether they have been discharged and then filter these out of the patient list by default.

A couple of questions:

  1. Has anyone else tackled this or thought about it and has some good ideas on an approach?
  2. Does the community think this would be a good product feature? I would prefer to implement this in a way that is acceptable to include in the standard product.

Thanks for any feedback.

sunsetsystems wrote on Wednesday, October 28, 2015:

What kind of stuff is in a discharge form? It might be suitable for a “transaction” rather than an “encounter form” because transactions are not linked to visits.

On that note I have a commit to support “layout based” transactions, so that transaction forms can be built and maintained without custom programming. If there’s interest I will put it up for review so it can get into the code base.

Rather than a boolean in patient_data it may be more forward-thinking to have a multi-state indicator for patients that are discharged, deceased, inactive or perhaps not patients at all (thinking also about the recent discussion of putting guarantors in the table).


arnabnaha wrote on Wednesday, October 28, 2015:

Hi Rod,

would love the feature of LBF forms as transaction forms to be added to the code base. It would help us create a lot of forms which should not be linked to encounters only. it will create a new dimension for sure. Please if possible share the github link of the code, so that many over here can try it out and eventually you can add it to the codebase.


sunsetsystems wrote on Wednesday, October 28, 2015:

OK Arnab, I just created a thread for that.


arnabnaha wrote on Wednesday, October 28, 2015:

Thank you so much Rod. I am gonna test it right now…

fsgl wrote on Wednesday, October 28, 2015:

Perhaps what is being requested is the office equivalent of the hospital discharge summary, which comprises of admission diagnoses, discharge diagnosis, exam upon admission, hospital course with labs, exam upon discharge & discharge plans.

If the CCD is too skimpy, the last clinical note can fill in the void.

In addition to deceased patients, there are 2 categories of never-to-return patients; those who transferred to another office & sociopaths, whom the practice was forced to give a Withdrawal of Care document.

It would be helpful to have 2 more fields in Misc in Demographics; one for the transferred status & one for transfer date. Medical-legally it is important to know at what point we are no longer responsible for said patients.

We are under no legal obligation to state a reason in the Withdrawal of Care, so it’s probably better not to provide a field for it.

It would be good to have a similar big, bold, red text like “Deceased for 126 days”. No reason to send recalls to patients who won’t be returning.

bradymiller wrote on Thursday, October 29, 2015:


Transaction sounds like a good route for the form since won’t be based on encounter and can configure whatever you want for your discharge form. The nice thing there is that it could be done in a way to record more than 1 discharges from the clinic. For example, discharged after issue #1 is resolved(or is a sociopath). Then returns again for issue #2 (or is less of a sociopath).

Bringing that into the patient searching sql query will likely be much tougher than if just had a flag in patient_data.

So may want to do both(the transaction for the documentation/recording and the flag in patient_data for the quick is patient not discharged or discharged in the sql queries (would this be the same as not active or active?)).


fsgl wrote on Thursday, October 29, 2015:

Unless one is a masochist, absolutely no reason (especially medical-legal) to rescind a Withdrawal of Care. (Was once asked to do the same by a board member of our local medical society. Very tempted to tell the fellow to go fly a kite, but declined politely instead.)

kylenave wrote on Thursday, October 29, 2015:

For reference I have attached the discharge form I have come up with so far. This is basically the format requested by the provider who is a LCSW.

I like the idea of a transaction but also a field in the patient record to keep the logic simple and making it multiselect sounds like a good idea as long as the statuses chosen are mutually exclusive. I imagine the actual status values would be user defined in the list manager but we could have at least a default value of “active” and then have an option to “display only active” or similar in the patient table.

Rod - I’ll also check out what you have so far. I definately like the idea!