We’ve been connecting to EMIS for several years and Thursday they stopped allowing connections from old versions of their EM_PACC.dll (those using TLS before 1.2 encryption).
They’ve told us to find a new version of their DLL from a EMIS Web client install.
However this DLL only works when an EMIS Web client is running on a machine, as soon as the client is not running we can’t make a connection.
I have this call which returns a sessionID if EMIS Web is running.
var result = emisole.InitializeWithID(2, _apiConfig.ServerIP, "", "", _apiConfig.SupplierID, _apiConfig.Key, out cdb, out productName, out version, out loginID, out error, out outcome, out sessionID);
If it is not running I use the returned loginID with this call
result = emisole.Logon((string)loginID, _apiConfig.User, _apiConfig.Pass, out sessionID, out error, out outcome);
This call is now returning an unsuccessful 3 outcome code. Have tried changing the users password
They clearly don’t value integrations if this is their attitude to providing an “EMIS SDK” - go and extract a bit of janky code out of the EMIS Web Client!
Integration is primary care is becoming a bureaucracy and complexity nightmare. It is far more difficult than secondary care.
I think we need client suppliers to start banding together and demanding what the API’s should be. For example this upcoming EU EHR requirement would work in primary care (something very similar is now quite common in UK secondary care and regional systems). Note: NHS Digital+X+INTEROPen did suggest something like this in 2019 (GP Connect did something else).
In plain language it’s a RESTful JSON API and secured by OAuth2 authorisation (and can work with OAuth2 authentication and openid). It will also have a EU Common Core data model.
