Correctness in clinical decision support systems

Features of Logiak for correctness in clinical decision support systems

BMJ Global Health has published “Electronic clinical decision support algorithms incorporating point-of-care diagnostic tests in low-resource settings: a target product profile” (volume 5, issue 2)

This was worked based on a workshop I attended in Geneva, organised by FIND & WHO.

The report is clear that any clinical decision-support “algorithm should be validated both analytically and semantically to ensure that the algorithm output is accurate and reproducible, does not deviate from expert content/evidence, and that there are no interactions or conflicts in the logic” and that “an important characteristic in this section is system validation. Today, there is no standard process to validate and assess the performance accuracy of CDSAs.”

We are very much in agreement about the importance of validation and have been working on this issue for some years. As a result, Logiak has many characteristics which contribute directly to the achievement of correctness in a system.

In this piece, we explain some of those features.

1. Doctors write (and maintain) the Logic!

Probably by far the most important aspect of Logiak for validation is the fact that it has been demonstrated more than once that medical experts are able to configure the logic of the algorithms themselves — that is, the logic that actually runs on devices is guaranteed to be what the Doctor ordered!

Photo by National Cancer Institute on Unsplash

Is this too good to be true? Well, it is most certainly true, but not easy. Typically, clinical algorithms are fairly complex logically, and to create and maintain one is not a doddle. It is not every doctor’s cup of tea, it is hard work. But it is not really programming, it is computer-aided specification, and it is a key advantage of using Logiak.

The logic remains transparent to the Doctor. It is possible to print it out and discuss it with colleagues.They can judge whether it is the logic they intend. It is amenable to “crowdsourced validation” by inspection.

2. All references are maintained — no hanging chads

As the Doctor develops the logic of the system, she makes logical connections between things. For example, the logic might say that whether a child’s breathing is regarded as rapid or not depends on age, hence a variable representing the child’s age will be connected with conditions defining respiration. But Logiak remembers and maintains all of those connections explicitly and it means two main things, both of which are important from a validation point of view:

A Doctor cannot inadvertently delete anything which is referenced

Each reference chain can be followed when checking the logic

Logiak goes further, and gives support to what logicians call “forward-chaining” — it lets you know what are the possible consequences of certain things being true. So let us suppose a child of 8 months was found to have a high respiratory rate, what follows in the logic we have defined?

Forward chaining to find out what follows if a given condition is true

3. The system looks over your shoulder for mistakes

Logiak stands over your shoulder and waves a yellow flag when you do something which is likely a logical mistake. For example, if you add a question which is to be presented to the user and you don’t actually do anything with the response (i.e. it is not saved to the database, nor is it used in any logical calculation), then Logiak will stick a yellow flag on it.

You can suppress the yellow flag, which is saying “no, I really do intend that”, but usually when Logiak yellow flags you, it is being a very useful referee and the important point is that what it flags, you very likely did not intend.

Again, this is all about correctness of the system, avoiding errors. The absence of yellow flags is one of many things we look for in validating.

The system cautions you with a yellow flag if you do something which is likely a mistake

4. There is a “trace” debugger.

By far the most traditional validation-relevant tool from a programming point of view is that Logiak provides a step-by-step debugger within which it is possible to interact with the logic as a user and at the same time see exactly where one is in the Process at each step, what the values of all the variables are etc. go backwards and forwards etc.

Debugger — interactions happen on the left and examinations of values on the right

5. Development Mode — on-device debugging and hot deploy

If you don’t want to debug on the server, you can debug on the device. Logiak makes it possible to use an App in a special “Development Mode”. In Development Mode, you get a lot of the debugging features described above — your position in a Process is made clear, and you can call up a debug window at any time to show values of variables and which conditions are true and false.

As well as for debugging, Development Mode is used as a “hot deploy” mode, in which changes made to the app or the logic of a Process can be called onto the device with a click of a refresh button.

6. Simulations (singular)

If you have a complicated clinical algorithm, testing on a device can be very time consuming. Quite frankly, you can forget expecting your team to “test all paths” through the logic, there are too many. But when we get to “testing” we are explicitly in “checking correctness” territory, so this is very unfortunate.

What to do? Well, Logiak offers you the ability to simulate a consultation, which means have the system pretend to be a patient and generate responses. The system can do that randomly, which means sometimes the responses make no sense, but you can set bounds and constraints on questions so that even the random responses are sensible.

A simulation is then a rapidly produced script of a possible consultation. A consultation mandated by the logic you have defined. It is similar to testing on a device, though much much faster. Generating simulations and examining the scripts, the trained eye can very quickly spot any errors in the logic.

Simulations result in scripts of possible consultations. Errors can be identified quickly.

7. Simulations (en masse) and exploring the search space

Just as the system can produce one different simulated consultation after another for you, after you click the Simulate button, so the system has no problem doing hundreds or thousands for you at a single button click.

Because the responses are generated randomly, simulations will essentially search the space of possibilities for you. You can then examine and filter the simulations which have been produced and find, for example, whether any of your algorithm was simply not visited by the simulations. If not, why not?

8. Test cases

Finally, and perhaps the most important feature since number 1, it is possible to define Test Cases. A Test Case is a set of values for variables (e.g. user inputs) plus a specification of conditions which should be true and false at the end of the consultation.

Values being specified for a Test Case

A Test Case can be “run” like a simulation, but instead of values being randomly generated, they are taken from the Test Case. The system can automatically check whether the conditions which should be true, are true, and the conditions which should be false, are false.

Test Cases permit the most meaningful validation check. Test Cases can also be partially specified, so the consultation which result when the Test Case is “run” are part simulation. It means you can set some assumptions and see whether, given the logic you have defined, the assumptions always hold. As described above in 7, you can also let loose some Cloud Computing on this validation problem.