Данная небольшая статья написана как комментарий к моей предыдущей статье, в частности в той её части, где BC Holmes рассуждает, что «один из способов количественной оценки сложности HL7v3 в подсчёте уровней вложенности типичного сообщения. Оно, как правило, имеет в 5-10 раз больше XML узлов, чем любые другие стандарты основанные на XML, такие как Interactive Financial eXchange (IFX) или Amazon EC2 SOAP API. Кто-то может сказать, что бизнес процессы в здравоохранении существенно сложнее и семантически богаче, чем в финансовой области и, тем более, в книгоиздательстве.»
Вот как раз рассмотреть один типичный процесс в здравоохранении и хотелось бы, дабы удостовериться, действительно ли он сложнее и семантически богаче, чем в финансовой или книгоиздательской деятельности. Благо и наглядный материал также подвернулся.
В данном случае будет рассматривать работу хирургического отделения на примере набора информационных сообщений для поддержки одной единственной хирургической операции. О типе операции и её сложности ни чего не сообщается, т.е. возможны отклонения в любую сторону сложности.
Предоперационный период
Предоперационный период — время, необходимое для подготовки больного к операции. Длительность предоперационного периода зависит от степени срочности операции, состояния больного, его возраста и тяжести предстоящего оперативного вмешательства. Информационные потоки в предоперационный период показаны на следующей диаграмме.
Условно информационные потоки можно разделить на следующие группы и соответствующие им HL7v2 сообщения или шаблоны документов CDA (в скобках даются типы сообщений HL7v2 и их краткая расшифровка):
• Регистрация Пациента (ADT),
• Контроль листа ожидания (SIU — Изменение расписания),
• Данные по пациенту (MDM – Управление мед документами, CCD, CDA Referral Summary),
• Результаты лаб анализов (ORU – Результаты обследования, CDA для HITSP C37 Lab Report Document)
• Уведомления (MFN — Изменения в нормативно-справочном файле)
Операционный период
Информационный поток для операционного периода представлен на следующей диаграмме.
Для передачи информации используются следующие HL7v2 сообщения:
• Использование материалов (DFT – Детальная финансовая транзакция)
• Результаты лаб анализов (ORU – Результаты обследования, CDA для HITSP C36 Lab Result Message)
• Данные с мед аппаратов (ORU — Результаты обследования)
Послеоперационный период
Послеоперационный период — время от момента снятия больного с операционного стола до заживления раны и исчезновения расстройств, вызванных операционной травмой. Информационные потоки в предоперационный период показаны на следующей диаграмме.
Для передачи информации используются следующие HL7v2 сообщения:
• Данные с мед аппаратов (ORU — Результаты обследования)
• Данные по пациенту (MDM – Управление мед документами, CCD, CDA Referral Summary),
• Финансовые расходы (DFT – Детальная финансовая транзакция),
• Использование материалов (MFN — Изменения в нормативно-справочном файле).
Кроме вышеперечисленных сообщений, хирургу (точнее ИТ-отделу, ответственному за интерфейсы) приходится думать о работе систем в соответствии со следующими стандартами:
• IHE ATNA – Audit Trail and Node Authentication
• HITSP T15 — Collect and Communicate Security Audit Trail Transaction
• HITSP T17 – Secured Communication Channel Transaction
• IHE XDS.b – Cross-Enterprise Document Sharing-b
• HITSP T13b — Manage Sharing of Documents
Вышеприведённые сообщения и прочие стандарты описаны в следующих профайлах IHE (Integrating the Healthcare Enterprise):
• Patient Care Device;
• IT Infrastructure;
• Patient Care Coordination.
Ну и теперь возвращаясь к началу этой статьи, я не понимаю, почему специалисты IFX или Amazon EC2 SOAP API не могут дружно ужиться с HL7, там вроде всё достаточно просто.
:)
Также хотелось бы добавить суждение по поводу HL7 FHIR. Из всего вышеприведённого, тестовые FHIR сервера пока что возятся с функционалом равным ADT и SIU сообщениям. Вполне вероятно, что есть более продвинутые реализации (по крайне мере одну такую я знаю), но их создатели пока что не торопятся выступать открыто и выложить на суд публики особенности реализации.
Вот как раз рассмотреть один типичный процесс в здравоохранении и хотелось бы, дабы удостовериться, действительно ли он сложнее и семантически богаче, чем в финансовой или книгоиздательской деятельности. Благо и наглядный материал также подвернулся.
В данном случае будет рассматривать работу хирургического отделения на примере набора информационных сообщений для поддержки одной единственной хирургической операции. О типе операции и её сложности ни чего не сообщается, т.е. возможны отклонения в любую сторону сложности.
Предоперационный период
Предоперационный период — время, необходимое для подготовки больного к операции. Длительность предоперационного периода зависит от степени срочности операции, состояния больного, его возраста и тяжести предстоящего оперативного вмешательства. Информационные потоки в предоперационный период показаны на следующей диаграмме.
Условно информационные потоки можно разделить на следующие группы и соответствующие им HL7v2 сообщения или шаблоны документов CDA (в скобках даются типы сообщений HL7v2 и их краткая расшифровка):
• Регистрация Пациента (ADT),
• Контроль листа ожидания (SIU — Изменение расписания),
• Данные по пациенту (MDM – Управление мед документами, CCD, CDA Referral Summary),
• Результаты лаб анализов (ORU – Результаты обследования, CDA для HITSP C37 Lab Report Document)
• Уведомления (MFN — Изменения в нормативно-справочном файле)
Операционный период
Информационный поток для операционного периода представлен на следующей диаграмме.
Для передачи информации используются следующие HL7v2 сообщения:
• Использование материалов (DFT – Детальная финансовая транзакция)
• Результаты лаб анализов (ORU – Результаты обследования, CDA для HITSP C36 Lab Result Message)
• Данные с мед аппаратов (ORU — Результаты обследования)
Послеоперационный период
Послеоперационный период — время от момента снятия больного с операционного стола до заживления раны и исчезновения расстройств, вызванных операционной травмой. Информационные потоки в предоперационный период показаны на следующей диаграмме.
Для передачи информации используются следующие HL7v2 сообщения:
• Данные с мед аппаратов (ORU — Результаты обследования)
• Данные по пациенту (MDM – Управление мед документами, CCD, CDA Referral Summary),
• Финансовые расходы (DFT – Детальная финансовая транзакция),
• Использование материалов (MFN — Изменения в нормативно-справочном файле).
Кроме вышеперечисленных сообщений, хирургу (точнее ИТ-отделу, ответственному за интерфейсы) приходится думать о работе систем в соответствии со следующими стандартами:
• IHE ATNA – Audit Trail and Node Authentication
• HITSP T15 — Collect and Communicate Security Audit Trail Transaction
• HITSP T17 – Secured Communication Channel Transaction
• IHE XDS.b – Cross-Enterprise Document Sharing-b
• HITSP T13b — Manage Sharing of Documents
Вышеприведённые сообщения и прочие стандарты описаны в следующих профайлах IHE (Integrating the Healthcare Enterprise):
• Patient Care Device;
• IT Infrastructure;
• Patient Care Coordination.
Ну и теперь возвращаясь к началу этой статьи, я не понимаю, почему специалисты IFX или Amazon EC2 SOAP API не могут дружно ужиться с HL7, там вроде всё достаточно просто.
:)
Также хотелось бы добавить суждение по поводу HL7 FHIR. Из всего вышеприведённого, тестовые FHIR сервера пока что возятся с функционалом равным ADT и SIU сообщениям. Вполне вероятно, что есть более продвинутые реализации (по крайне мере одну такую я знаю), но их создатели пока что не торопятся выступать открыто и выложить на суд публики особенности реализации.