kevmccor wrote on Thursday, June 14, 2012:
OK, that one is totally objectified. How about another one that is more free-form, but still well organized?
deschel wrote on Friday, June 15, 2012:
Or, rather than re-creating the wheel from scratch, you can use an already established framework that has extensive features, has more power, has large usage, and is well tested - i.e. the MVC framework called Zend.
Smarty is not really a framework - it is a PHP template system with a lot of controversy, and is not as well respected. On the other hand, Zend is extensively used, and is very well respected. You can’t compare the failure of trying to use Smarty (a poor choice) as a justification of not trying to use Zend (a much better choice).
bradymiller wrote on Friday, June 15, 2012:
kevmccor,
Lots of stuff in the libraries directory:
acl.inc (access control functions)
amc.php (some AMC tracking processing)
api.inc (some form stuff)
appointments.inc.php (appointments functions)
auth.inc (authorization functions)
and so on…
Also some functions in custom directory:
code_types.inc.php (code set searching functions)
Perhaps a way to document these would be to standardize all the function headers and run them through a standard library documentation script. Then would have really nice documentation for developers (this would then likely lead to re-organization of libraries etc.).
-brady
OpenEMR
bradymiller wrote on Friday, June 15, 2012:
Hi deschel,
My point is not really meant to point out the failure of Smarty. My point is really that most of the OpenEMR codebase bug fixes, improvements and new features happen in the code that is not within any MVC/template/framework(as a code reviewer, it is important to note that most coding “failures”, meaning don’t get into the codebase, fall into these sections of the codebase). I guess a way to visualize it is, is that the development community is sort of like a river, and rather than go over large rocks (ie. anything that involves more work such as frameworks/templates/MVC’s), the river simply goes around them. Even with the current OpenEMR coding standards, it is not unusual for larger features to go through more than 5 code revisions before getting accepted.
Regarding Zend, I suppose a place to start is to point us to an example of use in OpenEMR or other open source projects on github that use it (then we can begin to garner an idea of what it does and looks like).
-brady
OpenEMR
yehster wrote on Friday, June 15, 2012:
A big part of the problem with the current calendar is that it lacks reasonable encapsulation. Functionality that needed to be used in each of the separate calendar views (day,week,month) is duplicated in what I would term “copy and paste style.” So to make changes to the “datePicker” requires modifications to each of the view templates individually rather than being able to make changes in a single location. I encountered this when adding the direct month selector to the calendar so very long ago. Similarly, to address the provider selector issue on iPad mentioned in another thread, the event binding for each of the view templates would need to be updated separately.
While Smarty may have influenced some of the design choices that lead to this arrangement, I think the old adage about the craftsman who blames his tools is appropriate.
As for Zend, this is a question asked on their “Zend’s Quick Start Programmer’s Reference”:
It would be a good idea to tell people what sort of things can be achieved with Zend, or more easily achieved with Zend, than with a straightforward and direct use of html/CSS/jQuery/PHP/MySQL. I did eventually stumble through to the next part of Quick Start (not sure how) and see that it is all pretty complicated and highly unlikely to work first time. What’s the reward?[/quote
I still haven’t found a satisfactory answer, and Dr. Eschelbacher, for your specific task of data import processes, I honestly think Zend would get in the way.
There shouldn’t need to be a lot of complex user interaction and this isn’t something that is going to accessed on a daily basis, so a slick presentation layer isn’t important or perhaps even necessary. If the base abstractions for manipulating data are written well, you could use them in both a simple command line utility and in a more sophisticated interface.
kevmccor wrote on Friday, June 15, 2012:
deschel - I am not going to create a framework - not at all (way over my head). I am going to try and put together more of a “style guide” that talks about a good organization pattern. I believe that lots of people could contribute, in big or small ways, if the code was more clearly organized. I’m totally certain there are great advantages to the Zend Framework, but there is one disadvantage - it is not used by the existing code (and it is unlikely that a large body of users or contributors would learn that or any other framework).
My idea, and I think Brady is talking about it, is documenting and discussing a small selected set of scripts that would be examples. Ideally the same functionality could be demonstrated with objective design and procedural design. I believe most people interested in contributing are users who want something. They are linear thinkers and put things together step-by-step in their own way. Example: contributor1 figures out how to create an interactive form, it gets adopted because it fills a need, and, forevermore, that is how it is done by contributor1 he now has his own “framework”. No one else really understands it or is willing to dissect it to the point of mastery. Later, another form is needed and there is absolutely no commonality because second contributor is not willing to imitate contributor1, for whatever reason. Then a user has some issue and no reliable way to interpret the code. I am fine with everyone writing their own stuff, but maybe we could get some basic style/organization formats that are not hard to use and that would help in many ways. If there are some digestible explanations of practical MVC they should be incorporated, and probably applied to core functionality.
To me, the single most important aspect of OpenEMR is open-source, with the idea that it is as accessible and useful as possible. Furthermore, in my experience, the best software is software that has been debugged and refined many times over many years. How does that happen if it is too cryptic or random to understand?
standardize all the function headers
forgive my ignorance, but does that mean the “javadoc” comment format, like
/**
* @param string $my_arg a word I need
* @return string the sentence I want
*/
and this goes right above the line
function my_function($my_arg) { … }
I thought “headers” are parts of big Chevy engines.
I am playing with PHPDoctor http://peej.github.com/phpdoctor/
and there is the more complicated phpdoc http://www.phpdoc.org/ that I have not looked at yet.
tmccormi wrote on Friday, June 15, 2012:
I’m very much in favor of Kevin’s approach, using PhpDOC to document each function/api and make including that part of the code review/acceptance process will provide two very big things:
1) Automatically generated development documentations (over time)
2) The documentation can be used to clean up redundancy and move towards a better “framework” in the general, regardless of the specific model…
It’s very hard to make good choices when you are mostly guessing about the potential effects of any changes, whether large or small.
-Tony
cipher-naught wrote on Friday, June 15, 2012:
I agree about the documentation. Documentation has always been a big part of how I think a large project should be organized.
I have created a separate thread Project Code Documentation and Style Guide to discuss since it seems like we have two conversational threads in this topic:
* Zend and MVC, and
* Documentation, Coding Standards and Styles
-cipher-naught
deschel wrote on Saturday, June 16, 2012:
I agree that Zend is overkill for the data importer. However, my intention would be for it to be a test for implementing the Zend framework. I have a list of 20 projects that I plan on implementing, many of them being interface oriented where Zend would make a big difference.
My next project involves creating a new contacts database for managing all contacts within openEMR, using one to many relationships for people and phone numbers and addresses. This would allow us to have a central database to store contacts for patients, secondary contacts, insurance companies, address book, users, etc. It is currently pitiful that Address book uses the table for Users to store addresses of contacts that are not Users. Part of this would require an overhaul of the demographic screen and the address book screen to support the one to many relationships of addresses and phone numbers.
Other interface projects that I am planning include improving the interface for display of patient information. The current one has serious problems, in my opinion, and is well behind that of commercial products. I would like to overhaul it to make it easier to use, and easier to navigate the patient chart. Also, I would like to introduce a customizable user dashboard, a feature many commercial products have, that is missing from OpenEMR.
I believe that using the Zend framework would make these interface improvements significantly easier to implement, and also allow for a cleaner more evolved interface.
I hope that no one is offended by my saying that OpenEMR’s user interface could stand to have much improvement. I feel that the Zend framework would allow more effective implementation of these improvements.
David Eschelbacher, MD
kevmccor wrote on Saturday, June 16, 2012:
I am not offended. Will you have a github or other way I could see some of how it is done?
Thanks
jcahn2 wrote on Sunday, June 17, 2012:
Ahoy David,
While you are thinking about a doctor-patient interface that is more “2012”, I want to make you of the suggestion I made about this over a year ago:
http://www.openmedsoftware.org/wiki/Interface_proposal My representations are the crude crayon model, but get the point across I think.
IMHO the current collection of disjointed forms that the doctor uses to document a visit is clumsy, non-intuitive, and below standard for accessing past information in real time face-to-face interaction with the patient. I believe it is the major turn-off for potential new users of OpenEMR and a royal PITA for current clinician users. And you are correct in saying that all the commercial EMRs have already figured this out.
I am encouraged to see you state that you have this project in your sights. Lets gets a thread started ASAP. A discussion of a split framed approach was started here:
http://www.oemr.org/phpBB3/viewtopic.php?f=5&t=115&p=659&hilit=frames#p659
No one should take offense at your comments. Sometimes it has to be your best friend to tell you when your fly is unzipped. Thanks for your comments and enthusiasm.
Jack
OEMR Board
sunsetsystems wrote on Sunday, June 17, 2012:
Googling to find the Zend Quick Start that Kevin references, I ran across this interesting reading at the top of the search results:
http://www.alexhudson.com/2012/03/24/a-fond-farewell-to-zend-framework/
tmccormi wrote on Sunday, June 17, 2012:
I haven’t looked a ZF2 at all, but that does not look promising… 
-Tony
deschel wrote on Sunday, June 17, 2012:
ZendFramework is tricky but may still be beneficial. It the near future, ZF2 will be their main focus. Unfortunately, ZF2 does not appear to be close to be ready for prime time.
In the article, he did note that ZF2 fixes many issues that are problems in ZF1.
The author’s issue is the complexity of the skeleton and the difficulty in using ZF2. If you read the comments, ZF2 is not in final release stage yet. There is a good chance that the skeleton and configuration issues will be addressed by the time it is ready for final release.
It is not in the company’s interest to make it difficult to migrate from ZF1 to ZF2 (although I know that does not mean programmers always act in the company’s interest 
.)
ZF1 is still a widely used and powerful product. And, in the future it probably won’t be too difficult to migrate to ZF2 once they iron out the kinks and it becomes more established. I still don’t think this is a reason to summarily dismiss ZF1.
Bottom Line: if we submit the data importer utilizing the ZendFramework more as a proof of concept, with lots of documentation so that people can see how to implement software with ZendFramework AND the data importer works well, will you approve the code and allow it to be added to the master ?
Then, at a later date, if it becomes too much of a mess, and no one uses the framework for anything else, and it does not help in implementing my other interface projects, the data importer code can be converted to not use the ZendFramework, and ZendFramework libraries can be eliminated from the project.
By the way, according to the other thread, someone was already developing code to use the ZendFramework, I believe for the lab module. What happened to that?
David Eschelbacher, MD
deschel wrote on Sunday, June 17, 2012:
As far as interface, I do and will create another thread.
I would be interested in addressing the encounter interface down the road, but first want to focus on demographics.
Demographics first because my first implementation of openEMR will be to use it as a scheduler before I start doing clnical notes.
More to come.
David Eschelbacher, MD
sunsetsystems wrote on Monday, June 18, 2012:
David, if you want to do the importer with Zend I think it could at least go into the “contrib” directory. Just make sure it’s separately installable, and I suggest making sure it works with ZF as distributed with Ubuntu to simplify installation in that case.
If the importer becomes truly compelling, we may decide to endorse Zend or someone might convert it to some other model. There are always options, and we like to encourage contributions.
bradymiller wrote on Monday, June 18, 2012:
Hi,
Jack and David; a framework is not required to get what you want for improving/refactoring the user interface. Just need resources(ie. funding) to get what you want. There was a time not so long ago when there was not even a Patient Summary screen, but MI2 stepped in and contributed man hours to make this happen. The only thing needed to have a centralized user interface/form to improve workflow is very simple; and that is resources to build it. What is more important? Attaining the set of features you are trying to accomplish or controlling the specific mechanics on how it is done?
BTW. Also agree with Rod on the import code. We rarely turn away contributions in any form and it would be a nice way to introduce Zend code into the codebase without needing to include the Zend footprint (then the community can take it from there).
-brady
OpenEMR
yehster wrote on Monday, June 18, 2012:
I agree that Zend is overkill for the data importer. However, my intention would be for it to be a test for implementing the Zend framework. I have a list of 20 projects that I plan on implementing, many of them being interface oriented where Zend would make a big difference.
I don’t think it’s just overkill. I think Zend is the wrong paradigm (MVC) for what you are trying to accomplish.
Read up on ORM: http://en.wikipedia.org/wiki/Object-relational_mapping
and tools like doctrine: http://www.doctrine-project.org/ or http://www.propelorm.org/
If you build from something like this, you will get a foundation of reusable objects which you can still use later in a MVC framework on top of ORM. Defining mappings between entities using ORM means you can have things like collections of addresses belonging to people.
jcahn2 wrote on Monday, June 18, 2012:
Ahoy Brady,
Yes, I’m sure funding turns dreams to reality. “Money doesn’t talk, it swears”, Bob Dylan. I was just trying to steer this deschel chap’s enthusiasm toward my own priorities ;>)
Jack
OEMR Board
bradymiller wrote on Monday, June 18, 2012:
Hi Jack,
I completely agree that your feature request is rather vital; ie. a real time templating workflow to build a note. I have noted some commercial EMR’s have gone rather overboard on this, though (for example, have you ever tried to decipher notes from EPIC; total pain for docs, but guessing great for billers).
(perhaps should migrate this discussion to another thread)
-brady
OpenEMR