I’ve worked on the following systems and projects over the past several years. Maybe this looks impressive, but it’s been a very steep learning curve, and there were many challenges along the way.
This was either the first or one of the very few test automation initiatives for clinical applications in Wales. Clinical applications that are mission-critical are thoroughly tested, with each new build, by a dedicated team of testers and analysts before they’re deployed to production servers. There is always a possibility that an update, new feature and environmental change might affect some existing functionality. A full regression test for a large application can take several weeks to complete. Naturally they wanted to determine how much of this process could potentially be automated, and that’s where I started off.
The advantages of test automation are that a collection of rule-based tests are applied consistently across multiple builds of an application, and that, applied to the core features of an application, it vastly reduces the time required to complete a regression test (think several weeks down to ~40 minutes).
Automation isn’t without problems, though. A test automation system, by its nature, cannot adapt to minor changes in the core application, and tests can subsequently fail without any defects being detected. Coded UI Tests for a large application will also become a software project in itself, requiring maintenance, version control, documentation, etc.
We develop Web Services as one of our systems integration solutions, to provide something of a compatibility layer between clinical applications, databases and service broker. Typically a Web Service has an entry point, a controller and an Object Relational Mapper (e.g. Entity Framework). It might accept requests and associated parameters, pass them to stored procedures and return the response as a JSON data structure.
What messages do our Web Services handle? Well, often it’s blood test requesting and results reporting, and one of the things that came of it is that samples don’t need to be acquired and tested at the same site. Blood sample could be taken and the test results be made accessible at different sites. Test results and other demographics for a given patient are available to clinical staff at any site.
A healthcare professional with access to a portal application could view diagnostics, test results demographics and other information for a given patient, regardless of where that data originated. This means the information is readily available wherever needed, and patients wouldn’t need to travel to any specific facility.
As I understand it, pathology, radiology and cardiology data are supported.
This was particularly tricky to develop. Some of our applications communicate via an asynchronous Service Broker messaging queue, and occasionally malformed HL7 v3 messages are pushed onto that queue for whatever reason. The Messaging Dashboard displays the contents of the binned message queues, to help those administering Service Broker to determine the cause of the errors.
What made this application tricky to develop was that any message displayed by the Dashboard would be marked as read by the Service Broker, and either removed from the queue and/or pushed back onto the queue with a different conversation ID. Also, the Dashboard required some additional logic to perform data transformations to make the messages readable.
Messaging Metrics Dashboard
Closely related to the Web Services, as it’s an application that displays the status of the messaging systems.
Basically this was another Dashboard application, but this one displays information about the messaging systems, such as the volume of messages being processed, how many messages were being generated at each facility, the volume of messages by type, etc.
I’ve since began working on an improved version of this application as a side-project.
Reference Data Service
As the name implies, this deals with reference data used across the healthcare organisations. This is essentially an ASP.NET application that provides clinical staff with an interface to our reference data systems. I’m currently extending this to make it interoperable with third-party systems.