Hello, I’m new to this community. I’ve been reading the wiki and looking into the code base for almost a week now, and I’ve to say you guys have been doing outstanding job and its really great community to join.
However, going through the code you can see that its shown its legacy and there is no clear separation between presentation and application logic, PHP, HTML and SQL are all together, which make it really hard for new developers to join the project.
Migrating an existing application to a framework can be a daunting task, especially if the migration must occur all at once; however, I see that ZH Healthcare incorporated Zend library into the OpenEMR codebase for Module Installer. This should be the starting point where new features should be created using ZF2 then later start refactoring the existing code bit by bit into ZF2.
I know its a long journey, but it has to start somewhere, and I know it will not have immediate affect for users, but it will for long run make the developers life much easier and attract new developers to join the community which in return will reflect on OpenEMR users.
Sorry for the long post or if what I said doesn’t make sence or repetitive, But I see big future for this project and I’m glad that I’m officially joining this community today and I hope I can be some sorta of help to the growing OpenEMR community
Piecemeal modularization of code does seem to be a good first step. The problem with focusing on frameworks is making a wise choice, and the risk of better ones coming along later. Good code can be migrated more easily to any framework.
That said, what is your experience with ZF2 and other frameworks?
Lately I’ve been working symfony, and I have worked with ZF2 before, I agree that the choice of framework is critical. I brought up ZF2 framework even knowing it require steep learning curve compare to other frameworks because:
its already used in OpenEMR for module installer
ZF2 is light years ahead of any other PHP framework when it comes to Object-oriented Goodness
its decoupled nature comes handy to integrate with other libraries and classes (e.g. smarty templating system which is used in OpenEMR), also ability to integrate ZF2 with legacy code in OpenEMR, then start refactoring and rewriting the project over time.
My point here is not about framework itself, instead I’m talking about legacy spaghetti code in OpenEMR that need to adhere to PHP modern best practice in order for this project to prosper and grow into something much bigger.
I think that a better model would be to start creating a new RestFUL API that runs in parallel with OpenEMR and can be developed with first principles. Choosing the base tools to do that with should be done carefully and with the community of developers after deciding on a set of “Prime Directives”
The OEMR.org is working on a draft of that right now. I’m here at OSEHRA with some great Open Source minds and have been taking notes to supplement our thoughts on the road ahead.
Expect to see the results of that early next week,
The time is now to start that process and it can be done without disrupting the current code base using a method known as Sistering (or sometimes called Strangler Vine Development)
Although I do not want to get into a debate, Yii framework is pretty good and reduces development time quite a bit. I have used that with reportico for reporting successfully on a big healthcare portal project. Let me know if I can help in anyways.
@Abdul, ZH spent lot of effort in getting zf2 in the standard codebase. Most of that effort was to provide interoperability with legacy code.
If you have ZF2 architectural expertise, community will benefit tremendously if you spend some time looking at what’s in here, understand / question the choices made and comment on if current setup is what a typical zf2 developer will expect when starting to maintain this package.
Hi Mark,
This and the related layout editor are major features of OpenEMR that are heavily used. What specific obstacles are they causing?
-brady OpenEMR
Mark I read your Comments one thing if you would remove My comment from the title
Negative comments on this functionality Since it was not negative I was asking a question on how to use a new feature.
Terry
User looking for information on how to hide demographics using layout engine
Can someone tell me how the feature for hiding a field works and will it work for the demographics form. I am trying to keep a field from being displayed when there is information in the SS field.
Go to Administration/Layouts/Demographics to change field to Unused in the UOR column. This will hide the particular field irrespective of entered data.
Users in the past have made the mistake of deleting fields in the layout_options table. To their dismay, this maneuver is the quickest way to temporarily toast OpenEMR.
Hi,
Medmasterpro api project went stale 2 years ago because not enough resources to review the code. I was reviewing this in the past but had to prioritize my resources to MU2 items and nobody else was able to continue the review. I just noted the github code link was broken, so updated it.
-brady OpenEMR
Your comment is important to document the evolution of the feature. I have renamed to the section so that it does not imply that all comments are negative.
This file now exists in the OpenEMR repository, but LBF renders it utterly useless and worse, misleading to other new developers. The reason it is useless is because those field names in Robert’s patient class are taken from the database table patient_data. However, LBF can add new fields or change the name of old ones, rendering any code that depends on this class obsolete in a particular installation.
Creating a representation php class for a patient is the very first thing anybody who begins studying the OpenEMR source code would like to do, as Robert appears to have done.
The problem is that LBF’s current implementation destroys any notion of a canonical Patient representation.
It’s really a problem of dependency management. Pretty much everything in OpenEMR depends on information about patients, but LBF’s current implementation undercuts that dependency by making a nice gui where users can unilaterally and without warning or understanding destroy or rename the information that various other parts depend on.
Thus my contribution thus far has been to identify some of the issues around improving the most simplistic and basic task of OpenEMR, collecting patient demographics.
Note that the library/Patient/src/Patient.php file does not exist in the openemr codebase:
Note above commit is not associated with any branch and it’s not in the openemr codebase. I think this may happen when a there is a pull request for code.
I wish to interject a physician’s point of view regarding the Layout Based Visit Form.
Our office had only a 3 month window of time from initial download to going live. Were it not for the LBV form, everything would have ground to a halt.
The SOAP note & other contributed forms do not meet the needs of the average Ophthalmologist. The various Eye forms would have been well-nigh impossible absent the LBV form. If we can’t record our findings, the EHR is dead in the waters.
OpenEMR, being open source, lends itself to easy customization. Perhaps at times it’s too easy; when users, who don’t know what they are embarking upon, over-tinker to the detriment of the application. There is nothing like a white screen of death to instill a healthy sense of respect.
Once I asked a patient who had been an IBM employee why programs become corrupted. He replied that there are million lines of code for an application, written by different people who often don’t coordinate their efforts.
The same situation must be true in the open source community.
Is the expectation of an equivalent of the Hammurabi or Napoleonic Code realistic?
I for one think free is pretty darned good & wouldn’t mind if the codebase is not nearly perfect.