When Text Direction Becomes a Clinical Risk

When people talk about Hebrew support in medical software, the conversation tends to end with a single question: is the interface translated. That is the least important question. A system can be translated well and still show a physician the wrong number, because the problem is not in translating the words but in the order in which the browser draws numbers inside a Hebrew sentence.

What actually happens

The bidirectional text algorithm, part of the Unicode standard, determines how sequences of characters that run in different directions are arranged on screen. Hebrew letters run right to left, digits always run left to right, and marks such as space, period, slash, hyphen, plus and minus are neutral — their direction is set by their surroundings. When two numbers are separated by a neutral mark inside a Hebrew paragraph, the mark takes on the paragraph’s direction, and the two numbers are swapped in display order.

The result is not theoretical. These are three examples found in a systematic review of Hebrew screens:

The real value	What is drawn on screen	What reaches the clinician
Blood pressure 140.4 / 87.6	87.6 / 140.4, with the unit ahead of the number	Systolic and diastolic are swapped: hypertension reads as hypotension
Lab reference range: greater than 60	The sign is drawn as less than	A value within range reads as abnormal, and an abnormal one reads as normal
A credit of 25 shekels with a minus sign	The sign jumps to the other side of the amount	A credit in the ledger reads as a charge

The comparison-sign case is especially dangerous

In the first two examples the mechanism differs. In the blood pressure, the characters did not change, they were merely reordered. In the reference range something else happens: the “greater than” and “less than” characters are defined in Unicode as characters that have a mirror image. When they sit at an odd embedding level — that is, inside a right-to-left context — the engine draws the mirrored character. Nothing moves. The character itself is replaced by its mirror image.

The same is true of any mark that has a mirror image: brackets of every kind, angle quotation marks, and sometimes the slash as well, depending on the font. If a clinic uses status codes that are punctuation marks — and that is more common than it seems in legacy systems — you can end up with one status displayed as an entirely different status.

Why screenshots do not catch this

This is the most important point for a clinic manager evaluating a system. The usual test for Hebrew support is to open screens and look. But a reversed range still looks like a range. Two numbers that were swapped still look like a normal blood pressure. The eye sees a correct structure, and so it moves on. Only a check that compares the actual character order against the original value reveals the gap.

The right test is therefore not visual but measured: take a value whose content you know, view it on screen in Hebrew, and compare character by character. You can do this manually during a demo. These are five values worth asking to see:

• A composite vital sign, such as blood pressure or a pain score on a scale.
• A lab result that has a reference range with a comparison sign.
• A credit line in the ledger — that is, a negative amount.
• An appointment time range, for example a start time through an end time.
• A dosage instruction that includes a number, a unit and a frequency on the same line.

Why this happens in almost every translated system

Because reverse-direction support is usually built after the fact, as a layer of patches on top of a design built for English. In a long-established, well-known open-source system in the field, measuring the stylesheet shows that only about 5% of the styling rules change between the normal mode and the right-to-left mode, and that the Hebrew interface is about 61% translated by string count. Numbers like these produce hybrid screens: partly aligned correctly, partly not, with buttons left in the wrong place.

The problem is deeper than percentages. A patch-based fix addresses the screen that was reported, not the mechanism. Every new screen built afterward is born with the same defect.

The practical rule: the unit of isolation is the datum as the clinician reads it, not the individual number. Blood pressure is one datum. A date range is one datum. An amount with a sign is one datum. Isolating each number on its own, while leaving the separator exposed, reproduces the defect precisely.

How to solve it properly

The solution is not a list of screen fixes but three infrastructure decisions:

1. A typed formatting layer. Every numeric datum passes through a function that knows its type — a vital sign, an amount, a range, an identifier, a date — and returns a single isolated sequence. The developer writing a screen does not decide this.
2. A single stylesheet with logical properties. Instead of physical left and right, use start and end. That way there are not two stylesheets to maintain, and a new screen is born correct in both directions.
3. Character-order tests in continuous integration. Not screenshots, but assertions that verify the displayed value matches, in its order, the value that was stored. A test like this fails the moment someone adds a screen that did not go through the formatting layer.

What to ask a vendor

When evaluating a system, three questions separate real support from declared support. First, is there a single stylesheet for both directions, or two. Second, is number formatting centralized in a single layer, or does each screen handle it on its own. Third, are there automated tests that check character order, and if so — can you see an example of a test that failed and was fixed.

A vendor with clear answers to these three questions has probably taken the matter seriously. A vendor who answers that the system is translated into Hebrew has answered a different question.

Back to the blog