Writing
Interoperability, quality control, tenancy and field work. Each one is the article that would have saved a week of somebody's time, written by the person who lost that week.
This is the component library, not a picture of it. Change the theme in the header and it changes with the rest of the page.
Six rules, what each one is actually looking for, and the arithmetic that explains why running all of them on every analyte produces more false rejections than real ones. Includes the plot, and the reason 1-2s is a warning rather than a rejection.
About 11 minutes.
Ends at the point where quality control stops being arithmetic and becomes your laboratory's own policy decision.
The honest answer is v2, and the reason is not technical merit. It is that the systems you have to talk to this year speak v2, and the pipe that carries it is a separate problem from the message inside it.
About 9 minutes.
Names the boundary between a message format and the network process that carries it, which is where most integration estimates go wrong.
One is organised around a patient and the other around a sample, and the two produce different tables, different permissions and different reports. Buying the wrong one is usually discovered at the first accreditation assessment.
About 8 minutes.
Includes the cases where the distinction genuinely blurs, rather than pretending it is a clean line.
Why a list query has to prove its own tenant from its own filters instead of trusting the caller, why a policy that reads a field the query never filters on is a leak that returns a clean 200, and what a shared patient record does to the whole argument.
About 12 minutes.
The longest of the five, and the one with real query examples in it.
A home visit and a hospital basement are the two places a phlebotomist reliably loses signal, and they are also the two places where guessing which write wins is unacceptable. What queues, what cannot queue, and why a conflict has to reach a person.
About 10 minutes.
Scoped to specimen collection. Result entry, validation and release are online operations and the post says so rather than implying otherwise.
Each of these started as a problem that cost a week. The article is what would have been useful at the start of that week, which is a different document from the one a content calendar produces.
That has a consequence worth stating: there are five, they appear irregularly, and there will not be one this month unless something is worth writing down.
The domain, not the product. A post that explains a standard and closes by asserting that LabFlow implements it perfectly is an advertisement in a friendlier voice. Where one of these reaches what LabFlow does, it says what is built, what is not, and which side of the boundary the remaining work falls on. The features page is where the product claims live, with a limit stated beside each one.
Not categories invented to fill a filter. These are the four areas where a decision made in the first month is expensive to reverse in the second year.
Message formats, and the difference between speaking a standard and having a validated integration with a named product. The second is a claim; the first is a capability.
The rules, the plot, and the coupling that matters: control that is filed and never consulted is paperwork, and control that gates a release is a safety mechanism.
Tenancy, isolation, and the modelling choices that decide what a system can express. A range stored as two columns and an amendment stored as a status flip are the same mistake twice.
What happens away from the bench. Home visits, basements, couriers, and the awkward truth that the network is a place the specimen has already left.
They were not written in this order and they do not need to be read in it. This is the sequence that answers an evaluation question earliest.
Everyone who has evaluated laboratory software recognises it, which is why it is worth naming rather than quietly avoiding.
Nine hundred words explaining a standard, competently, and then a final paragraph: "This is why we built X to handle Y automatically." The explanation was the delivery mechanism for the claim.
The tell is that the article stops being specific exactly where the product enters it. Precise about the standard, vague about the implementation.
The explanation ends where the explaining ends. Where LabFlow is genuinely relevant it is named with its limit attached, in the same sentence, and the limit is the specific half.
Worked example: LabFlow exports and imports HL7 v2 and FHIR as files, with no live feed. That second clause is the one that decides an integration timeline.
The ledger
Some of these are missing on principle and some are missing because the thing they would describe does not exist. Both reasons are stated, because they are not the same reason.
There are no laboratories in production and no pilot tenants, so there is no customer to write one about. Earlier versions of this site claimed hundreds of users across pilot tenants. That was false and it has been removed.
The same reason, and an anonymous quote from an unnamed laboratory director would be indistinguishable from an invented one. It is safer for everybody that neither appears.
There is no mailing list and no sending infrastructure behind one. A capture field that collects addresses for a list that does not exist is a small lie that compounds.
No whitepaper, no buyer's guide, nothing that trades a document for contact details. If a document is worth reading it is on the page, and the contact form is there for people who actually want to talk.
The LabFlow team writes every post, and requests to place a post here are declined. A byline that means nothing is worse than no byline, and in a clinical domain it is worse still.
A comment thread on a clinical article needs moderating by somebody with the domain knowledge to spot advice that would be unsafe to follow. That is the same team, and it is busy writing the software. Corrections go to the inbox and get made in the post.
No weekly cadence and no content calendar. Five posts exist because five things were worth writing down, and the next one appears when the sixth is.
Quietly editing an article so that it was never wrong is the publishing equivalent of overwriting a released result, and this product exists partly because that is not acceptable in a laboratory.
So the correction is visible: the text changes, a dated note at the foot of the post says what changed and why, and the original claim is quoted rather than paraphrased. If you acted on the old version, you can see exactly what you acted on.
If something here is wrong, say so. A correction with a name against it is credited unless you ask otherwise.
The same affordance the product uses for an amended result, because it is the same problem: somebody read the first version and made a decision with it.
Four comparisons against products that are mature, installed and supported by real organisations. Every one of them names where the other product wins, because a comparison page that never recommends the competitor is an advertisement and a reader in this market sees it instantly.
The laboratory module of an electronic health record suite, bought by health systems that already run the suite.
The same structural position from a different vendor, with a long installed base and a different integration posture.
A dedicated clinical laboratory system rather than a module, and the closest of the four in what it is for.
A configurable LIMS platform whose centre of gravity is the sample rather than the patient, which is the distinction one of the posts above is about.
LabFlow has no laboratories in production. That sentence is on every one of those four pages, near the top, because a comparison written by a product with zero installations against products with thousands has to say so before anything else it says can be weighed.
This matters for how you read the clinical parts. The domain here was read rather than practised: standards documents, published rule sets, accreditation requirements and the source of the system being replaced. That is enough to build software carefully and it is not the same as having run a bench.
So every clinical claim in these posts is traceable to a published source, named in the post, and every operational claim about LabFlow is traceable to code. Where something is inference rather than either, it says so in the sentence.
None of this is clinical advice and none of it substitutes for your own laboratory's validated procedures. It is software writing about a clinical domain, which is a genuinely different thing and is worth keeping separate. More on who is behind it is on the about page.
A blog with five articles and no schedule is a poor marketing asset and an accurate signal. It says the team writes when something is worth writing, and that nothing here was produced to fill a slot.
If one of them is useful, that is the whole return expected. There is no sequence waiting behind it and no address being collected.
Found something wrong in one of these? Say so. It gets corrected in place with a dated note, and credited unless you ask otherwise.