Ideas from potential students for GSoC 2016 projects

I am Shashank Motepalli(sm86 on IRC). I am student from India and a GSOC 2016 aspirant. I feel some of ideas worth sharing. Idea 1: How about giving the choice of option of free style writing for certain fields like comments or diagrams to describe their views.It can be integrated with android module of teleconsultation module. Else even in system, option to scribble with help of cursor should be provided. And the data will be sent to a RESTful service preferably. The database must be storing these images. For ease, can be started with fields that don’t used for search/filter operations, like comments or other similar fields, so the problem of text recognition and parsing don’t come into play. May be even Reception roles can use to capture images of patient and send to restful server. This may help in improving the experience of usability with the openmrs. I want to get some suggestions in framing a project based on it. Idea 2: The patients will be having the medical records. How about an android module that gives patient remainder for their medicines and patient marks once he has taken medicine . This data may help in maintaining records of the time the medicine was taken. And also a simple counter may notify pharmacy. And also, during next check up, doctor will be having data of the medicine intake pattern. This would be helpful in assessing the patient with long-term diseases with medication better. In addition to this, the alerts to care taker if the patient don’t take medicines. This module may be useful with lot of out-patients to track their medication records. Idea 3: As @ivange94 suggested. An android chatting module between the reception, nurse, lab persons and doctors even patients. This may improve the clinical experience. But with an additional teleconsultation module which permits calling. I would like to hear the feasibility of the discussed ideas for GSOC this year. Also suggestions/criticism required.

Shashank’s ideas (especially 2 and 3) are great. Some of mine as an interested GSoC candidate and an Android Developer:

  1. What I would add is a robust notification system, something that is entirely missing from the app. There needs to be notifications for patients incoming, for any type of transaction happening that needs attention.

  2. Also, considering that the app will have a patient interface, I would add a sticky notification feature for medicine reminders. The patient cannot ignore/swipe it, it has to get an answer, affirmative or negative before the reminder goes away.

  3. A chat module - suggested by @bholagabbar seems a likely candidate for a new feature. Ideally, I would create chat channels patientwise as follows, a patient’s chat channel would have all his current doctors and current nurses added as contacts. The doctor’s channel would have all the other doctors and nurses in the hospital added. We would have control on the type of chat this needs to be, whether like Whatsapp, or we would create specific groups in each channel…is to be discussed with mentors and pilot users.

  4. Another feature off the top of my head is a more robust first aid system built into the app, with diagnosis for common health problems and their cures/medicines. One way to extend this very feature is to add voice recognition for keyword-based early diagnosis. If the diagnosis detects that merely first aid will not help, an alert will be sent to the MRS system for further actions.


I feel points 1, 2 and 3 are valid.

  1. A notification feature is definitely something that can be implemented. Also, there are a couple of random bugs such as the url-textbox is buggy and deletes a ‘/’ character when you try to delete a character forward. The error message also has a grammatical mistake. I guess you can try and work on these as tickets.

  2. A patient interface is something that definitely needs to be implemented. Great point there. I guess I had implicitly suggested something along the same lines in my proposal of a Telecommunication Module but yes, it deserves attention as a whole

  3. A chat/telecommunication module is something that I am currently looking at. If we were to implement it in your way, I guess we would need to create separate interfaces for doctors, patients and even nurses. Not sure if that’s the way to go. I guess the way we can implement cross platform communication still requires some thinking. As for your idea of having a sort of Intra clinic chat module, it does seem fair but I’m not sure how positively it would affect the work culture and how feasible it is in general. I guess this requires some brainstorming as well.

I strongly disagree with point 4. Self-diagnosis is definitely something you don’t want to be looking at, even if you intend to call it ‘First-Aid’ of sorts. While I believe incorporating an offline first aid feature into OpenMRS is viable, we simply cannot automate the process of suggesting medicines/cures on the basis of initial diagnosis. What if the patient is allergic and doesn’t know about it? Several symptoms of dangerous diseases are those of ‘Common Health Problems’. We can’t risk generalizing things in anyways. I hope you get the point I’m trying to convey.

I guess we have to wait and see what @r0bby and the others have to say about all this :slightly_smiling:

@bholagabbar Sure thing. I’m actually waiting for @raff 's green signal for my earlier PR. Once it is ready for merge I’ll squash the commits and shall claim the earlier tickets. I need to be sure everything is working after gradle migration. :slight_smile:

Edit: About point 4, yes I get what you are trying to say. I think a middle ground can be reached, where the first aid system suggests some immediate relief measures and sends the symptom data (photos or voice by patient) to the MRS nevertheless. This can be considered an SOS/911 system for medical emergencies and the receiver of the data can follow up, maybe via the chat module if it is ready by then, to the patient with informed diagnosis.

Edit 2: About the chat, it is not unfeasible, given that we have just recently implemented such a channel system in another project by our college team for a recent competition: . However, we have used Parse and Pubnub in it, both of which are freemium services. The Parse stack is opensourced and can be replicated on a server with DJango, I’m not sure how viable an alternative of PubNub will be or what other options we have. Nonetheless, very much possible.

Yeah I’m pretty sure it’s feasible in implementation. I was talking about how the idea is in general. As I mentioned, a sort of ‘intra-clinic chat app’ could have implications on work ethic and also whether it is needed in general. As I said, we need to brainstorm over these issues, possibly with other developers and hear their opinions about this :slight_smile:

We have got good ideas flowing here. These have to be discussed.

My interest in subject lean towards machine learning and data mining. Therefore as a GSoc 2016 aspirant, my ideas is about a module which can support collecting and processing important data and information for disease detection using openmrs user-base. Probably in the bio-medical engineering domain they do it for particular diseases like cancers, diabetics and heart attacks etc. There are ongoing researches on these and their findings will be really helpful. As a wide spread software I believe, OpenMRS has the best potential of doing this. Sure the scope of this from this explanation is wide. But we can narrow down it to a good start. A lot of researches for cancers have being done and classification and clustering techniques are also found by the researches so far. We can do two things here.

  1. Develop a module that will detect particular diseases based on the patient’s symptoms or life style. In doing this we can use open source libraries like scikit-learn.

  2. Process data to get information to be given to a third party so that they can use that information to do the above. The main use of this will be for researchers.

Definitely both suggestions will take a considerable amount of time and is not feasible to complete in three months. But we can narrow it down and give it a start in this.

We need to mine these data. Because people are dying. They need more information and more miners not only to detect but also to find a cure.

1 Like

I like your idea from an abstract point of view.

However, the data you are talking about is actually stored on OpenMRS servers all around the world, most of which you will NOT be having direct access to. If it were, pharmaceutical companies would’ve made a fortune by analyzing data from these sources and making region centric drugs, while getting all this data free of cost.

Also, I believe that sometimes the symptoms people would show in a particular region could differ significantly from those shown in other regions for the same disease. Analyzing data just got a lot harder :slightly_smiling:

I believe that the RESTWS module provides individual OpenMRS servers around the world the ability for 3rd party to extract and insert data. If a phama company were accessing thos data, they probably would be using far more sophisticated proprietary technology anyways


I love the passion! The challenge will be, as @bholagabbar suggests, that implementations are running their own servers, these many may not be connected to the network, patient data (especially identifiable patient data) are sensitive, and the data in each implementation may be represented in different ways (variations in concept dictionaries).

One possible way to crack this nut would be to provide a module or tool (although, a module would probably be easiest for an implementation) that scans the implementations data and transparently creates a de-identified payload to be contributed to the whole. For example, imagine something like:

It wouldn’t be a small task, but providing an easy mechanism for implementations to contribute data to a central database in the cloud and doing it transparently and in a manner that doesn’t compromise patient privacy could be a powerful tool. The biggest challenges would be inability to include precise demographics or text-based data (for privacy) and managing variability in how data are modeled across implementations (my little Scancer example suggests a 1- or 2-page automated survey up front might help configure the module to understand the local modeling).


-Burke :burke:


Woah that is such an awesome idea! :smiley:

Also, why can’t we sort of generalize it? We can create internal sections for every diesease. That way, we can generalize it further and the user just has to install 1 module. All it does is collect data anonymously and we can code it up in such a way that it maintains separate sections for all diseases.

Similar to the adage “Think globally, act locally” and in the spirit of hacking in the right direction, I’ve found that it often best to “Architect generically, solve specifically.”

My advice would be to focus up front. It doesn’t have to be cancer, but I’d recommend choosing a single focus up front. From the DOTADIW perspective, you can be far more productive & effective in the short term by focusing the effort. It’s also easier to explain to people. If you create a generalizable solution up front, you add the risks of scope creep, unclear strategy, and a diluted message to implementations. Instead of 15 implementations contributing to a single disease, you end up with two implementations wanting to focus on disease X, one implementation wanting to focus on disease Y, and a dozen implementations that never got engaged because it sounded too complicated. Note that solving a specific problem does not require the solution be hardcoded to that specific solution. For example, creating a module like Scancer doesn’t prevent you from designing it under the hood so it’s capable of accommodate other diseases in the future. In fact, solving a specific problem with a generalizable architecture can act like a Trojan horse – i.e., giving people a simple solution they are eager to use (because it addresses their problem) that can later, with little or no effort, be used to solve other problems.

Imagine, for example, it’s 2004 and you’re asked to build an HIV care system. You build an HIV care system, but under the hood you design it as a generic EMR platform that can be used for any medical care needs. Who knows what might happen. :wink:


-Burke :burke:


At the very basic we could build a pilot module to fit features: (symptoms, medical history, person’s details - age weight, height demography details-ethnicity,locale, diet) to the label: diagnosis. This can be an English language classifier. All we need for this is a large amount of accurate training data and an even larger amount of test data. Once we have them using an example module (say Scancer)- @burke , we could actually train our classifier and predict a diagnosis for every set of data it throws back at us. This is not even very difficult, considering we are not targeting images and only text data. Scraping details taken at Hospital reception and labelling them with the Doctor’s diagnosis can be done and tested. I’m thinking bs4, NLTK and Scikit-Learn for Learning and Prediction.

I’m still a newbie for the OpenMRS. With my some experience, I believe OpenMRS should support plugging ldaps, providing SSO capabilities which very useful mostly common used features. Some applications allows users to be login with Social Media details such as google, facebook and etc. Wouldn’t that be a good feature to have in OpenMRS? I might be wrong when looking at health informatics perspective.

For typical OpenMRS implementations, using social media or other online credentials would be unusual because (1) most users won’t have such accounts or wouldn’t want to associate their personal Facebook account with the electronic medical record used professionally and (2) many servers are not connected to the internet or internet availability is not reliable.

That said, SSO would still be handy for any implementation that is using more than just OpenMRS and may want, for example, to leverage a local LDAP directory for authentication. That was the intent when I created TRUNK-381 – i.e., refactor the platform so a custom authentication scheme could be plugged in (whether to support SSO with something like LDAP or to support non-username/password approaches to authentication like biometrics).

@burke you totally nailed it. Yes that is true that the instances are in different places globally. That is why a community like openmrs, who provide the infrastructure to the industry should lead in these. We can’t expect every one to be positive minded towards such operations. “May be”, sometimes the users will think this as an extra burden. A lot may (some times) will think this as the “send notifications via email” field when registering to some facility. (We usually reject it) But it is good to give a try and if a community like OpenMRS can’t do it then who else will do that? :slightly_smiling:

The Scancer by the implmentation is exactly what I also had in my mind. But I got few different ideas about the implementation.


  • I always like “Think globally,act locally” concept. We can use interfaces and abstract classes, and implement or extend them for a particular disease. That way any one can build their own custom implementations built on that using the core functionalities without any problem.

  • The survey is indeed a good idea to map the custom attributes of local modeling to the needed information. What about implementing an interface that includes these much needed and attributes and giving them the chance of adding more on top of it. Then we can get the needed data without requiring them to go additional step. The less steps, more temptation.

  • What ever the information is the most important thing. Once we have that we can share them with anyone who has interest. May be we are lucky to find out investers like bringing this valuable information to competitions like [Kaggle] (

We need to frame a fruitful project idea out of this abstract. When will be the next weekly meeting regarding GSOc project? I will try to prepare a wire-frame for this. What do you think?

Agreed. I was assuming the “survey” would be like a customized admin/configuration screen for the module. I was assuming the module may want to perform an initial scan to do any automated mapping or to minimize the number of questions the admin needed to provide, the admin would fill out a form to supply mapping or settings that couldn’t be fully automated, and then the admin would be able to start the scan.

Great idea. The needle to thread is: what is the most useful information that can be collected without compromising patient privacy? While collecting any patient information is technically feasible and politically possible given the appropriate agreements to protect patient privacy, collecting any identifiable information would create a significant barrier to adoption that might be fatal to the project. My opinion is getting less precise data (without patient demographics, exact dates, or any free text) would reduce the analytic power, but significantly lower the barrier for people to contribute data. While limited for privacy sake, you could still do data analytics (with more data) and, by keeping a local linkage file, you’d have the option of coming back to implementations saying “Our initial analysis suggests there could be a link between X and Y. To test this theory, we would like to work with you to go through the appropriate review board, etc. to ‘unlock’ the records for these 500 patients for this research.”

To get an idea of what would be “off limits” for data collection, take a look at the definition of Protected Health Information (PHI) in the U.S. These data include names, addresses (e.g., any location information that associated with fewer than 20,000 people), birthdates, identifiers & account numbers, dates (dates on data/appointments would need to be “blurred” by, for example, removing month & day), and any other data that could be used to re-identify the person. Avoiding these data and limiting data collecting only to codified (concepts/diagnoses) or numeric values that could be guaranteed to be anonymously collected would be absolutely critical for the data to be shared publicly. We had to go through these steps with our demo data. It’s important because many OpenMRS implementations not only contain private health information, but also contain very sensitive information (e.g., HIV status), so any remote possibility of re-identifying someone from the data would be catastrophic. In short, you could get data on a lot of patients, but you wouldn’t know who was male or who was female; age of each patient would be a category like 0-10, 11-20, …, 90+; and, the dataset would need to be limited to coded/numeric data with fuzzy dates on them. You probably couldn’t make conclusions from the data, but you could likely generate informed hypotheses from the data to guide subsequent research.

1 Like

@rasanjana me and @sunbiz would like to see a variant of social media into OpenMRS … Look out for the project pages when these open


@burke Agree about the social media logins. Thanks for the clarification. I’m not familiar with OpenMRS deployments and the infrastructure much as still a newbie. But with OpenMRS spreading across the global wouldn’t it be a good to have feature? It might not be social media only but supports external Identity provider based logins like SAML, OAuth and etc.

@judy :slightly_smiling:

@judy it’s really cool idea of having a social media type platform in which users get a chance to update their health. Check their records if public. It’s also cool and may be successful just as LinkedIn in professional and Facebook in casual friendly conversation. Openmrs would create a platform for medical field with a medical track time line too.

If a student worked on this, I would be so happy to see it.

1 Like

+1 for the Scancer module.