cybercod wrote on Wednesday, November 02, 2011:
The beginnings of an app for OpenEMR
https://code.google.com/p/openemr-app/
We are just getting started, so do not expect a working app yet.
bradymiller wrote on Wednesday, November 02, 2011:
Hi,
This is very exciting. I placed a section for OpenEMR Apps in the wiki:
http://www.open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Page#Apps
Along with a OpenEMR Android App page with your project on it:
http://www.open-emr.org/wiki/index.php/OpenEMR_Android_Apps
Please feel free to modify anything you want on the wiki; I just put some quick items there to get it started. When you have something ready to be tested, I’m guessing it won’t be hard to find tester here on the forums.
-brady
bradymiller wrote on Friday, November 04, 2011:
Hi,
One quick thought here. Since you are using it like a web browser, if you want a really simple Hello World android app project to do, check out the patient portal in the demo. I say this, because it is just one web page 
http://open-emr.org/wiki/index.php/OpenEMR_Version_4.1.0_Demo#Patient_Portal_Demo
-brady
OpenEMR Project
cybercod wrote on Sunday, November 06, 2011:
These are addresses we were thinking of adding buttons for. These are just what we found within the OpenEMR instance we have locally installed. If we could get some feedback on which pages should have priority, that’d be great.
We are essentially trying to do away with the left window frame, and use buttons to get to specific locations quickly. We intend for the buttons to be in a grid, within a sliding drawer. Icons vs text is being discussed. We welcome input on that, but will probably make both options available once we’ve figured out how.
–OPENEMR ADDRESSES
*all of these are basically strings added onto the server address to reach a browsable page within the OpenEMR directories. If we can get some feedback about what would be handy on an android device versus what would be best left on the desktop, that’d be appreciated. Also, if we missed any important ones, please let us know.
We have a lot of design ideas already, and we’re still learning Android. So feature requests, while welcome, will probably remain unanswered or unimplemented for quite some time.
// left navigation frame
//webview.loadUrl(getString(R.string.srv)+"/openemr/interface/main/left_nav.php"
// Calendar/schedule
“/openemr/interface/main/main.php”
//navigation (not with buttons)
“/openemr/main/main_navigation.php”
// new patient dialog
“/openemr/interface/new/new_patient.php”
//messages
“/openemr/interface/main/messages/messages.php”
// lab results
“/openemr/interface/main/messages/lab_results_messages.php”
// authorizations
“/openemr/interface/main/authorizations/authorizations.php”
// authorizations (full)
“/openemr/interface/main/authorizations/authorizations_full.php”
// just calendar
“/openemr/interface/main/calendar/index.php”
// office notes
“/openemr/interface/main/onotes/office_comments.php”
// address book
“/openemr/interface/usergroup/addrbook_list.php”
// order results
“/openemr/interface/orders/orders_results.php”
// index of reports
“/openemr/interface/reports/index.php”
// user validation (not sure how it is used)
“/openemr/interface/login/validateUser.php”
// pending followup from results
“/openemr/interface/orders/pending_followup.php”
// pending orders
“/openemr/interface/orders/pending_orders.php”
// statistic reports
“/openemr/interface/orders/procedure_stats.php”
//order types and results
“/openemr/interface/orders/types.php”
// lab exchange system
“/openemr/interface/orders/lab_exchange.php”
// add or edit drug
“/openemr/interface/drugs/add_edit_drug.php”
//edit drug lot
“/openemr/interface/drugs/add_edit_lot.php”
// destroy drug lot
“/openemr/interface/drugs/destroy_lot.php”
// dispense drug
“/openemr/interface/drugs/dispense_drug.php”
//drug inventory
“/openemr/interface/drugs/drug_inventory.php”
// generate and print notes (needs printer driver)
“/openemr/interface/forms/CAMOS/notegen.php”
//patient encounter form
“/openemr/interface/forms/newpatient/view.php”
//create or edit work/school notes
“/openemr/interface/forms/note/new.php”
//edit / print school/work notes
“/openemr/interface/forms/note/view.php”
// new dictation
“/openemr/interface/forms/dictation/new.php”
// view dictation
“/openemr/interface/forms/dictation/view.php”
// order procedure
“/openemr/interface/forms/procedure_order/new.php”
// view or change procedure
“/openemr/interface/forms/procedure_order/view.php”
// review of body systems
“/openemr/interface/forms/ros/view.php”
// review of body systems checked
“/openemrinterface/forms/reviewofs/new.php”
//review patient vital stats
“/openemr/interface/forms/vitals/view.php”
// create patient vital stats instance
“/openemr/interface/forms/vitals/new.php”
cybercod wrote on Sunday, November 06, 2011:
Our original idea was to put the left navigation frame into a drawer that slides out from the left, and have the frame target instructions intercepted somehow to go into the main webview of the app, but drawers from the side are problematic at our current learning level, and we’ve not figured out how to translate the frame instructions yet either.
Currently, we can make buttons for specific addresses, and we’re working on putting them into a drawer, either in a grid, or in a list.
cybercod wrote on Sunday, November 06, 2011:
On the subject of patient portals, It would probably be of more benefit to hardcode them to a specific system. They’d be very easy to implement, and quick to produce for medical institutions, and putting stuff on the Android market is very cheap to do, and they wouldn’t need to advertise the external address of the OpenEMR server system to users. I would think the patient side of things needs to be very easy, ie. look for your healthcare provider in the market, download their app, use your login and then tada, bob’s your uncle. Posting the address for the purposes of putting INTO an app like that would just advertise the server’s address, and invite attacks. Thats just my opinion, I welcome opposition to it from more informed people.
mdsupport wrote on Sunday, November 06, 2011:
It’s great that you are taking the initiative to take this software in the new direction. There was lot of discussion started by some suggestion from hrivera787 that kind of fizzled during the certification days.
To add to the discussion, considering the nature of underlying platform, it may be good to avoid duplicating the current GUI. Great benefit of the web-based interface is we were able to use standard OpenEMR interface with little modification. So for a potential user of an App, the browser option is always available. The App(s) will be very useful if they act as a bridge between external systems - e.g. immunizations need CVX codes that are set and continuously updated by CDC. So instead of every EMR installation replicating the changes, the app can lookup and provide codes from CDC and then create EMR records with appropriate CVX codes. Think of huge medication databases or even CPT & ICD codes that we currently are forced to replicate and maintain. This is an ‘administrator’ activity that is likely to be ignored by many ‘non-tech’ practitioners.
The other suggestion is to rely on OpenEMR solely through function based web services. This will de-link App development from main web interface development. It will also prepare this package to collaborate with a lot of external systems, devices and god knows what…
bradymiller wrote on Sunday, November 06, 2011:
Hi cybercod,
I think the following links would cover things well for non-admin use of OpenEMR:
“Calendar” (link as above)
“Messages” (link as above)
“Patient Summary” -> interface/patient_file/summary/demographics.php
“Encounters” -> interface/patient_file/history/encounters.php
“New Encounter” -> interface/forms/newpatient/new.php (note that if we place a link to this in OpenEMR on the above Encounters button, then wouldn’t need this)
“New Patient” -> interface/new/new.php
“Patient Search” -> contain the search box within the left_nav into a function, and then use this function within a new script specific for the app (script will only contain a call to the search display function)
“Address Book” -> interface/usergroup/addrbook_list.php
I think the above 6 or 7 buttons would do a good job covering stuff for clinic staff except for the admin (things left out that others may want are labs/procedures,billing screens, and reports). The reason it’s so few buttons is because of the Patient Summary and Encounters screen, which contains links to most of the clinical things.
-brady
OpenEMR Project
cybercod wrote on Monday, November 07, 2011:
mdsupport: The general idea right now is just to make a streamlined browser. Code lookup is a bit out of our league as of yet, but its something to consider if some other Android developers jump onboard. We’re learning as we go.
My partner and I both have the habit of learning by doing, and so we chose to start this project as a way to learn Android, and do something worthwhile simultaneously. Neither of us are in the medical field, although I have worked for some doctors in the past doing PC repair. What this means to you is that we don’t understand medical jargon and acronyms very well. If you can link me to a site where I can look up the codes you’re talking about, perhaps we can make it available within the app as another web destination, but as for scraping the site and auto-loading codes, we’re not quite that skillful yet. 
Brady: Ok, we will prioritize those. We’re working on trying to integrate the PHP code into android for the search function, or we may use a local html or php file. We are aware that it is a necessary element… just trying to figure out how to put it in.
This is the code involved, right?
/** Process the click to find a patient by name, id, ssn or dob.
function findPatient(findby) {
var f = document.forms;
if (! f.cb_top.checked) {
f.cb_top.checked = true;
toggleFrame(1);
}
f.findBy.value = findby;
setRadio(‘rb_top’, ‘dem’);
top.restoreSession();
document.find_patient.submit();
}
*/
cybercod wrote on Monday, November 07, 2011:
After we get these first page buttons in, we’ll release an apk for testing.
bradymiller wrote on Tuesday, November 08, 2011:
Hi,
The search code looks correct, which calls the following on that page:
<form method='post' name='find_patient' target='RTop'
action='<?php echo $rootdir ?>/main/finder/patient_select.php'>
Which calls the interface/main/finder/patient_select.php script, so should be able to call it directly and here are the pertinent variables that can be passed
$patient = $_REQUEST['patient'];
$findBy = $_REQUEST['findBy'];
$searchFields = $_REQUEST['searchFields'];
Rec looking through the script to get a better idea of how to use it.
-brady
cybercod wrote on Sunday, December 18, 2011:
Had a little break from programming (blame Skyrim) but we’re getting back into it and should be releasing something soon.
cybercod wrote on Sunday, December 18, 2011:
Fresh eyes will probably help us out of the little conundrum we were stuck in.
arimal wrote on Monday, December 19, 2011:
Hi I’m the novice developer working with cybercod thought I’d introduce myself and pass the news, we’ve got a mostly working app a few navigation issues and remaining functions to implement. We should have something to release within a few days.
arimal wrote on Monday, December 19, 2011:
Consider this the Alpha release. This is just to let you all know how much more there is to be done, as well as so you can see what kinds of problems we’re encountering trying to shoehorn old-skool web design into the app.
http://dl.dropbox.com/u/38293434/OpenEMR.apk
Currently, it uses the testing server at http://opensourceemr.com:2098/openemr as the default value, but you can hit menu to change the server to one of your choosing.
Button choices (aside from those mentioned above) were arbitrary and can easily be changed.
Search is still pretty broken. We’re having trouble dealing with the frames, as well as the behavior to open a new window (in a desktop browser) and the ways that buttons within OpenEMR often send instructions to other frames.
In any case, check it out. Feedback is appreciated.
For some of these things it may be better to have some of the pages changed on the server side. A mobile version perhaps. You all take a look and we look forward to your thoughts.
arimal wrote on Monday, December 19, 2011:
Also, setting the username and pass in the settings doesn’t do anything right now.
cybercod wrote on Tuesday, December 20, 2011:
Anyone tried this yet?
arnabnaha wrote on Tuesday, December 20, 2011:
I tried it…a really nice effort must say…and it looks very good too… I know a bit of work is left but this app is very helpful and definitely will help a lot.
I found out the Server address doesnt get right. I tried with my server address…which is nahahealthclinic.dyndns.org/openemr but it projected the address as “nahahealthclinic.dyndns.orgopenemr”. Thus, I was not able to connect to the database and the server. If you fix it…it is a good app.
And there are few text wraps in the apps. after logging in i found that i was connected to the openemr demo site. There are a few text overlapping within the app.
Thanks for the good hard work you are doing…This will be very very helpful app. I am using it in Android 2.3.6 in Samsung Galaxy S 2.
yehster wrote on Tuesday, December 20, 2011:
To be better than just using a regular browser under android you should “break the frames” interface.
My suggestion is after logging into the system. Redirect the browser to the
openemr/interface/main/main_info.php
for the calendar and have the user interact with a single browser page at a time at that point.
Use your menu items to update the url directly to go to the appropriate pages at that point. (No more need for left nav)
If you have an app where I can view the main “info page” that gets displayed in the RTop frame, without needing the left_nav.php frame (navigation replaced by android menu), that would be useful.
Don’t worry too much about the communications between frames at this point. If you ultimately need things like opening in the same window instead of in new windows, that could be changed.
Also, suggest you point at the 4.1.0 or 4.1.1 demo instead. The calendar looks nicer
arimal wrote on Tuesday, December 20, 2011:
Thank you for the feed back, I’ll look into the url problem directly, just a string formatting problem. I’ll be back with a little more polish and hopefully working search soon.