My apologies for the slow reply on this one, returned from vacation yesterday. This is not really tied in with the atom feed stuff. The Atom Feed module just notifies of events that have occurred in openmrs. MoTech will listen to these events and react to them. (either updating their local dictionary by making a ws call or ignoring the change as not relevant).
The plan is for MoTech to push data to openmrs via web services. This puts all decisions about how to relate the motech datamodel to openmrs on motech's shoulders. That said, I'd suggest using active lists for this. I was going to make that rec but Roger beat me to it (by 8 days). The motech integration piece will be required to run openmrs 1.8.1+, so if this module is specifically for that installation as well, you have no problem. The only issue then is support of active lists by xforms and your mobile app. If thats not feasible, Darius' suggestion of only storing an obs/encounter if the obs value has changed is the next best choice. You can then be guaranteed to to have support by xforms and mobile. And you will only have a large number of encounters if the child is swapping back and forth between immunization suggestions daily. What you do lose is the ability to know how ofter a child was polled for this, but I don't see that being a reporting question. Ben On Mon, Apr 30, 2012 at 3:41 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < r...@cdc.gov> wrote: > Exposing things through webservices is quite easy and now's the time. > If you need help, let me know. Now if this is tied in with Ben's atom > feed, I'm not up to date on what/how that's doing.**** > > ** ** > > *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Andrew > Kanter > *Sent:* Monday, April 30, 2012 10:50 AM > > *To:* openmrs-deve...@listserv.iupui.edu > *Subject:* Re: [OPENMRS-DEV] what could be the best scenario for saving > patient cohors observation ?**** > > ** ** > > Mmm. Interesting. I think the active list approach makes sense in terms of > what OpenMRS might want to expose to the application layer or potentially > even other applications. I don't know how we'd do that though as since we > are on 1.6 we don't have much experience with them. Using programs seems > like a bit of an overkill though, and provides another issue about exposing > them through webservices. I wonder what Ben W would think of this question > given his understanding of where we are going on the > OpenMRS-MoTech-CommCare front...**** > > ** ** > > 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: andrew.kan...@dbmi.columbia.edu > Mobile: +1 (646) 469-2421 > Office: +1 (212) 305-4842 > Skype: akanter-ippnw > Yahoo: andy_kanter**** > > ** ** > ------------------------------ > > *From:* "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <r...@cdc.gov> > *To:* openmrs-deve...@listserv.iupui.edu > *Sent:* Monday, April 30, 2012 9:43 AM > *Subject:* Re: [OPENMRS-DEV] what could be the best scenario for saving > patient cohors observation ?**** > > > > **** > > So why not create an immunizations active list that shows the most recent > status for each vaccine-preventable disease? Or treat each VPD as a > program and record only state transitions between up-to-date, needs > immunization and series complete? This last is probably best for computing > clinic-wide coverage.**** > > **** > > *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Andrew > Kanter > *Sent:* Friday, April 27, 2012 4:55 PM > *To:* openmrs-deve...@listserv.iupui.edu > *Subject:* Re: [OPENMRS-DEV] what could be the best scenario for saving > patient cohors observation ?**** > > **** > > So to add on to what Ben has described...**** > > **** > > What we are looking for is something like the the active problem list > functionality to carry the current recommendations for immunizations. Right > now we are stuck in having to save this information as OBS. To do this, we > either append an OBS to a current encounter with the recommendation in a > concept, or we create a new encounter to hold the OBS. The issue is that we > expect to run the recommendation algorithm nightly or weekly. This would > create a ton of unwanted encounters if each time we created a new encounter > from the procedure. If we update the OBS for an existing encounter then we > have the issue of the encounter date either not matching the OBS date, or > by changing the encounter we break a rule of EHRs but essentially deleting > the old encounter and creating a new one with the current information.**** > > **** > > The last quirk has to do with the xforms module and the past medical > history display. If we decide to just keep appending the OBS to an existing > (older) encounter... will the obs display in reverse chronological order in > ODK display or will it look only at the encounter date (not the obs > datetime) and display all the OBS for that encounter on the first page (not > workable).**** > > **** > > Thanks for the advice! > Andy (and Ben)**** > > **** > > *-------------------- > 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: andrew.kan...@dbmi.columbia.edu > Mobile: +1 (646) 469-2421 > Office: +1 (212) 305-4842 > Skype: akanter-ippnw > Yahoo: andy_kanter**** > > **** > ------------------------------ > > *From:* benjamin rukundo <ben.ruku...@yahoo.fr> > *To:* openmrs-deve...@listserv.iupui.edu > *Sent:* Friday, April 27, 2012 4:14 PM > *Subject:* [OPENMRS-DEV] what could be the best scenario for saving > patient cohors observation ?**** > > ** ** > > Hi all, > > I'm working on the immunization module, and the module provides > immunization recommendation for patients, currently we have expanded the > immunization recommendation to be accessible on mobile phone so the > immunization recommendations are saved as text data type in obs table and > these immunization recommendations are downloaded from a mobile phone to be > viewed. The idea is to save the immunization recommendation for a cohort of > patient eg children < 5 years old. > > instead of saving new encounter for each audit date on a daily or weekly > basis to get the latest immunization recommendations which will create many > encounters for one patient > 2 options are proposed > > Option 1) we create an "immunization recommendation" encounter if not > already there. If one exists, we append a new obs with the date of the > audit. > as new audits are done, we simply append new OBS to the same old encounter > but save (obs_datetime) with the audit date as the OBS date > > Option 2) we do the same as option 1 but change the encounter date to the > current audit date. > > On the phone, we should only view OBS information (the historical > information) for a given concept not sure if this sorts by OBS datetime or > encounter date time ? > > Thanks**** > > **** > > Benjamin RUKUNDO**** > > EMR Programmer**** > > MVP-Rwanda**** > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > **** > > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
