Medicine of the future

Ето един учебен случай: екип в българска болница обсъжда програма, която подрежда медицински изображения според нуждата от по-бърз преглед. Тя не поставя диагноза и не решава самостоятелно кой да получи лечение. Нейната обещана роля е по-ограничена: да насочва вниманието на специалиста към случаи, които вероятно изискват по-ранна оценка. Всички числа и събития в този текст са част от измислен пример за дискусия, а не медицинска препоръка. На първата среща разработчикът показва висока точност при предварителна проверка с подбрани изображения. Лекарката обаче пита от коя група са данните и как са определени верните отговори. Ако проверката повтаря прекалено близо условията на обучението, моделът може да изглежда по-надежден, отколкото ще бъде на друго място. Затова екипът иска външна проверка с други данни, отделни от използваните при разработването. Добрата презентация не замества това изискване. Следва въпросът какво точно означава „точност“. Чувствителността описва какъв дял от хората с определеното състояние се открива от теста. Специфичността се отнася до хората без това състояние: какъв дял от тях получава отрицателен резултат. Дори добрите стойности не означават, че всеки положителен резултат е вярно потвърждение. Значение има и колко често състоянието се среща в проверяваната група. Затова число без описание на групата може лесно да заблуди. На срещата присъства и представителка на пациентите. Тя не спори за формулите, а задава друг въпрос: какво става с човека, когато програмата сгреши? Фалшиво положителният резултат може да доведе до допълнителни прегледи и тревога. Фалшиво отрицателният може да остави важен случай без своевременно внимание. Не е достатъчно да преброим грешките; трябва да проследим как влияят на работата и на хората. Това вече е въпрос за клинична полза, не само за красива таблица. Пилотният проект затова предвижда сравнение между обичайната работа и работа с помощ от програмата. Екипът ще наблюдава времето до преглед, пропуснатите случаи и натоварването на служителите. Лекарят ще може да променя подредбата, като записва причината. Пациентът ще получава разбираемо обяснение как се използват данните му. За обсъждането на резултатите няма да се разгласяват имена. Конкретните правила и процедури подлежат на промяна и се проверяват със съответната институция. Най-вероятно технологията ще бъде полезна само ако е вградена в добре организирана грижа. Това е хипотеза, която проектът трябва да провери, а не извод, който вече е постигнал. Ако спести време, но увеличи броя на пропуснатите случаи, оценката няма да бъде положителна. Бъдещето на медицината в този разговор не е кабинет без лекар, а по-добра възможност човекът да получи внимание навреме. Именно това е обещанието, което си струва да се измери.

Imagine a learning scenario: a team in a Bulgarian hospital is discussing software that ranks medical images according to the need for faster review. It does not make diagnoses or independently decide who receives treatment. Its promised role is narrower: to direct a specialist's attention towards cases that probably require earlier assessment. All figures and events in this text form part of a fictional discussion example, not a medical recommendation. At the first meeting, the developer shows high accuracy in a preliminary check using selected images. The doctor asks which group the data comes from and how the correct answers were established. If the check closely repeats training conditions, the model may look more reliable than it will be elsewhere. The team therefore requests external validation using other data, separate from that used in development. A good presentation does not replace this requirement. The next question is what "⁠accuracy⁠" actually means. Sensitivity describes the proportion of people with the specified condition whom a test detects. Specificity concerns people without that condition: what proportion receive a negative result. Even good values do not mean that every positive result is a correct confirmation. How common the condition is in the group being tested also matters. A figure without a description of the group can therefore easily mislead. A patient representative also attends the meeting. She does not argue about formulas but asks a different question: what happens to a person when the software makes a mistake? A false positive result can lead to additional examinations and anxiety. A false negative can leave an important case without timely attention. Counting errors is not enough; we need to trace their effects on work and on people. That is a question of clinical benefit, not merely an attractive table. The pilot project therefore plans a comparison between usual work and work assisted by the software. The team will monitor time to review, missed cases and staff workload. Doctors will be able to change the ranking and record their reasons. Patients will receive an understandable explanation of how their data is used. Names will not be disclosed in discussions of results. Specific rules and procedures can change and should be checked with the relevant institution. The technology will most likely be useful only if integrated into well-organised care. That is a hypothesis for the project to test, not a conclusion it has already reached. If it saves time but increases the number of missed cases, the assessment will not be positive. The future of medicine in this conversation is not a consulting room without a doctor but a better opportunity for people to receive attention in time. That is the promise worth measuring.

Здравейте, колеги! Елена съм. Изпращам ви кратко обобщение след днешната среща за измисления ни пилотен проект. Моля ви, не препращайте стария вариант на презентацията. В него пишеше, че програмата ще замести първия преглед. Това не е договорено. Тя ще предлага подредба на изображенията, а прегледът и оценката остават при специалиста. Звучи като малка поправка, но за пациента разликата е огромна. Променихме и начина на проверка. Няма да показваме на лекаря само случаите, които програмата е отбелязала като спешни. По време на учебния опит всички изображения ще минават през обичайния преглед. Иначе бихме пропуснали точно грешките, които искаме да открием. Ще сравняваме и работата със и без предложената подредба. Още не знаем дали тя ще спести време на екипа; това е въпрос, а не рекламен лозунг. Има и нещо практично. За демонстрацията предвидихме двайсет евро за печатни материали. Колегата предложи да ги спестим и да дадем само код за достъп през телефон. Оставяме обаче и кратко обяснение на хартия. Това е учебен разход, не такса за пациента. Не всеки има подходящ телефон, а някои хора предпочитат да прочетат спокойно и да зададат въпрос. Да не бъркаме спестяването на хартия с разбираемо информиране. Петър попита кой ще записва промените в подредбата. Това ще прави специалистът, който е променил предложението. Причината ще се запазва за обсъждане в екипа. В публичното обобщение ще има само общи резултати, без имена или други разпознаваеми подробности. За конкретните процедури ще проверим актуалните правила с институцията. На демонстрацията ще покажем две подредби на едни и същи изображения. В единия вариант се вижда обичайната работа, а в другия се добавя предложената подредба. Нека всеки колега обясни какво би направил и защо. Ще запишем и случаите, при които предложението помага, и тези, при които създава допълнителна работа. Не търсим съгласие на всяка цена. Може да се окаже, че една и съща функция е удобна за един екип и по-малко полезна за друг. По тази причина обратната връзка ще е част от оценката, а не само от края на презентацията. За това ни трябват конкретни примери. И последно: до петък ми изпратете по два въпроса, които ви се струват важни. Не търся само доводи в полза на програмата. Искам и силни възражения: при какъв резултат бихме казали, че не си струва да продължим? Едва ли един хубав процент ще ни отговори. Ще ни трябва разговор за реалната работа. Трябва да чуем и хората, които ще работят с нея всеки ден. Благодаря ви и до утре!

Hello, colleagues! Elena here. I am sending a short summary after today's meeting about our fictional pilot project. Please do not forward the old presentation. It said the software would replace the initial examination. That has not been agreed. It will propose a ranking of images, while examination and assessment remain with the specialist. It sounds like a small correction, but the difference is enormous for a patient. We have also changed the checking procedure. We will not show the doctor only the cases that the software has flagged as urgent. During the learning exercise, all images will undergo the usual review. Otherwise, we would miss precisely the errors we want to detect. We will also compare work with and without the proposed ranking. We do not yet know whether it will save the team time; that is a question, not an advertising slogan. There is a practical point too. We budgeted twenty euros for printed demonstration materials. A colleague suggested saving that money and providing only a code for access by phone. We are retaining a short explanation on paper as well, however. This is a learning expense, not a patient fee. Not everyone has a suitable phone, and some people prefer to read at their leisure and ask a question. Let us not confuse saving paper with providing understandable information. Petar asked who will record changes to the ranking. The specialist who changed the proposal will do so. The reason will be saved for team discussion. The public summary will contain aggregate results only, without names or other identifying details. We will check the current institutional rules for the specific procedures. At the demonstration we will show two rankings of the same images. One version shows usual work; the other adds the proposed ranking. Let each colleague explain what they would do and why. We will record both the cases where the proposal helps and those where it creates extra work. We are not seeking agreement at any cost. The same function may prove convenient for one team and less useful for another. For this reason, feedback will be part of the assessment, not just the end of the presentation. We need concrete examples for this. One last thing: send me two questions each by Friday that you consider important. I am not looking only for arguments in favour of the software. I also want strong objections: what outcome would make us say that continuing is not worthwhile? One attractive percentage is unlikely to answer that. We will need a conversation about the actual work. We also need to hear from the people who will work with it every day. Thank you, and see you tomorrow!