At the 6/8/2016 OEMR organization board meeting, it was decided to create a Roadmap Committee to begin looking at pursuing community driven roadmaps. There are 2 separate entities, the OpenEMR Project and the OEMR organization, which will have separate roadmaps. However, since the main goal of the OEMR organization is to the support the OpenEMR project, it makes sense to develop roadmaps for both of them in unison.
At the 6/8/2016 OEMR organization board meeting, it was decided to create
a Roadmap Committee to begin looking at pursuing community driven roadmaps.
There are 2 separate entities, the OpenEMR Project and the OEMR
organization, which will have separate roadmaps. However, since the main
goal of the OEMR organization is to the support the OpenEMR project, it
makes sense to develop roadmaps for both of them in unison.
The OEMR organization created a Roadmap Committee, which is open for
anybody to join (you do not need to be a OEMR member; just let me know and
I’ll put you on the list): OEMR wiki page - OpenEMR Project Wiki
Matrix’s roadmap is linked on the wiki page I posted above and will be an
excellent starting point. If need the direct link to it, here it is: Matrix Perspective - OpenEMR Project Wiki
I updated the OpenEMR roadmap. I basically used Matrix’s roadmap as a starting point and added information regarding which items have already been completed or that have code undergoing code review.
There are definitely items missing on the list and perhaps some that the community don’t think belong on the list. Anyone, please feel free to post suggestions/recommendations here and will modify the roadmap accordingly: http://www.open-emr.org/wiki/index.php/Roadmaps
At this point, there isn’t much stuff on there that either isn’t being worked on or is vital. Please post suggestions on things that could be added to or improved in OpenEMR. I’ll then update the roadmap and use this list for those companies to work on. Note this list is also what the OEMR organization will use when it has money to fund development.
In my view it’s a no-brainer as to what the most important item is: refactor existing data access logic into a PHP data object model. I see Scott has taken on “Consolidate PHP libraries”… does this have any relation to that? Either way, help will be needed there and I can definitely offer guidance.
Thanks for the input. I updated the roadmap to include the Modernization items (and also strategically placed links to the Modernization roadmap). It is nice keeping the Modernization roadmap separate because that is more of a project tracking tool that is focused on modernizing OpenEMR(whereas the standard roadmap is just a quick snapshot in order to quickly find things to work on (for volunteers, companies, and OEMR organization).
Rod and Matthew, let me know if current Frameworks section covers your input.
I also placed a ??? for the items that don’t seem to belong on the roadmap. Let me know if think should keep those items on.
And most importantly, are there any more items that should be added. There is at least 1 company that is looking for something to do(just starting with OpenEMR, so wouldn’t make sense to do something for difficult like php data models) and at this point don’t have anything there for them to work on.
Thanks Brady. Not sure I get the DAO reference. Isn’t that Microsoft? Not really asking you, but whomever that came from. In any case we want a PHP solution.
I dunno about the ??? stuff either. I guess it depends on who takes an interest and what they want to do.
Not sure I agree that data models are beyond someone starting with OpenEMR. I can easily see someone doing research into one or more tables, learning how and where they are used, asking some questions and documenting a proposed approach for an object model. It would be a good way to learn some things quickly. Of course if you are also just learning PHP and SQL, then no.