In-house R&D
Independently developed LIMS and supporting products, with multiple software copyrights and continued investment in R&D.
Chengdu Yiheng Technology Co., Ltd. is a software company dedicated to laboratory informatics for the testing and inspection industry.
Independently developed LIMS and supporting products, with multiple software copyrights and continued investment in R&D.
Trusted by 300+ laboratories across disease control, food, environment and third-party testing sectors.
ISO 9001 quality management and China Multi-Level Protection Scheme (MLPS) Level 3 security hardening.
Implementation starts from the laboratory's own procedures: which standards it tests against, who reviews and approves results, and how samples and retention are handled. Those decisions are configured into the system, then validated in a pilot before the laboratory switches over. Training is delivered to the people who will actually enter data and sign reports.
Because our customers are audited under CNAS and CMA requirements, the system keeps the records those audits ask for: original observations, instrument output, review history, and the identity of every person who touched a result. Where a laboratory already runs an older system, historical results are migrated so that audit trails remain continuous across the changeover.
Laboratories rarely start from nothing. There are years of records in spreadsheets, in an older system, or in paper archives. We treat migration as a separate workstream with its own plan, because the main rollout should not be blocked by it.
The practical approach is to migrate structured data first: samples, test items, results and dates. Attachments and scanned records follow if the institution wants them searchable. Where historical data is incomplete, we migrate what exists and record the gap rather than inventing values, so that a later audit sees an honest picture.
The test we apply is simple: pick a sample from five years ago and ask whether you can follow it from acceptance to report in the new system. If you can, the migration did its job.
The weeks after go-live matter more than the weeks before it. During that period we keep a direct channel to the laboratory's key users rather than routing everything through a ticket queue, because early problems are usually process questions rather than software defects.
After stabilisation, support settles into a regular rhythm: periodic checks on task backlogs and overdue items, review of user and permission changes when staff move roles, and verification that backups can actually be restored. Upgrades are validated in a test environment first, specifically for interface and template compatibility, before touching production.
We also keep a written record of configuration decisions, so that when a new quality manager arrives, the reasoning behind the current setup is available rather than remembered by one person.
Laboratory informatics is broad: hospital laboratories, research laboratories, manufacturing quality control and third-party testing all use the same vocabulary but operate under very different constraints. We work with the testing and inspection side, where the governing question is evidential: can this result be defended to an assessor, a client or a regulator, and can the laboratory prove how it was produced?
That focus shapes the product. Retention and disposal rules matter as much as result entry. Instrument raw files matter as much as calculated values. Review history matters as much as the final report. Narrowing the scope this way means we spend less time explaining the domain and more time getting the details right, which is ultimately what a laboratory is buying.
Because the system runs on your hardware, your IT team remains in control of the server, backups and network policy. We provide a deployment document covering ports, service accounts and storage growth, and we agree in advance who is responsible for operating-system updates and for restoring a backup during a test.
This division is deliberate. Institutions that have been through a security review prefer to keep infrastructure ownership in-house, and it also means the laboratory is not dependent on a vendor remaining in business to read its own records.
A typical project has three roles on our side: an implementation consultant who owns the analysis and configuration, a technical engineer who handles servers, interfaces and instrument connections, and a project lead who keeps scope and schedule honest. On the laboratory side, the most important counterpart is not IT but the quality manager, because that is who knows how the written procedure differs from daily practice.
We ask for one named contact per department during rollout. Projects where every question routes through a single overworked coordinator tend to stall; projects where each section has someone empowered to decide tend to finish on time. This sounds administrative, but it is usually the difference between a four-week deployment and a four-month one.
After go-live we stay reachable through the same people who ran the implementation, rather than handing the account to a separate support desk. That continuity matters most in the first month, when the questions are about process rather than software.