Android and iOS Apps

feature

(MD Support) #1

Several years ago there was lot of discussion about an native Android app. Looking back, that approach lead to its natural conclusion while making scripts designed for desktop work with small form factor devices.

We have had limited success in building dedicated scripts and rolling it out as ‘Apps’ - thanks to Bootstrap 4. That approach does not use the full potential of these devices which now have better processors and more features than servers running emr.

We are currently looking to see if clinicians seeing patients out of the office can use their phones to check active meds, record some data and upload facesheets to office emr.

This is a call to see if anyone has real native apps (published or not) on any of the major platforms? If so, we would be interested in their experience and hopefully the code.


Noob question - OPENEMR suitability
#2

At one point there was this


And this


(Dan Ehrlich) #3

My guess is this will almost certainly happen Ivan react native. We basically have to rewrite app in React at some point if JS is to be modernized. This is like 3 years off though. Anyway this would give you both iOS and Android.


(MD Support) #4

As noted in the original message, mobile and to a great extent tablet interfaces have to be designed from scratch. It is also clear for us that number of entry points/screens has to explode to account for smaller viewports.

What we are hoping is to leverage existing production grade code with reusable components rather than iterative evolution from “Hello World” tutorials for any and every framework. The code/components could be from another project that can be altered for this project.

BTW, at least now Iconic seems to be better match for our needs.


(Clement) #5

It would be better to develop OpenEMR which can open from using laptop and smart phone using Android and iphone. Usually a doctor can consult in the room using laptop and accessing OpenEMR through internet to webhosting. If a doctor want to do home visit let say, the doctor can access OpenEMR using his/her smartphone through Android or iOS apps using 4G/5G.


(Jerry P) #6

Need to do a slow roll here. What is being talked about here should really not be about trying to engineer OpenEMR to small screen devices but developing clients that do these task. This is where FHIR is the best fit and the general purpose of FHIR.

I know of and have tested with a couple groups that are using our FHIR/Standard Rest API for phone apps. Granted our API is still evolving but, the good news is that the engineering has been worked out with another one of our excellent engineers coming on board to help see this through.

We also are close to having a major sponsor that we hope to have with us in the next few weeks where our planned milestones point to having completed 14 to 16 weeks after starting.

The project has two major goals:

  • Complete clinical resource API meeting ONC clinical dataset.
  • Embedded Provider Client in OpenEMR that allows interfacing with external FHIR repositories to search, import and export patient data. The plan is to be able to search all available repositories and interface with a default repository for the installed enterprise. Could be public or private.

I know we have been talking about the API for awhile now and it has been slow coming but, this is going to happen one way or another as it is a mission for me. If anyone cares to help sponsor or contribute to this end, please PM me or Brady.

Thanks for your attention and regularly scheduled thread activity may now resume. :slight_smile:


(MD Support) #7

Apps run on platform foreign to current project. Each platform comes with approaches that work for a given requirement and then there are approaches that scale. This inquiry is more about leveraging any work that has already been done using a best practices for mobile apps.

In general all these clients are good consumers of structured data. So anything running on server is secondary for this task.


(Manabu Tokunaga) #8

Could someone explain to me why you would need a native app rather than 100% HTML(5) reactive mobile app?

We have a mobile clinical app on iOS but with all the installation and deployment hassles and now with browser databases, HTML5 and worker threads and notification issues becoming solved, I feel like the need for native apps are getting less.


(Jerry P) #9

For me, browser based client app’s are perfectly reasonable. But, my experience with native app’s has mainly been developing kernel drivers so the advantages here I can’t say.


(Stephen Nielson) #10

I’ve built apps both for android and iOS. At the time Ionic was too buggy for us to work well there, but it has gotten better. I have a number of friends that are having really good success with both Ionic and react native if that helps with anything. There are pros and cons to native apps and to HTML5 apps. Unless you go the Ionic/Cordova kind of route your HTML5 app will be limited and run into issues if you go beyond a simple business app.

If you want to include anything with telehealth (smooth video, audio, etc) its been my experience that you invariably will run into issues with HTML5 audio and video for anything beyond the pure basics. Android plays better here than safari support. Safari also has the option of purging your HTML5 databases from time to time even though they claim they’ll retain data. If there is any kind of memory constraint I’ve seen safari website databases be treated as ‘cached’ files and dropped whereas native app data is more likely to be retained. You also have access to all of the native device functionality as well as for HIPAA pieces better encryption libraries as well as apples HealthKit if you go native.

HTML5 is nice that you maintain language consistency and you can write once and ‘nearly’ deploy across all devices. You also don’t have to deal with the problems of the gatekeepers. I have a friend that lost over a million dollars of app development when apple decided to pull their app for some arbitrary reason. It took my company three months of back and forth iterations with Apple to get our app published because we were doing some innovative things with the network stack that their engineer couldn’t figure out (seriously 4 weeks for the employee to figure out how to click on a link in an email with no recourse to escalate the issue at the time).


(Stephen Nielson) #11

@mdsupport Also this was a couple of months ago but this thread the group had made a native app Patient care mobile app for openemr You could try reaching out to them. I’m not sure what happened but they took the link down. They might be open to sharing code with you.


(ViSolve) #12

Among many benefits in having native-apps vs browser based, one can utilize the power
of the device like facial recognition, finger print reader, camera etc
-ViSolve OpenEMR team


(Manabu Tokunaga) #13

In terms of smooth video, that’s exactly the reason why we do an iOS app, I too agree. But as for an EHR app, I am a bit perplexed as to why someone would need heavy multimedia capabilities routinely.

It’s so much so that we actually are hoping to do the “EHR” part as embedded HTML5 app and only do more heavy lifting on images in the app. But even in radiology imaging people have done some amazing things with “just” HTML5 with web based radiology viewers coming from various developers.

Yes, definitely the gate-keeper stuff has been issues with us. At one time we had a critical health care issue to fix and they are not willing to expedite the release. That was quite a bit of pain. That’s another reason why we will likely do any textual/foam stuff within HTML.


(Jerry P) #14

Hi @imanabu,
Are you aware we added Dicom viewer support in OpenEMR v5.0.1. You may upload images via Patient Documents where image is detected by mime type. They may be single images or a zip file of multiple images.
Perhaps this will give you an idea of what happens running from browser. I think loading performance will become your biggest hurdle.


(MD Support) #15

@imanabu:
From central EMR perspective, we look at iOS, Android and whatever comes next to be client devices. We see a win-win if number of interfaces included with the standard project installation increases. Towards that end, as requested in other discussion, is there any part of your app code you are willing to share with community without affecting your commercial interests? If so, either reply or PM please. Thx.


(Manabu Tokunaga) #16

First, I am so grateful that there is OpenEMR and a very active community and that it supports most of all big EHR systems support like HL7, FHIR and even DICOM as I just learned from a previous post by @ sjpadgett.

I did not want to openly post something that could be mistaken for a commercial promotion, but my company ZenSnapMD.com provides secure mobile photography and “chat” collaboration capabilities. And viewing part will always be free so that consults can be done with anyone without a worry of additional costly signups.

We are super focused on mobile photos and videos combined with chat and especially for situations in ER, Air Lift operations, Ambulance use cases as well as hospital exam rooms where internet radio signals are very iffy.

This is not something that HAIKU or Cerner Photo Capture can address well, and of course, being a full modality, we integrate our photos to DICOM and as well as in Encounter Based Imaging Modes now that Cerner Millenium and CAMM (DICOM PACS) are both integrated.

Our plan is to integrate our photos with OpenEMR image viewing capabilities. Secure mobile video and photography, I believe, is an important and under-served step in improving the efficiency and accuracy of care not just in soft tissue situations but also ENT, Cardiology and Opthalmic situations.

My first goal is to add the patient info and observation view on top of what we already do from OpenEMR so that a our mobile user can see all the important care contexts.

Anyway, that’s my intro. If anyone is more curious about where I came from, please look me up on LinkedIn profile under Manabu Tokunaga.

If any of you are going to the SIIM meeting in Colorado next month, I am there. Hope to meet with you in person.

Let’s continue to discuss what I can do to make our mobile app to enhance the values of OpenEMR!

Manabu Tokunaga


(Jerry P) #17

Our DICOM viewer was phase one of a PACS project that was, when I helped integrate the viewer, fairly mature. Maybe you could offer some guidance/advice there. Picture Archiving and Communication System (PACS) and there are several other thread discussing the same. I’m unsure why it has stalled.

Also sounds to me that you face the same issues that many other providers face in remote locations, stable enterprise/repository data access. This is where offline/online sync becomes important with the core OpenEMR infrastructure for that support being looked at currently.

While it is difficult for the open source version of OpenEMR to create and maintain value added applications, we do strive to provide tools to support those endeavors and in the case of clients, native or browser, a robust set of APIs are important. So any contribution in that regard is a win win for everybody.

Lastly yes! I am shameless in plugging OpenEMR.


(MD Support) #18

Thx @rmagauran. Current focus is to build a generic client as consumer of many services now beginning to get exposed by this and other medical systems.


(Pimm Blankevoort) #19

75Health has a good functioning App. Company bases in India, but it is definitely a OpenEMR derivate.


(Marcelo Scarano) #20

Hello,

I run a boutique development company and recently implemented OpenEMR for a couple of doctors (friends) for them to test it. I was thinking about the viability of developing a new mobile app from scratch - we have the resources and a great UI team with professional designers. The app would follow a client approach to an OpenEMR cloud implementation and would be developed using the Ionic platform, with which we have good expertise and projects running successfully.
I was wondering if there is a market for a very affordable yearly subscription or any other way you see to fund the project and keep it fresh and updated.

Best,
Marcelo