Author Archives: Neil Penman

Announcement of Smap Release – February 2013

Leave a reply

 

 

The february release of Smap is out of development and undergoing pre-release testing.

New Features:

  1. Multi-projects.  A user with administrator privilege can now create a new project and assign users to that project.  This allows you to manage separation of projects on the same server.  A user will only see the survey templates and results for the projects that they are assigned.
  2. Pictures, videos and audio can be included as survey questions or options.  Any or all of these media types can be added, along with text, to help an enumerator in completing a survey.  This capability has been on the phone for a while as it is part of odkCollect.  However the ability to manage this media on the server is new.  (video)
  3. Publish reports to a Facebook group.  This extends the current ability to publish a report via email.  A menu option named “Discuss” has also been added to allow you to link to a new Facebook app from Smap Consulting, that summarises the discussions on the reports as a word cloud and shows the locations of reports on a map.  (video)
  4. Added ability to specify an export of data as XLS or CSV.  For XLS exports the following formatting is now applied:

  • Dates.  Formatted correctly for excel and always set to GMT.  To change the timezone in excel add the hours difference divided by 24.  You can now do calculations such as subtracting _start from _end to get the duration of the survey.
  • _device formatted as number so it does not show as scientific notation by default.
  • Links added to locations.  If you click on the link it will show on a map where the survey was completed.
  • Links added to pictures, video and audio.

Bugs Fixed

  1. Hourglasses were not always being shown when the system was busy
  2. Name of survey in monitor screen was not being shown.
  3. Could not filter by survey name in monitor screen.Burn Down Chart
  4. Running out of database connections under heavy load

This diagram is of the project burn down and is taken from Acunote, which is a great tool for managing Agile projects. The chart shows the rate of progress across the month and confirms that development was completed on time.  Of course any tasks that could not be done prior to the release date, and that could be moved, were simply put into the sprint for the March release.  Completing “on time” for an agile project is usually a given!

Real Time Assessments

Leave a reply

Stuart Thomson has put up a great site Desire Lines for Change showing how the  Smap software can be used to contribute to community discussions and decision making.  This fits well with one of the principles on which the software has been developed.

The idea came from when I worked at Rolls Royce aero engines R&D labs back in the early 80’s. Royces had this concept of assessing in real time whether or not an engine test was successful,  real time was defined as 20 minutes.  Within this time it had to be possible to decide if the test was successful and whether or not we could move on to the next test.  The totality of the data from the test, which could be very large,  would however be analysed over weeks, months and even years in order to contribute to engine design decisions.  If this data was going to be useful then we had to know if we had done enough cycles and the engine was run within the required parameters.  The diagram below shows the principle.

real time

The Smap mobile phones software is intended to contribute to this sort of real time assessment shown as the green 20 minute cycle in the picture above.  The data is collected and can then be analysed in the dashboard which may result in requests for more data.  Once the data is assessed as sound it can then be exported and analysed in a statistical analysis package or a GIS system over much longer periods of time.

Similarly as described in Desire Lines for Change, an initial assessment with the mobile phones can be made.  The data can be analysed and checked using the dashboard.  It can then be posted into a community forum to prompt an ongoing discussion, the results of which can be used in subsequent design decisions.

A report released today stated that 43% of Australians received sub-standard (below best practice) care at each visit to a general practitioner.  http://www.abc.net.au/news/2012-07-16/healthcare-system-failing-australians/4132056. Apparently this is largely due to GPs not being up to date with the latest treatments and practices.  Smart phones were suggested as a way to improve the situation.

I recently spent a couple of weeks in Africa looking at ways to increase the effectiveness and reach of mHealth initiatives.  Its customary to emphasise the importance of low cost devices in developing countries.  Applications that only require SMS or voice can be used by the widest number of people on the lowest cost phones with the longest battery life. Which is absolutely true if you are creating an application to be used by the general population or community health workers then this is almost certainly the sort of phone technology that should be your first preference.  To some extent this is also still true in developed countries.  If SMS works for your app then you should probably use it.

However I think you can make a strong case that doctors in developing countries can benefit just as much from smart phones as GPs in developed countries, if not more so.  Just as mobile phones leap frogged land lines, supplying a developing country doctor with a smart phone or tablet connected to a cloud based server can be much simpler than equipping the clinic with PCs and associated medical software.  It is also cost effective if that phone becomes an integral part of treating scores of patients per day and reporting health informatics.

The following diagram attempts to illustrates this.

Phone cost versus ease of use, flexibility and capability

No future for j2me phones?  There does not seem to be much development happening on these phones in developed countries nowadays.  I don’t think that it should be so different in developing countries.  So maybe applications should either be aimed at low cost devices over SMS / Voice, or smart phones, or both.