FreeHealth / freehealth

Free and open source Electronic Health Record
https://freehealth.io
Other
44 stars 16 forks source link

EHR doesn't take into account updates of forms added in user Documents folder. #93

Closed jeromecc closed 6 years ago

jeromecc commented 7 years ago
  1. Add a well formed form directory into 1 of the 2 user form directories: ~/$USER/freehealth/Documents/forms/subforms ~/$USER/freehealth/Documents/forms/completeforms
  2. Restat the application.
  3. Add the new form to the current form structure.
  4. It is integrated in the database.
  5. Stop the app.
  6. Modify the same form, bump the version
  7. Start the app
  8. Nothing happens. The modifications of the form are not included in the database.

Workaround: delete the fmf_xmlforms database, it will be recreated automagically without any intervention on your part from the forms inside the application folder and from the modified version of your modified form inside Documents/forms

jeromecc commented 7 years ago

EHR complains about the fact that the file of a form added to database through Documents/... doesn't exist in the app forms folder: ERROR(xmlformio.cpp:129) File /home/$user/git/freehealth/global_resources/forms/subforms/simplest/central.xml does not exist"

jeromecc commented 7 years ago

This is a big mess. We just want to put a few files in a database and be able to update them if they change... how is it possible that this requirement becomes such a mess? Ok.

Simplification:

Pull mechanism:

Base everything on a real uuid: the name of the form "this::is::a:form::that::does::this", not on path names. Directory structure should be there only to help developers. In practice, forms (MedForms) are independent, discrete entities. They should be organized in a tree structure independently from their own content. Embedding forms inside forms to organize the tree structure leads to a complete mess that is impossible to maintain because the data is at two different places: inside the xml structure of the forms themselves, and in the fmf_episodes (why???) database: FORM_FILES table. The data about the structure should be kept in one place. Each user should be able to have her own structure (with a visual clue that other forms exist for this patient), adapted to each patient.

jeromecc commented 7 years ago

FreeHealth will switch to problem list and 3D data visualization as the main entry points to data. Forms skeleton/structure will not matter much. Recursive forms (1 MedForms inside another MedForms) is a nice idea in theory but it leads to an incredible mess. Tree structure should be used to classify forms, not to classify medical data.

jeromecc commented 7 years ago

during MySQL/MariaDB install forms are copied to freehealth folder but they do not appear in the selection list. fmf_xmlforms database is empty.

jeromecc commented 6 years ago

Clean way to manage extra forms on Linux would be to add code to check /usr/local/share/freehealth/forms <- host specific forms managed by system administrator in addition to /usr/share/freehealth/forms <- standard forms installed by package manager

jeromecc commented 6 years ago

About staff group in Debian

staff: Allows users to add local modifications to the system (/usr/local) without needing root privileges (note that executables in /usr/local/bin are in the PATH variable of any user, and they may "override" the executables in /bin and /usr/bin with the same name). Compare with group "adm", which is more related to monitoring/security.

jeromecc commented 6 years ago

Summary: user form code was commented out and incomplete. It will be removed in a future release. I added local(Sub/Complete)Forms code that will allow a local Linux admin to add forms inside /usr/local/share/freehealth/forms This will do for v0.11 until a complete rewrite of forms architecture in a future release.