OpenEMR API is a REST based API for OpenEMR. It provides almost complete functionality of OpenEMR using the powerful REST architecture and enables users to access all the basic functions that can be performed using OpenEMR in a very easy way.
It is developed by Master Mobile Products to allow the iPad based application, MED Master Mobility, access to OpenEMR and perform all basic operations in a perfect way. Do check the iPad application on app store to have an idea about API’s usage in more detail.
The API can be used with any software application to use OpenEMR deployment on server and perform operations as they are performed on OpenEMR. All the operations performed using API are totally in accordance with the OpenEMR standards. We would like the API to be refined according to the suggestions/recommendations from all of you. Do suggest and let us make it perfect and part of OpenEMR.
Wow, you read my mind yehster. Need to make sure the API supports all the triggers related to meaningful use reporting. List_touch is just one of them. There is an AMC reporting table and some others places. Good chance to document all the critical places that are part of this.
Tony
I have merged your latest pull request containing the copyright/gpl and some of the security updates into the master branch of the oemr501c3/openemr-api project.
@Yehster,
No, at the moment API is not using setListTouch() when update list is performed. In API it is used when a list is added. Will surely be looking into further details to improve it asap.
@Tony,
Sure, we will make sure API supports all the triggers. And thanks for merging the changes.
It seems like the best thing to work towards short-term is getting your code in the official OpenEMR codebase. After looking through your api, here are my thoughts in order to get it into a form that could be integrated into the official codebase:
1. Place your code in an a directory called api
2. Implement in openemr database (create a api_tokens table to hold the tokens, modify users table along with pertinent form information along with places to enter them into the Users GUI within OpenEMR)
3. Incorporate a global(Administration->Globals) in openemr that shuts this down (Maybe a Allow use of REST API server? in the Connectors tab) that is default to off; guessing easy to incorporate the global in the validatetoken() function.
Then after it’s in the official codebase, my thoughts would be on other things like:
1. Run all queries through the openemr sql wrappers (You have already taken this on in your last code revision )
2. Incorporate the new security model (http://open-emr.org/wiki/index.php/Codebase_Security#Plan) (You have already taken this on in your last code revision )
3. Translate the strings (will be best to work out a way to escape the xml, which it appears you have already worked on with the xmlsafe function you are using; figured I’d look more into this (and potentially incorprating the xmlescape function and creating a hybrid translate/xml escape function) when the code has evolved a bit more)
Look very forward to the next revision,
-brady OpenEMR
PDF Library is used to generate PDF reports based on OpenEMR reports format. We are also looking to get the HTML reports directly from OpenEMR and send them in response when requested.
It looks like you are quickly approaching a form that is ready to be integrated with the OpenEMR codebase. My thoughts are that you should start an OpenEMR repo (and then proceed with the following): http://www.open-emr.org/wiki/index.php/Git_for_dummies
(above is a link on starting an OpenEMR repo on github)
1. Create an api directory in the OpenEMR repo and copy the contents of your api directory there.
2. In your original repo, don’t bring over the openemr directory, readme.md or license.txt files
3. In your original repo, Update the Medmasterpro-API.pdf file (I suggest considering changing it to simple text to make it much easier to update/maintain) and place it in the Documentation directory of the OpenEMR repo
At this point you should be now working in the OpenEMR repo that has your api directory in it. Then would proceed with the following:
1. Migrate the openemr/api/includes/pdflibrary folder to the openemr/library folder (There is a possibility that your solution of html->pdf may be superior to what we currently have in openemr/library/html2pdf, so it makes sense to put it there for now)
2. Wrap the openemr/api/includes/functions.php with the OpenEMR sql wrappers and convert the queries to the new security model (ie. use binding).
3. Once number 2 is complete you should now be able to remove the openemr/api/includes/class.database.php and openemr/api/includes/configure.php files.
4. Remove the openemr/api/includes/class.phpmailer.php file and use the file already at openemr/library/classes/class.phpmailer.php instead.
5. I am not sure what the openemr/api/includes/apns-dev.pem file does. What is the role of this file?
6. Add your global to openemr/library/globals.inc.php as you have already done previously.
7. Add the api_tokens table to the openemr/sql/database.sql (alphabetical, so will be placed near top) and openemr/sql/4_1_1-to-4_1_2_upgrade.sql script.
8. Add the new sql columns to the users table to the openemr/sql/database.sql and openemr/sql/4_1_1-to-4_1_2_upgrade.sql script.
9. To the api, add two more functions/scripts:
-version.php (simply returns a version that you have hard-coded within the script; so start with 1.0; this can then be incremented when you make any significant changes in the api)
-version_openemr.php (returns the openemr version information in the ‘version’ sql table, v_major,v_minor,v_patch,v_realpatch will suffice; just so you know, the labels are not very intuitive, so here is an example, 4.1.2(10) would be v_major is 4,v_minor is 1,v_patch is 2,v_realpatch is 10)
After this is done, your code may then be ready for getting committing into the official codebase (of course, make sure the api is working for you).
Forgot to mention the v_tag column in the openemr version table. This is important, because it is set to ‘-dev’ for development versions and set to be blank for production versions.
We’ve made changes in the code and structure as you asked.
Move code to api directory.
Make security changes in the code as describe on wiki http://open-emr.org/wiki/index.php/Codebase_Security#Plan and remove duplication binding.
Create api_tokens table to hold tokens instead of tokens table. Remove medmasterusers table and incorporate extra fields of medmasterusers table in users table (fields that are not available in users table).
Add “Allow use of REST API server?” settings in Administration->Globals->Connectors and place check in the code to check the settings. API only works if user enable settings. Add settings in library->global.inc file and you can find file in openemr->library directory.
Add copyrights text in all api files as describe on wiki http://open-emr.org/wiki/index.php/How_to_Document_Your_Code_Properly#Page-Level_DocBlock
Please review the code and let us know, if any changes are required.
Yes, it is getting close. After my suggestions above are finished, then the last step will be to do a detailed review of the actual algorithms; I’ve been looking through these, so don’t expect any big surprises. There will likely be some issues that need to be addressed to avoid obvious breaking of things (for example, it appears that copays are going to the billing table rather than the ar_* tables) along with MU issues that yehster brought up. Note it is actually a bit tough to enforce strict standards/compatibility of OpenEMR with the full web application and the app because a lot of the implementation(and incompatibility issues) will be dependent on how the client application calls these APIs. There are potentially even new features in here that we can bring into the main web application (for example, saving of user photos/docs/etc). Anyways, it’s exciting and look forward to seeing it integrated into OpenEMR and devling further into the API specifics.
Please have a look at our forked OpenEMR repository here on GitHub if you can manage some time for review. It contains the changes you suggested earlier. We are testing it finally before sending a pull request to merge changes into master OpenEMR repository.
Do suggest if any modifications are required or in case if anything is not correct.
Let me know when the code is working for you. Then I (and hopefully others) will start walking through the scripts to ensure that the functions are compatible with OpenEMR web browser use. I was hoping to get some clarity on how you are using this app. This app appears to be something that the physician/scheduler can use on the ipad for workflow. However, it appears you (meaning the clinic or IT support) still need to use the OpenEMR web browser (ie. backend) for features like reporting etc. Having that concept clear will make the code review easier for myself.
On the version.php script in api, just return a hard-coded version of your api (for example, could start with 1.00 for now) to the caller.
And for the version_openemr.php script in api, just return the variables within the main version.php script (so could require_include the main version.php script and then send these variables back to the caller).
And the way you are managing your github repo looks good (as you are doing, the merging in of the official codebase every week or two is a clean way to keep your code updated to the most current codebase).
Yes, the API is working well on our side after the suggested changes are completed.
We have also deployed the updated OpenEMR code (with changes to API as suggested by you) on our test server deployment(s) and everything seems to work perfectly. We have also initiated a pull request on GitHub to pull final changes to the OpenEMR codebase. Please start code review and let us know if anything else is required in this regard.
About the use of the API, yes you are absolutely right. The MedMaseter Mobility API was specifically designed to allow our mobile applications (iPad; and possible future Android) to connect to an OpenEMR installation. The application provides access to but is not intended to replace an EMR installation, but rather to enhance the EMR and provide mobility.
The API allows application development that can have its own flow and can use different presentation, but will totally be dependent on OpenEMR deployment for all its functionality.
This API could also be used by other Desktop or Web applications. (MedMaster’s Mobility applications remain proprietary and do contain several items that are patent pending).
So just to be 100% clear, the user will still need to have and use a complete OpenEMR installation, and many functions must be done through that installation.
Our feature set will continue to expand to provide a better mobility experience, but is not intended be a complete desktop replacement.
Please review the latest code and let us know about your suggestions.
Thanks for the clarification of use. This is going to be a “marathon” review that I predict will take weeks/months. The goal is to have the use of the api be 100% compatible with the use of OpenEMR(current development version) over the web browser(and goal of having it ready by the 4.1.2 release). Should have some time over the weekend to begin the review.
(There is no need for pull requests or anything like that. We will work from your openemr repository. When complete, is straightforward to then bring this into the official codebase.)
Thanks for your reply. Sure, please start the review whenever it is easy for you. We have already tested OpenEMR over the web browser after complete inclusion of API according to your suggestions on our test server and it worked well.
Yes, I agree that the review would be very thorough and detailed, and will take time. We will surely welcome any suggestions /recommendations from your side to make the integration process as much quick as possible.
Another thing I’m trying to get clarification on is the notification function in includes/function.php is doing, which seems to be using a live messaging type of server via badge id’s stored in the api_tokens in some pertinent parts of the api? If this is the case, then this specific feature should be controlled by a global (would place it below the global you already added).
)