So, in recent years, there have been many advancements in browser standards and technologies which they support; two major ones are CSS 3.0 and the use of HTML5. Neither of these technologies are supported by older browsers such as MSIE7 and MSIE8.
Both MSIE7 and MSIE8 have been defunct for some time now, and are well past their ‘end of life’ with Microsoft. This means that they no longer provide updates, security patches or support for these old browsers. There is no way that anyone in any business or professional setting ought to still be running these browsers if they are capable of connecting to an internet based source of content. (Legacy APP support on an isolated network might be the only excusable reason to want to run these versions).
In some settings, a ‘WebBrowser control’ is used within other applications to allow the desktop based application to access, and view web based content. In particular, Microsoft provided such a control, and allow MSIE to be invoked in an embedded manner within other applications. This is the approach used by both Medtech and MyPractice.
The ‘WebBrowser control’ ships with some standard, default settings which force certain behaviours unless altered. The good news is that on a per-application basis, registry entries can be added to the machine which uses these controls, to nominate what emulated version the current desktop browser ought to be run as. This is where things get a little confusing and certainly more detailed…
If you’re running Windows 7, Windows 8 or Windows 10, the chances of you running MSIE8 as your desktop browser are almost nil. However, the WebBrowser control’s default settings force even these newer browsers to run in an emulation mode, pretending, and limiting the browser’s function to that of MSIE7. Clearly this is a hampering default setting and one which severely limits the usefulness of the embedded browser.
This is a major issue for software development companies who maintain modern approaches to development and deployment. Enigma, as one of those companies is focussed on delivering the best in terms of usability and end-user-experience as well as security. This means that we need to be able to use the most modern application development approaches and frameworks. – Simply put, we cannot while your embedded browsers are being forced to continue to run in this MSIE7 compatibility mode.
So, we’re forced to find a way to allow you to use your native browser, the one installed on your desktop, your current version. – A linked popup window appears to be an interim solution. It’s not the most appropriate answer, but it will allow us to continue with delivering decent software, in an integrated manner. We’ll only have to take this approach until the PMS vendors have figured out a suitable way to allow all form vendors to make use of the latest versions within the PMS.
— But, can’t that happen now? You mentioned Registry settings?…
Yes, it can. By adding a changed registry setting, your PMS vendor can opt into allowing the very latest browser which you have installed on your desktop to be used within the PMS. This is something which they are capable of delivering out to you within a version update.
— So, why have they not done this?…
There may be more than one single reason, but the easiest to explain is that there is concern over whether all forms which have been previously deployed will continue to work in this latest version. So until they have managed to talk to all form vendors to assess their readiness, they appear reluctant to change these settings.
— Is anything being done about this?
Yes, there have been a series of discussions which date back over 18 months on this topic. Also, we have started to make plans to use this popup method of window-linking between the window within the PMS, and the popup window. Using this approach, we’re able to talk back to the PMS, to perform our approved methods of integration with the PMS, using data, and writing back etc; while making the most of the newer capabilities and functions of your more modern browser.
— So this is a temporary thing?
Yes, we very much hope so. – There are some potential issues with this approach which make it a little more clumsy for end-users, you might lose sight of where your window is etc; also if you close the patient within the PMS, there is nothing we can do apart from simply close the browser content, we will attempt to warn you that you have a patient based window still open before you close it, but if you do close it, and if you have already entered content into the popup window, then you will lose that work, sorry. Arguably, this is no worse than the current workflow, if you close a patient with an open embedded window, and accept it can be closed without first saving / submitting that work, you could lose that too.
— How long until this is sorted properly?
We cannot give you an idea of timeframes as the work is outside of our control.
— Which PMS versions is this currently a problem in?
At the time of writing: We have experienced MSIE7 version mode being forced in Medtech32, MSIE8 mode is being forced within Evolution. – Neither MSIE7 or MSIE8 is new enough to support our current needs, we will use popup windows in all PMS systems where their embedded browser versions are not new enough to support current development approaches. MyPractice does not apply any version-mode limitations.
If you need further information on this topic, please contact the team @ Enigma: firstname.lastname@example.org