В настоящее время на многих кафедрах Красноярского государственного медицинского университета используется малоэффективная система информирования студентов об отработках и учета их посещения. Обычно на кафедральных стендах вывешивается расписание отработок, которое и выполняет основную функцию донесения информации до студента. Студент, отрабатывающий занятие, должен прийти на кафедру, ознакомиться с расписанием отработок и записаться в журнале, который обычно находится в лаборантской кафедры. Журнал отработок выполняет основную функцию учета посещаемости отработок – принимая отработку, преподаватель в журнале ставит студенту оценку, либо отмечает неявку, если записавшийся студент не посетил отработку.

Данная система имеет ряд недостатков. Самый значительный недостаток заключается в том, что студенты не могут самостоятельно влиять на формирование расписания отработок, а только знакомятся с существующим расписанием. Кроме того, студент не всегда может оперативно получить информацию, содержащуюся в расписании – для этого ему необходимо в определенное время посетить кафедру, которая может находиться достаточно далеко от мест, где в настоящее время проходит цикл практических занятий и лекционный курс. Особенно эта проблема актуальна для клинических кафедр, которые расположены в лечебных учреждениях всего города. Данная система не совсем удобна и для преподавателей- преподаватель не может в любой момент получить доступ к журналу отработок, что мешает ему правильно распределить время и усилия для подготовки к приему отработок.

В связи с активным внедрением современных информационных технологий в работу Красноярского государственного медицинского университета коллективами научно-образовательного центра «Управленческие и информационные технологии в здравоохранении» и кафедры ортопедической стоматологии был разработан и внедрен в работу кафедры электронный модуль записи на отработку. Предлагаемое решение имеет массу преимуществ перед традиционной системой ведения посещаемости отработок в бумажном варианте. Модуль является компонентом корпоративного сайта КрасГМУ, что обеспечивает возможность работы с ним студентам и преподавателям в любое время из любого места с помощью компьютера или мобильного устройства.

Модуль автоматически позволяет организовать электронный учет отработок на любой кафедре КрасГМУ. Для того, чтобы студенты могли начать записываться на отработки, необходимо создать расписание отработок. Создавать расписание отработок может заведующий кафедрой или завуч, которым автоматически выдается на это право. Для каждой отработки необходимо указать, что именно на ней будет приниматься у студента. Студентам для записи на отработку предоставляется два инструмента: создание своей собственной записи на отработку и возможность присоединиться к другому, уже записанному студенту, отрабатывающему ту же самую тему. Данные инструменты зависят от настроек отработок и доступны для использования в строго определенных случаях. Составитель расписания отработок может выбрать, какие задолженности будет принимать каждый преподаватель на каждой отработке – по лекциям, практическим занятиям, семинарским занятиям, контролируемой самостоятельной работе, самостоятельной индивидуальной работе, либо практическим навыкам. Можно задать еще более жесткие ограничения, указав, принимает ли преподаватель на данной отработке разные темы или только одну конкретную тему. Если преподаватель принимает  только одну тему, то саму тему определяет студент, который первым записывается на данную отработку (в этом случае возможность создания собственной записи доступна только ему) – все остальные студенты могут только присоединяться к нему – таким образом студенты могут самостоятельно влиять на правила приема отработок. Также оставлена возможность ничем не ограничивать принимаемые отработки. Если преподаватель готов принимать разные задолженности и разные темы – в этом случае любой студент может как присоединяться к другим записям на отработки, так и создавать собственные записи. При этом нужно иметь в виду, что в любом случае один студент не может записаться на одну отработку более одного раза.

Модуль является компонентом корпоративной информационной системы Красноярского государственного медицинского университета, что позволяет связать его с другими модулями КИС и использовать в его работе как общесистемные сущности, так и сущности, изначально создававшиеся для других модулей. Например, студент выбирает тему, задолженность по которой он собирается отработать, из тематических перечней электронного учебно-методического комплекса дисциплин, который также является компонентом корпоративной информационной системы КрасГМУ. При изменении рабочей программы дисциплины в электронном УМКД все нововведения автоматически становятся доступными для пользователей модуля учета посещаемости отработок.

Модель данных и технология работы

Таблица 1. Таблица otr_rasp базы данных для хранения информации, необходимой для вывода расписания отработок.

Таблица otr_rasp предназначена для хранения информации, необходимой для вывода расписания отработок. Расписание отработок по каждой дисциплине необходимо составить для того, чтобы студенты могли работать с модулем. Данные вводятся с помощью формы ввода

Расписание можно создать на неограниченный временной период – при запуске модуль сверяет дату, на которую назначена отработка, с текущей датой, и разрешит запись только на те отработки, которые будут проводиться в течение следующей недели. В списке отработки, на которые разрешено записываться, выделены зеленым; отработки, на которые можно будет записаться позднее – красным. Все прошедшие отработки автоматически убираются из списка (но вся информация сохраняется в базе данных) при наступлении следующего дня. Также запрещено записываться на отработки, которые проходят в течение текущего дня. Таким образом исключена возможность записи на отработку непосредственно перед ее началом, что дает преподавателю возможность более тщательно подготовиться к приему отработок. При конструировании расписания заведующий кафедрой или завуч для каждой отработки имеет возможность настроить все необходимые ограничения.

Следует иметь ввиду, что для работы модуля записи на отработку помимо конструирования расписания необходимо заполнить перечни в электронном учебно-методическом комплексе для данной дисциплины – без этого студент не сможет выбрать тему из списка.

Таблица 2. Таблица базы данных otr_students для хранения информации о студентах, записывающихся на отработку.

Таблица otr_students предназначена для хранения информации о студентах, записывающихся на отработку. Студент выбирает нужную ему отработку из расписания и переходит на страницу записи. На странице записи на отработку можно увидеть список всех записавшихся студентов и темы, для отработки которых они записались. Все оцененные студенты, или студенты, отмеченные как не явившиеся на отработку, автоматически убираются из списка. Также в модуле реализована система контроля за работой преподавателей заведующим кафедрой и завучем – на отдельной странице выводится список студентов, которые записывались на отработку, день приема которой уже прошел, но оценки или неявки не были выставлены. Для студентов модуль предоставляет возможность просматривать свои оценки за последние 20 отработок – если студент был хотя бы единожды оценен на отработке, справа от расписания он будет видеть таблицу, в которой будут перечислены его оценки и указан оценивший его преподаватель.

Преимущества

Электронный модуль записи на отработки значительно усилил эффективность приема и учета отработок на кафедре ортопедической стоматологии. Студенты могут удаленно просматривать расписание отработок и искать других студентов, отрабатывающих ту же тему. Преподаватели в любое время могут просмотреть список студентов, записавшихся к ним на отработку и темы, которые они будут отрабатывать, что дает возможность эффективно спланировать время для подготовки к приему отработок. Заведующий кафедрой и завуч могут более эффективно контролировать работу дежурных преподавателей, так как система учета приема отработок становится более прозрачной.

В настоящее время модуль внедрен в работу кафедры ортопедической стоматологии. В краткосрочной перспективе планируется его внедрение в работу других кафедр КрасГМУ и последующая доработка с учетом пожеланий пользователей. В долгосрочной перспективе планируется разработка модуля для учета как оценок студента, так и посещений лекций, практических занятий, выполнения самостоятельной работы и т.п., и его последующая интеграция с модулем записи на отработку. Данная система даст студентам возможность оперативно получать информацию обо всех своих задолженностях, сотрудникам кафедр и руководству вуза – анализировать статистические данные и делать выводы об учебной работе студентов, что дает возможность более эффективно планировать системы поощрений студентов и воспитательной работы со студентами.

В связи с увеличением количества оказываемых медицинских услуг лечебными поздразделениями КрасГМУ руководством университета было принято решение об оптимизации работы своих лечебных подразделений с помощью внедрения в их работу медицинской информационной системы. Для внедрения была выбрана медицинская информационная система qMS, разработанная в компании «СП.АРМ». Выбор данной МИС обусловлен основными фактами:

1. Продукт создан на основе СУБД Intersystems Cache, активно использующейся в здравоохранении Европы и США. Cache, постреляционная СУБД фирмы InterSystems, претендует на роль системы, преодолевающей как ограничения реляционных, так и объектно-ориентированных баз данных. [В. Кирстен, М. Ирингер, М. Кюн, Б.Рериг. Постреляционная СУБД Cache 5. Объектно-ориентированная разработка приложений. 2-е издание, перераб. и дополн. – М.: ООО «Бином-Пресс», 2005 г. – 416 с.: ил. C. 11.]
2. Открытый исходный код с возможностью доработки функционала
3. Опыт внедрения в лечебном учреждении г. Красноярска – Сибирском клиническом центре ФМБА России

С момента покупки МИС руководством КрасГМУ была поставлена задача –в течение семи месяцев внедрить 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 на уровне программного кода. В процессе разработки регулярно проводились совещания с врачами отделения стоматологии, показывались все готовые наработки, проводился сбор отзывов и предложений об улучшении интерфейса и функционала, на основе которых и выстраивается дальнейшее развитие системы.

Наш опыт показал, что врачи могут смотреть на медицинскую информационную систему с позитивной точки зрения, если раскрыть перед ними потенциал возможностей по упрощению работы врача. Очень важным моментом является активное обсуждение с врачами разрабатываемого функционала еще на стадии разработки, поиск людей, готовых активно работать в медицинской информационной системе  и вовлечение их в процесс разработки.