On Sun, 2015-12-06 at 08:40 -0500, Marc Murray wrote: > On Wed, 2015-12-02 at 21:25 -0200, Roberto Novaes wrote: > > > Hello to all! I have sent a similar message to health list but with > > a different purpose. Only the same paragraph is the same. > > GNU Health has modules dedicated to the monitoring of neglected > > tropical diseases (dengue and chagas so far). We are working here > > Brazil to automate the process of data input into the system. > > Instead of using the desktop interface, we are studying the > > following possibilities: use a super simple tablet or a paper form > > that will be scanned. Those solutions would be used on the field by > > the health workers. Our first area of work would be to register > > dengue related information, which is, together with chicungunya and > > zika, major health issues in Brazil caused by Aedes Aegypt. > > > > > > We are thinking of two alternatives: > > > > > > 1) Use a super simple tablet, that would display a list of places to > > visit (like the Domiciliary Units). The user would, then, open a > > form to input the data colected regarding that place. This data > > would later be exported to a csv file to be imported into GNU > > Health.We are studying android development with SQLite to do that. > > > Maybe I'm biased because I don't know Android development, but I think > a web application may be more accessible than an Android app. > > I'm thinking that you could get away with using HTML5 and localstorage > for offline access. The synchronisation would then take place when the > device goes back online. Except, it would be through the same web-app > instead of CSV. > > To do this you could use flask-tryton [1] and you would need some > Javascript goodies to handle the localstorage part. > > And then there's this library I've heard of, but haven't used, called > wq [2] that seems to be designed for this kind of thing - through the > web.
I do not know a lot about Android development either. I will start to research the alternatives you have mentioned. I think, though, that an offline data storage is necessary for the following reasons: 1) You do not have to have a connection.Equipments without 3G technology are cheaper. Even if the price was the same, we cannot count on internet connections all the time. It also saves us battery life. > > 2) Use a paper form that could be scanned and the data collected > > would be also imported directly into GNU Health. We are studying > > sdpas to do that --> http://sdaps.org/SDAPS > > > If you (we) can pull off the web based interface as above, then we > could also provide some kind of web-service interface that will allow > the OCR and other machines to be able to submit data - without > understanding Tryton. Ok. I think a good point is to isolate the data format exported from the machines from Tryton implementation. I think a middleware layer is necessary or a good idea. > > GNU Health would have to make the process of generating the places > > to visit on a day to each health worker automatic. > a report? I am thinking of the following process (at least, in Brazil in the places we have visited and done some research the process goes as follows): each agent is responsible for an area (usually 1000 domiciliary units). The agent visits each DU under his responsability until it has visited all of them. The whole process usully takes 2-3 months. Usually an agent can visit 20-25 dus/day. Sometimes the du owner is not home, or does not allow the agent to enter the house. This situation creates two possibilities: to revisit the du on other time or, after some tentatives, if the owner is continuosly absent or refuses to allow the entrance of the agent, some judicial measure must be taken. The idea is to have a general list of du/agent. The processes would then be to create the daily list, to update the general list according to the visits and their statuses, to regenerate the daily list. This daily list would contain 20-25 du to visit, including the ones not visited on the current cycle, and the ones where the visit was impossible due to absence or denial of the owner. > I love it. And we will need something like this in Jamaica soon. We > are currently at the specification stage where the Environmental > Health experts are reviewing their paper forms. Thanks! We love the idea too. We currently have a lot of research papers we have been studying from Fiocruz (http://portal.fiocruz.br/pt-br) and many model forms used in Brazil. We would be glad to share. What is the best way to do so? Maybe create a google drive or wiki page? We would like also to discuss the use of ovitraps to monitor the Aedes infestation levels. Do you have this kind of initiative in Jamaica? > I have a couple of questions about your intentions: > > What would the field officer do if a location not mentioned on her > "visit sheet" is discovered? Good point. I think we can create a functionality to allow to register new dom. units on the field. This du would, then, enter on the surveillance cycle. > How will you handle authentication and accountability? Will the field > officers be regular users in/of GNUHealth? I think so. The officers could be users of GNU Health. Their visit runs could be filtered by operational sector and operational area. > Do timestamps matter for the data being collected? Yes. I think the purpose of the system is twofold: to do epidemiologic surveillance but also to control the work and the performance of the agents. > Will the field data contain personally identifiable information (name > of contact person/proprietor doesn't count)? If we have a good list of DUs, I think this info is important. Specially if you consider that WHO and OPAS guidelines demand the integration of epidemiologic surveillance and health services. So, it is fundamental to know where someone who is infected or is suspected of infection lives. Roberto Novaes SÃlex Sistemas www.silexsistemas.com.br
