Api

OpenEMR Development
1

technobuddhist wrote on Saturday, November 19, 2011:

Hi,

Is there some sort of API that would allow OpenEMR to be used from a standalone application? I thought I read a post about xml-rpc somewhere but can’t find it again. I can see some xml-rpc code(xmlrpc.inc & xmlrpcs.inc), but looking at some of the individual php pages, can’t see it.

I have a customer who would like an app written, but it is far too large to start form scratch and OpenEMR fits a large proportion of the functionality, but they require it to be an iPad only app, a browser is not an option for them. They want lots of eye candy, the ability to use the camera and other bits that mean a browser won’t make the cut.

If there are any changes/mods/enhancements to OpenEMR then obviously this would be fed back into the community, but the iPad code would reside with the customer unfortunately.

Many Thanks

2

technobuddhist wrote on Sunday, November 20, 2011:

I can imagine the effort in creating some kind of api, I’m not going to go down the route of parsing the returned html, nightmare for changes!

Thinking out aloud… How much effort would it be to put “xml data islands” in the html? That is much less hassle if the underlying html page changes but the underlying data hasn’t. Parsing the xml data islansd would be consistent even if there were layout changes to the html.

Feasible? How much dev effort, I’m obviously up for helping to change them if it’s a reasonable idea, assuming that we use openemr.

Cheers

3

yehster wrote on Monday, November 21, 2011:

First,
Not sure if/how much real progress these guys who are working on an Android app are making, but I think the discussion is relevant to this topic.
https://sourceforge.net/projects/openemr/forums/forum/202506/topic/4790802
Second,
There are SOAP calls available to access some functionality as used by the third party portal, ePrescribing through Newcrop and the Lab Exchange Network.   However most of the functionality is not neatly packaged.
Third,
The notion of returning XML or JSON instead of or in addition to HTML is interesting.  The difficulty I think at least in part is that the data access/logic coding is highly intertwined with the HTML generation in many places in the code. The ideal solution would decouple data processing from HTML/UI.

I am not familiar with iOS development/applications.  Is it simple to render HTML fragments in a native iOS app? Can you build something that is basically an “augmented browser?” Is a hybrid solution where some of the data is still entered through a browser on a PC, while other info is captured on the iPad acceptable to your customer? For example, do you need to be able to edit the full patient demographics through the iPad app?

If you really want to use OpenEMR for a fully native iOS (or Android) application, I think what you need to do is to start identifying core functionality that you absolutely need and figure out how to encapsulate it.  Like, what do you intend to do with the images you capture from the iPad camera?  Are you going to “upload” it into the existing patient documents workflow? Or something else?

-Kevin Yeh

4

technobuddhist wrote on Tuesday, November 22, 2011:

Thanks Kevin,

1. I’d seen the droid thread but discounted it because it appears they are maintaining the browser based model. Although if they do want to go bespoke app, then we could help each other by creating some form of api/data island dev.

2. If our client is happy to go with openEMR then from the high level requirements they have, there would be a large proportion of OEMR to be accessed, so I’d go with the way that the main devs would want to go for future proofing.

3. I agree decoupling is the best way to go. I’ve just had  a very brief look at some of the code and I see what you mean there is very tight coupling and integration with the data. I’ve not done anything more than a cursory look, but I can see that it could be a real pain to get the data into some kind of meaningful packet/island. Definitely some work to do on that front.

On iPad there is a widget that is basically a browser renderer. You could have an augmented browser in a single window(with your own widgets and UI surrounding it), or you could even have several of these widgets resized as you see fit and display them wherever you wanted on screen,… kind of like html frames for want of an analogy. Some of them could just display html, whilst other ones could accept input.

Not sure yet whether this is acceptable, at the moment I’m assuming not, but these html widgets can be well disguised so that you wouldn’t even know you were looking at html in a widget!

My problem with using html is the limited screen size on iPad. any change to OEMR could make the hybrid app look rubbish and the client would definitely not be happy! Yes they will want access to demographics.

One example given to me would be to use the camera to take a picture of new patients as their patient id photo, obviously uploaded along with their patient record. This would have to be done as seemlessly as possible with no manually uploading the photo using the file upload  feature and finding the correct folder in a structure to upload it to. 3 click operation, click1 on a photo button on the new patient screen, click2 to take the pic, click3 to confirm photo or retake. Photo is automatically uploaded and stored in the correct place.

I’m waiting for more a detailed requirements list that can be signed off anyway before we start anything, as well as there thoughts on using 3rd party server software(OEMR) that they have no intellectual property over. Like you say, when we get that, then I can start to identify the functionality and think of a way to encapsulate it.

Thanks for your thoughts, I may be back(or another developer) when the client finds out how they want to proceed.

Thanks.

5

yehster wrote on Tuesday, November 22, 2011:

Also FYI
There was also an effort to develop a mobile version of OpenEMR that would display nicely on phones.
https://sourceforge.net/projects/openemrmobile/
Some of the concepts those guys used may be applicable to your situation.