The benefit of doing this with a module is that the full OpenMRS application is still available to you. We recently had a demo from a Lance Armstrong-funded project where they developed a patient health record (PHR) atop OpenMRS within a module that completely replaced the UI of OpenMRS.
-Burke On Thu, Sep 1, 2011 at 1:05 PM, Dave Thomas <[email protected]> wrote: > Hi. I just wanted to second this, there are many examples of alternate > interfaces that have been built on top of the openmrs api, like the > touchscreen registration module we're running here in rwanda, or the mdrtb > module. I've also in the past built a deidentified data entry interface for > a large epi study based in lima. These are all examples in which the user > doesn't have to (or can't) interact with the default ui at all. In some > cases the interface seen by the user is role-based, meaning that you can > have totally different interfaces for different real-life roles against the > same implementation. > > D > > Glen McCallum <[email protected]> wrote: > > >Hi Thang: > > > >You might want to consider the user interface layer of openmrs separate > from the server platform openmrs. About 80% of OpenMRS is application server > and database software and it is decoupled from the web layer. > > > >From what I've observed (anyone, feel free to correct me) the user > interaction with the system was designed around a certain workflow. This > includes clinicians filling out paper forms then … later ... data entry > clerks transcribing those forms into the system (retrospective capture, as > Andy said). > > > >So if you're considering "physician point-of-care electronic > documentation" around specific topics … it might be worth developing your > own web layer and communicating with the OpenMRS server platform via the > Rest API. This would support your unique workflow and, in addition, you > could make the program appear very basic/simple to the end user. > > > >regards, > >Glen > > > >On 2011-08-23, at 3:30 AM, Andrew Kanter wrote: > > > >> Thang, > >> > >> There are many ways to hide the complexity of OpenMRS but continue to > use the application and database as the back end. In MVP, we are using > OpenMRS in all 10 African countries, with different applications for > different users at the front end. Our Community Health Workers use > ChildCount+ (RapidSMS) and this feeds into OpenMRS. Our clinics use OpenMRS > primarily retrospectively, although we are looking at prospective entry for > immunizations and children in some places. We also use ODK and xforms to > capture Verbal Autopsy data and this all goes into OpenMRS. > >> > >> Happy to discuss and will definitely be in Kigali. > >> > >> Andy > >> > >> -------------------- > >> Andrew S. Kanter, MD MPH > >> > >> - Director of Health Information Systems/Medical Informatics > >> Millennium Villages Project, Earth Institute, Columbia University > >> - Asst. Prof. of Clinical Biomedical Informatics and Clinical > Epidemiology > >> Columbia University > >> > >> > >> Email: [email protected] > >> Mobile: +1 (646) 469-2421 > >> Office: +1 (212) 305-4842 > >> Skype: akanter-ippnw > >> Yahoo: andy_kanter > >> From: Thang Dao <[email protected]> > >> To: [email protected] > >> Sent: Tuesday, August 23, 2011 3:53 AM > >> Subject: [OPENMRS-IMPLEMENTERS] Médecins sans frontières (aka Doctors > without borders) interest in OpenMRS > >> > >> Dear Implementers, > >> > >> We at Médecins sans frontières are interested in using OpenMRS data > model > >> to underlie our new generation of medical data collection tools. > >> > >> More and more of our operations are dealing with chronic diseases and/or > >> states of malnutrition. > >> > >> To support following up our patients, we are thinking of introducing a > >> medical record system in a pervasive way, yet masking out the > complexity. > >> > >> Thus our strategy is to opt for OpenMRS data model, yet introducing only > >> part of what is needed only, because our field users are not computer > >> literate. > >> > >> For instance, for our "Street violence" project in Honduras, we collect > >> data about young children living on the streets (name, sex), the type of > >> abuse they were victims of (sexual agression, ...), when it occurred (1 > >> hour, 6 hours ago...) and the treatment we provided (basic care, > bandage, > >> condoms distribution, ...). > >> > >> We meet the children again and then collect more data on the encounter. > >> > >> Since strolling the streets of Tegucigalpa with a laptop is the surest > way > >> of being mugged, we tally the children with a paper form and a digital > pen. > >> We go back to the point of care, download data into a CSV file, upload > the > >> file in a local data repository which we would like to build according > to > >> OpenMRS data model. We use QlikView to provide immediate synthesis / > >> analysis of data to local social workers. > >> > >> So the question are: > >> > >> Is this a viable option? Keeping the full fledged data structure in > the > >> database engine, yet feeding it only with data related to operation at > >> hand? > >> If yes, who has experience rolling out OpenMRS that way? > >> If your anser is Yes to question 2, are you going to Kigali? We would > >> love to go, but our budget is tight so we need a compelling reason. > >> > >> > >> Cordialement / Best regards / Freundliche Grüsse > >> > >> Thang Dao > >> Directeur Systèmes d'Information - Médecins sans Frontières (Suisse) > >> Information Systems Director - Doctors without Borders (Switzerland) > >> Informationssystem Leiter - Aertze ohne Grenzen (Schweiz) > >> Rue de Lausanne, 78 > >> 1211 Genève 21 > >> > >> +41 (0)22 849 8996 > >> _________________________________________ > >> > >> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail > to [email protected] with "SIGNOFF openmrs-implement-l" in the > body (not the subject) of your e-mail. > >> > >> [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] > >> > >> > >> Click here to unsubscribe from OpenMRS Implementers' mailing list > > > > > >_________________________________________ > > > >To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-implement-l" in the > body (not the subject) of your e-mail. > > > >[mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] > > _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
