Комментарии 14
Спасибо! Я знал что такой проект должен был появиться!
Какие медицинские системы поддерживают стандарт FHIR?
А в России?

Насчет систем не скажу, но насколько я помню доклады на конференции — в Австралии и Канаде муниципальные структуры используют FHIR, в США также, но у них ситуация немного отличается — проще в чатике по ссылке из статьи напрямую спросить, там присутствуют участники, непосредственно занимающиеся этими вопросами. Россия традиционно не спешит быть в авангарде, присматривается к чужому опыту )

Логичнее было бы совместить отображение данных ресурса с его описанием аналогично профайлам в Simplifier. Также, не совсем понятно по какому принципу отображаются поля. Например, некоторые из них пользователь не может менять и, по идее, вообще не должен о них знать (Resource.id, Resource.impliciteRule и т.д.).

Для конечного пользователя ресурс предоставляет Narrative, причём его содержимое не обязано совпадать с остальной частью (если status не generated). Для разработчика же возможно важнее видеть сам ресурс и иметь возможность его валидации design time с помощью XML/JSON Schema, профайлов и прочих подобных вещей (см. 7.5 Validating Resources).

Поля (как на верхнем уровне, так и в любом вложенном объекте) отображаются в алфавитном порядке (для унификации, хотя можно сортировать по условному ордеру в схеме структуры ресурса). Список полей ресурса (вместе с их типами, списками допустимых значений, флагами обязательности и множественности значения) берется из StructureDefinition конкретного типа — независимо от наличия/отсутствия значений этих полей в выбранном элементе. Если при этом в элементе ресурса присутствуют поля, не перечисленные в StructureDefinition, то они показываются ниже и всегда как строки — потому что без метаданных я не знаю их тип, но как честный человек должен показать их наличие и дать некоторую возможность редактирования ) Насчет того, что не может менять — я конечно могу сделать id и часть других реквизитов недоступными для редактирования, но тот же id во многих ресурсах может нести некоторую семантику (например при синхронизации со сторонней системой или при загрузке стандартного каталога с четко определенными айдишниками). Поэтому, а еще для универсальности, я не стал запрещать их редактирование.
То, что вы говорите про "видеть сам ресурс"… Конечно, мне самому привычнее смотреть содержимое ресурса в форматированном ямле или жсоне ) Но так можно дойти до того, что — используйте Postman или просто браузер, кидайте запросы вручную и смотрите ответы текстом ) Но имхо это не лишает данный проект права на жизнь. Наглядная визуализация структуры ресурса, типов и описаний полей, демонстрация возможно незаполненных реквизитов, да и просто — почему бы и нет? В комментарии выше даже предвосхищали появление визуализатора подобного рода )

Не очень convincing, но это твой проект. Ещё пара замечаний:
— сходу не вспомню где, но в некоторых случаях порядок может иметь значение, возможно в Slices или что-то подобное
— неизвестные элементы, такие как extension, в бОльшей степени должны браться из StructureDefiniton которые в свою очередь определяются профайлом
— когда делаешь PUT вероятно нужно использовать If-Match

Спасибо за интерес и замечания. Не написал ввиду очевидности, но порядок элементов внутри коллекций у меня сохраняется (хотя и пока отсутствуют стрелки для его изменения). А порядок полей объекта… Он приходит в виде жсона, там уже он теряется. Хотя, если в структуре полей есть ордер, по нему можно восстановить. Про легальные extension — если они определены в StructureDefiniton — я их вывожу с типами и как надо — в части ресурсов на демо-примере это видно. Про бестиповый текст я имел в виду т.н. нелегальные экстеншены, которые нарушают стандарт но могут присутствовать.


Про PUT и If-Match, простите, не понял. Не могли бы раскрыть мысль подробнее?

«Нелегальный» extension правильнее назвать локальными, они имеют право на существование и по хорошему должны быть описаны в StructureDefintion. Если пойти дальше, то url в этом StructureDefinition должен указывать на реальное описание локального extension, что позволило бы тебе взять его описание.

Если пользователей больше чем один, то отредактированный ресурс обратно на сервер лучше отправить как PATCH или Conditional Update (c HTTP header If-Match).
Большое спасибо за статью Андрей! Подскажите еще ресурсы, если не сложно, по опыту имплементации FHIR и c2s в проектах? Про чатик я понял — зарегистрировался. В данный момент я изучаю проекты от SAMHSA и все в этой области очень интересно. Заранее благодарен!

Спасибо.
Можно почитать обзорные статьи (и соседние по ссылкам), про опыт имплементации еще рассказывают на различных конференциях, как в России ОТКРЫТЫЕ СТАНДАРТЫ API, КАК ИНФРАСТРУКТУРА ДЛЯ ИННОВАЦИЙ: ПРИМЕРЫ МЕДИЦИНСКИХ ДАННЫХ HL7 FHIR INTERNATIONAL PATIENT SUMMARY, так и на многочисленных зарубежных. Но я не уверен насчет наличия материалов с них в сети.

На Vimeo есть полные видео всех FHIR Dev Days — несколько дней просмотра точно обеспечено.

И хочется спросить, что такого секретного рассказали на itmcongress.ru, что единственный доклад про FHIR недоступен хоть упытайся зарегится всему доступными на сайте способами.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.