Everyone is excited at the potential of using stem cells for research and therapy. Below is my presentation of the logistics necessary to get those stem collected in an orderly manner, especially in this time of the COVID-19 pandemic. It will also consider blood bank software logistics.
While I was Division Head, Laboratory Information Systems LIS elsewhere, we serviced a client hospital not using Medinfo for its patient hospital blood/transfusion services. It used the blood bank module of a hospital information system’s laboratory system.
In their service level agreement, they wanted a complete list of all the ISBT product E codes that we used. I found this strange and told them their system must have access to the ISBT database so they should have no problem in reading our codes directly.
The same hospital system was in use for our hospital system (excluding our blood banks, which used Medinfo and had no such problems.) I discovered that this hospital system could NOT read any ISBT codes natively for the end-users, e.g. departments outside the blood bank. Without informing us, the nursing staff were manually entering “something” into their system. That something could be anything: the system would accept any series of alphanumeric characters. They could select any type for each component (e.g. RBC for a platelet, plasma for an RBC, etc.). They had no reliable record of transfusion!
In fact, in that hospital information system, ISBT codes could only be read in their blood bank module, which we did not use at all. That vendor subsequently purchased another software to read the labels, but I discovered that the new “solution” software still could not directly access the ISBT database!! They still had no functionality to read ISBT labels on the wards!! You still had to hard-code it into their system.
Thus, we were forced to give the new client a list of our current E codes. I warned them that we did change these codes (e.g. when we adopted platelet additive solution). It was their responsibility to change the “hard code” into their blood bank module of that vendor.
As regards our hospital information system, we had to “hard code” the ISBT codes into the order requests so they could use that to document the transfusion. We also had to provide the descriptor for each and every code.
To this day, I am astounded that a modern hospital system still cannot read ISBT codes natively. Surely, they could license a copy of the ISBT database—or at least let the end-user client license it and upload it into their system.
I am skeptical of a “one-size-fits-all” comprehensive, Swiss Army Knife like software that has some limited functionalities but lacks the details needed for actually using blood components. I wonder if the compromises made to build this system make it similarly mediocre for other functionalities outside the blood bank sphere.
I consider myself very fortunate to have elected NOT to use this patient transfusion service module and go with a full-feature blood bank system.
Be careful about trusting the vendor’s promises. Check to see how they handle the ISBT labels.
The donor module of Medinfo includes recruitment, logistics, registration, donor screening, collection, marker testing, donor immunohematology, and component production. There is also a module for inter-depot transfer of blood units from the donor center to the hospital end-users.
The patient module includes patient testing (ABO/D typing, antibody screen, antibody identification), direct antiglobulin test, elution, component modification (washing, aliquoting, pooling), allocation/reservation of blood components for a patient, release of blood components, and their return.
Some sites elect to use their laboratory system’s blood bank module in conjunction with Medinfo donor module. In this case, they receive each and every unit into their laboratory blood bank module and do all patient activities in it. There is no link between patient and donor module. They will have to monitor and transfer inventories in their laboratory system.
At a site using integrating both the donor and patient modules of Medinfo, they will be able to track units across the system to any hospital blood bank. They will have access to the rules-based system to generate algorithms for use of blood components based on user-defined criteria. They can instantly perform look back of donor units associated with adverse effects, and be able to rapidly quarantine components subject to recall from the manufacturer or product incidents. Here are some examples of this functionality:
Example 1: The hematologists want all their patients to receive leukodepleted irradiated RBCs and platelets at a site not using pathogen-inactivation. Medinfo can prepare an algorithm by site, clinical diagnosis, or other criteria which will block release of those components that are not irradiated and leukodepleted. Blood Bank staff will not be able to release anything else. The donor module can prepare customized component or modification can take place in the hospital blood bank.
Example 2: During production, it is discovered that units prepared in one of the centrifuges (or automated component equipment Reveos) became contaminated with a foreign substance. In Medinfo. In Medinfo, all units prepared during the affected time interval can be immediately quarantined across the system including all hospital blood banks and thus prevent their being transfused.
Example 3: A patient has developed hepatitis C after transfusion. Using the transfusion history, one can retrieve data on all transfused units. The entire production process can be reviewed for each unit, including donor marker testing. If a unit is implicated, then all patients receiving other components from that donor can be immediately identified for follow-up.
If a disaster occurs, one can quickly check Medinfo’s cumulative stock display of all components at all sites—donor unit and all hospital blood banks. One can initiate transfer of units from unaffected sites to the disaster location. This can be updated as frequently as needed—within seconds!
There are probably ways to accomplish this by using the laboratory information system, but it will be slower and require separate communication to the Medinfo donor site. There will be no seamless integration and delay.
In summary, there are many advantages to using both donor and patient Medinfo modules. Even at sites where there was separate transfusion service functionality, I elected to use both modules together for seamless integration. It would be very time-consuming to manually check between the laboratory and Medinfo donor module. Medinfo’s patient module offers has strong safeguards to prevent release of untested or partially tested units (example: release of Kell-untested RBCs to a patient with anti-Kell) and a very robust electronic (computer) crossmatch.
While I was Division Head, Laboratory Information Systems LIS at my previous position, I was asked to use the hospital information system HIS to collect information during the procedure analogous to what was done for dialysis.
I thought of the logistics: one apheresis nurse, one Spectra Optia machine, and one metal cage containing a theft-proof computer on a stand. There was no room for the patient’s bed with all this equipment—the nurse could not move around comfortably.
Second, what I was presented was a hodge-podge of screens on the HIS that the apheresis had to maneuver back and forth between for each measurement—none of the data entry was on one screen! Honestly, there wasn’t enough time to enter all the data between the screens AND look at the patient.
I remind everyone that therapeutic apheresis is not a benign procedure. The patient may be critically ill. The apheresis nurse must concentrate on the patient. The HIS team was more interested in the data collection, even at the expense of the patient.
LIS had not been engaged in building the pathway and the HIS wanted us to follow the dialysis template. They did not know that there are many types of therapeutic procedures, often with different data collection. There is no one-size-fits-all screen!
I refused. The nurse must concentrate on the patient, not the LCD screen. To use the HIS would have been harmful to patient care in this situation. We retained the manual, cellulose interface. We scanned the manual data form and uploaded it into HIS.
Lessons to be learned:
- HIS must engage LIS, and in particular Transfusion Medicine, when building anything for the blood bank. This is in accordance with international accreditation standards.
- We must never lose sight that we are treating the patient, not the computer screen. Especially in therapeutic apheresis, we must use the apheresis specialist nurse to monitor the clinical status of the patient, first and foremost!
- If the proposed computer process is worse than the manual process, keep the latter.
You have already sent out an RFP (request for proposal) for a laboratory software and have received several responses. Regardless what the vendor provides, you need to contact a comparable site to your own and assess how well the solution is working.
The key word is COMPARABLE. The site should have similar functionality (breadth of test and process menus), test and activity volume. If you have multiple sites, does the candidate site have the same?
Technically, to assess response time, you should select a site that uses the same platform (e.g. Microsoft SQL Server, Oracle, etc.) and operating system (Windows, Linux, UNIX, etc.)
At one institution I worked at, they went on a site visit, but it used the software on a different platform (UNIX). They wanted to use it on Microsoft SQL Server. They were happy with the observed response times during the visit, but when they installed it on their chosen platform, it was very slow. You cannot compare an apple to an orange (or in this case to a prune).
I would ask to speak to key players at the site visit without the vendor being present. Hopefully, they will be honest with you about their experiences. I was once very surprised that I was asked to allow for a site visit for a non-blood bank software for which I had serious concerns. I would not serve as a site visit.
In my career, I have dealt with many different laboratory software vendors. Regretfully, not all encounters have been straight-forward.
Things that bother me:
- Current state: whoever prepared it for the client, didn’t care or understand the local processes and came up with a generic: order it, collect it, receive it, do it, report it for each and every test
- No training for super users: more like lambs being led to the slaughter
- No discussion of options: pushing client to take the default settings
- Corrections to build: only giving one shot to do it right, further corrections cost $$
- Scenarios: vendor shows specially crafted scenarios that “work” but when you ask the vendor to do a random, non-scripted scenario, it crashes
- Scalability: limited scalability on client’s chosen platform
- Reference site does not match the test volume or activities of the client, uses different platform, and thus cannot be compared
I will give further examples in upcoming posts.
This is an updated job description of what I used at NGHA Riyadh for a Systems Administrator for laboratory software. Such a person will have software privileges as agreed by the hospital information systems department. In our system there, there was a separate laboratory information systems section LIS:
To analyze laboratory databases and prepare reports to optimize laboratory utilization and management
- Maintains and secures the laboratory information server (to be distinguished from the LIS hardware) and its associated databases
- Uses downloaded database files from laboratory computer system to prepare reports as deemed necessary by and as prioritized by the Pathology Chairman, Laboratory Operations Administrator, and/or Portfolio Head, LIS, which may include but is not limited to:
- Cost containment (implementation of CEO directives)
- Internal laboratory and external hospital committees (as requested by them)
- OVA statistical analysis
- Specimen referrals to outside laboratories
- Specimen referrals from other hospitals or hospital systems
- ER Stat Laboratory utilization reports
- Laboratory Utilization Committee, including STAT turn-around-time and critical values
- Quality Improvement-Accreditation Portfolio
- Test utilization metrics
- Any other reports requested/approved by the Portfolio, LIS, Laboratory Operations Administrator, and/or Chairman
- Assists in the management of the document control program for the laboratory
- Assists in the management of the intellectual property control program for the laboratory
- Performs any other assignments as directed by the Pathology Chairman, Laboratory Operation Administrator, and/or Portfolio Head, LIS
Essential & Preferred Education & Experience:
- B.S. degree or higher in computer science including coursework in networking, database structure, and management
- Experience (at least two years) in operating enterprise-level (e.g. Oracle, IBM DB2), business-level (Postgresql, MySQL, Microsoft SQL Server) databases as well as Microsoft Access® desirable
- Fluency in English (high-level) essential, fluency in Arabic desirable
- Experience (at least one year) in working with databases in a variety of operating systems (Win32/64, Linux, UNIX) desirable
- Experience (at least one year) in working in a hospital laboratory environment desirable, not necessarily as a laboratory technologistLa
- Must be self-reliant and disciplined to operate independently and have excellent organizational and interpersonal skills to relate to a wide variety of laboratory and hospital personnel
Degree of Responsibility:
This is a middle-level management position within the Department of Pathology and Laboratory Medicine. The analyst must be self-reliant and disciplined to operate independently, have excellent organizational and interpersonal skills to relate to a wide variety of laboratory and hospital personnel.