You are here: Foswiki>Gnumed Web>LabImportersRu (18 Mar 2013, IvanLykov)EditAttach

Лабораторные импортеры

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

Обзор лабораторного исследования

Некоторые клинические исследования могут быть выполнены непосредственно клиницистом, например измерение роста, веса и артериального давления.

Обычно, исследования крови и мочи отправляются в диагностическую лабораторию. Лабораторные образцы (кровь, моча и т.д.) в некоторых случаях собираются специалистом, а в других - лаборантом. В Германии взятие на месте оказания медпомощи разрешает медучреждениям прикреплять подписанные этикетки на бутылки или пробирки с образцом препарата.

Понятия "назначивший" врач (специалист), копирование для врачей, идентификация пациента, дата исследования и какая-либо разновидность результата используют cовместно результаты лабораторных анализов с другими медицинскими исследованиями. В то время как результаты лабораторных анализов могут выдавать параграфы текста и действительно целые отчеты, более принято представлять числовые результаты совместно с "нормальным", "относительным" или "терапевтическим" диапазоном. Лабораторные анализы могут выполняться иногда различными аналитическими методами, которые могут дать неидентичные результаты, зависимые от метода.

Отслеживание статуса заявки

GNUmed намеревается поддерживать отслеживание "исходящих" запросов. По состоянию на 0.9 разработана таблица, содержащая их (clin.lab_requests).

Обычно, однако, прибывают нетипичные в GNUmed результаты:

  1. Лабораторные анализы в некоторых ситуациях назначаются через бумажные формы.
  2. Лабораторные анализы в других случаях (даже в том же месте) назначаются электронными запросами.
  3. Результаты могут касаться неизвестных пациентов – и анализы которых неожидаемы – для любой таковой программы медучреждения:
    • доктор вне практики может направить пациента к врачу практики, назначенному как "копировать для"
    • доктор практики может из больницы назначить анализы без записи их в программу практики
    • назначающие врачи или для копирования могут быть введены ошибочно
  4. Отправители результатов (лаборатории) плюс-минус посредник (программа-посредник данных) могут использовать различные форматы и кодировку:
    • Британская Колумбия, Канада
      • например, файлы HL7 XML-оболочки Excelleris (либо через сценарии https, либо через логин в браузере и сохранение XML-файла)
    • Германия
      • кодировка в спецификации Labordatenträger (LDT) среди протоколов DT одобрена Ассоциацией статутных немецких врачей и кратко изложена здесь
    • Австралия
      • некодируемые файлы PIT, предоставляемые отдельному пациенту, результируют в виде текста blobs (поток здесь) и поставляются зашифрованной email

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

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

Основы импортера

EMR должна:
  • иметь возможность получать и обрабатывать результаты без предварительной записи, запросив исследования
  • создавать чек из входящих результатов и
  • проставлять чек против любой существующей записи запросов/заявок

Импортеры должны:
  1. стремиться сигнализировать обработку недавно полученных результатов, либо daisy-прикованных к процессу "retriever", либо через вкладку cron с просмотром директории, либо указанием вручную
  2. стремиться дать оценку каждой строке (или сообщению) в исходном файле и обеспечить, чтобы
    • принимались только достоверные строки и сообщения (см. следующий раздел Проверка точности), и
    • те достоверные строки и сообщения, которые не могут быть привязаны к пациенту, должны быть помечены и выданы
  3. иметь возможность повтора ("повторная обработка") проблемных записей исправленных вручную

Привязка должна:
  • привести к одной из двух ситуаций -
    • либо выполняется критерий на основе правил для "адекватной привязки", когда обрабатывается полученная информация
    • либо критерий на основе правил не выполняется, когда эти сообщения остаются в clin.incoming_data_unmatched, где они могут быть обработаны администратором практики, который в подтверждение, что эти результаты должны быть импортированы, может вручную прикрепить их к пациентам (или подтвердить регистрацию новых пациентов).

Проверка синтаксической точности и регистрация успеха или отказа импортера

Должна иметься возможность обнаружить
  1. синтаксическую неточность на уровне файлов и
  2. синтаксическую неточность на уровне сообщений

Синтаксическая неточность на уровне файлов

Используя, например, Health Level 7 (HL7) файлы могут быть разделены на отдельные сообщения, каждое имеющее в качестве своего разделителя начальный <Hex 0b> и конечный <Hex 1c><Hex 0d> блоки и содержимое "foo" в следующей конструкции:

<Hex 0b> foo <Hex 1c><Hex 0d>

В первом несоответствии начального и конечного блоков файл может, по определению, быть истолкован, как "поврежденный", требующий отката. Сообщение журнала об ошибке импорта должно определять строку, в которой была отмечена неточность.

Синтаксическая неточность на уровне сообщений

Неточность на уровне сообщений в HL7 может быть определена на основе ожидаемых (действительных) ID сегмента сообщения, последовательности и длины. Как правило, если есть некоторая ошибочность в сообщениях HL7, это только одно или некоторые, а не весь пакет, поэтому нам нужно иметь возможность импортировать все, но не 'плохие' сообщения. Программы-посредники говорят нам, что они не имеют проблем со сбросом одного или нескольких отдельных присоединений после исправления любой 'неточности'.

Синтаксическая неточность на уровне сообщений должна привести к
  • сообщению журнала для ошибок импорта, в которой определяется
    • общее количество синтаксически плохих сообщений и
    • общее количество синтаксически удачных сообщений
  • элементу Входящие, обращая внимание на наличие плохих сообщений
  • плохие сообщения остаются в промежуточной таблице
  • удачные сообщения, обычно, импортируются

Журналирование неточностей

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

Здесь предлагается схема журнала импортера.

Обзор требуемой логики импортера

Вот основная идея:

  • пишет входящие данные в таблицу, которая не предполагает, собираются ли записи на сопостовляемость
    • возможно, эти данные уже были обработаны
    • возможно, лаборатория сделала нелепую ошибку и послала тонны информации о пациентах, которые 'здесь' даже неправильно получают помощь
    • возможно, файл получил повреждение при загрузке или он представляет какой-то документ текстового процессора с бессистемными вызовами
  • любые очевидные проблемы, выявляемые при попытке записи данных в первоначальную таблицу, должны быть журналированы
  • входящие данные должны быть последовательно "разбиты" на уровне "сущности пациента", одно входящее "сообщение о пациенте" на строку
  • данные необходимо оценить, являются ли они распознаваемыми
    • распознаваемость достигается за счет усилий по "привязке" к существующим пациентам и специалистам
      • в этом помогает первое заполнение "столбцов компаратора" с использованием информации, извлеченной из необработанных данных
      • "адекватная" привязка к пациенту и/или специалисту будет распознаваться, как "зеленый свет" (подтверждение) этим данным для обработки
  • даже если пациент или специалист "подразумевается" предстоящим в этой практике, имеется возможность
    • неправильно двойной обработки, или
    • наличия обновлений, которые стремятся исключить/перезаписать, возможно, ранее полученное

Британская Колумбия, Канада (программа-посредник данных Excelleris с сообщением образца)

В настоящее время имеющиеся в BC CA наиболее структурированные результаты состоят из загрузки файлов, содержащих XML-обертку, сообщений HL7 "ORU" (Результат Наблюдения), имеющих форму


MSH (заголовок сообщения, указывающий его тип),
PID (идентификатор пациента),
ORC (общий порядок, указывающий номер присоединения и TestCode) и
сегменты OBR (запрос наблюдения, содержащий административную информацию по лаборатории, образцу и врачу), следующие за нулем для многих сегментов
сегменты OBX (наблюдение/результат) и, при необходимости, после OBR и OBX,
сегменты NTE (примечания и комментарии), чье положение может идти за любым из OBR, OBX. В настоящее время неизвестно, могут ли быть ORC NTE в других реализациях.

Обратите внимание, что другие реализации не всегда могут обеспечивать ORC (то есть, могут пропускать)… см. этот пример.

Число сегментов OBX будет зависеть от того, был ли запрошен одинарный "анализ" или "панель" анализов, типа "Электролиты".

Сегмент OBX используется для передачи одного результата или его фрагмента. Он представляет наименьшую неделимую единицу отчета. Основной миссией сегмента является донести информацию о результатах в сообщениях отчета. В то время как OBR дает общую информацию о заявке на анализ, сегмент OBX дает конкретные, отдельные выполненные анализы (OBX 003) и конкретные результаты для каждого анализа (OBX 005). Сегмент OBX будет отображаться для каждого конкретного результата (или компонента "панели"), поэтому можно, в конечном итоге, несколько OBX для любой одной пары ORC OBR.

См. обсуждение обработки дублированных и обновленных сообщений ниже в разделе "Урегулирование исходного запроса".

Более полная документация исходной спецификации должна быть получена непосредственно в Excelleris. Этот раздел wiki ограничивается определением сопоставления полей и обработкой, которые крайне важны для GNUmed.

MSH|^~\&|PATHL7|BCB|HTTPCLIENT|vendor1|20071101120533||ORU^R01|MDC20071101120533673|P|2.3|||ER|AL
PID||9012345678|||EXCELLERIS^BPATIENT||19430102|F|||||(604)658-2107
ORC|RE||07-9999999-PT-0|||||||||90909^MDCARE^BOB
OBR|1||07-9999999-PT-0|PT^INR||20071009092600|20071009092600|||||||20071009092600||90909^MDCARE^BOB||079999999||07|079999999|20071010002500||HAEM3|F|||90909^MDCARE^BOB
OBX|1|NM|6301-6^INR||2.5||2.0 - 3.0||||F|||20071009134500
ORC|RE||07-9999999-CLOZ-0|||||||||90909^MDCARE^BOB
OBR|2||07-9999999-CLOZ-0|CLOZ^Clozapine||20071009092600|20071009092600|||||||20071009092600||90909^MDCARE^BOB||079999999||07|079999999|20071010002500||REFER1|F|||90909^MDCARE^BOB
OBX|1|FT|X500^Referred Test||Sent to Provincial Toxicology Centre.\.br\Telephone: 604-707-2710||||||F|||20071009092700

Импорт сообщений и установка на автоматическую и ручную привязку

Входящие данные (сообщения) должны быть записаны в clin.incoming_data_unmatched – см. спецификацию таблицы v16 до v17

Каждое сообщение должно быть развернутым XML (?) и записано по одной на строку в clin.incoming_data_unmatched с другими столбцами, заполненными следующим образом:

столбец _unmatched Номер поля для сегмента входящего сообщения (информация) Комментарии
.external_data_id   обработчик прерываний для конкретного исходника сценария hl7.py, или процедуры HAPI, или канала Mirth, который был "запущен/вызван", и который потенциально может быть "перезапущен/повторно вызван" после ручной привязки
.type   значение 'HL7'
.data непроверенные данные столбец bytea… сохраняет vs лента XML?
.error_info   новый столбец
.firstnames PID 005 (имя пациента:последнее^первое^среднее [как в программе-посреднике]) извлечение первого^среднего и пробела-разделителя для составных слов
.lastnames PID 005 (имя пациента:последнее^первое^среднее [как в программе-посреднике]) извлечение 'последнего'
.dob PID 007 (дата рождения YYYYMMDD [если неизвестно - null])  
.gender PID 008 (секс/пол пациента М/Ж/Н-неизвестно) пропущен, если 'Н'
.postcode    
.other_info PID 002 (внешний ID пациента/персональный медицинский номер BC [PHN], если известен) +
PID 003 ( Addn Patient ID / дополнительный идентификатор пациента – неуникальный MRN) +
PID 004 (альтернативный внешний ID пациента/например, номер карты) +
PID 013 (домашний телефон/может быть частично и неправильно отформатирован)
 
.request_id ORC 003 (Номер заявки наполнителя/Номер ID заявки для выполнения лабораторного анализа или присоединения кода тай-брейка к номеру анализа)  
.requestor ORC 12 (назначивший специалист), OBR 028 (копировать результат для) см. #AutoMatchProvider
.fk_identity_disambiguated   dem.identity.pk (авто- или ручная привязка)
v16 .fk_provider_disambiguated   fk к dem.staff.pk (авто- или ручная привязка)
.comment    

Автопривязка…

Планируется в GNUmed

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

автопривязка к имеющемуся пациенту

Имена крайне сложно сравнивать…
  • неправильная транскрипция
  • несколько фамилий (незамужние и замужние)
  • несовместимое использование пациентом имен/среднего имени/"прозвища"

GNUmed собран с поддержкой для любого одинарного dem.identity (индивидуального), несколько dem.names может быть противоречиво. Для некой загрузки, на которой был построен нижеуказанный алгоритм, обратитесь к этому обсуждению. Информацию о cPatientSearcher_SQL() см. в этом обсуждении.

Критерий авто-привязки:

  • входящий личный медицинский номер (уникальный в BC), в сочетании с
    • привязкой, по крайней мере, на одно из:
      • д/р в GNUmed dem.identity.dob
      • имя пациента:последнее в GNUmed фамилия
  • входящее д/р в GNUmed dem.identity.dob вместе с
    • имя пациента:последнее
    • вместе с…
      • любыми первыми-2 символами имя пациента:первое^среднее в GNUmed firstnames
        • наряду с полом (где входящий пол является 'М' или 'Ж', но не 'Н')
  • в будущем: clin.lab_requestпонадобится обмозговать

разрешение вышеуказанного:

  • если уникальное соответствие достигается через любой из вышеперечисленного, то .fk_identity_disambiguated обновляется с использованием dem.identity.pk
  • если находится несколько соответствий, то .fk_patient_candidates integer[] обновляестя с ?? Карстен
  • если соответствие не достигается… (оставьте в покое или входное значение 0)?

Полезные поля из импортированных сообщений HL7 посредством Excelleris:
HL7 поле исходные записи поле GNUmed
PID 002 Номер ID/PHN внешнего пациента [null, если неизвестен] dem.lnk_identity2ext_id, где dem.enum_ext_id_types.name = 'Персональный медицинский номер и dem.enum_ext_id_types.name = 'BC.CA_MSP'
PID 007 Дата рождения YYYYMMDD [null, если неизвестна] dem.identity.dob
PID 005 Имя пациента Последнее^Первое^Среднее [как предоставлено] компонент 1(последний): dem.names.lastnames; компонент 2 (первый) и 3 (средний): первые 2 символа любого firstnames в GNUmed
PID 008 Пол пациента Ж/М/Н - неизвестен dem.identity.gender, но игнорирует входящее значение "Н"

Цели для привязки (из имеющихся записей GNUmed):
таблица столбцы комментарии в GNUmed
dem.lnk_identity2ext_id external_id привязанный из id_identity < 10-значное значение, представляющее PHN пациента >
dem.identity field: pk integer
dem.identity д/р, пол используется to_char(foo, 'YYYYMMDD') , upper(substring(foo for 1))
dem.names lastnames, firstnames используется upper(foo)
dem.enum_ext_id_types отправитель 'BC.CA_MSP'
dem.enum_ext_id_types имя 'Персональный медицинский номер'

автопривязка к практикующему специалисту или – если пациент уже известен как действительный (привязан к практике) – назначение специалиста

В GNUmed все специалисты - это физические лица в dem.identity, имеющие одно или несколько имен в dem.names и от нуля до нескольких внешних ID, типа нормативного "номера врача" в dem.lnk_identity2ext_id, и, наконец, запись в dem.staff. В то время, как dem.staff_role , обычно, принадлежит "врачу", другие обозначения практиков могут быть у действительных назначающих специалистов, и, поэтому, привязки не должны требовать никакого отдельного staff_role.

Привязку можно найти через синтаксический анализ кодов и имен специалистов из конкатенации HL7 ORC 12 (назначающий специалист) || HL7 OBR 028 (копировать результат для), где каждый форматируется как = биллинговый номер BCMSP (если уже известен '00000')^LastName^FirstName^Middle Name= в
  • dem.lnk_identity2ext_id из подходящего внешнего типа id, соединенного с dem.identity и где dem.identity.pk имеется в dem.staff.fk_identity
  • или lab_request.fk_requestor ( будущая функциональность GNUmed )

из которых привязывается для извлечения dem.staff.pk.

Когда привязка на специалиста не была создана, но там, где пациент имеет автопривязку или вручную, ответственность по проверке результата должна быть присвоена к
  • значению пациента для dem.identity.fk_primary_provider (практикующий лечащий врач для данного пациента), или если нет…
  • результату SELECT value FROM cfg.v_cfg_opts_numeric WHERE option = 'patient.fallback_primary_provider' (если настроено)

Последний будет устанавливаем с помощью пользовательского интерфейса, через меню GNUmed > Предпочтения > EMR > Лечащий врач = ( который является значением =pk в Dem.staff).

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

Потребуется регистрация нового пациента:
таблица столбцы комментарии в GNUmed
dem.identity field: pk integer --> получается автоназначением
dem.identity dob, gender используйте to_char(foo, 'YYYYMMDD') , upper(substring(foo for 1))
dem.names lastnames, firstnames, id_identity, comment, id_identity является dem.identity.pk, подобный комментарию 'импортировано из названия организации'
dem.enum_ext_id_types issuer 'BC.CA_MSP'
dem.enum_ext_id_types name 'Персональный медицинский номер'
dem.lnk_identity2ext_id external_id, id_identity, fk_origin <10-значное значение, представляющее PHN пациента>, dem.identity.pk, dem.enum_ext_id_types.pk, где отправитель, имя…

Начать транзакцию в привязке…

назначение статуса заявок в этом сообщении и их связанных результатов

Каждое сообщение, инициированное MSH, несмотря на то, что оно касается только одного пациента, может в какой-либо одной загрузке содержать одну или несколько пар последовательности кода ORC OBR анализов, а также ноль или более OBX. Следующее сообщение MSH по этому же пациенту может содержать все, некоторые или ни одной из пар ORC OBR предыдущей заявки, а также некоторые, ни одного или все предыдущие сегменты OBX. Таким образом, в целом это не MSH, который должен быть отслежен.

Внутри каждого сообщения MSH это пара {ORC OBR} заявки, которая будет узнаваемо и уникально идентифицироваться каждый раз, когда приходит через:
  • Уникальность, определимую сочетанием Отправляемого объекта (MSH 004) и Номера наполнителя заявки (ORC 003)
  • Уникальность аналогична определяемости через сочетание Отправляемого объекта (MSH 004) и Номера наполнителя заявки в OBR (OBR 003), подобно, когда предоставляются и ORC и OBR, должны совпадать ORC 003 и OBR 003.
  • Любое приращение OBR 022 (MSH 004, ORC 003, OBR 022) потребует, чтобы любые и все связанные OBX, которые были ранее записаны в clin.test_results, должны быть перезаписаны, новый результат OBX вставлен и переназначен по специалисту.

Каждый новый (MSH 004, ORC 003), поэтому, должен проверяться на наличие значений в clin.lab_request и
  1. где он еще не существует, должен быть добавлен новый запрос и
  2. где он уже существуют, проверен, не новее ли входящий OBR 022,
    1. если входящий OBR 022 новее, удаляет все существующие строки, связанные с test_results, в lab_request.pk для этого (MSH 004, ORC 003)
  3. и в любом вышеуказанном случае, импортировать каждый из связанных сегментов OBX

Каждый ORC приведет ровно к одному дочернему OBR. Каждый OBR наследует и несет информацию, которая поставлялась либо непосредственно, как часть первоначальной заявки (например, инструкций, подобных специалисты copy-to), либо как информация, возникающая вследствии заявки (например, характер, что было назначено определять, какому отделу диагностической службы в лаборатории выполнять исследования).

Excelleris добавляет каждый "результирущий" OBX – как только он получен из лаборатории – во "встроенное" сообщение. До тех пор, пока последний компонент запроса не завершится, каждая загрузка результатов этого запроса будет включать все ранее построенные результаты OBX для этого запроса. Невозможно надежно связать уже полученные сегменты OBX из недавно полученных сегментов по следующим причинам:
  1. уже посланные результаты OBX получают повторно включенные с новыми, первичными результатами OBX, однако
  2. значение в OBX 001 (числовой счетчик) позднее не имеет гарантированного постоянства обновленных передач под включающими сегментами ORC OBX. Независимо от того, какой был OBX, например, ранее первый среди сегментов OBX может не быть первым в последующих сообщениях… любая характеристика OBX 001, подобно "Уникальный порядковый номер", верна в пределах любого экземпляра сообщения, просто это непостоянно
  3. несмотря на то, что метка даты-времени OBX 014 для исследования в лаборатории не изменилась, не ясно, насколько безопасно делать предположения о возможности оставления как есть какого-либо одного OBX, когда изменены другие элементы внутри этого ORC OBR.

К счастью, несмотря на то, что любая "заявка" на какого-либо больного может получить разбиение на несколько ORC (назовем их ORC1 и ORC2, несмотря на то, что нет надлежащей номенклатуры), большинство лабораторий отделит их частичное или полное оповещение дробно через {ORC OBR}. Многие даже не потрудятся сообщать какой-либо OBX внутри {ORC OBR} до тех пор, пока все составные OBX не станут доступны. Таким образом, например, панели анализов, необходимой для ORC2, потребуется 3 исследования {a, b, c} для выполнения

Лаборатория A не выдаст ORC2, пока не будут доступны все {a,b,c}:

MSH PID ORC1 OBR1 нет OBX (статус ожидающих)
ORC2 OBR2 OBX2a OBX2b OBX2c (финальный)

Лаборатория B вызывает приготовления внутри ORC, например …

MSH PID ORC1 OBR1 OBX (F = завершенный)
ORC2 OBR2 OBX2a OBX2b (P = предварительный)

и следует ему позже с более полным окончательным сообщением …

MSH PID ORC1 OBR1 OBX (F = завершенный)
ORC2 OBR2 OBX2a OBX2b OBX2c (F = завершенный)

не касаясь метки datetime (в первых OBR - OBR 022). Лаборатория B обновит OBR 022 только в задействованном OBR.

Обе лаборатории, и A, и B, допускают практике необходимость подписания результата OCR1 OBR1 только один раз.

Лаборатория A не предоставит результаты второй панели, до тех пор, пока они не заполнены, так что они также должны подписываться однократно. Лаборатория B, с другой стороны, обеспечит более ранние частичные результаты для этой второй панели (исследования OBX2a и OBX2b), однако, практике следует предпочесть удалить их и заменить на OBX2a и OBX2b, которые будут посланы с исследованием OBX2c, как часть окончательного отчета, и которые понадобится подписать только однократно. Альтернативой может быть примирение с несколькими копиями OBX2a и OBX2b, но может быть проблемой ситуация, когда лаборатория позднее запрашивает исправленные результаты, которые не согласуются с ранее предоставленными.

В BC CA
  • большинством лабораторий принят метод лаборатории A, за исключением
  • микробиологические результаты, обычно рассматриваемые в варианте лаборатории B с подготовкой и затем завершением, как известно, после уточнения вида, чувствительности и устойчивости
  • имеется один вариант "Лаборатории C", которая все время обновляет OBR 022, распространяет это обновление для других OBR в рамках этого же присоединения, несмотря на то, что ни один OBX в этих других парах OBR ORC не изменился!

Предлагаемая обработка таблицы clin.lab_requests
столбец lab_requests используемый наполнитель комментарии
.clin_when OBR 007 (наблюдение даты-времени) Временная метка YYYYMMDDHHSS взятия образца, если известно время, и YYYYMMDD, если время неизвестно
.fk_encounter   автоматически генерируемое обращение типа "лабораторное обращение"
.fk_episode   clin.episode.pk для существующего неотмеченного "лабораторного случая", также автоматическое создание
.narrative    
.soap_cat   DEFAULT 'p'::text
.pk   первичный ключ (автоматически назначенный)
.request_id   (будущее) исходящий маркер GNUmed, поддерживаемый в ORC 002 (Прикрепляемый номер заявки) – неиспользуемый в Excelleris
.fk_test_org MSH 004 (отправленный объект) привязан или создан автоматически
.fk_requestor   (если вычислимо) pk назначившего специалиста
.lab_request_id ORC 003 (Номер заявки наполнителя/Номер ID заявки для выполнения лабораторного анализа или присоединения кода тай-брейка к номеру анализа)  
rename .lab_rxd_when OBR 014 (временная метка даты получения образца) переименовать столбец lab_rcvd_when
.results_reported_when OBR 022 (временная метка изменения статуса отчета) это значение позволяет определить, не переработан ли результат, и не изменился ли он
.request_status OBR 025 (статус результата) I = в ожидании
P = предварительный,
F = завершен,
C = исправлен,
X = удален (по запросу; не всегда предшествует не-X OBR в более ранней передаче)
.is_pending   Если в [F,C] имеется request_status, то true, в противном случае - false
.diagnostic_service_section OBR 024 (отдел диагностической службы)  
.ordered_service OBR 004 (универсальный ID службы) Код анализа^Название анализа
v16 .note_test_org данные NTE удерживает содержимое NTE, касающееся модификаций заявки

UNIQUE {.fk_test_org .lab_request_id}

Дополнительные примечания

  • в будущем : без автоматического создания, если lab_requests уже имел что-либо отложенное для этого пациента под этим запрашивающим специалистом (оценка данных fk_requestor в данных ORC 12 "Назначающего специалиста"). В случае привязки это отложенный запрос может быть обновлен вместо автоматического создания новой записи.

импорт ± исправленные/замененные результаты анализов

clin.test_result источник значения примечания
fk_request clin.lab_request.pk нужен как fk, через который заменять промежуточные результаты с выполненными/исправленными результатами, где применимо
fk_type clin.test_type.pk если существует, все еще проверить для обновления комментария из OBR NTE 003
в противном случае автогенерация  
fk_encounter clin.lab_requests.fk_encounter  
в противном случае автогенерация  
fk_episode clin.lab_requests.fk_episode  
в противном случае автогенерация  
clin_when OBR 007 (наблюдение даты-времени) Временная метка YYYYMMDDHHSS взятия образца, если известно время, и YYYYMMDD, если время неизвестно
val_num OBX 005 (Результат) если OBX 002 (Тип значения) == NM
val_alpha OBX 005 (Результат) если OBX 002 (Тип значения) == FT
val_unit OBX 006 "Единицы измерения"  
val_normal_range OBX 007 (Ориентировочный диапазон)  
abnormality_indicator OBX 008 (Флаги отклонения от нормы)  
note_test_org OBX NTE 003 (Комментарий)  
fk_intended_reviewer ORC 12 (назначивший специалист), OBR 028 (копировать результат для) см. выше Автопривязка к специалисту/предполагаемому рецензенту

Как отмечено в разделе назначение статуса заявки в этом сообщении и их связанных результатов, может понадобится удаление некоторых результатов анализов, если они получают одно или несколько новых значений.

регистрация любого отсутствующего типа анализа

clin.test_type источник значения примечания
fk_test_org clin.test_org.pk  
в противном случае автогенерация  
code OBX 003 (идентификатор наблюдения) подстрока 1 код LOINC
name OBX 003 (идентификатор наблюдения) подстрока 2 Имя результата
coding_system "LOINC" фиксированная строка; информация о версии ?
conversion_unit OBX 006 (Единицы измерения) в Канадском SI позже проверяет в таблице ref.units table

регистрация любой отсутствующей лаборатории (исследовательской организации)

  • проверяет, существует ли уже в GNUmed объект, предоставляющий анализ (лаборатория
    • MSH 004 ("отправляемый объект", например, BCB MDS VCH)
    • проверяет, не противоречит ли MSH 004 в clin.test_org, где dem.org_category.description = 'Лаборатория'
    • если она отсутствует, то автоматически создает ее и назначает dem.org_category.pk, где dem.org_category.description = 'Лаборатория'

  • задает это значение ключа организации clin.test_org.pk в fk_test_org для lab_requests (требуется для управления ORC 003)

регистрация – если еще нет в сессии – обращения типа "импорт данных" и присоединение к результатам

Когда результат данного анализа не имеет соответствующего запроса лаборатории (которая в CA будет true, за исключением случаев, если уже создан в предварительном импорте результата, который теперь повторно отправлен):

  • добавляет в clin.encounter запись, имеющую clin.encounter_type.description = 'импорт данных'
  • повторно использует pk из clin.encounter.pk для каждого результата, импортированного для этого пациента во время этого импорта/сессии

регистрация – если еще нет для пациента – случая с названием "полученная информация" и присоединение к результатам

Когда результат данного анализа не имеет соответствующего запроса или получения лаборатории:

  • проверяет наличие пациента, неотмеченного случая, когда описание имеет 'полученную информацию',
  • если необходимо создает его в clin.episode
    • fk_health_issue = NULL (непомеченный)
    • description = 'несвязанные лабораторные данные'
    • is_open = FALSE

… конец транзакции

Blueprint для кода этого импортера

Обратитесь к теме LabImporterBC вики

Уведомление через почтовый ящик клинициста (автоматически)

Код GNUmed автоматически заполнит (виртуально) входящие сообщения для врачей на основе значений в clin.test_result.fk_intended_reviewer to .

Когда пациенты в неактивном состоянии в медучреждении…

В идеале, не будут получены результаты на не-пациентов (неактивных). Однако, учитывая получение результатов, может быть разумным их импортировать. Варианты для эффективной обработки могут включать:

  • когда статус пациента "неактивен" (для которого отсутствует функциональность GNUmed 0.9x):
    • импортировать их, только когда специалист практики был назначившим
    • автоматически отмечать такие результаты на виртуального клинициста
    • сохранять результаты таких пациентов в таблице "непривязанное" или
    • в противном случае, распоряжаться ими.

Предыдущие заметки и комментарии (некоторые могут быть больше неприменимы)

Ситуация с избыточными сообщениями (дубль/обновление)

вот как правильно выполняются идентифицированные компоненты сообщения (PID, OBRs+ORCs, OBXs, связанные с парами OBR-ORC:

  • пациент идентифицируется, как описано выше.
  • лаборатория отыскивается или регистрируется автоматически
  • clin.encounter и связанный с ним лабораторный запрос отыскивается через ORC 003 filler_order_code или авторегистрируется)
    • на самом деле, вышеуказанное должно быть MSH 004 + ORC 003 и эта модификация учтена в абзацах ниже
  • clin.test_result отыскивается на:
    • dem.identity id пациента
    • clin.encounter id
    • lab test_org id
    • ORC 003 filler_order_code
    • OBX 003.1 LOINC код LOINC и описательное имя OBX 003.2 descriptive name
    • OBX 004 sub-id если он имеется

более ранняя тема здесь Избыточные сообщения (дублированные).

примечания:

  • бегло были изучены файлы XML-спецификации mirthcorp для "наблюдения отчетов" и найдены, всегда содержащими иерархию OBR-OBX (для наблюдаемых отчетов)
    • --> исправлен
  • поэтому, было логически заключено, чтобы не получить когда-либо OBX, имееющий OBR без связи с filler_order_code.
    • --> исправлено
  • clin.encounter является в настоящее время методом, через который ORC связан с его OBXs. одно сообщение HL7 может содержать несколько ORC; один ORC может иметь несколько OBX. Не существует никакого другого метода, через который ORC могут быть связаны с OBX; таким образом, в ORC требуется единственный новый и уникальный clin.encounter. Это должно быть решено путем добавления fk_lab_request (по умолчанию NULL) в clin.test_result.
    • --> исправлен fk_lab_request (но NULL не по умолчанию, вместо последовательного)
  • "current_encounter" не может использоваться, если уже имеет существующий clin.lab_request, связанный с ним, кроме случаев, когда сообщение HL7 может быть определено, как в любом случае связанное с обращением в силу ORC 003 filler_order_code
    • --> не уверен в этом * OBX 004 sub-id был добавлен к имени типа исследования, чтобы отличить его от других "исследований". например, "X10011^ Комментарии патологии" плюс sub-id из 1 рассматривается, как тип отдельного исследования из точно такого же кода LOINC, плюс имя и sub-id из 2, через добавление "пробела (1)" к первому и "пробела (2)" ко второму. Таким образом, OBX гарантированно уникальный. Это меньше, чем идеал: идеально поле sub-id с именем "test_type_sub_id", как текстовое (не числовое, на всякий случай) - должно быть добавлено к clin.test_result.

СПИСОК ЗАДАЧ - также следует просмотреть

  • прекратите использование clin.encounter, как средство, обеспечивающее связь clin.lab_request с clin.test_result, используйте clin.test_result.fk_lab_result
    • это можно теперь сделать (июль 2011), так как теперь имеется clin.test_result.fk_lab_result
  • место OBR 002 (монтажник не наполнитель) в поле комментария для clin.lab_request (и вероятно также ORC 002)
  • используйте OBX 014 в clin.test_result и "обновление метки времени" в clin.lab_request, обновите его, когда последнее сообщение HL7 ничего не перезаписывает. В идеале/удобнее timestamp должна быть заполнена с соответствующей меткой времени сообщения HL7 (решается). Кто-нибудь имеет какие-либо предложения? MSH 007 - дата/timestamp сообщения озвучено достаточно хорошо?)
  • при "слиянии пациентов" используйте набор ключей (см. выше) для слияния clin.lab_requests и clin.test_results на основе ранее упомянутого поля "последнее обновление"
  • добавьте
    • таблицу clin.imported_data_matched, в которую перемещаются необработанные данные HL7 (из clin.imported_data_matched).
    • таблицы многие-ко-многим (pk fk_imported_data_matched fk_lab_request), а также многие-ко-многим (pk fk_imported_data_matched fk_test_result)
    • --> не думаю, что это необходимо -- Джим
Topic revision: 18 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark