looks like patch 1 is already installed based on the (1) after 7.0.0
ah okey. So I will not continue the path to install.
Yup I see the (1) there.
Will get back working on the issue.
Hi @stephenwaite , @adunsulag ,
Can you check where AM I going wrong please I feel somehow the Authorize URL is giving me a hard time connecting via Postman.
Hi All,
Yippyyyyyyyyyyyyyyyyyyyy
I got ittttttttttttttttttttttttt
Its workingâŚ
The callback URL was creating issue and I unchecked the âAuthorize using browserâ .
Couple of quick clarification as follows.
-
My scope includes âofflineâ so I guess I will have this Bearer token valid for somehours? May I know the life span of it ??
-
In case this expires I dont want to do a click click and say use this bearer and then call my API , is there a more automated way to get the bearer token even before it expires so there is no hiccup in my API calls
Please assist me I am soooo happy. I guess I have to listen @adunsulag video all over again to check if he has answered my above questions 
Regards,
Ayesha
We probably need to put this in the main API documentation, but the token life span is described here.
Note it talks about SMART apps but this applies to all registered oauth2 clients.
Hi,
May I ask you if there is a way that I can get the Bearer Token to be used avoiding the below screens.
- Click on the button > âGet Access Tokenâ
Next I get the below page after passing the credentials.
Only after I say âUse Tokenâ > I can click on the âGETâ URL to access the patient data.
Is there a way the above manual click steps can be automated. If so please guide me.
And many many thanks for all your responses.
Regards,
Ayesha
You need to describe what application you are trying to build or what your use case is. There is a reason why the system asks you to authenticate and go through those screens. Without understanding your use case, we canât advise you on if there are possibly alternatives for what you intend. If you are building an application that is patient or user facing that requires consent of the user, you SHOULD use the authorization_grant as the user/patient needs to be informed of what data you are grabbing on their behalf. The password_grant is another mechanism you could use but it should only be used for testing and at some point we will remove it from OpenEMR all together.
If this is a backend application you are using for backend communication, you could look at the client credentials grant. Its a much more complicated grant process but it allows you to do API calls without having to do an authorization session.
If you are building an application that already exists inside of OpenEMR and you want to just piggy back off the already existing session access controls you should look at the readme for using the API internally openemr/API_README.md at master ¡ openemr/openemr ¡ GitHub
Hi @adunsulag ,
Thanks for describing all the scenarios so well.
Yes my application is backend application where we are planning to use OpenEMR as the front end, no patient portal. So once the data is logged in OpenEMR we are working on connecting to a common entity which is a central repository using a EAI in between in this case Mirth connect to pull data out build it in Hl7 message formats based on patient episode for different triggers(ADT 04, ADT 08 etc, SIU, ORU etc) and load the message to the central entity.
Which means I donât want to keep passing and authorizing the bearer token as I would like to automate so the flow moves on smoothly.
I guess as you suggested the client credentials grant would be a good fit, though I have not checked will do some research on these lines, and if you can assist or guide to the right path it would be much appreciated.
Kind Regards,
Ayesha
Hi @adunsulag , @stephenwaite ,
Please find my description above.
Can you kindly guide me on the go to solution for the above mentioned scenario please.
Regards,
Ayesha