Honeydew Helps is a series where we answer some of the real questions our clients have reached out to us for. They may dive deep into technical aspects of each topic, but we hope to share the insights with anyone else that may have a similar question or would like to learn more.
If you have questions on this article or would like to submit your own question, please reach out to [email protected].
Question: “Should I build out all of my HIL rules in Beaker or keep them on the instruments/middleware?”
What are HIL Indicies?
Hemolysis, Icterus, and Lipemia – characteristics of a blood sample, determined at the time of testing, which can help identify potential processing issues with the sample that can in turn lead to skewed or invalid results.
For example, highly hemolyzed specimens – where red blood cells have been damaged, through improper collection, specimen handling, or a variety of other factors – will skew results for certain ion concentrations, namely potassium (K+). For this reason, K+ results are usually not reported to the physician or patient for hemolyzed specimens, and the patient is typically redrawn instead to test a fresh sample. The process of testing, analyzing the degree of hemolysis, sending for a redrawn sample, and repeating testing takes a considerable amount of time and can lead to diminished patient outcomes.
Tracking HIL indices allows the lab to monitor samples for processing errors and potentially invalid test results. To prevent such results from posting to the patient’s chart, organizations typically incorporate HIL checks into their auto-verification strategy.
As lab IT stewards, it’s our responsibility to build Beaker to minimize processing time, which will directly translate to improved specimen processing and, in turn, patient care.
What is the typical test volume to consider?
HIL indices primarily impact chemistry tests, which means the scope is potentially extremely large. Some organizations do choose to build out indices on every chemistry test, with component-level mnemonics that trigger based on specific ranges for each test in question.
Most organizations, however, elect to start with the most significantly impacted tests, such as Potassium and Iron, since these are high-volume tests that are significantly impacted by hemolysis in particular. Once they are live and stable, they typically continue to build out additional checks and mnemonics based on the needs of the lab.
Should we build it (all)?
Every organization needs to make this decision based on their preferred and established lab workflows. We have seen Beaker customers be completely successful with both scenarios.
Many organizations prefer to move everything to Epic, to minimize or eliminate the need for techs to work in multiple systems. This presents a large upfront burden to the build team, and should either be established as early as possible in the implementation, or adopted gradually during optimization.
Building and testing timelines will be impacted and correlate directly with the scope of HIL build. Eg: for limited scope indices on K+ and Iron, the build and testing timelines will be slightly affected; each additional test and validation point needs to be taken into account.
Should we skip it?
We have seen many organizations prefer to have their techs work in two systems (at least in some degree).
- Workflow: Results are held in instrument middleware if Hemolysis, Icterus, or Lipemia values are outside the specified range. Lab staff monitor Beaker for specimens that don’t show results after running, and monitor the middleware to re-process or release results for held specimens.
- Pros:
- No build in Beaker required to handle these specimens.
- Lab maintains ownership of HIL logic within Middleware.
- Auto-verification can be configured to allow all results released from Middleware to pass straight through Beaker, or to have to satisfy additional A/V criteria.
- Reduces overall Beaker build/testing time significantly.
- Cons:
- Lab users have to work in and actively monitor specimens in two systems (Epic and Middleware).
- Specimens that have been held in the Middleware will display no results or errors on the Beaker outstanding list, so lab staff may think they are still waiting to be processed, rather than having results held for review.
- No automatic comments will be applied in Beaker unless additional error code mapping is in place.
- May have to work with middleware vendor directly to resolve issues or perform maintenance/updates.
What should my organization do?
The key factor to consider is timing. If this conversation begins close to go-live, it may be best to keep everything within the middleware system, allowing the lab to maintain consistency without jeopardizing timelines or testing efforts, though it may require techs to work in two systems.
However, if testing timelines allow, we recommend building, testing, and validating a select set of high-impact, high-priority tests with HIL indices, gradually expanding to additional tests over time. This high-impact-first approach enables targeted testing and a streamlined workflow, though there may be some gaps that need to be manually managed.
What are others doing?
Live site #1 (TX)
- Only set up mnemonics on specific LRRs (Potassium, Iron)
- Only trigger for Hemolysis
- Specimens are held in Remisol for Auto Verification, so once they file into Beaker they pass through; samples with high HIL indices are held using Remisol rules
- Pros:
- Able to configure component-specific mnemonics
- Minimal build/testing required for Beaker/DI
- Lab maintains control over Remisol rules
- Cons:
- No comments or mnemonics for icterus or lipemia
- Techs work in multiple systems
Live site #2 (AZ)
- Error Flags for HIL Values (using category list MAC-656, which includes error codes for Hemolysis, Icterus, and Lipempia out-of-the-box)
- Error-code mapping on interface MAC record, and in DI
- Instrument error is used to prevent auto-verification; error does not display to provider or patient.
- Pros:
- Minimal build/maintenance required
- Techs work in Beaker instead of middleware to monitor for specimens that require intervention
- Cons:
- HIL error flags apply to the whole specimen regardless of value
Live site #3 (GA)
- Set up Hemolysis mnemonics for ALL chemistry LRRs
- Mnemonics for Icterus and Lipemia built for most LRRs
- Pros:
- Techs monitor Beaker for missing samples
- Mnemonics fire on all tests with comments configured to apply to each component only when the
- HIL value(s) are within ranges specific to that LRR
- Cons:
- Massive number of records to build and maintain
- Mnemonics are LRR and OVT specific, so very little is re-usable, meaning tremendous build is required.
- HIL ranges are different depending on the instrument and middleware, so different LRRs may need to be used at different locations to trigger messages appropriately. Some send numeric ranges, some send category values, and some send error flags that need to be translated in DI. (This also requires an entirely new set of OVDs.)
- Each mnemonic also requires its own reflex action build on the OVT, meaning that a CMP may have 9 mnemonics and 9 sets of reflex actions for each LRR (low, mid, high for hemolysis, icterus, and lipemia), totaling 100+ lines of result checking that cannot be easily copied or manipulated via import/export.
- Exhaustive testing required. Each mnemonic needs to be individually tested.
If you have questions related to HIL, feedback, or any other project please reach out and we would be happy to discuss them!