Hello OpenEMR community! I previously had a number of questions for our own implementation in Armenia, which were most helpfully answered, and we’ve since narrowed down our options to OpenMRS and OpenEMR. We would like to know generally speaking how long an ophthalmology build of OpenMRS typically takes to implement, including specific phases (e.g. system and hardware installation, system modification and module creation, staff training, etc.). Any help and insights from your past experiences would be most appreciated.
We’re particularly interested in the specific phases that other implementations have used.
The organization we’re working with does not have an in-house developer or IT staff, but has a good relationship with an outside developer who’s already built a separate system for them with a narrow focus. IT staff are third-party contractors. The EMR would need to be implemented at at least four sites (three regional clinics and the main office), with no more than three users at each site. Most of the early assessment work has been done, and we’re investigating the timeline starting from the decision to begin work on the system.
Our current model consists of approximately 2 months of work on a pre-production build for testing with select medical staff over 1-2 weeks, followed by another month or so of work on a final build. We don’t anticipate staff training on the launch version taking more than 1-2 more weeks, so we are estimating (hoping for) a primary implementation period of approximately 4 months, after which the developer will work part-time to address the inevitable avalanche of feedback from every user on an as-needed basis.
Does any of this seem reasonable? We’re counting on using existing modules as much as possible, though ophthalmology-specific tools may need to be built on our end.
Our experience with implementations is that the delivery chain is as heavy (if not heavier) to put in place than organising the actual development work. If it was only about sitting and coding…
By that I mean the ability to develop, stage, test and deploy versioned distributions (=a custom flavor of the EMR). Leveraging existing modules is certainly the way to go, but OpenMRS modularity and the web of interdependencies that it implies between artifacts adds a level of complexity that requires to be thoroughly managed.
If an effective delivery chain is not in place, it can become overwhelming to push through just a simple patch once the system is in production.
If the above has been factored in, then yes, your timeline seems reasonable.
This exact issue you describe is why we plan to have the single individual, whom we met and ran this by, be in charge of the development side of the EMR (she has a team at her disposal, but it seems likely that she will do it herself). Facilitating the deployment of updates and modifications is also one of secondary reasons we are recommending that the organization use in-house servers, with a parent /admin at the main office that the developer can have direct access to. The existing (specialty-specific) database is currently hosted in Canada, and given the unreliability of local internet access we’re shying away from solutions that take constant connection for granted.