Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 10
Next »
How to Join
Click here to expand...
By Browser
By telephone
- US telephone number: +1 201.479.2627
Agenda
- Quickly review previous meeting minutes (5 min)
- mUzima Demo
- Review next meeting agenda
Minutes
View at notes.openmrs.org
OpenMRS Developers Forum 2014-12-18
Attendees
Agenda
Notes
- mUzima means "Mobile for Life". mUzima is an Android application for deploying mobile forms.
Questions
- Martin Were, Win Ribeka, Sam Mbugua, Manu Tarus, Nelson Bore, Burke Mamlin, Ada Yeung, ThoughtWorks South Africa Team, Sahaj Team
- Who (if anyone) is financially supporting its development?
- The project is supported through various grants (Medtronic Foundation, Regenstrief Innovation Committee, AMPATH). The hope however is that eventually we can have a team working collaboratively on the platform
- AMPATH - for Chronic Disease Management and Oncology
- What is needed to use mUzima?
- We test it out using 1.9.7 (I think it's working on the 1.8.2 too)
- We need the Webservice REST module (mandatory) to get data from the server side and muzima-forms module (mandatory) for form management and muzima end point module (mandatory) where you can submit your form into. We also provide some standard processors for encounter form and the registration form (optional).
- How does mUzima compare to other mobile form clients (like OpenDataKit, OpenMRS Android Client)?
- More tightly integration between Clinic / Collect side
- Ability to work offline with parsing of data temporarily on the device for reconcillition
- Better management of changes - e.g. you do not have to wipe out everything each time before you reload new information (saves data)
- Easier handling of concepts selection etc
- How are cohorts exposed to the mobile device? Do they see all cohorts?
- We are pulling the static cohorts. We implement filter which would narrow down the list I think (in the options). This will send the "string filter" to the REST webservice GET method.
- Idea was to have a working application first before opening it up - as we do not have the cycles to handle all users requests at this time. We now have working version in the field, relatively stable, and we should be in a good place to make it available to others.
- FYI (this is Burke) you can share code without handling or even responding to requests. :-) Agreed - except then you end up with people saying that the solution does not work :) But you are right Burke.
- Are users supposed to manually choose which concepts they want? What value is there is downloading concepts if they aren't included on a form? Why are users asked to think about which concepts are loaded?
- The concept list is coming out from the form that you download. The questions in the form will be parsed and the concepts will used to decide which obs gets downloaded. We think that if you ask "WEIGHT" in your form, you probably interested in the historical data of the "WEIGHT". This is the reason why we use this approach. The idea of showing you all the concepts on your forms is to enable you to remove those for which you do not want data downloaded. In effect, you could make mUzima a simple data collection tool, by removing all concepts (i.e. not downloading any data). On occasion, you might want additional concepts other than those within your forms - mUzima gives you this provision too.
- Does the "Observations" button on the patient screen mean that individual observations can be collected without using a form? Or are observations read-only?
- All the data that we get from the server will "read-only". If you need to make changes, then you should create a form for this. We don't allow direct manipulation of data because we might run into synchronization issue.
- I think this is a good point - in the future, we might want to think about the ability to allow for individual observations to be entered - e.g. new lab results
- Is there a way to tell if a client has already been downloaded or not?
- When you're in that screen, it's a list of all patients in the server side. So you can download everyone in that list. If you re-download, I think it will reject the write operation as the unique id of the object (uuid in this case) will be the same with existing one in the device.
- Can mUzima install apps (e.g., an open web app)?
- We have a plan to have this feature (it is in the pipeline). This way you can load a web app of your choice. It's going to be similar to how OpenMRS works with SmartApps :)
- Many people have asked how they can help contribute to the project. Where should they go?
- We would love to get more people involved. Feel like we are ready to move to this stage. Ada is the custodian on getting people on board. We have lots to learn on getting the word out from the OpenMRS community and folks on this call.
- Mailing list? Website? Twitter account to follow? (Ada will share these)
- How is data being saved offline on the device locally, being secured?
- The data is encrypted. Lucene is used to index and fast retrieval, but all those lucene index will be encrypted. We add a layer between Lucene and disk storage. So all IO operation is encrypted.
- What is meant by "Expanded Cohort"? Ada said that you want to know when someone was added & removed. I can imagine an extension of Cohort that includes "dateAdded" for each member, but if a member was removed from the cohort, they are no longer in the cohort, so there is no place to look for "dateRemoved". :-/
- It sounds like mUzima needs a Cohort + status for each member. Cohort attributes?
- Other modules include: Teleconsultation, Media Management Module. We also have device management and security module that is almost close to v1.0.
- We want you (to be in mUzima team)!!!
TODOs
Transcripts
- Audio recording of the call: Listen online or download (available after the meeting)