В мире медицины практикующиеся врачи думают не только в

Онтология входных типов
В мире медицины практикующиеся врачи думают не только в терминах 5 классов данных,
соответствующих подтипу входа, описанному выше. Существует много подтипов каждого такого типа,
некоторые из них показаны на рисунке 1.
Записываемая
информация
Административная
информация
Информация по заботе
мнение
История
Наблюдение
Действие
Диагноз
Инструкция
Предложение
Обложение
Риск
Прогноз
Просьба об
исследовании
Просьба о
вмешательстве
Цель
Реккомендац
ия
Сценарий
Рисунок 1– онтология записываемой информации
Связанное с
наблюдением
Связанное с
вмешательством
Ключевые категории (верхний уровень): информация о заботе и административная информация.
Они окружают все утверждения, которые могут быть записаны в какой-нибудь пункт в течение
процесса заботы и состоят из более важных подкатегорий, на которых базируется Entry модель,
называемые «наблюдение», «мнение», «действие» и «инструкция» (тип наблюдения), которые
соответствуют прошлому, настоящему и будущему во времени. Категория «административная
информация» охватывает (покрывает) информацию, которая не производится в процессе заботы, а
относится к его организации, к таким пунктам, как приемы и выходы. Это информация не о заботе, а о
последовательности предоставления заботы.
Несмотря на разнообразие, каждая из категорий последнего уровня показывает в конечном счете
на этой фигуре (рисунок 1) подкатегорию одного из типов модели процесса и, следовательно, подтипы
openEHR Entry модели.
Корректное (правильное) представление о категориях из онтологии возможно с использованием
архетипов, предназначенных для точного выражения интересующей информации в терминах
определенных подтипов Entry модели (в этом случае, оценка). В системе, где поэтому входы
моделируются, не возникнет опасности некорректной идентификации переменных классов входов,
настолько долго, пока входные подтипы, время и уверенность/отрицание принимаются в расчет.
Примечательно, что если даже онтология на рисунке 1 не корректна (несомненно это не так), прототипы
будут созданы в расчете для каждой идеи улучшения того, что таких категории действительно должны
быть.
Утверждение и отрицание статуса.
Хорошо известная проблема при записи информации (в медицине) – это назначение так
называемого статуса записываемой статьи. Классы статуса включают такие варианты как
«действительное значение P» (P символизирует некоторое явление), «история возникновения (family
history) P», «риск P», «опасение P», вдобавок еще и отрицание их: «не P», «отсутствие истории P» и т.д.
Надлежащий анализ этих так называемых статусов показывает, что они не являются статусами в полной
мере, но являются различными категориями информации по онтологии на рисунке 1. В общем (в целом)
отрицания управляются с использованием «исключительных» подтипов для соответствующего
входного типа. Например, «отсутствие аллергии» может быть использовано для оценки подтипа, что
описывает, какая аллергия исключена для данного пациента. Другое направление типов утверждений,
которые может быть спутано в системах, которое делает неправильной модель категорий информации
касается вмешательства: например, «замена бедра (5 лет назад)», «замена бедра (рекоммендованна)»,
«замена бедра (зарезервировано на следующий вторник на 10 часов утра)».
Все эти типы утверждений отображаются непосредственно на один из openEHR входных типов в
недвусмысленном (однозначном) стиле (смысле), гарантируя, что вопросы (непонимания) по EHR не
связаны с некорректными данными, такими как утверждения о риске или опасении, когда сомнение
возникло по поводу наблюдения явления in question.
Дальнейшие детали openEHR модели медицинской информации даны в документе EHR IM, Entry
Section.
Управление вмешательством
Ключевая часть исследования показана на рисунке 2 и действительно забота о здоровье в целом –
это вмешательство. Специфика и управление вмешательством – это сложная проблема для
информационных систем, потому что это в «будущем времени» (это значит, что действия по
вмешательству должны быть выражены с использованием разветвленных/петлистых спецификаций
времени, не просто линейное время обследования), неожидаемые случаи могут изменить вещи
(например, пациент реагирует на таблетки) и статус оказываемого вмешательства может быть трудно
определяем, в особенности в распределяемых (нных) системах. Однако тем не менее, с
профессиональной точки зрения (по здоровью), почти ничего более важного (основного) нет, чем
желание обнаружить: какие медикаменты этот пациент принимает, с какого времени и какой прогресс
(как продвигается процесс лечения)?
openRHR подходит к этим требованиям для использования Entry типа «инструкции» - это подчасть
«действие» для специфического вмешательства в будущем, и Entry подтип «действие» для записи того,
что действительно случилось. Число важных особенностей предусмотрено в данной модели, включая:
 Единственный, гибкий путь моделирования всех вмешательств
 Способ восприятия любого вмешательства в терминах состояний в стандартной машине
состояний (автомат состояний), показанного на рисунке 2. Это позволяет запрашивать EHR
пациента стандартным способом, как например, показать «все активные процессы лечения»
или «все приостановленные вмешательства».
 Путь отображения особенностей процесса лечения по шагам в стандартной машине
состояний, позволяя медицинским специалистам определять и представлять вмешательства
в понятных им терминах.
 Поддержка автоматического технологического процесса, без запроса на его работу.
В связи с исчерпывающими (всесторонними) возможностями openEHR, конструкция
Действие/Инструкция позволяет медицинским работникам, которые работают с записями, определять и
управлять вмешательствами для пациентов в распределенной среде.
Приостано
вленные
отсроченн
ые
Истекшие
во времени
Занесенные в
расписание
выполне
нные
Предварите
льные
Планируем
ые
Отмененн
ые
Активные
«выкину
тые»
Рисунок 2
Blue: нормальное состояние изменяющегося события
Dark blue: нормальное отсутствие состояния изменяющегося события
Green: связанные планируемыми переходами
Red: события с истекшим сроком
Magenta: после окончания срока события
6.6 Время (период) в EHR
Время хорошо известно как требующая моделирования проблема в информации о здоровье
пациентов. В openEHR, периоды, которые являются побочными продуктами процесса обследования
/исследования (например, период взятия выбора, отбора или собирания, период измерении, период
активного события по заботе о здоровье пациента) и описаны ранее, реально смоделированы, в то время
как другие периоды, специфицированные на частичное удовлетворение (например, дата приступа
болезни, дата анализа) смоделированы с использованием прототипных общих атрибутов данных.
Следующая фигура показывает типичную взаимосвязь между периодами касательно процесса
наблюдения и соответствующие атрибуты внутри openEHR модели. Примечательно, что чем ниже
различные сценарии действий, такие как GP консультация, рентгенологический отчет и другие,
временные взаимоотношения тем они могут быть достаточно разными, чем указаны на рисунке 3.
Период описан в деталях в документе EHR Information Model.
Событие на текущий момент
период проб/сбора
период измерений/составлений
информации
отчетов
наблюдение
действия в
реальном
времени
событие по заботе о здоровью
рассмотрение
входная информация
запись
структура
openEHR
наблюдение
задержка записи
при необходимости
структура
интерпретация
Рисунок 3
6.7 Язык
В некоторых ситуациях, возможно наличие более одного языка, используемого в EHR. Это может
возникнуть вследствие того, что пациенты в процессе лечения пересекают границы (общее между
скандинавскими странами, между Бразилией и ее северными соседями) или находясь в путешествии они
лечатся, или вследствие того, что различные языки буквально используются в домашних условиях.
Язык управляется как указано ниже в openEHR EHR. По умолчанию язык для EHR назначается
локальной операционной системой. Он может быть подключен в объекте EHR_status, если это
необходимо.
Язык обязательно должен быть указан в двух местах в данных EHR а именно в «структуре» и
«входах», в атрибуте «язык». Это разрешает оба состава различных языков в EHR и входы различных
языков в том же составе. Дополнительно, в пределах входов, текст и закодированные элементы текста
могут иметь закодированный язык, если он отличается от языка,? включающего в себя входы или где
эти типы используются в пределах структур, не являющихся входами, которые не указывают на язык.
По большей части вероятно, использование этих особенностей происходит благодаря переводу,
хотя в некоторых случаях по настоящему многоязыковое окружение, возможно, существовало бы в
пределах клинического контекста столкновения (encounter). В смоделированном (former) случае,
некоторые части EHR, например специфические Составы, будут оттранслированы перед или после
клинического столкновения (encounter) относительно представления информации доступной на
первоначальном языке EHR. Акт перевода (подобно любому другому взаимодействию с EHR) вызовет
изменения записи, в форме новых Версий. Новые переводы могут быть удобно записаны как
ответвляющиеся интерпретации (versions) , привязанные к интерпретации (versions), из которой они
переведены. Это не обязательно, но обеспечивает удобный путь запоминания переводов так, что они не
заменяют оригинальное содержимое.
7 Безопасность и Конфиденциальность
7.1 Требования
Защита от несанкционированного доступа, конфиденциальность и согласие
Защита от несанкционированного доступа (право на ограничения доступа к личным данным) и
конфиденциальность (обязанность других уважать защиту открытых данных) – первоочередные задачи
многих клиентов относительно систем Здравоохранения. Широко общепринятый принцип состоит в
том, что информация, обеспечиваемая (или непосредственно, или благодаря наблюдению или проверке
образцов, и т.п.) доверием пациентов к работникам медицины в течение периода заботы, должна быть
только принята или иначе становится доступной другим группам (parties), если пациент
согласный; определим проще: совместное управление должно контролироваться на основе согласия
пациента. Более сложное подтребование для некоторых пациентов позволяет отличительный доступ к
частям их оздоровительной записи, например, относительно открытые права доступа к большинству
оздоровительных записей, но ограниченный доступ к половым или умственным оздоровительным
элементам. Взаимосвязанность оздоровительной информации может сделать это труднее. Например
список по лечению будет часто выдавать чувствительные условия, даже если диагноз скрыт еще он
нуждается в каком-то безопасном режиме, и много работников медицины - профессионалов видели бы
отсутствие информации о текущих лечениях (и аллергиях), которая чрезвычайно проблематична для
предоставления основной заботы.
Требования Поставщиков Здравоохранения
С другой стороны, медики-профессионалы, предоставляющие заботу по здоровью, хотят
быстрого доступа к необходимым данным, и должны быть уверенными, что то, что они видят на экране
- верное представление того, о чем сказал пациент. Аварийный доступ к оздоровительным записям
иногда требуется сиделкам ? по-другому несвязанным с нормальным уходом за пациентом; такие
доступы могут разрешаться только в общем случае, начиная со специфических поставщиков, которые
обычно не изветсны(involved will not usually be known).
Исследователи в здравоохранении как правило хотят доступа к данным больших номеров
пациентов для того, чтобы оценить текущую заботу и улучшить ее (клиническое открытие знания), и
для образовательных целей.
? – это несогласованность предложения,
группам – это неуверенность в переводе