DM assistant on the local model

Ask the study in words and get a table counted by the portal; let the installation's own language model review a patient for inconsistencies; you decide on every proposal.

The DM assistant helps the data manager with two everyday jobs: getting a quick count across the study (“how many open queries per site?”) and reading one patient's data for things that do not fit together. It works on the language model installed on this server only: no data leaves the server, and no external AI service is ever called. The model never changes data and never decides anything: it proposes, a person decides, and the audit trail keeps the decision.

The DM assistant page of the demo study: a ready question and its answer.

Who can use it

• The page is in the study menu as DM assistant. The data manager, the monitor, the medical monitor and the project administrator see it.
• Everyone sees only their own sites, and a blinded member never sees the forms for the unblinded team, neither in the answers nor in the reviews.
• Opening a query from a proposal needs the right to raise queries (data manager, monitor, project administrator).
• The patient review needs the local model of the installation (see “If the model is off” below); the ready questions work without it.

Ask the study

1. Type a question in your own words, for example “open queries older than 14 days by site”, and press Ask. Or press one of the ready questions under the field.
2. Your question is matched to one of the ready questions. With the model switched on, the model makes the match (up to a minute on the server’s processor); it gets only your question, never patient data. Without the model the match is made by keywords. The answer says which of the two understood it.
3. The portal itself counts the answer from the data of your sites: a total, a table by site (or by form, by patient) and the list of rows. Each patient code opens the patient, each form opens the form.
4. Above the answer the parameters are shown (days, grouping, kind of visit): change them and press Count again. The grey note says exactly how the answer was counted and when.

The ready questions: open queries, forms not entered after visits, visits out of window or missed, patients waiting for SDV, enrolment by site against the plan, pages changed recently, patients with adverse events, data entry delay by site, no-data marks without a reason and patients at risk of loss to follow-up. A question that does not fit any of them is answered with this list, not with a guess. At most 100 rows are shown.

Review a patient

1. In Review a patient type the patient code and press Start the review, or press Next patient with data changed since the last review.
2. The review runs in the background: on an ordinary server (two processor cores, no graphics card) it takes a few minutes per patient, and reviews run one at a time. You can leave the page; the review appears in the list when it is done.
3. The model reads the patient's data form by form and visit by visit and proposes possible inconsistencies: a diagnosis against a history question, a jump between two visits, an adverse event with no treatment, dates in the wrong order. Each proposal quotes the stored values it is about and comes with a draft query.
4. The portal checks every quote against the database. A proposal whose value is not the stored one, or whose place does not exist, is dropped and listed under Proposals refused by the portal.

A review: each proposal quotes the stored values; one became a query, one was dismissed.

A long record does not fit the model at once. The logs, the first visit and the latest visits are read first; the page then says how many values of the visits in between were left out. The review is a help in reading, not a complete check: the edit checks and your own review stay.

Decide on a proposal

1. Open the review. For each proposal check the quoted values in the form (the links lead there).
2. If it needs an answer from the site, choose the place of the query, edit the draft text and press Open the query. The query is an ordinary query of the study, from you.
3. If not, press Dismiss and give the reason: the data is consistent, explained in the source or by the site, already queried, the model misread the data, or another reason with a comment.

When a query on the same value was already open when the model read the data, the proposal says so, so that the site does not get the same question twice. If a quoted value changed after the review, the value stored now is shown under it in orange.

What is recorded

• The model is a tool of this installation. Every call is written to the log of model calls: the task, the model and the SHA-256 fingerprint of its file, the fingerprints of the instructions and of the text sent, the answer, the time taken. The patient text itself is not kept.
• The page of a review shows who asked, the model with its call number and the fingerprint of the data read.
• Each proposal is a draft. A person decides on each one, and every decision is in the audit trail: a query opened from a proposal says it was suggested by the local model and accepted by a member of the study team with their role; a dismissal keeps its reason.
• The model works at temperature 0: on the same server, the same data and the same model file give the same answer.
• Changing the model or its file is a change to the validated system: the administrator records it (see the installation notes on the local AI).

If the model is off

The page says which of these applies and what the administrator does:

• The server has no local model: the ready questions still work (matched by keywords); the patient review is not available until the administrator installs one.
• The model's address is not on this server or its private network: the portal refuses it, because patient data never goes to an outside service.
• The model works but this tool is not switched on: the administrator adds edc.assistant_ask and edc.assistant_review to the AI tasks of the installation.

In none of these cases is anything sent to a model.

In the demo study

A demo study has no model. The demo writes one review itself, as the local model would, from the real values of one demo patient: a few proposals with their quotes, one already turned into a query and one dismissed, and one made-up proposal that the portal refused. Open it from the list of reviews to see how proposals and decisions look. The ready questions work in the demo as in a real study.