Введение
В связи с увеличением количества оказываемых медицинских услуг лечебными поздразделениями КрасГМУ руководством университета было принято решение об оптимизации работы своих лечебных подразделений с помощью внедрения в их работу медицинской информационной системы. Для внедрения была выбрана медицинская информационная система qMS, разработанная в компании «СП.АРМ». Выбор данной МИС обусловлен основными фактами:
- Продукт создан на основе СУБД Intersystems Cache, активно использующейся в здравоохранении Европы и США. Cache, постреляционная СУБД фирмы InterSystems, претендует на роль системы, преодолевающей как ограничения реляционных, так и объектно-ориентированных баз данных. [В. Кирстен, М. Ирингер, М. Кюн, Б.Рериг. Постреляционная СУБД Cache 5. Объектно-ориентированная разработка приложений. 2-е издание, перераб. и дополн. – М.: ООО «Бином-Пресс», 2005 г. – 416 с.: ил. C. 11.]
- Открытый исходный код с возможностью доработки функционала
- Опыт внедрения в лечебном учреждении г. Красноярска – Сибирском клиническом центре ФМБА России
С момента покупки МИС руководством КрасГМУ была поставлена задача –в течение семи месяцев внедрить qMS в работу двух из восьми лечебных учреждений вуза, обеспечив возможность ведения базы данных пациентов и электронной истории болезни.
В процессе изучения базового функционала, предоставляемого qMS и его сравнения с потребностями, возникающими у сотрудников отделений лечебных учреждений, был сделан вывод о том, что наибольшие трудности возникают в процессе внедрения qMS в работу отделения стоматологии. Вывод основан на анализе существующих печатных форм, стоматологических статусов и базовых возможностей системы по обработке информации, необходимой для работы отделения стоматологии.
Для обеспечения первого этапа внедрения потребовалось разработать функционал, позволяющий выводить данные из заполненных статусов в печатные формы (для реализации автоматического заполнения формы №043/у – медицинской карты стоматологического больного) и функционал, позволяющий реализовать автоматическое заполнение наряда – выбирать из системы наименования и стоимость оказанных пациенту услуг, основываясь на частично вводимых пользователем данных – номера порядкового пункта услуги и ее количественного значения.
Разработка статусов
Форма №043/у (медицинская карта стоматологического больного) включает в себя восемь страниц формата А5, каждая из которых содержит медицинские данные различного характера. Так, на первой странице находится паспортная часть, жалобы пациента и история развития заболевания. Вторая страница включает в себя данные о внешнем осмотре, исследовании ВЧНС и осмотре полости рта. Третьей страницей карты являются различные вкладные листы. Вкладные листы различаются по видам приема: для терапевтического, хирургического, парадонтологического, ортопедического, ортодонтического, детского и консультативного. В печатном варианте некоторые вкладные листы занимают несколько страниц формата А5.
Четвертую страницу карты занимает добровольное информированное согласие пациента, пятую – лист учета дозовых нагрузок при R-исследованиях зубов, шестую – учет онкопатологии, седьмую – дневник, восьмую – продолжение дневника, эпикриз и наставления.
Для обеспечения ввода информации в систему врачом для заполнения медицинской карты стоматологического больного было принято решение разработать одиннадцать статусов:
1) Основной статус – предназначен для ввода информации, содержащейся на первой, второй и восьмой страницах.
2) Лист учета дозовых нагрузок – ввод информации, содержащейся на пятой странице.
3) Учет онкопатологии – ввод информации, содержащейся на шестой странице
4) Дневник – ввод информации, содержащейся на седьмой странице
5) Зубная формула
Вышеперечисленные статусы универсальны и походят для ввода информации по любому типу приема. Отдельно для каждого приема были разработаны следующие статусы:
6) Терапевтический прием
7) Хирургический прием
8) Ортопедический прием
9) Ортодонтический прием
10) Детский прием
11) Консультативный прием
Данные статусы предназначены для ввода информации, содержащейся во вкладном листе (страница 3) и привязаны к различным услугам – видам приема.
Рис.1 – Окно основного статуса
Рис. 2 – Все статусы-части стоматологической карты предлагаются для заполнения. На данном примере показан терапевтический прием
Рис. 3 – Заполненный статус.
После разработки статусов у врачей появилась возможность вносить медицинскую информацию в систему qMS. Следующий этап заключался в создании печатных форм с возможностью корректного поиска и вывода на печать информации о пациенте. Особый момент заключается в том, что на некоторых страницах формы 043/у содержится как паспортная часть пациента, так и его медицинские данные, что не дает возможность просто использовать стандартный механизм печати данных статуса системы qMS. К тому же в нашем случае было необходимо реализовать возможность печати информации как из конкретного статуса, так и части информации из одного статуса на разных страницах стоматологической карты. Для решения проблемы было принято решение о доработки функционала системы на уровне языка qWORD, получив тем самым возможность вставлять данные статуса непосредственно в печатные формы на этапы их конструирования с помощью встроенного в систему визуального конструктора.
Разработка функционала.
Для реализации данной задачи был создан ряд функций, отвечающих за поиск, подготовку и отправку в печатную форму данных по выбранному пациенту. Стоит отметить, что при разработке печатных форм в qMS в качестве объекта фиксации чаще всего используются объекты: 153 – Реестр физических и юридических лиц и 174 – Эпизод (аналог законченного случая обращения.). В qMS объект также является типом. Поддерживается иерархия супертипов и подтипов, реализуя тем самым стандартный механизм объектно-ориентированного программирования – наследование. [Иванчева Н.А., Иванчева Т.А. Постреляционная СУБД Cache. – Новосибирский государственный университет, 2004.]
Начав разработку функций, отвечающих за печать данных, изначально было принято не совсем верное решение – использовать в качестве объекта фиксации объект 186 – Данные специалиста. Данное решение, хоть и позволяло выводить на печать данные из статуса по открытому пациенту, не учитывало открытого в данный момент эпизода, что не позволяло врачу печатать данные своего приема в эпизоде другого врача.
Рис.4. Функция, выводящая данные в форму, привязанная к 186 объекту
После выявления данной ошибки в процессе тестирования все функции, которые должны обеспечивать любому врачу печать данных из любого эпизода, были переделаны под использование 174 объекта в качестве объекта фиксации.
Рис.5. Функция, выводящая данные в форму, привязанная к 174 объекту
После того, когда в функцию, выполняющую вывод данных на печать, передается код экземпляра статуса, система определяет, какой пользователь вызвал функцию в текущий момент и ищет данные специалиста (186 объект), проверяя указанную дату, специалиста и общее начало кода экземпляра. После того, как будет найден список подходящих под условие запроса данных специалиста, система ищет внутри каждых данных экземпляры объекта 293 (Раздел медицинских записей), т.е. статусы, имеющих указанное название. Название статуса, которое следует искать, жестко указано для каждой функции. Например, функция, отвечающая за печать второй страницы стоматологической карты, ищет статус с названием “КРАСГМУ_МЕДИЦИНСКАЯ_КАРТА_СТОМАТОЛОГИЧЕСКОГО_БОЛЬНОГО_(ФОРМА_043/У)”; функция, отвечающая за печать листа учета дозовых нагрузок, ищет статус с названием «КРАСГМУ_ЛИСТ_УЧЕТА_ДОЗОВЫХ_НАГРУЗОК».
В процессе тестирования разработок было отмечено, что qMS может изменять дописываемый участок кода экземпляра объекта 293 к коду экземпляра вышестоящего объекта для разных приемов разных специалистов. Поэтому мы доработали функционал, используя гибкий метод поиска экземпляра, не основанный на жестком указании дописываемого фрагмента кода к заранее известному коду экземпляра вышестоящего объекта.
После определения нужного экземпляра 293 объекта система находит ряд экземпляров 294 объекта (Данные), которые содержат информацию статуса. Экземпляры объекта 294 имеют постоянно одинаковый дописываемый участок кода к коду экземпляра вышестоящего объекта, поэтому для извлечения информации используется жесткое указание нужного участка кода.
Для представления информации в табличной форме мы создали статусы, имеющие необходимое количество полей, которое соответствует требуемому количеству строк и столбцов таблицы. Например, одна из страниц медицинской карты стоматологического больного – Лист учета дозовых нагрузок содержит таблицу, состоящую из трех столбцов и тринадцати строк. Соответствующий статус предлагает ввести данные в тридцать девять полей, по три на каждую строку. Такая идеология позволяет четко разграничивать данные для каждой ячейки и создать печатную форму, корректно выводящую табличную информацию.
Рис 6. Статус «Лист учета дозовых нагрузок» – способ ввода информации для каждой ячейки.
Рис. 7. Печатная форма, обрабатывающая информацию из статуса «Лист учета дозовых нагрузок», открытая в конструкторе форм. Здесь видно, что для каждой ячейки после вызова функции, указано, для какой строки и какой ячейки в этой строке необходимо взять информацию из всего статуса. Указание производится с помощью двух последних числовых параметров после qqc – номера строки и номера ячейки в данной строке.
Стоит отметить, что в этом случае информация корректно выводится в печатную форму при условии того, что пользователь начал заполнение таблицы с первой строки. Иначе будет вызвано несоответствие дописываемой части составного ключа номеру строки.
После того, как разработанные статусы для заполнения медицинской карты стоматологического больного были показаны врачам отделения, мы получили массу предложений по улучшению и упрощению ввода данных. Самыми важными из них оказались предложения по структурированию информации и замене текстовых полей в статусах на выпадающие списки.
Интересен тот факт, что изначально статусы в функциональном плане представляли полный аналог печатной версии медицинской карты стоматологического больного – выбор из списка предоставлялся только в тех местах, где в печатной версии предлагалось подчеркивание какого-либо из вариантов, а ввод информации в текстовое поле находился там, где в печатной версии находится пустое место, предназначенное для ручного вписывания данных.
Врачами отделения было предложено структурировать диагнозы, выбирая самые распространенные диагнозы вместе с кодом МКБ из списка и лекарственные средства, используемые в «Профессорской клинике» с разными дозировками. Также структурирование затронуло достаточно много информации другого рода, от возможности выбрать номер зуба из списка до выбора стандартных описаний жалоб в анамнезе.
Рис. 8. Выбираем диагнозы из списка на приеме пародонтолога.
Данный пример наглядно показывает возможность упрощения работы врача с помощью использования медицинской информационной системы. К тому же такой способ ввода данных позволяет более четко структурировать информацию, избавить ее от ошибок ручного ввода и получать более точную и детальную статистику.
Помимо предложений по структурированию информации врачи отделения предложили заменить стандартный способ заполнения зубной формулы на отдельный табличный статус с выбором данных из списков. Стандартный способ предоставляет возможность редактирования изображения зубной формы (в формате графического файла) и сохранение файла в базе данных. Недостатками этого способа оказались достаточно неудобный вывод зубной формулы на печать (автоматическая вставка изображения в генерируемый документ Word) и сам процесс вставки данных на графический рисунок, схожий с рисованием в графическом редакторе Paint. В итоге стандартный способ был удален из медицинской карты стоматологического больного и сделан отдельный статус (по идеологии, приведенной в примере «Листа учета дозовых нагрузок»).
Помимо разработки механизма ведения и печати медицинской карты стоматологического больного еще одним условием для начала работы отделения стоматологии в qMS явилось обеспечение возможности распечатывания нарядов по каждому пациенту для каждого врача. В печатном варианте наряд представляет собой лист формата А5 с указанием фамилии, имени, отчества врача и пациента и списком услуг, оказанных данному пациенту данным врачом. Список услуг включает в себя порядковый номер услуги в прайсе, наименование услуги, стоимость услуги, количество оказаний услуги и суммарную стоимость как каждой услуги с учетом количества, так и суммарную стоимость всех услуг.
Изначально была разработана полностью автоматизированная возможность печати наряда – программа осуществляла поиск по всем врачебным услугам раскрытого в данный момент эпизода, сравнивала данные пользователя, печатающего наряд с данными врача, привязанными к каждой услуге и отбирала услуги, оказанные только врачом, который в настоящее время распечатывает наряд. После отбора услуг на основе кода каждой услуги определялась ее позиция в прайсе и уникальный код экземпляра объекта «Прайс», к которому привязана данная услуга. После этого программа определяла код экземпляра нижележащего объекта по отношению к прайсу, хранящего цену услуги (на основе общего начала кода экземпляра данного объекта и кода экземпляра прайса) и брала оттуда значение цены.
Стоит отметить, что при программировании данной функции было необходимо неоднократное преобразование получаемых данных из строкового формата в массив и обратно для последующей обработки. Это связано с тем, что для поиска кодов экземпляров и их объектов в системе qWORD широко используется функция FastKey, возвращающая список подходящих под условие запроса данных в строковом формате, в результате чего без преобразования в массивы данные нельзя было использовать для циклового поиска по экземпляров других объектов. Данные, полученные в результате циклового поиска, записывались в массив и конвертировались обратно в строковый формат для большей совместимости с результатом, выдаваемым FastKey при отправке данных в печатную форму и генерации XML-документа.
Хотя после реализации данной функции был получен успешный результат – теперь программа могла автоматически искать услуги по каждому пациенту, оказанные ему врачом, печатающим форму, в целом модуль не смог удовлетворить запросы врачей отделения стоматологии. Причинами этого послужили:
- Различия в кодировке пунктов прайса, принятого внутри «Профессорской клиники» и прайса внутри qMS, создающемуся для единовременного обслуживания всех восьми лечебных подразделений КрасГМУ.
- Наличие различающейся кодировки пунктов прайса, принятого в «Профессорской клиники». Так, прейскурант цен на материалы и медикаменты для оказания стоматологических услуг имеет сквозную нумерацию в двухуровневом формате с 1.1 до 8.14, в то время как прейскурант цен на стоматологические услуги имеет сквозную нумерацию с 1 до 305.
- Невозможность указания количества оказаний услуги. Программа дублировала повторяющиеся услуги, устанавливая по умолчанию для каждого дубля количественный показатель в одну единицу. Хотя это не приводило к искажению результатов, бланк наряда становился излишне перегруженным информацией.
В результате после расширенного анализа потребностей врачей отделения и их отзывов и предложений по улучшению продемонстрированной им версии наряда было принято решение о кардинальной перереработке данной функции. Сотрудники отделения в первую очередь настаивали на предоставлении им возможности вводить часть данных – порядковый номер услуги, соответствующий ее номеру во внутреннем прайсе клиники и количество оказаний данной услуги. На программу было предложено возложить функции поиска наименований услуг, их цен и математические операции с ценами.
Для реализации данных возможностей в первую очередь потребовалось создать связи прайса qMS со внутренним прайсом «Профессорской клиники». Прайс qMS, как системы, рассчитанной на обслуживание восьми разнопрофильных лечебных подразделений вуза, изначально создавался с многоуровневой кодировкой услуг, которая в принципе не могла приобрести полное соответствие внутреннему прайсу «Профессорской клиники» (равно как и внутреннему прайсу любого лечебного подразделения КрасГМУ). В этой ситуацией очевидным решением стало добавление кода услуги из внутреннего прайса к основному коду услуги прайса qMS в точном соответствии с его кодом во внутреннем прайсе. Существенно облегчил задачу тот факт, что кодировка прайса qMS изначально была разработана с сохранением одинаковой длины любого кода.
После дополнений к кодировке прайса был создан статус «Наряд». Статус содержит текстовые поля в количестве, необходимым для резервирования двух ячеек и пятнадцати строк в печатной форме. На каждую строку отводится два текстовых поля, в первое из которых врач заносит порядковый номер строки из внутреннего прайса, а во второе – количество. Статус привязан к первичным и повторным услугам врачей-стоматологов и заполняется вместе с медицинской картой стоматологического больного. Наряд печатается в виде таблицы и идеология его разработки соответствует приведенному выше примеру на статусе «Лист учета дозовых нагрузок».
Рис. 9. Наряд, заполняемый врачом. Указывается код услуги из внутреннего прайса клиники и ее количество.
Рис. 10.Наряд, сгенерированный для печати в Microsoft Word. На основе введенных данных программа определила название услуги, цену и сумму.
Заключение
На подготовку МИС qMS к первому этапу обеспечения потребностей отделения стоматологии «Профессорской клиники» ушло около сорока дней. За это время были с нуля созданы необходимые статусы (на основе форм, утвержденных Министерством здравоохранения), разработан функционал, позволяющий генерировать печатные формы с выводом информации из заполненных статусов. Было освоено несколько алгоритмов поиска данных на уровне языка qWORD; в процессе разработки было получен большой опыт работы как с языком qWORD, так и с доработкой МИС qMS на уровне программного кода. В процессе разработки регулярно проводились совещания с врачами отделения стоматологии, показывались все готовые наработки, проводился сбор отзывов и предложений об улучшении интерфейса и функционала, на основе которых и выстраивается дальнейшее развитие системы.
Наш опыт показал, что врачи могут смотреть на медицинскую информационную систему с позитивной точки зрения, если раскрыть перед ними потенциал возможностей по упрощению работы врача. Очень важным моментом является активное обсуждение с врачами разрабатываемого функционала еще на стадии разработки, поиск людей, готовых активно работать в медицинской информационной системе и вовлечение их в процесс разработки.
Библиографический список
- В. Кирстен, М. Ирингер, М. Кюн, Б. Рериг. Постреляционная СУБД Cache 5. Объектно-ориентированная разработка приложений. 2-е издание, перераб. и дополн. – М.: ООО «Бином-Пресс», 2005 г. – 416 с.: ил.
- Иванчева Н.А., Иванчева Т.А. Постреляционная СУБД Cache. – Новосибирский государственный университет, 2004.
Количество просмотров публикации: Please wait