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.

Malaria

It would appear that the best guidelines for detection of Malaria to follow in the UK would be the one from the British Society for Haematology. The direct link for this guideline is here. The full section on Malaria can be found here.

Direct link for Guideline

http://onlinelibrary.wiley.com/enhanced/doi/10.1111/bjh.12572

Direct link for Malaria section on BSH website

https://b-s-h.org.uk/guidelines/guidelines/laboratory-diagnosis-of-malaria/