Notifications
Clear all
Topic starter
I have read the document "CENTRICITY INTEGRATION WITH AZURE" on the support site, but i still really don't understand why GE needed to add this additional level complexity.
Anyone with a 10,000 foot description of why they decided to take this route?
Thanks,
Peter
Posted : September 23, 2018 6:17 am
Topic starter
is it only to enable patient access to information via APIs? If so isn't it a shame that they force everyone to do this even if you never plan on allowing that.
Seems like they should provide a local option to the APIs if you wish... or is it because the new APIs are not JAVA so instead of having another APP server locally they just force you to use Azure... if that is the case, that just seems lazy.
Posted : September 23, 2018 6:29 am
You are correct, it does have to do with open API access. It is not just for patients. It is also for third-party developers so they can extend the functionality of Centricity’s native solution. I understand the concerns and frustrations, however all EMR companies will be incorporating open APIs to accommodate greater interoperability. The choice to move authentication to Azure in order to provide access to the API makes sense because the overall strategy for Centricity is to move functionality to the cloud. This is not an endorsement necessarily, but an explanation as to why we are seeing these changes. I would encourage you to attend the upcoming GE State of the Union as I suspect they will be sharing more information about their roadmap.
Posted : September 23, 2018 6:57 am
Topic starter
I'll be there for the next state of the union although I don't expect much more information out of it than the last one unfortunately. I listened to the webinars about the AAD FIHR API, etc. Unfortunately none of the links in the presentation work since they switched from JIVE to the Force portal... lol. Also the expert on the webinar couldn't answer basic questions about multiple domain controllers, domains etc...
Hate subscribing to such a closed model (MS cloud).
We are getting way to complex here for a small practice, not that we can't handle it but definitely overkill, but yeah we bought in 1998, before Allscripts was even a twinkle in someone's eye. Very jealous of all of those practices.
Posted : September 23, 2018 4:24 pm
Question regarding this new process, if I am understanding this correctly when the Users sign into Centricity they would use the same password as their network login.
Thank you
Posted : September 24, 2018 2:32 am
@Beth Ann, that is correct. You might be able to continue using the identity management native within Centricity (i.e. not integrated with Active Directory) for some grace period, but this will limit the functionality you have within Centricity over time. In other words, it won't be practical over the long haul. I think the bigger concern on everyone's mind is how the Azure AD integration will work. For instance, will it be possible to specify a local domain controller as the primary authentication server or will access to Centricity only be granted after authentication with Azure? I think a lot of folks are going to have issues if access to Centricity will be dependent upon the reliability of your Internet connection. GE's strategy seems to introduce an additional point of failure, so I'm hoping one can use a local AD server if/when connectivity to Azure is compromised.
Posted : September 24, 2018 3:18 am
Topic starter
yes, but you can do this starting with CEMR 9.10, without having to do anything with Azure Active Directory.
Posted : September 24, 2018 4:33 am
Hi - question for those who have Azure integrated... We have several EMR accounts created for service layer purposes --DTS EMR user account and SMPP EMR user account for example. For these generic accounts, were you required to create an AD account for the Azure integration?
Posted : December 20, 2018 3:28 am
