Данная короткая статья мой вольный перевод поста на блоге Rene Spronk на тему “Analysis of CDA R2 testing tools — most requirements are neither tested nor respected” [1], которая сама по себе основана на презентации сделанной во время конференции IHIC (International HL7 Interoperability Conference) в Праге в начале 2015 года. [2]
PS. Ссылки на видео и прочие материалы в конце статьи.
Во время конференции была затронута очень интересная и важная тема валидации как документа CDA, так и не очень многочисленных средств разработки CDA. Насколько они соответствуют или не соответствуют стандарту.
Рене выделяет следующие 4-ре шага валидации документа CDA, что также соответствует основным шагам валидации сообщений HL7v3 (где возможно я буду это указывать), причём если документ или сообщение не прошли валидацию на каком-то шаге проверки, то не имеет смысла проводить все последующие шаги.
1. Проверка файла на соответствие стандарту XML (то, что в Altova XMLSpy и подобных средствах называется well-formedness);
2. Проверка на соответствие опубликованным XML схамам документа CDA или сообщения HL7v3;
3. Проверка на соответствие абстрактной модели HL7 CDA
Вот тут я сделаю небольшое отступление. Возможно вы знаете, а может быть и не знаете, но средств XML схемы не хватает для описания всех возможных требований предъявляемых к документу CDA, а также к сообщениям HL7v3. HL7 рекомендует использовать для этого файлы в формате MIF (Model Interchange Format), но не все средства поддерживают этот формат, вернее поддерживать могут не только лишь все, мало кто из средств разработки может это делать.
Найти MIF соответствующий CDA вроде как просто, он должен быть в папке ..\processable\MIF1-Lite под именем POCD_MT000040UV.mif, однако он присутствует только в V3 Ballot Edition. В финальной версии стандарта, в Normative Edition, его нет, поскольку CDA MIF не является нормативным. Дело в том, что CDA XML схема, после генерации, допиливается вручную, и эти изменения не отражаются в CDA MIF.
Кроме того, возвращаясь обратно к шагу 3, на данном уровне проверки целесообразно использовать правила Schematron. Некоторые из них уже включены в стандарт, нужно только внимательно поискать. Так, в схеме datatypes-base.xsd (находится в папке ..\processable\coreschemas) правила для проверки типов данных находятся под пространством имён sch. Может быть кто-то даже попробует написать мелкую утилитку, которая берёт элемент документа CDA (или любого v3 сообщения), лезет в соответствующую XML схему, чтобы определить тип данных этого элемента согласно HL7, т.к. тип данных не всегда указан с помощью аттрибута xsi:type в самом документе, и подставляет правила Schematron для проверки этого элемента из datatypes-base.xsd. Насколько я понимаю, используя только XPath такое закодировать не получится.
4. Проверка на соответствие требованиям определённым в CDA Implementation Guide, когда необходимо проверить соответствие шаблонов секций и записей на соответствие стандарту.
На этом уровне проверки на первом этапе рекомендуется также использовать правила Schematron, подобные, можно найти в папке \templates для CCD, однако для CDA это не предусмотрено, т.е. придётся писать свои.
На втором этапе для этого шага проверки ни куда не деться от «вычитки» документа человеком, чтобы выявить ошибки которые трудно или невозможно закодировать. Например, соответствие данных в разных частях секции и т.п.
Вернёмся теперь к блогу Рене. Дальше он пишет, что на конференции был представлен доклад на тему исследования в какой мере существующие средств разработки CDA соответствуют третьему шагу проверки. Авторы (Abderrazek Boufahja, Eric Poiseau, Guillaume Thomazon и Anne-Gaelle Berge) определили 160 требований, которым любой CDA документ должен отвечать. Эти требования опубликованы под названием “HL7 CDA R2 Basic Requirements”. [3]
Анализу подверглись следующие средства разработки и/или проверки CDA: Trifolia, MDHT, Eclipse Instance Editor, Art-Decor, NIST validation tool и IHE Gazelle ObjectsChecker. Про MARC-HI Everest Framework в момент составления критериев проверки авторы не знали. Про Mirth CDAPI Рене ни чего не сообщает, видимо авторы и он сам про него также не знают. Хотя это средство строится вокруг MDHT, так что, можно считать, оно подвержено тем же ошибкам.
Результаты проверки самих средств разработки и проверки оказались следующие:
• IHE Gazelle ObjectsChecker можно сказать обнаружил все ошибочные критерии из 160, авторы ссылаются на то, что в данном фреймворке они учитывали свои же исследования.
• Из оставшихся, старый Eclipse Instance Editor, который не обновлялся с 2011 года, оказался самым лучшим по поиску ошибок.
• Trifolia и Art-Decor по определнию не заточены на проведение проверки согласно третьему шагу, они больше ориентируются на 4-ый шаг, а именно на проверку шаблонов (а ведь CDA на то и CDA, что может и не иметь заранее прописанных шаблонов).
• Оставшимся двум, MDHT и NIST validation tool, есть ещё куда развиваться.
Авторами также были проверены 153 CDA документа из разных стран (национальных проектов).
Оказалось, что количество ошибок в них колеблется от 2 до 44. Далее Рене замечает, что допущенные в документах ошибки фактически повторяют опубликованные ранее в 2008 в блоге “Common issues found in implementations of the HL7 Clinical Document Architecture (CDA)” [4] что лишний раз доказывает, что проверки только на соответствие CDA XML схемы недостаточно для уверенности в валидности CDA документа и необходимо перемещать планку к 4-му шагу валидации. От себя добавлю, что тоже самое касается HL7v3 сообщений.
[1] www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm
[2] Model-based Analysis of HL7 CDA R2 Conformance and Requirements Coverage — vimeo.com/119524890
[3] gazelle.ihe.net/cda/cda-basic-req.pdf
[4] www.ringholm.com/docs/03020_en_HL7_CDA_common_issues_error.htm
PS. Ссылки на видео и прочие материалы в конце статьи.
Во время конференции была затронута очень интересная и важная тема валидации как документа CDA, так и не очень многочисленных средств разработки CDA. Насколько они соответствуют или не соответствуют стандарту.
Рене выделяет следующие 4-ре шага валидации документа CDA, что также соответствует основным шагам валидации сообщений HL7v3 (где возможно я буду это указывать), причём если документ или сообщение не прошли валидацию на каком-то шаге проверки, то не имеет смысла проводить все последующие шаги.
1. Проверка файла на соответствие стандарту XML (то, что в Altova XMLSpy и подобных средствах называется well-formedness);
2. Проверка на соответствие опубликованным XML схамам документа CDA или сообщения HL7v3;
3. Проверка на соответствие абстрактной модели HL7 CDA
Вот тут я сделаю небольшое отступление. Возможно вы знаете, а может быть и не знаете, но средств XML схемы не хватает для описания всех возможных требований предъявляемых к документу CDA, а также к сообщениям HL7v3. HL7 рекомендует использовать для этого файлы в формате MIF (Model Interchange Format), но не все средства поддерживают этот формат, вернее поддерживать могут не только лишь все, мало кто из средств разработки может это делать.
Найти MIF соответствующий CDA вроде как просто, он должен быть в папке ..\processable\MIF1-Lite под именем POCD_MT000040UV.mif, однако он присутствует только в V3 Ballot Edition. В финальной версии стандарта, в Normative Edition, его нет, поскольку CDA MIF не является нормативным. Дело в том, что CDA XML схема, после генерации, допиливается вручную, и эти изменения не отражаются в CDA MIF.
Кроме того, возвращаясь обратно к шагу 3, на данном уровне проверки целесообразно использовать правила Schematron. Некоторые из них уже включены в стандарт, нужно только внимательно поискать. Так, в схеме datatypes-base.xsd (находится в папке ..\processable\coreschemas) правила для проверки типов данных находятся под пространством имён sch. Может быть кто-то даже попробует написать мелкую утилитку, которая берёт элемент документа CDA (или любого v3 сообщения), лезет в соответствующую XML схему, чтобы определить тип данных этого элемента согласно HL7, т.к. тип данных не всегда указан с помощью аттрибута xsi:type в самом документе, и подставляет правила Schematron для проверки этого элемента из datatypes-base.xsd. Насколько я понимаю, используя только XPath такое закодировать не получится.
4. Проверка на соответствие требованиям определённым в CDA Implementation Guide, когда необходимо проверить соответствие шаблонов секций и записей на соответствие стандарту.
На этом уровне проверки на первом этапе рекомендуется также использовать правила Schematron, подобные, можно найти в папке \templates для CCD, однако для CDA это не предусмотрено, т.е. придётся писать свои.
На втором этапе для этого шага проверки ни куда не деться от «вычитки» документа человеком, чтобы выявить ошибки которые трудно или невозможно закодировать. Например, соответствие данных в разных частях секции и т.п.
Вернёмся теперь к блогу Рене. Дальше он пишет, что на конференции был представлен доклад на тему исследования в какой мере существующие средств разработки CDA соответствуют третьему шагу проверки. Авторы (Abderrazek Boufahja, Eric Poiseau, Guillaume Thomazon и Anne-Gaelle Berge) определили 160 требований, которым любой CDA документ должен отвечать. Эти требования опубликованы под названием “HL7 CDA R2 Basic Requirements”. [3]
Анализу подверглись следующие средства разработки и/или проверки CDA: Trifolia, MDHT, Eclipse Instance Editor, Art-Decor, NIST validation tool и IHE Gazelle ObjectsChecker. Про MARC-HI Everest Framework в момент составления критериев проверки авторы не знали. Про Mirth CDAPI Рене ни чего не сообщает, видимо авторы и он сам про него также не знают. Хотя это средство строится вокруг MDHT, так что, можно считать, оно подвержено тем же ошибкам.
Результаты проверки самих средств разработки и проверки оказались следующие:
• IHE Gazelle ObjectsChecker можно сказать обнаружил все ошибочные критерии из 160, авторы ссылаются на то, что в данном фреймворке они учитывали свои же исследования.
• Из оставшихся, старый Eclipse Instance Editor, который не обновлялся с 2011 года, оказался самым лучшим по поиску ошибок.
• Trifolia и Art-Decor по определнию не заточены на проведение проверки согласно третьему шагу, они больше ориентируются на 4-ый шаг, а именно на проверку шаблонов (а ведь CDA на то и CDA, что может и не иметь заранее прописанных шаблонов).
• Оставшимся двум, MDHT и NIST validation tool, есть ещё куда развиваться.
Авторами также были проверены 153 CDA документа из разных стран (национальных проектов).
Оказалось, что количество ошибок в них колеблется от 2 до 44. Далее Рене замечает, что допущенные в документах ошибки фактически повторяют опубликованные ранее в 2008 в блоге “Common issues found in implementations of the HL7 Clinical Document Architecture (CDA)” [4] что лишний раз доказывает, что проверки только на соответствие CDA XML схемы недостаточно для уверенности в валидности CDA документа и необходимо перемещать планку к 4-му шагу валидации. От себя добавлю, что тоже самое касается HL7v3 сообщений.
[1] www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm
[2] Model-based Analysis of HL7 CDA R2 Conformance and Requirements Coverage — vimeo.com/119524890
[3] gazelle.ihe.net/cda/cda-basic-req.pdf
[4] www.ringholm.com/docs/03020_en_HL7_CDA_common_issues_error.htm
Wayfarer15 Автор
Я так понял, CDA ни кто не использует и не тестирует.