LBF and Patient summary connection

sapiens110 wrote on Saturday, November 22, 2014:

Hello everyone!

This is my first comment on the forum and I first thank everyone contributing to this software!

I have one question regarding the LBF:

Creating a form is easy. But it would be nice if data entered on the forms, somehow connects and auto-update themselves on the patient summary page, i.e if my form has an allergy section, filling out the form also updates the allergies from the patient summery page. Is there already a way of doing this?

fsgl wrote on Saturday, November 22, 2014:

Layout Based Visit forms don’t have this option without customization.

Issues can be linked to the Encounter form. Accomplished from Issues or Encounter.

Alternatively, using a split screen; Issues on the right hand side of Patient Summary can be copied & pasted into the LBV form.

sapiens110 wrote on Saturday, November 22, 2014:

Thanks for the reply, I’m aware the link is possible via New Encounter or Issues.
Actually right now, the layout is split screen and info can be put into an LBV but this will need to input data that has been already inserted into the system via Issues. And with more complex forms, it gets worse i.e with lots of fields for surgeries,allergies …

Any other idea to get the Issues first hand by a visit form so that the summary page (Issues list) will auto-update?

blankev wrote on Saturday, November 22, 2014:

It has been some time that I worked with LBV-forms, but if you look careful into Demographics and history you will find the ways to taking the correct field in the LBV-Forms and create a connection to the existing database for that patient and will show in the report section.

The other way around is an other story.

Having said this, it is sometimes hard to find the correct “original field”.

sunsetsystems wrote on Saturday, November 22, 2014:

I’ve been developing a feature like this for a client, where a LBF encounter form can include fields from demographics, history and other encounter forms. There are also features for conditionally hiding fields depending on the state of other fields. This will all find its way into the project after some more testing and refinement.

Rod
http://www.sunsetsystems.com/

sapiens110 wrote on Sunday, November 23, 2014:

Hi Pieter

Thanks for your reply, I’ve noticed them but they are really limited. As you can see in the Screen, I managed to only find a few such as allergies and Exam results.
Did you manage to add to these Data types or what you were saying is limited to these options only?
Also I tried to take the same ID and in did not work.

sapiens110 wrote on Sunday, November 23, 2014:

Hi Rod,

Thanks for your reply. This sounds great! If you’re saying it will be included in the community version, is it possible for us to also test and put it to use to help get it ironed out faster?

blankev wrote on Sunday, November 23, 2014:

In this example you want to get allergies from fname. It is like making the “F”-word field and try to see the sex type of the client on the same row. Or use Sex-type and answer choices are YES/NO.

allergies are used in a table of OpenEMR. Track this field and use this field with their specific field-name. If it is not in the available options you have to create the option and this is Developer work.

As I tried to say, I did it in the past, but it is too long ago to just in a moment recover my steps.

fname is First Name of the client like lname is Last Name of the client.

sapiens110 wrote on Sunday, November 23, 2014:

Thanks for the reply. I was just trying to list the available options. I did not use fname and allergies for one field. Any how, I guess I understand your point now. For my needs( having access to all patients demographics,allergies, surgeries,problems,medications,history and etc) I have two choices.

1- wait for the LBF update that Rod is talking about.
2- write my own form using OpenEMR convention (similar to CRUD as I skimmed through dev manual)

Now the question is that LBF uses one table( correct me if I’m wrong). If things scale, would the second option be superior?

blankev wrote on Sunday, November 23, 2014:

One question gives rise to many more questions. No I can’t help you with the answer.

Suggestion:

Make both options of forms in a demo and see what the results are.

sapiens110 wrote on Sunday, November 23, 2014:

Thanks Pieter!

arnabnaha wrote on Monday, November 24, 2014:

Hi Rod

great to hear about the feature you are developing. It will definitely add a new dimension to the openemr forms and save us from filling many different forms as we would be able to bring in data from different forms into one. Thanks a lot and really looking forward for the commit.

Rod, I am eager to test it out, if possible please give a link in github…

thanks and regards
Dr. Arnab Naha

sunsetsystems wrote on Monday, November 24, 2014:

I’ll put up a github branch soon, need to finish testing and refinements here first.

Rod
http://www.sunsetsystems.com/

sapiens110 wrote on Tuesday, November 25, 2014:

Hi Rod

Thanks for your reply. Eagerly looking forward to test this cool feature! It makes OpenEMR much more capable.

sapiens110 wrote on Saturday, December 06, 2014:

Hi Rod

May I ask if there is any update for the current situation of the feature you talked about?

sunsetsystems wrote on Saturday, December 06, 2014:

It’s basically done, just need to port it over to current dev code. Coming soon!

Rod
http://www.sunsetsystems.com/

sapiens110 wrote on Sunday, December 07, 2014:

Thanks Rod! Eagerly waiting.

sunsetsystems wrote on Sunday, December 07, 2014:

It’s on github now. More info here:

https://sourceforge.net/p/openemr/discussion/202506/thread/c10ddf8d/

Rod
http://www.sunsetsystems.com/

sapiens110 wrote on Monday, December 08, 2014:

Wow lot of goodies. I’ll test drive it in this week! Thanks Rod.