Connecting new data manager

This week, a new data manager went live in the lab. It’s not important which as what I want to discuss would apply to loads of them. This particular one was in a Blood Science lab but the thought process would also apply to certain Microbiology analysers. Not sure about the Cell Path.

Instrument connections would generally carry orders and results. If there is a single connection, only one thing can happen at any one time. So all the time orders are being sent, results are held back and all the time results are being sent, orders are held up. This is generally okay for lower volume analysers as the frequency or orders and messages doesn’t cause a problem.

When you start hitting the volumes seen in a data manager handling full blood counts and general Biochemistry, it then does becomes a problem. To prevent this issue, a dual connection is used. So orders are sent via a dedicated connection and results are sent back on a different connection. Think of it as a narrow country lane versus a road with a central reservation.

Under no circumstances should anything new just go into use without testing. From a LIMS point of view, you might have a dedicated version of the LIMS to perform testing of new things to ensure everything is working okay before it is used in a production environment.

The scale of duplication of testing and production environments might vary between hospitals but it is also good to have a test system to try things out in before real world use. Which brings me back to the go-live.

The data manager had been tested in the test environment and everything was ready to go live. The first samples were loaded and the order channel was monitored but no orders were being seen. The data manager was happily reporting it was connected but wasn’t seeing the orders.

When you have two systems and you switch over, make sure you connect to the right one! As the testing connection was still running, it latched onto the data manager meaning that the production connection couldn’t connect. It should be a quick fix to rectify this kind of issue.

Then when production was indeed connected to the new data manager, things weren’t running smoothly. Orders were being sent on the results channel and the data manger was getting confused as it wasn’t expecting to get orders from there.

This is a downside of having a complete duplication of production and Live, it means that everything has to be configured twice and allows room for mistakes to creep in. Or potentially problems noted during testing and fixed in testing have forgotten to be applied to the production environment.

Even if testing has gone smoothly, never just assume it will just work in production. Never just assume that when you have made a connection, it definitely is connected to what you think it is. So in this case, when the new connection from production was started, the testing connection should have been stopped so there was no chance of it establishing a connection to the data manager.

Also, make sure the settings in testing match what they are in Production. This step needs some thought as there will probably be some differences e.g. testing IP address could be different to production. So note any differences and think are they justified. Also remember to check spellings. An instrument called ABC in one place but called ACB in another wouldn’t be seen as being the same thing and may cause issues.

Sometimes, no amount of testing will ever guarantee a problem free go-live as you are never able to fully replicate the real world in testing. What you can could is eliminate the predictable problems to reduce the scale of problems. Make sure you have tested the different situations you would expect to see in testing and see how they appear in the downstream systems.

Most problems can be easily fixed. The challenge is spotting where the problem is and finding the right person who can fix it!

 

Data migration

A lot of labs will pursue a data migration strategy when they have a new LIMS. Some may choose a little data to move and some a lot. the scale of the migration can be variable on a project. Generally transfusion would seek to have a full migration of data whereas Blood Science might only migrate creatinine data of rate AKI calculation.

With the march towards digital pathology in Cellular Pathology, I don’t think any hospitals have had to contend with a data migration of their digital pathology data. I do wonder if the image data is stored in an open standard or some proprietary format.

If stored in an open format, moving the data would seem to be a fairly easy and reasonable task. If stored in a proprietary format, I suspect a lab might be forced to maintain some level of access to the data as opposed to trying to re-scan their slide archive.

I am intrigued by the challenges created by digital pathology due to the amount of data being stored each day. I think I recall a terabyte per day as a possible level of image data being stored for a reasonably sized laboratory. Even if the dat was half that size, moving 5-10 years of data would be an immense task. I would like to think that the cloudy mccloud would be able to cope though I would expect it wouldn’t be a simple, straight forward task.

Maybe I will be able to revise this topic when I have some firm answers!

Dipping my toe back in the NHS water

I spent yesterday visiting my new employer trying to get up to speed with some of the things I need to know ahead of my start on Monday. I knew the role is going to be a challenge for me, just starting to become clearing what those challenges are going to be!

On the positive side of things, the traffic wasn’t bad at the time I left home and I arrived in plenty of time for a normal start time. I stayed around a little longer to ensure I travelled at a representative time and the traffic wasn’t bad at all leaving. One thing I did notice, I was getting hungry by the end of the day so might need a banana before I setoff on the journey home.

I did bump into two old colleagues from a previous employer who were on site configuring a new instrument. Took the opportunity to have a quick catch up. Always good to catch up.

Next week will be the big step into the unknown. Seems there are a lot of things being lined up for me already. I hope to live up to the heady expectations that are already building up!!!!

Return to the NHS

I began my career in the NHS as a MLA. For the last 10+ years, I have supported the NHS from the private sector. Initially working for a diagnostics company configuring new equipment for use in labs and currently working for a LIMS company.

I have owned this domain for ages and have never really done much with it. I initially installed Moodle on here and started to put various questions on it to help new members of staff. I think recording the various things I will have to deal with in my new position back in the NHS might help focus my mind and might be of interest to others.

Pathology networks

Pathology has undergone many changes over the years. It seems there is always another major change waiting to be implemented. It seems the next major change is the forming of 29 pathology networks up and down the country (https://improvement.nhs.uk/resources/pathology-networks/).

There are already several networks up and down the country that have formed from previous re-organisations as people understand the logic for forming a network. Forming a network with neighbouring hospitals allows the laboratories to standardise on the same equipment and thereby getting more savings from diagnostics companies due to increase scale. These kind of savings would never be possible to hospitals working in isolation.

The level of integration of the hospitals sometimes depend on geographic reasons and the services provided by the various hospitals. If there are two close by hospitals, any patients living in-between them, might end up going to either hospital. When that patient is being seen at that hospital, having a full history of the patient would be important to the clinician. Having just access to the visits that patient made to just that hospital might lead to important information being missed.

When the network does form, one of the key issues is the need to harmonise processes. Sometimes there are reasons why some things can’t be harmonised at that point in time e.g. differences in instrumentation. For everything else, there is a compelling case for driving everything to be done the same way.

This could be something initial as simple as supporting the network. Having one way of doing a particular workflow means one orderable and therefore makes mapping a lot simpler. Having one way of doing things means work can be moved around as the same process will occur regardless of where it is analysed. Also means the clinical validation process can then potentially be site independent as the post analytical decision process will be using the same cut-offs for all sites for example.

In a future post, I will discuss the issues in a bit more depth.