|
Автоматизированные системы ведения истории болезнино при этом она еще не может обеспечить распознавание слитной речи. Кроме того, ее пользователи при диктовке своих текстов должны ограничиваться заранее заданным словарем. 4.5 Альтернативные варианты изображения информации Структура рукописных документов очень проста: они разбиваются на страницы. Если те же самые данные требуется представить в другом виде, их приходится записывать повторно - такова общая практика. Врачи записывают план лекарственных назначений в дневник истории болезни, а затем то же самое пишут на бланках рецептов. Лаборанты вписывают результаты анализов в бланки заказов, а врачи затем повторяют отдельные результаты в своих записях, диаграммах, выписных эпикризах. Можно привести много других примеров дублирования записи медицинской информации. В отличие от этого данные, однажды попавшие в компьютер, могут быть представлены во множестве документов без повторного ввода. Кроме того, хранящиеся в компьютере данные могут быть представлены в новом виде, еще не использовавшемся в ручных системах. 4.6 Бумажные документы и видеотерминалы Видеотерминал имеет много достоинств. Он позволяет изображать данные почти мгновенно, в то время как принтеру на печатание одной страницы могут потребоваться секунды и даже минуты. Изображение динамически меняется в ответ на реакцию пользователей при просмотре информации. Кроме того, терминалы работают тихо и не нуждаются в расходуемых материалах - бумаге и красящей ленте. Несмотря на все разговоры о “безбумажной технологии”, бумага также имеет определенные достоинства. Современные недорогие принтеры могут напечатать на одном листе бумаги в четыре раза больше данных, чем их помещается на экране стандартного видеотерминала с 24 строками и 80 колонками. Кроме того, способности шрифтовых выделений, обеспечиваемых принтерами, намного превосходят возможности сопоставимых по цене видеотерминалов. Люди могут без труда носить бумажные документы в карманах, делать на них пометки и пользоваться ими без специальной подготовки. Кроме того, человек читает текст бумажного документа на 25% быстрее и воспринимает его на 10% точнее, чем тот же самый текст на экране видеотерминала. Графические видеотерминалы с большими экранами, имеющими высокую разрешающую способность, увеличивают преимущество этой технологии перед бумажной и ускоряют приближение дней, когда скоросшиватели и их содержимое станут анахронизмом. Сомнительно, однако, чтобы бумага была вовсе изгнана из кабинетов врачей; даже в условиях полной автоматизации врачи могут предпочитать иметь бумажные копии фрагментов истории болезни для специфических целей. 4.7 Компьютерные версии ручных отчетов Автоматизированные системы ведения истории болезни обеспечивают вывод большинства отчетов, используемых при ручной технологии; примерами могут служить дневник визита, направления на консультации и медицинские заключения. В отчетах о течении заболевания данные организованы в соответствии со временем их сбора, и тем самым акцент делается на изменение состояния пациента с течением времени. Например, отчет, используемый для контроля за состоянием пациента, выполняющего программу избавления от избыточного веса, должен содержать значения веса, артериального давления, толщины кожных складок, а также другую информацию, которая должна регистрироваться при каждом визите пациента. Фрайс отметил, что врачи могут найти информацию в отчете о течении заболевания в четыре раза быстрее, чем в обычной истории болезни. Автоматизированные системы ведения истории болезни могут выводить большую часть, если не всю историю болезни. в форме отчетов о течении заболевания. Программы вывода отчетов о течении заболевания могут позволять выбор устройства вывода (надо ли печатать отчет или достаточно вывести его на экран терминала?), или ориентации (какие именно значения надо включать и как их сортировать и группировать?), а также временного периода (каков временной интервал между наблюдениями?). Последний параметр требует комментариев. Если пациент находится в блоке интенсивной терапии (БИТ), то регистрация изменений его состояния через каждую минуту может представлять определенный интерес. Врачу амбулаторного учреждения достаточно знать, как менялось состояние его пациентов с интервалами в недели или даже месяцы. Для удобства человека, анализирующего отчет о течении заболевания, масштаб времени должен быть выбран соответствующим интенсивности терапии. Следовательно, в отчете о 2- летнем курсе лечения пациента с эмфиземой легкого, предназначенном для лечащего врача амбулаторного учреждения, не надо указывать все 25 групп значений концентрации газов в его крови, зарегистрированные в течение одной госпитализации, поскольку они могут затруднить анализ долгосрочных тенденций. Когда в одном отчете о течении заболевания представлено большое число результатов осмотров, то приходится делать выбор между представлением их в виде большой матрицы или в виде нескольких подматриц. Одна большая матрица имеет то преимущество, что с ее помощью легче сопоставлять значения параметров состояния пациента на каждую дату, но при этом становится труднее сравнивать изменение результатов анализов, заказываемых не очень часто. Кроме того, такой отчет будет содержать много пустых мест. Поэтому обычно бывает лучше разбивать большую матрицу отчета о течении заболевания на несколько меньших матриц. 4.8 Заключения и эпикризы Автоматизированное ведение истории болезни позволяет представлять важные компоненты истории болезни в виде подборки компактных и более обозримых документов. Обычно для этого выбираются специфические классы данных о пациенте, например активные аллергии, активные проблемы, активное лечение и результаты последних осмотров. Хорошим примером может служить заключительный эпикриз, сформированный системой COSTAR. В будущем можно ожидать появления более сложных стратегий составления заключений и эпикризов, связанных, например, с выявлением значительных отклонений в параметрах состояния пациента или с агрегированием в одном диагностическом заключении аномальных значений параметров близкой природы (например, повышенного содержания трансаминазы (SGOT), повышенного содержания щелочной фосфатазы и билирубина, каждый из которых является индикатором нарушений функций печени). Можно будет встретить заключения, в которых различаются аномальные значения параметров, на которые направлено лечение, от тех параметров, которые данным лечением не улучшаются. При этом могут динамически предоставляться возможные объяснения наблюдаемых аномалий. В будущем компьютеры должны приобрести способность формировать точные и содержательные документы, подобные выписным эпикризам, составляемым опытными больничными врачами. 4.9 Оборотные документы Оборотные документы представляют собой выданные компьютером отчеты, в которых дается определенная информация и задаются дополнительные вопросы. Они являются бумажными эквивалентами экранных форм, выдаваемых на видеотерминалы. Формы регистрации визитов, а также суперсчета являются примерами оборотных документов, выдаваемых большинством автоматизированных систем ведения истории болезни. Наличие хорошо формализованных оборотных документов позволяет обеспечить получение информации непосредственно от врачей, работающих в различных условиях. Бумажные оборотные документы являются хорошо известным средством; люди могут пользоваться ими при минимальной подготовке. Обычно оборотные документы больше всего используются в учреждениях, обеспечивающих амбулаторное обслуживание пациентов, поскольку в этом случае есть время заготовить такой документ до прихода пациента. Они также использовались на постах медсестер в больницах, например для сбора медицинскими сестрами информации о приеме лекарств и других сведений об уходе за пациентами, а также как бланки заказов на диагностические исследования. 4.10 Динамическое предоставление информации Каждый, кто пытался анализировать историю болезни пациента, знает, что бывает очень трудно найти требуемую часть информации, например интерпретацию последнего исследования на компьютерном томографе (КТ) или установить сам факт, что таковое было сделано. (Исследования, подобные КТ, выполняются очень редко, но их результаты могут быть критичными для постановки диагноза.) Врачи могут задаваться сотнями таких вопросов, листая взад-вперед историю болезни в поисках фактов, которые подтверждают или опровергают одну из возникших у них гипотез. Наличие медицинских записей в памяти компьютера не исключает работу по поиску необходимого факта, но зато позволяет пользователю получить данные в хорошо структурированной форме (например в виде отчетов о течении заболевания), позволяющей облегчить извлечение необходимой информации. Еще важнее то, что некоторые программы берут на себя часть работы по поиску данных и могут предоставлять данные, имеющие отношение к конкретной проблеме пациента. Например, в системе COSTAR выдаются свои формы отчетов для гипертензии, гематологических, эндокринологических и других областей проблем пациентов. На более сложном уровне компьютер мог бы выдавать перечни аномалий, которые не могут быть объяснены известными проблемами пациента, или указывать побочные действия лекарств, которые могли бы объяснить последние изменения, например повышение концентрации печеночных ферментов. Обеспечивая поиск данных и распределяя их по отдельным группам в соответствии с контекстом конкретной медицинской проблемы, программа может ускорить сопоставление данных пациента и эволюцию диагностических гипотез. В конце концов компьютерная система может стать настолько разумной, что будет самостоятельно выбирать из контекста истории болезни необходимые врачам виды данных. 4.11 Графические терминалы Во многих ситуациях человек может усваивать графическую информацию гораздо быстрее, чем ее текстовые или числовые эквиваленты. Графические представления сведений из истории болезни можно подразделить на следующие три класса: 1. Представительская графика. Существуют типичные графики или гистограммы, которые используются в публикуемых отчетах для того, чтобы ясно показать временные зависимости между клиническими событиями и корреляции между значениями параметров. 2. Диаграммные отчеты. В этих отчетах диаграммы используются в сочетании с числами или традиционными графиками. Хорошим примером могут служить экранные формы, выдаваемые системой хирургического блока интенсивной терапии Медицинского центра Cedars-Sinai. 3. Непрерывные кривые и изображения. Электрокардиограммы, радиографические изображения и даже фотографии пациентов могут храниться в электронном виде и выдаваться на графические терминалы. Компьютерные изображения электрокардиограмм и графиков изменения артериального давления стали обычным явлением в системах, предназначенных для автоматизации блоков интенсивной терапии. Более сложные системы обработки радиологических изображений позволяют показывать на графическом терминале оцифрованные радиограммы. Как только цены на устройства, обеспечивающие хранение и обработку изображений и кривых, станут достаточно умеренными, эти методы изображений начнут широко использоваться в автоматизированных системах ведения истории болезни. 4.12 Повествовательные отчеты Автоматизированные системы ведения истории болезни нередко предлагают средства формирования специализированных отчетов, например по нагрузочным тестам или спирометрии (оценке дыхательного объема легких). В этом случае врачи сначала заполняют формализованный входной бланк (часть полей которого надо отметить, часть заполнить текстом). Когда эта информация будет введена в компьютер, последний может представить ее в виде связного повествовательного текста. Специализированные системы для обработки электрокардиограмм и спирометрических исследований включают в такие отчеты еще и графические изображения. Компьютеры могут использовать два основных способа обработки текста для формирования таких повествовательных отчетов: 1. Компоновка заготовок фраз. Существуют распространенные фразы и абзацы, которые можно вводить при наборе надиктованных или рукописных текстов с помощью нажатия нескольких клавиш. Этот метод часто используется в системах отделений радиологии и рентгенологии для составления заключений по нормальным результатам и по выявленным типичным патологиям. Он может также применяться для формирования повествовательных заключений, интерпретирующих показания медицинских измерительных приборов, например спирометров и электроэнцефалографов, а также для формирования заключений по хирургическим патологиям. 2. Заполнение шаблонов. Многие текстовые процессоры предлагают средства создания шаблонов стандартных писем или документов, в которые потом можно вставлять индивидуальные отклонения. Текст шаблона состоит из постоянных и переменных компонентов; для получения окончательного документа пользователь заполняет переменную часть шаблона данными конкретного пациента. Примером могут служить талоны приема; переменными компонентами талона являются фамилия пациента и его адрес, дата и время приема, а также врач, который должен принять пациента. 5. Системы выполнения запросов и ведения контроля Возможности обработки запросов и ведения контроля, обеспечиваемые при хранении медицинских записей в памяти компьютера, не имеют аналогов в системах ручного ведения истории болезни. Медицинский персонал и администраторы могут использовать эти возможности для формирования предупреждений о грядущих важных клинических событиях, для извлечения сведений о медицинских или административных характеристиках пациентов, а также для статистической обработки данных. Запрос означает выборку и агрегирование данные о группах аналогичных пациентов. Контроль означает выявление и пометку состояний пациента, требующих повышенного внимания со стороны медицинского персонала. Хотя эти функции и являются различными, их внутренняя логика похожа. В обоих случаях центральная процедура анализирует записи из истории болезни пациента и, если эти записи удовлетворяют заранее заданным критериям, формируют соответствующий выходной документ. Выполнение запроса обычно связано с обработкой больших подмножеств пациентов или всей популяции; выходным документом является таблица, строки которой содержат либо исходные данные, извлеченные из медицинских записей, либо итоговую статистическую характеристику этих данных. Контроль обычно используется только для пациентов, находящихся на активном лечении; выходным документом является предупреждение или напоминание. Системы выполнения запросов и ведения контроля могут быть использованы для обеспечения клинического лечения и для ведения научно- исследовательской работы, проведения ретроспективных исследований, решения управленческих задач. Клиническое лечение. Напоминания, выдаваемые компьютерами, значительно расширяют возможности врачей организовать профилактические мероприятия в отношении избранных пациентов. Системы контроля могут идентифицировать пациентов, нуждающихся в периодических профилактических осмотрах и других мероприятиях, например иммунизации, маммографии, исследованиях соскоба цервикального канала, и могут напоминать врачам, что эти мероприятия надо выполнить при очередном визите пациента. К примеру, врачи, получавшие такие напоминания, вчетверо увеличивали определенные виды вакцинации пациентов по сравнению с теми врачами, кто таких напоминаний не получал. Если при заказе лабораторных тестов или при назначении лечения врачи ведут непосредственный диалог с системами контроля, например с системой HELP, это обеспечивает еще большие возможности улучшения качества лечения и снижения затрат на лечение. Системы запросов особенно полезны при проведении исследований ad hoc, например для идентификации пациентов, получающих лекарство, отозванное с рынка. Эти системы могут облегчить выполнение мероприятий по оценке качества, например составление рефератов по применению лекарств, требуемых органами аккредитации. Они могут идентифицировать пациентов, которые будут рассматриваться как кандидаты для ретроспективного клинического аудита, и могут собрать большую часть данных, необходимых для проведения аудита. Клинические исследования. Системы выполнения запросов могут быть использованы для идентификации пациентов, которые удовлетворяют минимальным требованиям отбора для последующих клинических испытаний. Например, исследователь может идентифицировать всех пациентов мужского пола, старше 50 лет, принимающих лекарства для лечения гипертензии. Системы ведения контроля могут помогать в проведении таких исследований, отмечая пациентов, подлежащих контролю, и предлагая выполнить необходимые для клинического испытания шаги, когда эти пациенты приходят на прием. Тем самым они облегчают следование протоколам, описанным исследователями, назначение необходимого лечения и выполнение требуемых измерений. Ретроспективные исследования. В настоящее время рандомизированный анализ будущего лечения стал золотым стандартом для клинических исследований, но ретроспективные исследования уже имеющихся данных всегда вносили большой вклад в развитие медицины. Ретроспективные исследования могут давать ответы на интересующие исследователя вопросы за небольшую часть времени и цены, требуемых для проведения исследования по вновь собираемым данным. С их помощью можно выделять группу исследуемых пациентов и контрольную группу, а также выполнить статистический анализ, необходимый для сопоставления этих двух групп. Хранение медицинских записей в памяти компьютера не исключает всю ручную работу, необходимую для проведения эпидемиологических исследований; все равно могут понадобиться составление эпикризов по содержанию историй болезни и проведение опросов пациентов. Если из этих записей можно извлечь больше информации, то указанные трудоемкие операции могут проводиться менее часто и менее интенсивно. Фрагменты истории болезни, обычно хранящиеся в памяти компьютеров, чаще всего включают в себя сведения о лекарственных назначениях, результатах лабораторных тестов и диагностических исследований, а также диагнозах, поставленных при приеме пациентов. Это особенно характерно в тех случаях, когда первые два типа данных передаются в машиночитаемом виде из автоматизированных систем аптек и лабораторий. Поэтому хранящиеся в памяти компьютера медицинские сведения чаще всего оказываются полезными при исследованиях особенностей обслуживаемой популяции, эффективности выполнения лабораторных тестов и проведения лекарственного лечения, а также токсических эффектов лекарств. Управленческие задачи: Появление системы фиксированного возмещения затрат на лечение специфических заболеваний (клинико-статистические группы, или подушная плата) и связанная с ней конкурентная борьба больниц за заключение контрактов с органами здравоохранения привели к тому, что администраторам медицинских учреждений пришлось начать рассматривать и клиническую информацию при решении вопросов, какие медицинские услуги должно предлагать учреждение, кому и по какой цене. Кроме того, администраторы должны иметь возможность контролировать ресурсы, используемые врачами для лечения тех или иных классов пациентов, и предоставлять обратную связь тем врачам, чье поведение значительно отклоняется от нормы. Медицинские системы выполнения запросов могут предоставить информацию о взаимосвязях между диагнозами, индексами тяжести заболевания и потреблением ресурсов. Тем самым системы выполнения запросов являются важным инструментом для тех администраторов, кто пытается принять информационно обоснованные решения о действиях во все более чувствительной к экономическим вопросам сфере здравоохранения. 5.1 Языки запросов и контроля Медицинские языки запросов и контроля во многих отношениях напоминают языки запросов систем управления базами данных общего назначения (СУБД ). Как и в большинстве формальных языков программирования, в них предусмотрены средства присваивания значений переменным, управления порядком выполнения операторов языка, а также стандартные логические операции AND, OR (И, ИЛИ) и операции сравнения (, =). Кроме того, они позволяют делать выборки из ряда повторяющихся измерений и выполнять такие операции, как найти первый элемент, последний, максимальный, минимальный; найти направление изменения; определить число элементов в выборке, величину изменения, интервал между измерениями и т.д. Врач может использовать подобные операции для того, чтобы определить среднее значение содержания сахара в сыворотке крови по измерениям, проведенным в первый год после начала лечения инсулином, или найти максимальное значение содержания калия в сыворотке крови после начала калий-дополняющей терапии. Наконец, в этих языках предусмотрены средства указать, какое сообщение надо послать и кому в ситуация, когда сведения о пациенте удовлетворяют определенным критериям отбора. К числу наиболее известных систем запросов и контроля относятся: подсистема MQL, входящая в состав системы COSTAR; подсистема CARE, работающая в составе системы RMRS. Подсистемы MQL и CARE похожи тем, что в обеих задания и запросов, и контроля имеют общий синтаксис команд; кроме того, обе этих подсистемы были первоначально разработаны для использования в пакетном режиме в целях анализа амбулаторного лечения пациентов. 5.2 Возможности и ловушки Имея успешный опыт проведения эпидемиологического исследования по выборке из нескольких сотен историй болезни, можно было бы надеяться, что автоматизированный доступ к тысячам историй болезни приведен к новым вершинам клинических знаний. Однако само по себе хранение медицинских сведений в памяти компьютера не приведет к тому, что в результате одного нажатия на клавишу будет выдана целая научная статья; существуют серьезные практические и методологические проблемы, мешающие осуществиться этой утопии. Во-первых, исследователь не может получить точную информацию из автоматизированной системы ведения истории болезни, не будучи тесно знакомым с содержанием хранящихся в ней сведений, а также использованных в ней способов получения информации, ее кодирования и хранения. Если, к примеру, требуется выбрать всех пациентов, принимающих фенитоин (лекарство, используемое для лечения некоторых форм эпилепсии), то при этом надо знать, что для данного лекарства в системе используются три кода: один для фенитоина в форме таблеток, другой для фенитоиновой мази, а третьим обозначается раствор фенитоина для инъекций. Если целью исследования является изучение распространенности рутинного анализа мочи при лечении взрослых пациентов, то необходимо знать, каким именно образом получаются результаты анализа мочи и как они регистрируются. Компьютер может выдать отчет по всем анализам, выполненным в лаборатории, но при этом пропустит те, что выполнялись самими врачами вне лаборатории, поскольку могло оказаться, что врачи записывают результаты этих анализов только в своих дневниках. При получении данных могут возникать значительные задержки. В системе обработки выписных эпикризов может существовать 2-х или 3-х месячная задержка между фактом выписки пациента и вводом его выписного эпикриза. Неполнота хранящихся в компьютере медицинских сведений о пациенте является общим правилом. Если сбор данных опирается на технологию заполнения медицинскими специалистами формализованных бланков, то почти наверняка эти бланки будут содержать неполную информацию. Поэтому пользователи системы выполнения запросов должны понимать ограничения на достоверность и полноту информации, накладываемые процедурами сбора данных, и составлять свои запросы к системе с учетом этих ограничений. 6. Примеры автоматизированных систем ведения амбулаторной истории болезни Автоматизированная история болезни является ключевым атрибутом как больничной информационной системы, так и автоматизированной системы ведения амбулаторной истории болезни (АСВАИБ). Оба вида систем обеспечивают как административные функции, так и процесс лечения пациента. Однако для амбулаторных систем многие функции автоматизированной больничной информационной системы, например планирование питания и мониторинг состояния пациента в блоке интенсивной терапии, являются ненужными. Большинство АСВАИБ содержит модули для ведения медицинских записей, выполнения административно-финансовых функций, а также для формирования отчетов. Хотя многие общие принципы создания систем ведения истории болезни равным образом приложимы как к стационарному, так и к амбулаторному лечению, основные свойства этих систем будут описаны на примере четырех систем ведения амбулаторной истории болезни: COSTAR, RMRS (Regenstrief Medical Record System), TMR (the Medical Record) и STOR (Summary Time Oriented Record). Эти системы имеют долгую историю развития и их особенности широко освещались в литературе. 6.1. Система COSTAR Система COSTAR была разработана в конце 60-х годов Барнеттом и его коллегами в Лаборатории кибернетики Массачусетского общего госпиталя (Laboratory of Computer Science of Massachusetts General Hospital). Эта система проектировалась для обеспечения выполнения Гарвардской программы общественного здравоохранения HCHP (Harvard Community Health Plan), но затем она была пересмотрена, чтобы ее можно было использовать в других учреждениях, обеспечивающих амбулаторное обслуживание пациентов. Разработчики расширили функциональные возможности системы (например, обеспечили выполнение функций, связанных с оплатой лечения) и удалили из нее многие функции, оказавшиеся специфическими только для плана HCHP. В 1978 году версия системы, получившая название COSTAR 5, была объявлена доступной любой организации, желающей использовать ее или продавать как коммерческий продукт. В настоящее время учреждение, желающее установить систему COSTAR, может воспользоваться ее общедоступной версией (public domain) или приобрести одну из многих коммерческих версий, обладающих более широкими возможностями. Общее число пользователей системы COSTAR не известно; на проведенный в 1986 году опрос пользователей откликнулось более 110 мест, в которых она была установлена. Разработка системы COSTAR 5 преследовала две цели: (1) улучшить лечение пациентов за счет большей доступности и лучшей организации истории болезни и (2) улучшить возможности управления амбулаторным учреждением с помощью автоматизации административных, управленческих и финансовых функций. Для достижения этих целей разработчики системы выбрали модульный подход, позволяющий каждой организации настраивать систему на свои административные и клинические нужды и финансовые ограничения, а также обеспечили возможность постепенного наращивания модулей. Базовая система COSTAR 5 содержала модули для (1) обеспечения безопасности и целостности данных; (2) регистрации паспортных данных пациентов; (3) записи пациентов на прием; (4) формирования счетов на оплату лечения и финансовых отчетов; (5) сбора и хранения фрагментов истории болезни и (6) генерации отчетов управленческого характера. Для функционирования системы было достаточно установить только модули обеспечения безопасности данных и регистрации пациентов, а также минимальный вариант модуля ведения истории болезни; расширенные функции ведения истории болезни и другие модули были необязательными. Система COSTAR могла оперировать как полностью автоматизированная система ведения истории болезни. Будучи однажды введенными, все медицинские сведения могли быть получены в режиме оперативного доступа; тем самым потребность в бумажной истории болезни исключалась. Перед приходом пациента на прием система распечатывала реферат истории болезни, предназначенный для просмотра принимающим врачом, а также формализованный бланк приема, предназначенный для записи административных и медицинский сведений о пациенте. Никакая специфическая информация о пациенте в этот бланк не впечатывалась. В процессе приема пациентов врачи собирали медицинские данные и заполняли бланки приема. Они отмечали соответствующие диагнозы, параметры и симптомы в кодированных списках проблем, и указывали статус проблемы: M означало основную проблему (main), I - неактивную проблему (inactive) и так далее. Врачи могли вписать свои комментарии в специальное поле внизу бланка или надиктовать те сведения, которые должны были обрабатываться отдельно. После визита вспомогательный персонал вводил данные из бланка в компьютерную систему. В дополнение к бланку визита модуль ведения истории болезни позволял получить три стандартных выходных документа: Отчет о визите обобщал сведения о отдельном визите пациента, включая диагнозы, результаты осмотра и лабораторных тестов, а также лекарственные назначения. Отчет о текущем состоянии пациента обобщал текущие сведения о состоянии здоровья пациента, включая список профилактических мероприятий, аллергии, основные и сопутствующие проблемы; семейную и социальную историю пациента, а также историю его заболеваний; результаты последних лабораторных тестов; текущие лекарственные назначения. Специальные диаграммы, обобщающие хронологию заболеваний и клинических исследований в виде упорядоченного по датам списка клинических наблюдений и результатов лабораторных тестов. Модуль генерации отчетов управленческого характера обеспечивал вывод множества стандартных отчетов (например, числа визитов по пациентам, по врачам или по специальному виду услуги). Учреждения могли без труда добавить к системе вывод других периодических отчетов. Кроме того, система COSTAR обеспечивала работу со специальным языком медицинских запросов MQL (medical query language), который мог использоваться для выполнения произвольных заранее не запрограммированных сложных поисков информации в базе данных системы. 6.2. Система RMRS Система RMRS (Regenstrief Medical Record System) была разработана Макдональдом и его коллегами в Медицинском центре Университета Индианы (Indiana University Medical Center). Она была введена в эксплуатацию в Мемориальном госпитале Вишарда (Wishard Memorial Hospital) в 1974 году. В 1988 году она обеспечивала ведение историй болезни более чем 250000 пациентов, из них по меньшей мере для 50000 пациентов данные существовали 9 лет и более. В этой системе хранилось более 25 миллионов записей об отдельных наблюдениях за пациентами; все эти записи были закодированы и могли выбираться в режиме оперативного доступа. Система RMRS представляла собой часть более широкой системы обеспечения административной деятельности, обеспечивавшей запись пациентов на прием и формирование счетов на оплату лечения. Уникальной функцией компонента ведения истории болезни была система выдачи напоминаний, которая активно просматривала данные пациентов и выдавала врачам напоминания, основанные на 1400 закодированных протокольных правилах. Проведенное исследование по оцениванию полезности начальной версии системы продемонстрировало, что напоминания значительно улучшили поведение врачей в части назначения необходимых лабораторных тестов и лекарственной терапии, а также в части модификации планов лекарственной терапии. Система RMRS обеспечивала диспетчеризацию записи на прием и в преддверии визита пациента выдавала три документа: 1. Отчет по оценке качества, содержащий рекомендации врачу о профилактических процедурах, которые должны быть выполнены для пациента, о проблемах пациента, на которые надо обратить внимание, а также о противопоказаниях к лекарственной терапии (см. рис. 6.16). Этот отчет по завершению визита удалялся из памяти системы. 2. Хронологический эпикриз, представляющий собой упорядоченную по датам информацию о пациенте, хранящуюся в клинической базе данных. 3. Бланк визита, представляющий собой специфический для данного пациента бланк, в который должны вписываться медицинские данные, полученные при визите пациента. Содержание бланка (списки проблем, активных лекарственных назначений, общераспространенных лабораторных тестов, а также наблюдений, которые должны быть выполнены) определялось системой в зависимости от имевшихся данных пациента по правилам, заданным врачами. По завершению визита врач заполнял дневник истории болезни, вносил изменения в список проблем, оформлял рецепты и заказы на лабораторные тесты, и все это на бланке визита. Затем оператор вводил информацию о выполненных наблюдениях в клиническую базу данных. В систему RMRS можно было в закодированном виде вводить информацию о течении заболевания и сведения из дневника; однако из-за высокой стоимости ввода данных на практике вводилась лишь малая часть этих данных. Вместо этого копия заполненного бланка визита подшивалась в бумажную историю болезни. Таким образом, система RMRS не заменяла традиционную историю болезни, но дополняла ее. Результаты лабораторных тестов и информация об отпуске лекарств получались системой RMRS от систем клинической лаборатории и аптеки. Медицинский язык запросов CARE использовался для получения выборок из файлов с историями болезни и для формирования отчета с оценками качества. Набор операторов языка CARE определял критерий поиска. Результатом выполнения запроса являлся список историй болезни, удовлетворявший критериям запроса. Результатом формирования отчета с оценками качества являлся перечень напоминаний, соответствующих критериям формирования. 6.3. Система TMR Система TMR (the Medical Record) разрабатывалась Стедом и Хаммондом в университете Дьюка с 1975 года. Первоначально целью разработки было исключение из обихода бумажной истории болезни. Поэтому разработчики системы основной акцент сделали на получение и хранение данных о лечении |
|
