Posted on behalf of Lily Cohen, Marketing Associate at Summit Healthcare
I sat down with Paul Actis, Summit’s Senior VP of Research & Development, to learn more about the upgraded SST Web Dashboard with Citrix and Script Engine Enhancements.
Can you provide an overview of what the new SST Web Dashboard is?
To talk about the dashboard, you have to take the whole platform into account.
Previously, SST was a standalone application. It would get installed on a user’s system, but there was no communicating with a more centralized management system – what any record did was isolated to that machine.
What we did in the 2005 version is open up SST to Summit Exchange. Summit Exchange is our integration platform. It does all the HL7 and web services work within the hospital ecosystem. You can distribute that work on what we call “engine servers.” It has a centralized management tool or view, and it also combines with our Summit web platform to give you a web integration into those servers from a mobile device outside of the network.
SST didn’t do that before – we brought SST into that mode now. Now you can manage both your HL7 and non-HL7 or non-integration servers from one view. It’s nice because it gives you the ability to set up what we call our “workflow servers” alongside your integration servers and to share data that way. You can manage and edit workflows from that one view. You don’t need to have one person logging into specific workflow servers in order to monitor what their workflows are doing.
Can you talk about the improved functionality with Citrix and Meditech?
As we’ve transitioned to a more virtual environment, hospital systems are moving away from physical machines and more towards virtual machines. We can then put our applications on what we call Citrix servers – then you have a “thin client” that allows you that view into the applications and is much more manageable from an IT Staff level.
A “thin client” is like a web application that’s user-facing. In regard to Meditech, it can look like their own windows client, or what you’d call a “thick client.” A “thick client” allows you to manipulate the application in a different way. You grab different things, like text off of the screen, change the cursor position, etc.
When we talk about “thin clients” or a Citrix client, it just installs a pathway into that server or application, like a web application. From an automation standpoint, this makes viewing the application more difficult, because it presents itself as one big image. Whereas if we look at something like Meditech, a “thick client,” we can view all the inner controls within the application. From an automation standpoint, this is a lot easier to work with. With the Citrix connection, we were able to manipulate, interrogate, and render text from those images to give you a more reliable and consistent way of doing automation.
The simple functionality of automation is mimicking a user. In the case of logging into an application, instead of a user being presented with a screen, typing in a password, and clicking a button, the automation opens the application and renders keystrokes and mouse clicks, logging in for you. Automation also has to make decisions.
In the case of Meditech, if you’re updating a doctor’s dictionary, and you put in bad data from a user standpoint, you would see something that comes up on the screen and it tells you it’s bad data. From a machine standpoint, it won’t know that – so you have to have the machine learn those things. What the Citrix connection does is provide the ability to work with “thin clients” at the same level as working with “thick clients,” making the automation much more reliable and better able to make decisions as opposed to blindly rendering keystrokes and mouse strokes.
To learn more about our RPA solutions, sign up for our upcoming presentation:
Improve Processes and Increase Efficiencies Organization-Wide with RPA
November 10th @ 1pm EST
