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!


Reference ranges for transgender patients

I have just an article from the Annals of Clinical Biochemistry about establishing reference ranges for transgender patients. It does seem that finally evidence is being collected in order to address the problem rather than just assuming that existing male and female ranges would be appropriate.

The data they collect is on a limited number of patients but as these patients have recruited from a transgender clinic, I’m not sure what else they could do to reliably recruit more patients. Only patients on hormone treatment are included in their analysis. I don’t remember if these patients were screened to ensure that only patients who have been on treatment for a prolonged period of time. I would like to think the data was collected on a stable population.

The paper mentions the various treatments that patients might be under e.g. different medications and doses. I wouldn’t like to assume that each medication would have the exact same effect, especially when the discussion section discuss the biochemical impacts of the different medications. If the dataset was sufficiently big enough to break down into different treatment groups, I’m not sure how that information would ever be captured and passed onto the lab.

I suppose I approach the problem from a lab perspective. At the moment, identifying transgender patients isn’t a simple process of ticking a box. HL7 is the standard way of moving healthcare information between a PAS system and the LIMS. At the moment, there is no concept of sex and gender within the HL7 specification. Should the sex at birth be recorded or the transitioned sex? A transgender patient is allowed to have a completely new NHS number and doesn’t have to disclose they have transitioned. So whilst studies are being down to identify appropriate ranges, the challenge then becomes in the implementation of that range.

This particular study was performed on a particular analyser platform. So whilst is possible that it highlights analyses where they might be differences, it wouldn’t be appropriate to just apply these ranges on results being generated on different platforms. Just look at any EQA data and you will notice the difference between various analysers.

So whilst this study does indeed start to address the lack of data, I feel I must make a similar conclusion to the authors that more studies are required to complete. Hopefully some of these studies would replicate earlier findings as it seems that some studies are finding the same thing.

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!!!!