hey,
I’m beginning to go work through all the code to ensure works well with and without translations.
One of the things I’ve noted is the use of lists. Rod’s included excellent functions in openemr/library/options.inc.php to display the specific list selectors and output the chosen item in list (generate_form_field() and generate_display_field() functions respectively). We need to use these functions (not collect the lists directly from mysql), since this ensures correct translation settings, gives the warning if data not on list, and will allow easy use of widgets as these get developed. For example the chart tracker didn’t use these functions for accessing the chart location list; I’ve converted this to using the list functions and also added an option to the generate_form_field() functions that allows sending the title displayed in the empty field (ie. where ‘unassigned’ is). Likely place developer documentation of this stuff in wiki at some point to ensure keeping use of lists standardized.
-brady
Another example in the address book editing form at openemr/cvs/openemr/interface/usergroup/addrbook_edit.php . Here, there’s a input menu item for the title of person(Mr, Mrs. etc), which is a hard-coded listing. By merely including openemr/library/options.inc.php file can use the following command to replace what was there to leverage the titles list (with all the benefits that come along with it):
generate_form_field(array(‘data_type’=>1,‘field_id’=>‘title’,‘list_id’=>‘titles’,‘empty_title’=>’’), $row[‘title’]);
It would be helpful to add types of immunizations to that list this things driven by lists. Right now I have to add new ones and missing ones using the phpMyadmin, unless I’m missing something.
Things like immunization and Internationalization are issues that need international constants AND accepted coding. WHO/CDC/ICD/UNICEF/WONCA… etc. might provide these lists. This could be of value when any doctor works in any clinic with any kind of EMR and any patient wants to transport his/her registered medical information to any another Clinic.
Per your request, please add to your plate changing the Rx drop-downs which are now defined by …/classes/prescription.class.php to conform to the language internationalization and use the drug_xxx data tables with widget add ability instead. I won’t hold my breath, though ;-) Thanks.
Goal is to create more abstract functions for lists and layouts to make translations more manageable. (since need to allow the user to turn on/off translations of layouts and lists)
I’ll post here with new additions. Basically adding this stuff as I work through the code for the Translation Project.
Just added a simple function return_list_titles() which simply returns a ordered listing of a specific list titles; this was required in openemr/interface/reports/services_by_category.php script .
hey,
After testing an committing the return_list_titles() function and looking through the openemr code some more, it hit me that this was a stupid function. Can’t find any other places it would even be useful, so gonna remove it. And instead realized it would be better to create a xl_list() and xl_layout() function in options.inc.php to wrap xl() (only goes through xl if the globals.php toggles are actually set to translate the lists and layouts). This seems to be the best way to deal with scripts such as openemr/interface/reports/services_by_category.php which are doing custom mysql queries on lists and outputting list titles.
-brady
Added another list titled ‘Subscriber Relationship’ and incorporated it into the insurance form. While doing this also had the sex input from the insurance form use the ‘Sex’ list. Now, should be a bit easier for somebody to migrate insurance form to layout at some point (likely have to create another (3rd) boolean list with TRUE/FALSE as ID’s to work with the yes/no ‘Accept Assignment’ field).
And the process keeps going…
Migrated the patient notes (pnotes) types to the list_options table entitled "Patient Note Types". Ended up touching several files to do this:
openemr/interface/fax/fax_dispatch.php
openemr/interface/main/authorizations/authorizations.php
openemr/interface/patient_file/summary/pnotes.php
openemr/interface/patient_file/summary/pnotes_full.php
openemr/interface/patient_file/summary/pnotes_print.php
openemr/library/pnotes.inc
openemr/sql/3_0_1-to-3_0_2_upgrade.sql
openemr/sql/database.sql
Just a thought; "Sex" may require transgender definitions. Probably not worth "text w/add" ability, but logic might be problem. Currently can only be Male/Female, which would be legal status, and that can be changed.
In administration => list => it used to be that add was a possibility.
Our local situation is that often "they" use names of incomprehensible structure of father and mother First name and Last name is also often derived from a First name in the far history.
And when you import many patients it is possible that you do not know the gender. I used to add the gender unknown or undetermined and added this gender next to Male and Female, since it was obligatory.
(I never have been corrected by OpenEMR until I uses the gender: "YES"… …
The non existing patient was angry when she found the SEX to be YES…)
Currently, "sex" can also be set as undefined. However, if this is a required field then you must choose a value.
Beyond that you can alter the List values in via the Admin->Lists tool
You can also change the requirement of ‘sex’ via the Admin->Layouts->Demographics tool
Migrated the outcome and occurrence listings from the issues menu to list_options table. There was no simple way to place the actually issues themselves into the lists (file openemr/library/lists.inc), because of the multiple titles (singular, plural, abbreviation) and style entry.
Rod, note that I’ve internationalized the openemr/library/lists.inc file, so all titles and abbreviations are now translated. I noted you are translating your sports team and fertility clinic stuff, so I translated these also. I traced all files that use this data array, and nothing is broken by translating the titles (all your code uses the type or id, which is friggin excellent). It tested well in the sports team and fertility environment, although my testing is a bit limited because of missing tables needed for these customizations.
Here are the files i touched to do above:
openemr/interface/patient_file/summary/add_edit_issue.php
openemr/interface/patient_file/summary/stats_full.php
openemr/library/lists.inc
openemr/sql/database.sql
openemr/sql/3_0_1-to-3_0_2_upgrade.sql
openemr/interface/patient_file/summary/stats.php
openemr/interface/patient_file/problem_encounter.php
NEXT:
List wise, plan to start seeing if possible to utilize the drugs forms/units/routes/intervals listings. To help me out, are we actually using these lists anywhere yet (or solely stuff hard coded into openemr/library/classes/Prescription.class.php ) ? This is important to answer because I’ve noted a discrepancy on the lists that I’d like to change to make consistent with the variables in openemr/library/classes/Prescription.class.php . If your curious here are discrepancies:
—grams and micrograms are swapped in dosing (this is something you don’t want to confuse!!)
—also in routes the OS entry has a space before the ID of 5
Hi Brady, I’m pretty sure all the list types are used somewhere. Regarding drug attributes, I don’t recall offhand where exactly they are used but try looking at the scripts in the interface/drugs directory. Thanks!
Was hoping to get the immunizations into the lists. This would in effect possibly deprecate the immunization mysql table. This would be great for new users, but could be a data "confusion" issue with upgraders whom have modified their immunization table. The options seem to be (both are not very pretty):
1) Create a immunization ‘list’ and remove the immunization mysql for new installations. For upgraders, could place a toggle in globals.php that will allow them to continue using their previous ‘immunization’ mysql table. (I’m worried that older users may miss this step and in effect mislabel all of their immunizations)
2) Have the ‘immunization’ data from the ‘immunization’ mysql table information appear in the admin->lists like it’s a list. (this would require custom changes to lots of the lists functions so it acts like a list(in effect making this code more confusing for developers; a specific problem here will be that the immunization table is missing a ordering column)
Option 1 would be easy, but possible issues for upgraders. Option 2 would take a lot of work, and still with some issues. Not sure what to do here? Anybody have any better ideas or votes on above options.
I think you can use "INSERT … SELECT" syntax in 3_0_1-to-3_0_2_upgrade.sql to copy data from immunization to list_options. Check the MySQL documentation for details.
Rod’s idea works great. Here’s what I’ve got so far that works well in the upgrade script:
#IfNotRow list_options list_id immunizations
INSERT INTO list_options VALUES (‘lists’,‘immunizations’,‘Immunizations’,8,0,0);
INSERT INTO list_options (list_id,option_id,title) SELECT ‘immunizations’,id,name FROM immunization ORDER BY name;
DROP TABLE immunization; #EndIf
Working on trying to get a counter to number the ‘seq’ column before I commit the changes(also gotta test the source code changes required to transition the immunization list a bit more).
Soon the immunization table will just be a fond memory…
…