Burke … Lance Armstrong demo on the implementers call … please? Glen
On 2011-09-01, at 10:51 AM, Burke Mamlin wrote: > 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] > > > 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]
