Archive for 2012

Adding gamification to quizzes and mobile learning

I’ve just begun to add some gamification into mQuiz and our mobile learning application. We’ve been thinking quite a lot about badging for the mobile learning modules and perhaps how we could apply this to quizzes too. However, for me, awarding badges for just completing a single quiz, seems to cheapen somehow the value of the badges. So I’ve decided to try out a dual approach of points and badges and see how that works. You gain points for creating/taking quizzes and for completing activities in the mobile learning app, but you only gain a badge for completing all the activities in a given module (or perhaps creating a certain number of quizzes).

So far I’ve only implemented the basic points scoring system (I’ve retrospectively added points to those who have previously been using mQuiz), and the scores only appear on the leaderboard on the homepage, but shouldn’t be too much work to get this more integrated (for example showing your score in the mobile app etc).

For those interested, the scoring currently works like this:

  • 100 – creating an account
  • 200 – creating a quiz
  • 20 – first time you attempt (someone else’s) quiz
  • ? – percentage score you got for a quiz on your first attempt. E.g. if you score 75% on your first attempt you get 75 points
  • 50 – bonus if you get 100% on your first attempt at a quiz
  • 10 – each subsequent attempt at a quiz (max. once per day per quiz)
  • 5 – someone attempting a quiz you created (max. once per day per quiz per user)
  • 10 – completing an activity in the mobile learning app (max. once per day per activity)

I’ve tried to encourage people to try and get as high a score as possible on their first attempt, although you are rewarded for trying the quiz repeatedly (on different days), and I also wanted to encourage people to create popular quizzes – hence the points when someone attempts a quiz you created.

I’m not sure I’ve got all the points quite right yet, so will see how this works and I may make some adjustments over time. I’m sure there are a few ways to cheat this (I’ve thought of a few already), especially with the API to create quizzes.

Next steps are to get the points, leaderboards etc displaying in the mobile app…

New mQuiz and mobile learning app released

I’ve just released the new version of mQuiz. For those of you who have previously signed up to mQuiz and/or the mobile learning app, the key change is that you will need to reset your password (the new version of mQuiz uses a more secure way of storing passwords) and upgrade the mobile learning app on your Android phone.

To reset your password, go to: http://mquiz.org/profile/reset/, enter your email/username and a new password will be emailed to you. Once you log in, you can reset your password to something more memorable. If you are using the mobile learning app, after you upgrade the app, you will need to log in using your updated password.

The key changes to mQuiz are:

  • Quiz creation/editing. You can now add different question types (not only multiple choice) and add feedback to give to the user.
  • Rewritten in Django application framework. This should make the app faster, more robust/stable and easier to add new features.

The key changes to the mobile learning app are:

  • Improved interface
  • Better management for media/video files
  • more info and screenshots here

Finally, I should add that this is all still a work in progress, there are many, many more features and improvements I’m looking to make. If you find anything isn’t working as expected, or if you have any comments/suggestions then please either post a comment below or email me.

Updated mobile learning app – sneak preview…

Alongside updating mQuiz into Django, I’ve also been updating the Digital Campus mobile learning app. Rewriting mQuiz into Django has been going really well, it’s almost there now and hopefully I should be able to get this released live before Christmas. For the API side I’ve been using TastyPie, which has made it much simpler for creating the API for the mobile app.

The main changes to the mobile learning app include:

  • Better user interface and navigation: the old app was rather text heavy and you couldn’t jump directly into a particular activity. With the new app, when exporting the course/module from Moodle you can specify icons for each activity/section/module, or just use the default icons in the mobile app. I’m not sure I’ve got the default icons exactly right yet, but to me, the layout and navigation looks much better than before.
  • Downloading media files: I’ve been avoiding including media files within the download packages to keep the filesize down, but until now I’ve not had a good way for users to know where to get the media files from, or how to download onto their phone. All the media file info (including download link) is now included in the module package, so I’m now building into the app a media checker/manager, so users can see straightaway which video files are missing and can download them much more easily.

A few screenshots of the updated app:

New research paper: Knowledge and performance of the Ethiopian health extension workers

Araya has just had his second paper published: “Knowledge and performance of the Ethiopian health extension workers on antenatal and delivery care: a cross-sectional study”. The full paper is available from Human Resources for Health, provisional abstract:

Background

In recognition of the critical shortage of human resources within health services, community health workers have been trained and deployed to provide primary health care in developing countries. However, very few studies have investigated whether these health workers can provide good quality of care. This study investigated the knowledge and performance of health extension workers (HEWs) on antenatal and delivery care. The study also explored the barriers and facilitators for HEWs in the provision of maternal health care.

Methods

In conducting this research, a cross-sectional study was performed. A total of 50 HEWs working in 39 health posts, covering a population of approximately 195,000 people, were interviewed. Descriptive statistics was used and a composite score of knowledge of HEWs was made and interpreted based on the Ethiopian education scoring system.

Results

Almost half of the respondents had at least 5 years of work experience as a HEW. More than half (27 (54%)) of the HEWs had poor knowledge on contents of antenatal care counseling, and the majority (44 (88%)) had poor knowledge on danger symptoms, danger signs, and complications in pregnancy. Health posts, which are the operational units for HEWs, did not have basic infrastructures like water supply, electricity, and waiting rooms for women in labor. On average within 6 months, a HEW assisted in 5.8 births. Only a few births (10%) were assisted at the health posts, the majority (82%) were assisted at home and only 20% of HEWs received professional assistance from midwives.

Conclusion

Considering the poor knowledge of HEWs, poorly equipped health posts, and poor referral systems, it is difficult for HEWs to play a key role in improving health facility deliveries, skilled birth attendance, and on-time referral through early identification of danger signs. Hence, there is an urgent need to design appropriate strategies to improve the performance of HEWs by enhancing their knowledge and competencies, while creating appropriate working conditions.

mHealth: Patient Identification Issues

Patient identification is still proving to be quite an issue with the records that Health Workers are submitting, making it difficult to be sure that a record for a follow up visit is attached to the right patient.

As not everyone has an id number we can use, originally we asked health workers to identify patients by the id number they enter in their log book. This, we thought, had the advantage that we could easily then match up the database records to the paper records. The combination of this and the health post name (selected from a text list in the form, but stored as code number in the database) should have given us a unique identification for each patient. Only the first registration form contains the full name, on the other visit forms, we just ask for the health post name and the id number, plus the year of birth and age to use as checks for the data.

Using the year of birth and age checks we can identify where patient ids may have been entered incorrectly, but we are seeing quite a lot of errors. In theory rectifying these errors shouldn’t be very time consuming or difficult, assuming that follow up calls to the HEWs are made soon after the error is made. Unfortunately, delays to following up these errors, mean that now it will be quite difficult to fix all the errors.

On each patient visit form, we recently also added the patient first name, as an aid to matching errors back to their correct registration forms.

Some of the problems we have come across include:

  • Two (or more) patients being registered with the same ID number
  • Patient visit forms being entered with the wrong ID – and so getting matched to the wrong patient registration record
  • Patients being re-registered with a new id number, especially when they may attend a visit at a different health post, or in a health centre. HEWs issue a registration card to each patient when they are first registered. If the patient later visits a different facility, the health post name and id from the card should be used, but seems this is not always happening and patients are getting re-registered. This makes it very difficult to track whether patients are following up on referral advice.
  • Some health post have restarted the numbering in their log books (the new year in the Ethiopian calendar started in September), so we are starting to see the same id number being re-used for new patients (although this wasn’t meant to happen)

Given the lack of reliable identification numbers, it was probably inevitable that we would have experienced some errors with correctly matching records up. I would have hoped that with quick follow up to rectify errors, the health workers would have soon got used to taking extra care when entering patient id information.

There are other options we could have taken for patient identification, but these may have also had their own drawbacks. For example:

  1. pre-registering all patients in a given area – though this seems like substantial work; or
  2. providing a set of pre-generated bar codes or numbers (with check digits), which the HEWs can issue when the see a new patient. A check digit mechanism, would have really helped ensure mistakes in entering id numbers were minimised – though it may not have avoided the same numbers being reused for different patients. In retrospect I think this is the approach we should have taken.

Another factor which may have contributed to this problem is that we’re forcing ODK to do something that it probably wasn’t really designed for. ODK is a general data collection tool, each form is an independent entity, not necessarily designed to link up records entered from different forms. Some other recent mHealth tools, have a front-end so the user needs to click on a particular patient to enter the a visit record. But this requires some form of synchronization of the data between the phone and the main database, to ensure that all the patients a health worker may visit have their records already stored on the phone, otherwise it may lead (again) to patients being re-registered.

In Ethiopia, there seem to be some efforts to resolve this identification issue, for example the national Health Management Information System (HMIS) or Family Folder system, but these aren’t fully rolled out to all the health posts we’re working in, so we wouldn’t be able to take advantage of these. It seems to me that for these types of mHealth tools to work well and generate good quality reliable data, then a reliable and consistent system for patient identification is required, but hopefully this will be coming soon in Ethiopia.

Update on Ethiopia Visit

Have just returned from another visit back to Ethiopia, a week in Mekelle to see how the Health Workers are getting on, followed by a few days in Addis, mainly in meetings and catching up with friends.

The new batch of Health Workers who started with us in the last 3 months are doing really well, and we updated their phones with the latest version of the mobile learning app, along with the video content. The research program is due to run until April next year, and we’re looking at ways in which Health Workers can transition over to the new national mHealth program. This national program has started recently and the pilot area in Tigray (there are other pilot areas in other regions) overlaps with where we’ve been working and the HEWs are already familiar with the phones.

Although the national pilot is focused on maternal care, so the forms/protocols and technology used should be very similar, I think there are some differences in the implementation. I’m not sure the details have been finalised, but the information I currently have is that there will be one phone per health post (so 1 per 2 HEWs) and the phones will have some restrictions on which apps can be accessed. I’m not sure how the HEWs who have been working on our research program will react to this, as is more restrictive than what they have become used to. I think one of the reasons that our project has been relatively successful is because we tried to encourage the HEWs to take real ownership of the phones, they have one each and we allow them to use any of the apps on the phone (or even install apps themselves). I think this ownership explains why we’ve had such a low level of loss/breakage (only one phone was stolen, but then later recovered) and we’ve had very few technical issues (accidentally deleting apps/files etc). There will be much more information on all this once we get the feasibility and technical papers finalised and published in the coming months.

Whilst in Mekelle I also visited the Health Sciences campus and the lab we set up there over 3 years ago now. The lab is still (just about) running, surprising given the very low level of maintenance it has had for the last couple of years. The Health Sciences college has been investing a huge amount in improving student computer access. They’ve recently purchased over 300 Macs, most people don’t believe me, until they see the photo, so here it is:

Mac lab at Ayder campus

Although it wasn’t quite up and running when I visited, they’re just waiting for the wireless network to be set up, the lab looks really impressive and is almost certainly the most number of Macs in one room in Ethiopia! I should also mention that these Macs weren’t from a donor, but purchased directly by the college. I hope the students can make really full and effective use of this resource. I believe the college also has plans to buy large numbers of Galaxy Notes, for students to be able to loan from the library in the same way they loan books. These new Macs are in addition to a smaller Mac lab (approx 50 machines) which has been established for a while now.

Back in Addis in the last week, we’ve had lots of meeting with various NGOs and technology companies here, as there is now a lot of interest here in mHealth, specifically around using smartphones. So hope our research project in Tigray can provide a lot of information and lessons learned to contribute to the success of any new projects. But I still get the feeling that mHealth is seen as the silver bullet rather than just the tool. I think mHealth by itself is unlikely to solve many underlying problems of low level of training, lack of motivation etc.

I also met up with Ahmed, a masters student from Addis Uni, who recently contacted me about porting our mobile learning application to run on J2ME phones. He has made excellent progress and it looks really good, but still a few areas to get finished off. I’d originally thought he was doing this as part of his masters project, but seems not, he’s just doing this because he’s interested and wants to move into programming/computing after he finishes his masters.

Here are the rest of the photos I took:

Demo site for patient management tools

We’ve just set up a demonstration site of our analytics and mobile site for the patient management tools. Previously if someone wanted to test out the tool for themselves, we could really only give them the mobile application and the protocols to look at, but we didn’t have a demo area for the server side. The only demo was on my laptop, and we can’t give access to the live site as it has real patient cases. I took this opportunity to look at using Amazon Web Services (EC2) for setting up the demo server – it all worked out really well and very easy to use.

You can log into the analytics/scorecard site at:

http://odk-demo.digital-campus.org/scorecard/ (username/password is demo/demo)

and the mobile version is at:

http://odk-demo.digital-campus.org/scorecard/mobile (same username/password)

The demo user has supervisor privileges, so is able to see all the data entered, usually health workers logging in would only get to see the data directly related to their patients.

If you would like to see the whole process, from entering the protocols on the smartphone, all the way through to seeing the cases on the analytics scorecard and mobile site, I also set up a demo ODK Aggregate server for submitting protocols. To set this up:

  1. Download and install on your phone our version of ODK
  2. start the app and enter the following settings (go to menu > change settings):
    • Server: http://odk-demo.digital-campus.org/ODKAggregate (note that this is case sensitive)
    • Username: demo
    • Password: demo
  3. Go to ‘get blank form’ – this should connect to the server and show all the available protocol forms – select and download the ones you would like to try out
  4. Enter and submit a few protocols from your phone
  5. You will then be able to see the forms you have entered on the analytics scorecard, and the mobile version – note that the forms don’t appear instantly on the scorecard or mobile site, it may take a couple of hours, as we have some caching running, to make the site run more quickly

Please let us know how you get on – especially if I need to add some more info to the instructions above.

Curso de autosocorro

This weekend we had a self rescue (autosocorro) course, to know what to do if someone injured whilst on a rope and needs to be brought up or taken down quickly. On Wednesday we had a theory session and then at the weekend we went out to Patones (where I did my initial SRT course back in February) to practice outside. There are different techniques depending on whether the ‘victim’ is currently ascending or descending and the rescuer is trying to reach them from above or below, and finally whether you want to take the victim up or down. This weekend, we were mainly just practising accessing the victim from below and bringing them down, so the only variation was if they were currently ascending or descending.

For me, bringing the victim down when they were already on their descender was relatively straightforward, but when they were ascending, it was really tough. I tried 3 times and managed to get something wrong every time – so the supposedly unconscious victim had to help me out and ended up being more injured/bruised then when I started. From the photos below, and the mass of equipment/ropes between the rescuer and victim, you can see why it could be easy to get something wrong – although given your weight is hanging on the ropes it would be very hard to detach yourself completely. Think I will need more practice, but hopefully I never have to ever use anything we learned!

Caving Discovery Day

On Saturday we had a day trip out to Cueva del Asno, near Los RĂ¡banos (just south of Soria), to take some potential new caving club members (hence the “cave discovery day”, or “Salida de descubrimiento”). It’s the first cave I’ve been to in Spain that we’ve not had to use SRT in, so makes a nice change not to need harnesses, ropes etc. Although to formations inside are good, there’s quite a lot of damage to many of them, broken off stalactites/mites, (and graffiti) – I guess because the cave is very accessible, so quite easy for anyone to get into with only a torch. Next weekend I have an “autosocorro” (self rescue) course – so will learn and practice what to do in case anyone gets into trouble whilst climbing up/down on the ropes.

Some photos from Saturday:

Learning Django (and Python) and OpenBadges

Although I’ve played around a little with Django since I got my Raspberry Pi set up as a web server, I haven’t really written a proper application, only some small test scripts.

So, to push myself into learning it all properly, I’ve been looking at rewriting the mQuiz website as a Django app. This may seem like a bit of an academic exercise given that the website is already up and running fine in PHP. However, recently I’ve been looking into how we can incorporate badging into mQuiz, so, for example, if you get 80% or more in a quiz you’ll earn a badge. I’ve not yet figured out how it will all work, but in order to make the badges useful (in a minor way), I’m looking at using Mozilla OpenBadges.

So, what’s giving badges got to do with rewriting mQuiz in Django? Well, there’s already a OpenBadges issuing app written in Django, so thought I could use this and it gives me something substantial to work on for learning Django (and if it all works I can issue myself a badge!). For reference, there is a OpenBadges app for PHP too (see: https://github.com/mozilla/openbadges/wiki/Open-Badges-related-widgets), though I’ve not yet tried it out.

As well as just a learning opportunity/challenge, I also not too keen on the PHP framework I’ve used for mQuiz – it’s not based on any known framework (I made it up myself) and I think once we start to want to do more with mQuiz (especially extending the tutor monitoring/scorecard side), it would be good to have the app written in a known/supported framework, especially for extending any functionality, or if others are going to help install/maintain/support/develop/integrate the application.

There’s bit of a way to go yet, basically all I’ve done so far is write the login/logout script, but I’m now getting a feel for how much work it will be to re-write. So far, Django certainly seems a much more suited to rapid development than PHP frameworks I’ve looked at in the past. As yet, I’m unsure what changes I may make to the db/model structure, and so how to transfer any existing data (especially the users) from the current app to the Django mQuiz db, though I’m sure this will become clearer once I learn more.

As a byproduct of this, I realised that the mQuiz web design was looking a bit tired, so I’ve given it a minor facelift, with a new stylesheet, although only the main site, not the mobile version (yet).