Предложите, как улучшить StudyLib
(Для жалоб на нарушения авторских прав, используйте
другую форму
)
Ваш е-мэйл
Заполните, если хотите получить ответ
Оцените наш проект
1
2
3
4
5
НСИ
Основные атрибуты
OID Руководства по реализации СЭМД
Полное наименование
Дополнительные атрибуты
Вид медицинского документа
Дополнительные атрибуты 2
Редакция
Уровень
Ссылка
Дата отправки
Дата публикации
Формат
Термины и сокращения
Термины и сокращения, используемые в документе.
| Сокращение | Определение |
|---|---|
|
N2O |
Платформа РМИС с обновленным интерфейсом |
|
РМИС |
Региональная Медицинская Информационная Система – региональный сегмент Единой Государственной Информационной Системы Здравоохранения Российской Федерации |
| МСЭ | Медико-социальная экспертиза |
| НСИ | Нормативно-справочная информация |
| СНИЛС | Страховой номер индивидуального лицевого счета |
Доработка N2O
Модуль Реестр инвалидов
Скорректировано формирование XML по Руководству по реализации CDA (Release 2) уровень 3 «НАПРАВЛЕНИЕ НА МЕДИКО-СОЦИАЛЬНУЮ ЭКСПЕРТИЗУ», Редакция 4.
Для справочника «Причина инвалидности» реализовано новое поле «Код НСИ». Теперь в поле «Причина инвалидности» отображаются значения, у которых имеется код НСИ.
- путь вызова: модуль «Реестр инвалидов» → раздел «Направление на МСЭ» → кнопка «Добавить» — окно «Направление на МСЭ».
- путь вызова: модуль «Реестр инвалидов» → раздел «Направление на МСЭ» → кнопка «Результаты МСЭ» /»Редактировать результаты МСЭ» → вкладка «Решения» — кнопка «Редактировать» — ссылка «Добавить инвалидность».
Реализована возможность выбора значений из справочника «Срок, на который установлена степень утраты профессиональной трудоспособности» (НСИ) в поле «Срок утраты» в форме «Направление на МСЭ». Справочник предназначен для корректной передачи в МСЭ срока, на который установлена степень утраты профессиональной трудоспособности.
- путь вызова: модуль «Реестр инвалидов» → раздел «Направление на МСЭ» → форма»Направление на МСЭ».
Реализовано условие: если в поле «Срок утраты» выбрано значение «Бессрочно», то поле «Дата окончания утраты» не отображается.
- путь вызова: модуль «Реестр инвалидов» → раздел «Направление на МСЭ» → форма»Направление на МСЭ».
Реализована проверка полей на заполненность при отправке направления на МСЭ. Проверка осуществляется если хотя бы одно из нижеуказанных полей заполнено на момент отправки направления на МСЭ:
- «Степень утраты проф. трудоспособности (%)»;
- «Срок утраты»;
- «Дата окончания утраты».
Примечание – Если в поле «Срок утраты» выбрано значение «Бессрочно», то поле «Дата окончания утраты» не проходит проверку на заполнение.
Если одно (и более) из полей заполнено, но при этом есть не заполненные поля – отобразится одна из ошибок:
- «Не указана степень утраты проф. трудоспособности»;
- «Не указан срок утраты профессиональной трудоспособности»;
- «Не указана дата окончания утраты профессиональной трудоспособности».
Реализована проверка указания СНИЛС у председателя врачебной комиссии при отправке направления на МСЭ. Если у председателя врачебной комиссии не указан СНИЛС, то отобразится ошибка: «У председателя врачебной комиссии не указан СНИЛС».
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Neonatal Care Report Implementation Guide for CDA Release 2 – Level 3 PowerPoint Presentation
Download Presentation
Neonatal Care Report Implementation Guide for CDA Release 2 – Level 3
— — — — — — — — — — — — — — — — — — — — — — — — — — — E N D — — — — — — — — — — — — — — — — — — — — — — — — — — —
Presentation Transcript
-
Neonatal Care Report Implementation Guide for CDA Release 2 – Level 3 Children’s Hospitals Neonatal Consortium
-
Overview • Purpose • Industry Sponsors • Why HL7? • Objectives and deliverables • Approach • Project team subject matter experts • Q&A
-
Ultimate Purpose Improve decision making resulting in neonatal care that is more safe, effective and efficient
-
Industry Sponsors • Child Health Corporation of America • CHCA Owner Hospitals are North America’s leading children’s hospitals • 43 children’s hospitals represent more than 20,000 physicians, 100,000 employees • Children’s Hospitals Neonatal Consortium • 21+ children’s hospital NICUs with unique patient populations interested in collaborating to improve patient care • Formed in 2006; Developed extensive list of desired data elements for sharing
-
Why HL7? • Use data standards to support electronic reporting of an initial segment of data elements in the CHNC Neonatal Intensive Care Unit (NICU) Core Data Set (CDS) from Neonatal Intensive Care providers to CHNC, managed by CHCA • Foundation to support for future performance improvement work
-
NICU -B NICU -A NICU -C NICU -F NICU -E NICU -D
-
Objectives and Deliverables • A prose implementation guide: • Defining a subset of NICU monitoring data for reporting • Providing consensus among the neonatal data set developers and standards community prior to bringing the full data set into standard format • A report sample file • Schematron • A rendering style sheet
-
Project Team: Subject Matter Experts • David J. Durand, MD: ddurand@mail.cho.org • Director, Division of Neonatology — Children’s Hospital and Research Center Oakland • Karna Murthy, MD: k-murthy@northwestern.edu • Attending Neonatologist, Assistant Professor of Pediatrics, Northwestern University, Children’s Memorial Hospital • Mike Padula, MD: padula@email.chop.edu • Attending Neonatologist , Director — Neonatal IT ,Children’s Hospital of Philadelphia • Feliciano (Pele) Yu, MD: fyu@peds.uab.edu • Information Technology Division, Children’s Hospital of Alabama and University of Alabama at Birmingham School of Medicine
-
Questions ?
Время на прочтение
4 мин
Количество просмотров 14K
Clinical Document Architecture ﴾CDA﴿ — один из стандартов HL7, разработанный для стандартизации структуры и обеспечения семантической совместимости мед систем при обмене медицинской информацией и/или мед документами. Первая версия стандарта была одобрена ANSI ещё в 2001 году. Вторая версия, котороя используется и по сей день, была утверждена ANSI в 2005. Третья версия, CDA R3, находится в стадии разработки и согласования.
CDA R2 (Release 2) гарантирует наличие следующих семи характеристик в CDA документе:
• Сохранность представленной информации;
• Управление представленной информацией;
• Поддержка требований к аутентификации всей представленной информации;
• Поддержка контекста представленной информации;
• Поддержка цельности информации;
• Возможность чтения представленной информации человеком;
• Поддержка бинарной информации, таких как мультимедийные компоненты, PDF, изображения и прочее.
Подобные характеристики делают CDA крайне гибким к использованию в различных областях. И даже несмотря на то, что в среде разработчиков мед систем CDA считается крайне сложным стандартом, он стал одним из наиболее успешных разработанных HL7 для интеграции мед данных и согласуется с требованиями Meaningful Use 1 и 2 принятыми в США. Большинство мед систем в настоящее время кодируют информацию в одном из девяти возможных шаблонов документов CDA, например, Continuity of Care Document (CCD) один из таких шаблонов.
В данной статье представлен обзор или упрощённое описание основных компонентов CDA. И так, как и любой документ, CDA содержит заголовок документа (CDA Header) и тело документа (CDA Body).
CDA Header
Как показано на следующей картинке, в заголовоке CDA включена некоторая административная информация на основе классов и сущностей RIM модели HL7.
Основной класс в заголовке CDA так и называется — Clinical Document, и, в соответствии с его названием, содержит кроме всего прочего информацию для идентификации документа, заголовок, используемый язык, версию, дату публикации и уровень конфиденциальности. Далее рассмотрим назначение некоторых из выше приведённых классов. Чтобы избежать путаницы названия классов будут даны в их английской транскрипции.
Authenticator
Этот класс включен в документ для идентификации лица и/или организации, которые могут использоваться для проверки подлинности всего содержимого документа CDA.
Recipient
Здесь всё просто, в заголовке документа recipient используется для идентификации получателя (лица и/или организации) документа и может включать такие данные как имя, адрес и прочую информацию. Получателей может быть множество.
Author
В данном классе кодируется информация для идентификации и проверки лица или устройства, а также организации их представляющих, которые ответственны за данные в CDA документе.
Custodian
Данные класс используется для идентификации и проверки организации ответственной за сохранность документа. Подобная органиация отвечает за сохранность всех данных в документе (за весь документ).
Source
В данном классе кодируется информация о лице и/или организации поместившим данные в медицинскую систему, на основе которых и был создан документ. Подобным лицом может быть, например, Data Entry clerk.
Parent CDA
Поскольку документ CDA может быть частью другого документа CDA, подобная информация должна быть где-то представлена. В данном классе как раз кодируется информация о взаимосвязях между двумя и более документами.
Patient
Используя данный класс в заголовке CDA документа представлена информация о главном участнике всех событий – пациенте. Имя, адрес, опекуны и всякая прочая информация для полной идентификации пациента. Стоить заметить, что некоторые типы данных запрещены в некоторых странах. Например, информация о расовой и религиозной принадлежности требуется в США, но недопустима в Европе.
CDA Body
Тело документа или CDA Body может быть как неструктурированным для данных, которые не кодируются в XML, так и структурированным для представленных в формате XML данных. С особенностями такого кодирования тесно связано понятие уровней семантической совместимости CDA (в данной статье не рассматриваются).
В описании ниже также будут использоваться английские названия компонентов или классов.
Non-structured Body
Неструктурированное тело документа может содержать только одно вложение со ссылкой на данные вне этого CDA документа, либо Base64 кодированное бинарное вложение (PDF, изображение, аудио, видео и т.п.).
Structured Body
Структурированное тело документа разработано как крайне гибкий механизм для включения разнообразных клинических и административных данных. Именно это делает CDA настолько мощным в концептуальном плане, что теоретически его можно использовать для кодирования всей истории болезни пациента, какой бы сложности она не была. Обратная сторона подобной гибкости в сложности реализации всех имеющихся особенностей стандарта. Одна из причин этого в неправильности или неполноте понимания самого стандарта различными организациями.
Для устранения подобного разногласия были придуманы шаблоны CDA документов. Создание шаблонов и различных руководств разработчика нацелено на упрощение реализации и ограничения разночтений стандарта для одних и тех же клинических областей. К таким шаблоном относятся Clinical Notes, CCD, Discharge Summary и прочее). Все они представлены на официальном сайте HL7. Кроме того, существует около 70-ти шаблонов секций и ещё больше шаблонов записей.
Как показано на рисунке выше, структурированное тело документа может содержать одну или более секций, каждая из которых может содержать мед или адмнистративную информацию, а также вложения. При этом в самом стандарте CDA ни чего не сказано как устанавливать отношения между подобными данными, для этого нужно обращаться к многочисленным руководствам разработчика доступным на официальном сайте HL7 либо разрабатываемых каждой огранизацией в отдельности.