In our public repository we will be placing partial commits for some of the new features that we have put in production. Creating PR compatible with current standard code may be delayed or may not happen due to various reasons. But we hope that if someone else sees benefit, they can put in extra effort to incorporate code blocks into a standard PR.
Demographics v5+ : Title block (0)
This commit provides 2 changes:
Main title frame will load patient and encounters information without need for loading of demographics frame. Currently the title frame calls demographics which then updates the patient data in title frame.
Instead of loading encounter and document history, we automatically load the last encounter. For many practices, it is common to have patients with 50-100 encounters.
Not included in this commit are changes to demographics.php - that remove code that fills patient & encounter blocks.
Demographics v5+ : Deconstruction (0)
This commit is first step towards making patient demographics screen flexible.
Patient dashboard is most frequently used interface component. All users need ability to add/remove and rearrange components that they use. Unfortunately current structure does not lend itself to any flexibility.
For starters, this commit :
Deconstructs existing code into fragments with a requirement that each fragment (for now) have its php, html and scripts in a single file.
Introduces a class that is used for constructing fragment objects.
Maps the page into an array making it possible to add/remove or rearrange the fragments.
In next step, these fragments would become providers of data for one of the views of underlying emr objects.
I looked briefly through the code and anything that breaks large massive files like the demographics.php into smaller logical chunks that can be better reasoned about is fine by me.
My understanding is that you are not wanting to make this into a pull request at this point? Is that just due to concerns about meeting PSR2 standards or what?
I actually like the approach of the fragments because it allows us to filter those array components using the event dispatcher if we want to extend / customize this via module extensions.
Just my 2 cents.
Stephen: These commits are based on our fork at 5.0. In the past we have tried to provide PRs of individual features that got obsolete - (e.g. in the code you will notice include for globals.php does not have hard coded path) . We also have switched to latest bootstrap 4 and will soon move to standardized view classes targeted for tablets.
As the forks diverge, creating each PR becomes prohibitively expensive. At the same time we feel the standard code could use these as hints/suggestions or just our 2 cents worth of contribution to this good project.
Been awhile since i’ve boned up on bootstrap. Can BS3 and BS4 coexist? I’m all for anything that breaks down demographics especially from a performance point of view. Also if BS4 is the goto for better responsiveness then am onboard as well. So how difficult would it be to stage BS4 into codebase?
Didn’t try but I suppose the script injector can be directed to select specific version. Good news here is BS isn’t widely used in the project as your efforts show.
Performance issues in current 2000 lines of demographics.php are architectural - it tries to do everything for everybody. As an example, if an user while reading messages wants to see documents for that patient, they go to demographics which loads issues, appointments (2-3 times), all encounters, all issues, prescriptions and birthday cake . As a bonus, the rules popup 2-3 alert boxes that need to be closed before they can click to see list of documents by category. If that patient has 50-60 encounters and 100+ documents, this check takes more than few minutes.
Then the user moves to the next message for another patient!
Now that basic rant is over, as far as demographics is concerned, BS version is not an issue - towards the end there are 4-5 lines that do overall remapping that can be removed in standard code. Bulk of the effort will be :
- Validating if fragments is the approach community wants to take
- Explode current (5.0.2) code to their respective fragments (php, js and html)
- Test full set of fragments and then possibly with few fragments removed from the array.
Effort for RTop is basically removing code from the updaters/callers without impacting frames users. We have removed left_nav from our code and have no idea if anything breaks there.