Custom lists request and def. lang. problem

OpenEMR Development
1

semteacher wrote on Thursday, April 12, 2012:

Dear Mr. Brady Miller!

Again have are some question on OpenEMR.
Firstly about some possible bugs.
1. Yesterday I was downloading OpenEMR distr from your github fork. There in list present Russian language. But I do not receive Russian Gui when choose it as default and logon. Only several terms translated (Administration item name in navigation pane, Add button in calendar, etc). Totally, 5-6% of translation. In database table Russian terms presents.
I test this at three different PC - same results! During installation not any one error was observed. At your demo site http://opensourceemr.com:2089/openemr everything work fine!
2. Under Administration-Globals-Miscellaneous I found a rows “State List” and “Country list”. I mentioned that this features allow replacing a default country and state list with custom in all related drop-down controls. I create new state list named “State_ukr” fill it with data and use in the Miscellaneous. But nothing changes not anywhere. In which I was wrong?
I seem that I can use my new custom state list with LBF forms. I try to customize the Patient Demographics state drop-down list with my own - it work. But for me important clearly understanding the Miscellaneous rows “State List” and “Country list” purposes.

Second set of questions will be related to features requestion.
3. Is it possible to add a third special list type (after country and state) for the state sub-region - for example called “district”. In my country every time need to extend both this data for any administrative issues.
3.1. Is it possible to allow customization a district list in same manner as country and state (if my understanding it correct - see q.2)
4. Same question about addition the fourth special list type “city”. Reasons for it same as above with same customization.
5. I think will be fine in the “Facilities” form replace text field “country” and “state” with drop-down lists which are associated with appropriate lists (it exist in the patient demographic form).
6. Also will be fine to add a “district” and “city” drop-down lists to the “Facilities” form if the q.3 and q.4 will be positive solved.
7. Same the “district” and “city” drop-down lists will be fine to add to the patient search/create dialog (country and state selector now present there).
8. Please add a “default facility” In addition to the “Provider” drop-down list under the patient demographic form.
9. Add the “Facilities” selector at the patient search result window. If q.8 will be positive solved - in the patient search results dialog perform automatic resultset filtering by the logged user “default facility” value.

And… Stop! Several dozens of the national forms and reports I will try to develop itself!

2

bradymiller wrote on Friday, April 13, 2012:

Hi semteacher,

1. The online developer demo (the link you posted above) pulls the most recent translation table build, which is built daily from the google docs spreadsheet. If you want to use these translations in your local OpenEMR instance, can easily do by following the instructions on this wiki page:
http://open-emr.org/wiki/index.php/Install_Translations
(download the Daily Development Release link in the Development Translation Releases section)

We don’t include the daily builds in the actual OpenEMR development codebase for space and technical reasons. Occasionally, when I add new english constants to the translation engine, I then update the tables in the main codebase.

2. That setting only really is meant for the insurance sections of demographics since it can’t be customized via the Administration->Layouts editor.

3. Yes, you can add this entry in the Administration->Layouts editor to see it in the Patient demographics. However, to add to other places (such as the facility, insurance, address book, user addresses, would likely require coding in a new entry on the form and sql column for the pertinent tables; if you used ‘County’ as the label, then could included this in the official codebase, which you could then convert to your wanted label via the translation engine).
3.1 Yes, in the Patient demographics via the Administration->Layouts editor.

4. Yes, in teh Patient demogrpahics via the Administration->Layouts editor.

5. To see how to do this, check out the state/list entries in the Insurance part of the patients demographics input screen (these are using the lists that were entered into the globals->miscellaneous section). This would be a useful addition to the official openemr codebase.

6. Would create new entries in the globals->miscellaneous section for these.

7. Yes, these can be added via the Administration->Layouts editor.

8, To do this, would need to add a Facilities Data type to library/options.inc.php . Then, would be able to add it in the Administration->Layouts editor. This would be a useful feature in official openemr codebase.

9. Per 8, could then add it in the Administration->Layouts editor. Would require some search logic mods to then support this (only returning patients where facilities are same for patient and the user) and would be a useful feature in the official openemr codebase. Alos, if your looking to fully separate each facility, then check out the multisites module:
http://open-emr.org/wiki/index.php/OpenEMR_Multiple_Sites_Module

Hope this helps to get you started,
-brady
OpenEMR

3

semteacher wrote on Friday, April 13, 2012:

Hi Mr. Brady Miller!

Thank you for your answer and for your hints. I will tray to implement it step-by-step.

1.Today I try to complete the q.8 because this feature important for me. Results fine! The new data type "“facilities” now available and can be used LBF forms overall.

2.About Ukraine translation. I download spreadsheet document. I want to translate it offline by sharing with my staff friends. Then I will edit an online document. I now that restricted to replace by upload. I read all notifications about translation.
But we will start our job next week - tomorrow  we will have Easter  that are three days long in my country.

4

bradymiller wrote on Friday, April 13, 2012:

Hi semteacher,

1. If you’ve gottent 8 to work, this would be a really nice feature to add to the official openemr codebase.

2. I’d recommend only editing the spreadsheet online (your staff can be added to the spreadsheet as long as they follow the instructions/guidelines). The problem with editing it offline is that it can be hard to get it back into the spreadsheet after I add more english constants (which I plan to do very soon). You may get stuck having to copy/paste individual cells.

thanks,
-brady
OpenEMR Project

5

semteacher wrote on Friday, April 13, 2012:

Hi Mr. Brady Miller!
1. I will try to perform a github commit as much possible quickly.
2. In discuss with my chef we are planned to involve the foreign language department staff colleagues to translation. I some fear with access them to spreadsheet because their PC experience not good.

6

blankev wrote on Friday, April 13, 2012:

Brady and Andrilov,

I would suggest the contrary.

Make with the group an off-line translation. As soon as you Brady add new Constants they will show up at the end of the rows. So the next part to translate will be additions at the end. It should be easy to copy paste the contents  and make these additions on the end of the off-line spreadsheet.

As long as the English column of constants is kept in place  you can add many Ukrainian Columns for each translator and make the pick of the best translation.

The column with best translations can be copy = > pasted into the official on-line translation spreadsheet. (My  advise would be to let a medical professional make the best pick and be the leader of the translation group)

Never ever make any change in Column A and Column B

7

blankev wrote on Friday, April 13, 2012:

**Some caution has to be in place though! **

All new constants, still to be inserted some time, have to be added at the end of the existing spreadsheet (action could be taken by Brady in the automatic insert process), but as long as this is not in place follow the next two steps:

These correction mechanism have to be in place:

1. Insert new Ukrainian Definitions every day before Brady inserts his constants.
2. Make a new spreadsheet after every update with some merge process to keep the used and NEW-mixed spreadsheet in synchronization.

Would be an option to have some sort of sorting column in place to sort the new Constants to the end of the spreadsheet.
(Could be an update-date or numbers)

Pimm

8

bradymiller wrote on Saturday, April 14, 2012:

Hi Pimm,

You raise a very valid solution(keeping the new translations at the end and then using a sort to keep them alphabetized), however the current back end perl scripts wouldn’t support this (and I don’t have time to incorporate this solution at this time). Best thing for me to do is to probably get the new constants out before the Easter holidays end for semteacher. Then will let semteacher know before adding constants after this to give time to update the official translation spreadsheet from his local one.

-brady
OpenEMR

9

bradymiller wrote on Saturday, April 14, 2012:

Hi semteacher,

I noted your commit for the facilities entry to be available here:
http://github.com/semteacher/openemr/commit/0838d6669480dc3c453cfcaa2ad196180470c43b

On a quick glance this looks really nice and clean; will plan to look at in more detail when have time. Also posting here if others want to review it. It is adding the following feature:
1. A Facility drop-down box in the layouts/LBF engine
2. Adding a default Facility entry to patient demographics.

-brady
OpenEMR

10

semteacher wrote on Saturday, April 14, 2012:

Hi Mr. Brady Miller!

Thank you for attention to my job. I must notify you that current commit some incomplete.
1. The “Facility” data type I create and now it available in the LBF
2. The “FacilityID” field was added to the “patient_data” table.
3. The “Facility” drop-down list was inserted into the “Demographics” form. It work correct - allow change facility.
What did not implemented/tested?
1. By default in the “Facility” drop-down list must  be selected current user default facility.
2. Changes in the SQL files I did not test with installation/upgrade.

Additionally I plan to put default both facility and provider values equal to the current user (if he is provider) when  a new patient will be created.

11

bradymiller wrote on Monday, April 16, 2012:

Hi,

Thanks for the explanation. Plan to review this soon. Just to make sure, are you ok with us committing this (or some of it) to the codebase?

thanks,
-brady
OpenEMR

12

bradymiller wrote on Monday, April 16, 2012:

Also,
Just added 165 constants to the google docs spreadsheet yesterday, so if you plan to translate offline, make sure you base it on the new document. And check in with me every once a week or so to see if I’m planning on adding new constants to ensure we add your translations before this.
thanks,
-brady
OpenEMR

13

semteacher wrote on Tuesday, April 17, 2012:

Hi Mr. Brady Miller!

Thanks for your attention.
1. I will be happy if my small job will be included in general OpenEMR codebase.
2. I will download a new file. We will start translation this week.

Andriy Semenets

14

bradymiller wrote on Wednesday, April 18, 2012:

Hi,

I placed a couple comments on your above github code. I think the “Facility” data type should definitely go into the codebase, but the - All Facilities - seems a bit confusing on this situation (see my github comment). (once get this part into the codebase, then will review/test the other parts)

thanks,
-brady
OpenEMR

15

semteacher wrote on Monday, April 23, 2012:

Hi Mr. Brady Miller!
Thanks you to make a backup of the my previous commit. Last week I was recreate my fork of the OpenEMR and on Friday I was commit changes that included:
1.Updated/added data types: Facilities without All/Facilities with All

2.Updated dropdown_facility function
-aded new parameter $allow_allfacilities that control visibility of the “All facilities” option
-changed logic to use it
3.New Facilities drop-down list on the Demographics form now searchable.
4.Database scripts now tested
Commit there:

16

bradymiller wrote on Wednesday, April 25, 2012:

Hi Andriy,

I rebased your commits into two separate features on this branch:
http://github.com/bradymiller/openemr/commits/semteacher-facility-data-types_3

First commit is to simply add/support the Facility datatypes in the LBF/Layouts engine:
http://github.com/bradymiller/openemr/commit/b09dda5294c6f0ecb393726d12b195b0b2210d46

Second commit is to add a Facility selector into the patient demographics layout:
http://github.com/bradymiller/openemr/commit/349a4f83e58a9ea8459a19ea4cd1e070d1b6652f

Was hoping others could weigh in on these features. I think the first would be very useful, but curious what others think. Also not sure what other think of adding a Default Facility field to the patient demographics form (for example, should it support multiple facilities or is a default single selection ok).

thanks,
-brady
OpenEMR

17

bradymiller wrote on Wednesday, April 25, 2012:

Hi,
Placed a review on the above two commits on github. To see my comments, search for ‘bradymiller’ when looking at the commit via your web browser.
thanks,
-brady
OpenEMR

18

bradymiller wrote on Thursday, April 26, 2012:

Hi,

I just committed Andriy’s first commit to sourceforge:
http://github.com/openemr/openemr/commit/6107a4cb9aa2d3fa4704039fce2715ef65e30be0

Still awaiting some feedback if it makes sense to add a Default Facility entry to the patient demographics. The most recent commit to review/test for this feature is here:
http://github.com/openemr/openemr/commit/6107a4cb9aa2d3fa4704039fce2715ef65e30be0

thoughts?

-brady
OpenEMR

19

bradymiller wrote on Thursday, April 26, 2012:

Made an error in above link for the Default Facility entry code review. Supposed to be:
http://github.com/bradymiller/openemr/commit/cd0ca155ff70330213b5fb7522faab797f22abaf