OpenEMR API

OpenEMR Development
1

bradymiller wrote on Friday, September 07, 2012:

Hi,

There is currently a SOAP API for patient portal functionality, which is at openemr/myportal (note there is very minimal documentation).  The next step is to develop a more comprehensive and well documented set of APIs (need to determine whether to use SOAP vs. REST vs. another type and need to determine what actual APIs to build). There is an organization that may potentially offer to build (or sponsor somebody to build) these API if we provide specs on which API functions OpenEMR should have. Any thoughts on whether to use SOAP vs. REST vs. other and on what API functions would be useful to have?

-brady
OpenEMR

2

mcaloon wrote on Friday, September 07, 2012:

Hello,
    I have done some SOA development and coming from a UNIX background I find REST, being an engineering approach vs. a framework, a much simpler way to build interfaces. The community would have a lot of latitude in designing and implementing the openEMR interface as a collection of “URI addressable resources” offering up their objects. REST is also prevalent in the net as an interface discipline. SOA has a mature definition but can be a bit complex for a non-developer/administrator type user.

Mac

3

mcaloon wrote on Friday, September 21, 2012:

Hello,
     Here are some ideas for the design of the “opeEMR API”. If we agree, it will be based on the REpresentational State Transfer (REST) approach which is an architectural style whose name was coined by Roy Fielding and can be further explored by reading his PHD thesis here http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (along with a lot of other discussions across the net). For those of you familiar with SOAP (Service Oriented Architecture Protocol), yes, REST will not make your head explode as it is only as complicated as we choose to make it. :slight_smile:

    Basically the HTTP protocol GET, PUT, POST and DELETE messages are used via URI specification (new URIs) to access the collection of openEMR resources that we choose to publish to the world (or a health care team’s secure view of that world - more on this later).  This proposed API is the basis for the openEMR mobile platform where devices will have a native device application running locally using the openEMR API to process the healthcare team’s workflow when caring for patients. This API might also be helpful in re-designing the workstation user interface that we’ve been bandying about on the forums recently.

    The premise being that the API (useless on its own) will be released with the corresponding mobile apps on a set of devices that the community is currently using or planning on using. We’ll need to use a cross platform tool to support both IOS and Android. We’ll be implementing new server side methods to respond to each new HTTP request and these methods will produce JSON output. There will be a lot of existing code that could be snagged to streamline this implementation, especially when dealing with the database.

    The interface and its application will evolve, but the initial release focuses on the workflow for handling the initial patient encounter, acquiring vitals, current medications and the hand-off to the physician.  There has been much work done in the forums on this encounter workflow (I can’t recall the location right now) and it will serve us well to use these analyses as input in implementing this message based model.

    The primary resources for the initial release at this point that we’ll be “publishing” via the interface are:

  • Encounter

  • Patient

  • Medications

  • Vitals

  • Calendar

  • Reminder

  • Live Messaging

For example, the URI

<splat>/mobile_openEMR/patient?cmd=search&lname=miller

might the be eventual format of the URI for an HTTP GET command that we’d be using to retrieve the list of those patients with last name Miller.

We’ll have to build out the list of resources, the methods associated with each resource and the mapping to the appropriate HTTP operation for each method. There is a lot of work here. Collaboration…… :slight_smile:

More to come another post…

Mac

4

tmccormi wrote on Friday, September 21, 2012:

Mac,
   Surface level, REST is as good a choice as any.  We should note there are already several interfaces that are SOAP based in OpenEMR.  The use of URI to make calls to functions/classes/modules is also in use in numerous places, like the Rules UI framework and many of the Controllers based objects.   That model is fine by me, but it does tend to confuse straight up functional programmers :slight_smile:
-Tony

 

5

robertdown wrote on Saturday, September 22, 2012:

I like REST over SOAP as SOAP seems to have a larger learning curve, some more overhead, and in my opinion doesn’t fit as nicely into the URI architecture as SOAP (Although that’s a different conversation).

I feel REST would be easier to implement cross platform (iOS, Android, Flex)