|
ЗАЧЕМ И КАК |
|
Выпуск 181 5 августа 2008 г. Медицинская информация глазами разработчика. Врач и разработчик автоматизированной системы по-разному относятся к медицинской информации. Первый стремится отразить изменчивую целостную картину единичного объекта, индивидуальность пациента и всего, что с ним происходит. Второму, наоборот, нужно выявить в медицинской информации общую структуру, разъять её на стереотипные детали, неизменные элементы, из которых потом медик сможет конструировать любые целостные объекты и любые индивидуальные цепочки событий. Из-за различия в установках врач и разработчик не всегда хорошо понимают друг друга, а это не лучшим образом сказывается на программном продукте. Мне показалось полезным отвести этой проблеме несколько выпусков. Может быть, медик найдёт в них объяснение того, что же требуется программисту, что надо до него донести, а заодно чуть шире взглянет на особенности своей работы с информацией. Что касается разработчика, то ему я хотел бы на конкретных примерах продемонстрировать лишь структуру медицинских сведений и многоплановость их использования. Свои программистские приёмы, на которые волей-неволей приходится ссылаться, я ни в коей мере не противопоставляю другим возможным приёмам, в том числе и принципиально отличным от моих. ГДЕ ЛЕЖИТ ЭЛЕКТРОННАЯ ИСТОРИЯ БОЛЕЗНИ? Электронная история болезни - не электронное подобие бланка, заполняемого по мере необходимости. В виде обособленной формы, в виде того или иного файла или строки файла со всем множеством специализированных полей её не существует. По крайней мере, в моих системах. Это было бы совершенно не рационально. На сей счёт есть, по крайнем мере, три соображения. Первое состоит в том, что обширная и многосторонняя информация истории болезни распределяется по разделам, число которых достигает трёх десятков. И при работе с отдельным пациентом, и при анализе массива историй болезни эти разделы используются по-разному: с разными целями, с разной частотой, с различной глубиной и широтой анализа. В одни разделы (например, в "паспортную" часть, в "исходы госпитализации") информация вносится один раз и никогда не изменяется или изменяется крайне редко. Другие должны быть специально организованы для следующих друг за другом дополнений и изменений - примером могут служить лечебные и диагностические назначения врача. Есть важные разделы, относящиеся только к женщинам, только к детям младшего возраста, только ко взрослым. Есть разделы, которые могут оставаться пустыми, и разделы, которые нельзя не заполнять. Есть взаимозависимые разделы. Во многих разделах необходимы свои собственные дополнительные сведения: в "Лечении" - способ введения лекарства и его расходование, в "Больничном листе" - причина временной нетрудоспособности, использование стационара, даты врачебных комиссий, сведения о совместительстве, в "Операциях" - вид обезболивания, фамилии хирурга и анестезиолога, номер записи в операционном журнале и т.д. Одни события, отражённые в истории болезни, сопряжены с датой, другие - с двумя датами (начало и завершение), третьи - с указанием на часы и минуты, для четвёртых ничего этого не нужно, - всё это разные форматы, разные способы автоматического контроля. Обеспечивать формализацию и хранение этой обширной и разнородной информации в единой форме - значит создавать чрезвычайно громоздкую структуру, с которой во всём её объёме придётся иметь дело при любой обработке данных, при любом запросе, даже самом простом и локальном. Это так или иначе сказывается и на скорости обработки данных, и на особенностях работы в многопользовательской среде, и на устойчивости информации к потерям и искажениям. Ничего фатального, но дополнительные проблемы могут возникать и у разработчика, и у пользователя. Второе соображение касается рациональности использования ресурсов компьютера. По объёму одноимённой информации пациенты существенно различаются. У одного диагноз исчерпывается одной строчкой, у другого может быть целый букет заболеваний и осложнений. То же можно сказать об обследовании и лечении: у одних - большое количество анализов, а у других - незначительное, в одном случае осущствляется только обследование, в другом - многокомпонентное лечение. Если в единой форме для каждого такого раздела резервировать пространство, исходя из предположительного максимума, то каждая история болезни будет зиять огромными пустотами. А они, хоть и пустоты, занимают место. Наконец, третье: для электронной истории болезни надо сохранить возможность развития, добавления новых разделов, которые, хотя и очень редко, могут понадобиться для отражения новшеств, связанных с развитием медицины и организации здравоохранения. Дополнять однажды выстроенную и отлаженную монолитную конструкцию тем тяжелее, чем она сложнее и обширнее. Так что и здесь единая форма для электронной истории болезни создаёт серьёзные затруднения. По изложенным причинам информация, образующая историю болезни, рассредоточена по нескольким файлам. В одном - паспортные данные всех пациентов, причем каждому здесь присваивается уникальный код. В другом файле - все диагнозы всех больных, в третьем - все анализы, в четвёртом - всё лечение, в пятом - операции, в шестом - социальные и социально-бытовые характеристики и т.д. Разумеется, сведения, относящиеся к каждому пациенту, снабжаются его индивидуальным кодом. Когда пользователь запрашивает историю болезни, всё собирается с помощью этого кода в тот самый документ, который можно видеть на экране, вносить в него новые сведения, записывать его в текстовый файл и печатать на бумаге. Вне этого запроса электронной истории как таковой нет. Между прочим, точно так же нет и никаких сводок, отчетов, списков, - всё создаётся только в момент запроса из первичных данных, имеющихся на момент запроса. Иначе говоря, база данных поликлинического участка, госпитального отделения или всей больницы - это совкупность примерно десятка файлов (ряд разделов истории болезни с идентичной структурой данных можно объединять). Каждый файл содержит свою специфическую информацию о пациентах или действиях врачей, каждый пополняется строчками для пациента только тогда, когда вводят соответствующие данные. Пока пациенту ничего не назначили, на него в файлах для анализов и лечения не будет ни одной строчки. Затем появится столько строчек, сколько анализов и лечебных мер врач назначит. То же касается описаний анамнеза и статуса, диагнозов, осложнений, дневников, операций, социальных характеристик, больничных листков, фамилий лечащих врачей и проч. Это не только экономно. Такая конструкция существенно спсобствует анализу информации об отдельном пациенте, сравнению пациентов, подсчёту историй болезни, их группировке по заданным признакам, разнообразным обобщениям. Все такие функции осуществляются проще и надёжнее.Когда пользователь ставит новую задачу подобного рода (а время от времени это непременно случается) программисту обычно хватает пары часов, чтобы такое задание выполнить. Для подсчётов, простых и сложных, для составления таблиц и списков никогда не нужна полностью вся огромная информация историй болезни, и здесь это легко использовать. Чтобы посчитать операции за заданный период или расход медикаментов программе нужен только файл с операциями или файл со средствами лечения. Чтобы те же данные соотнести с конкретными пациентами, нужен ещё файл с паспортными сведениями, а если нужно учесть и диагнозы - файл с диагнозами. Каждый из файлов можно упорядочивать не только по кодам пациентов, но и по признакам, характерным для данного вида информации: самих пациентов - по фамилиям, возрасту и полу, месту жительства, виду медицинского страхования, по учреждениям, направившим на госпитализацию и проч., диагнозы - по кодам Международной классификации болезней, анализы - по видам лабораторий, проведенное лечение - по клинико-фармакологическим группам и т.д., и т.п. Повреждение одного файла не выводит из строя всю историю болезни, а главное - его не сложно локализовать и исправить, причём и локализацию, и исправление обеспечить программно, сделать их автоматическими, так что пользователь либо вообще не заметит проблемы, либо его попросят подождать несколько секунд, сообщив об аутокоррекции. При появлении обстоятельств, которые невозможно предвидеть и которые потребуют развития системы в том или ином направлении, каждый такой файл можно, дополнять, по-новому индексировать, изменять в нём формат полей, не затрагивая ничего другого. Не представляет труда и добавить к десятку "специализированных" файлов ещё один - для новой информации, которую раньше не приняли во внимание или которой раньше не было в природе. Наконец, при новых запросах можно в ряде случаев просто расширить "специализацию" того или иного файла. Стоит иметь в виду ещё одну деталь: как правило, файлы, образующие базу данных, не содержат наименований . Нет в ней диагнозов, анализов, операций, исходов, социальных характеристик и т.п. в их словесном виде - наименования заменены кодами. Эти коды программа берёт из соответствующих справочников в тот момент, когда врач с их помощью вводит информацию в историю болезни. Когда эту информацию надо вывести, выдать для прочтения, программа с помощью тех же справочников подставляет вместо кодов их словесные значения. Помимо экономии ресурсов компьютера, это создаёт программисту большие удобства для многоаспектной обработки данных, а также для развития автоматизированной системы. Описанная структура данных, вероятно, применяется большинством разработчиков. Она означает, что просто, напрямую, прочесть информацию в файлах базы данных нельзя, в доступном для читателя виде её там нет. Она появляется только в результате специальной обработки, только в момент вывода по желанию пользователя. Отсюда, между прочим, следует, что выходные формы всегда соответствуют состоянию базы данных в момент их выдачи. Если между двумя выдачами одной и той же формы (истории болезни, сводки, списка или отчёта) данные пополнялись или корректировались, то в последней выдаче это обязательно будет отражено. Поэтому каждая печатная выходная форма должна автоматически снабжаться датой и временем (часами и минутами) её выдачи. Это позволяет предупредить или объяснить недоумения в случаях, когда, казалось бы, один и тот же документ выглядит по-разному. Специальные вопросы, связанные со структурой базы данных, возникают, когда заходит речь об электронной цифровой подписи. Если в качестве юридического документа используется не подписанная обычным образом распечатка истории болезни, а именно электронный документ, то что под этим имеется в виду? Что именно и когда должно удостоверяться? Каждый отдельный акт (каждая строчка в каждом файле)? Вся совокупность данных на данный момент? Что делать, если после этого произойдут изменения: назначенное лечение будет отменено, добавлено новое, появятся новые анализы и новые диагнозы, придут результаты анализов и представление врача о картине изменится? Здесь есть над чем поломать голову. Один из вариантов - создавать и хранить вторичный объект , то есть историю болезни в виде текстового файла, его и заверять электронной цифровой подписью. Но такой документ не пригоден для автоматической обработки данных, у него лишь одна единственная роль - свидетельствовать о том, что было с пациентом и что сделано врачами на данный момент времени. Конечно, таким же образом можно хранить и подписывать другие вторичные объекты - отчёты, списки. Только зачем, если их всегда можно получить из объектов первичных? Во всяком случае, такую возможность стоит иметь в виду. Где-то она может пригодиться. |