Comments 18
Используется HL7 в РФ федеральных сервисах интеграции медучреждений?
Когда я 1.5 дня в медлайнсофт проработал, то я видел лишь очередной велосипед для передачи данных между ЛПУ, свои форматы для хранения данных пациентов и т.п.
Когда я 1.5 дня в медлайнсофт проработал, то я видел лишь очередной велосипед для передачи данных между ЛПУ, свои форматы для хранения данных пациентов и т.п.
Подобное явление уникально не только для РФ, особенно когда речь идёт о внутреннем взаимодействии систем. Приходилось видеть реализацию, как утверждалось, HL7v2.1, где от всего стандарта взят MSH, да и тот с грубыми нарушениями, а всё остальное Z-сегменты. Всё это помноженное на свои собственные типы данных. От того, что в сообщении используются «крышечки» и «палочки», сообщение не становится автоматически v2.
Что самое интересное, эта реализация достаточно успешно работает, выполняет все необходимые бизнес требования и менять её на «правильный» стандарт ни кто не собирается. Ещё раз, это не в РФ.
Что самое интересное, эта реализация достаточно успешно работает, выполняет все необходимые бизнес требования и менять её на «правильный» стандарт ни кто не собирается. Ещё раз, это не в РФ.
vendor lock-in в чистом виде)
Спасибо вам за статьи! Очень интересная тема, хоть и не особо популярная
Спасибо вам за статьи! Очень интересная тема, хоть и не особо популярная
Согласен. Стыкался с таким же. В один продукт приходится вставлять костыли для разных госпиталей. Речь скорее о значениях полей так как один разработчик воспринимает это поле для одних целей, а другой разработчик — совсем для других.
Есть госпитали, которые не купят продукт без поддержки HL7 и CЄ-mark или аналога, а другим пофиг.
Есть госпитали, которые не купят продукт без поддержки HL7 и CЄ-mark или аналога, а другим пофиг.
Если есть идеи какие темы из области HL7 стоит рассмотреть, предлагайте. Попробую что-то написать. Про FHIR пока не заикаться.
Было бы интересно почитать про фичи и возможности того же Mirth.
К примеру, мне нужно было вытаскивать процедуры назначенные пациенту из БД и отдавать их в массиве BAR записей одним месседжом (один рекорд из БД = один BAR). Пришлось скриптиками писать, хотя я почти уверен что был и путь попроще.
Ну и прочие типичные задачи. Если с примерами реализации будет, то вообще супер.
К примеру, мне нужно было вытаскивать процедуры назначенные пациенту из БД и отдавать их в массиве BAR записей одним месседжом (один рекорд из БД = один BAR). Пришлось скриптиками писать, хотя я почти уверен что был и путь попроще.
Ну и прочие типичные задачи. Если с примерами реализации будет, то вообще супер.
Всё это здорово, но кому это нужно? Google Health умер, так и не сумев достучаться до широких масс.
googleblog.blogspot.ru/2011/06/update-on-google-health-and-google.html
Утечка такой информации — это вам даже не номер кредитки! Кто захочет, чтобы его болячки стали достоянием гласности?
googleblog.blogspot.ru/2011/06/update-on-google-health-and-google.html
Утечка такой информации — это вам даже не номер кредитки! Кто захочет, чтобы его болячки стали достоянием гласности?
Мне это нужно.
Системы приходится стыковать, и правильно делать это, используя стандартный протокол, как бы ни хотелось сделать это по-своему. Если ваша система поддерживает коммуникации с одной внешней системой — то это ничего — делайте что хотите. Если с десятью — двадцатью: уже имеет смысл некоей стандартизации между ними. Если при этом они меняются (в год, скажем, пять новых приходит и пять старых уходит) — другого выхода нет, кроме как использовать отраслевой стандарт. Так что потребность в стандартах есть. Стандарты вроде тоже есть, а на русском языке публикаций немного. Так что есть польза от статей как эта.
И вы правы в том, что отрасль сама по себе очень консервативная, да еще и законами со всех сторон ограничена. Организации предпочитают хранить данные, связанные с пациентами строго у себя, никогда их не терять, пусть даже и переплачивая за это.
Google health не гарантировал вечного хранения, не объяснил как будет обеспечиваться приватность, не предложил прорывных интерфейсов, протоколов. Продукт умер, поскольку пользы в нем было немного.
Скорее всего Google обкатывал какой-то продукт, где Google health был частью, или просто собирал информацию. А поскольку это Google а не разработчик Вася Пупкин из Петушков, они и выкатили продукт в Internet, просто потому что могут. Жизненный цикл этого продукта к жизненному циклу HL7 никакого отношения не имеет пока.
Системы приходится стыковать, и правильно делать это, используя стандартный протокол, как бы ни хотелось сделать это по-своему. Если ваша система поддерживает коммуникации с одной внешней системой — то это ничего — делайте что хотите. Если с десятью — двадцатью: уже имеет смысл некоей стандартизации между ними. Если при этом они меняются (в год, скажем, пять новых приходит и пять старых уходит) — другого выхода нет, кроме как использовать отраслевой стандарт. Так что потребность в стандартах есть. Стандарты вроде тоже есть, а на русском языке публикаций немного. Так что есть польза от статей как эта.
И вы правы в том, что отрасль сама по себе очень консервативная, да еще и законами со всех сторон ограничена. Организации предпочитают хранить данные, связанные с пациентами строго у себя, никогда их не терять, пусть даже и переплачивая за это.
Google health не гарантировал вечного хранения, не объяснил как будет обеспечиваться приватность, не предложил прорывных интерфейсов, протоколов. Продукт умер, поскольку пользы в нем было немного.
Скорее всего Google обкатывал какой-то продукт, где Google health был частью, или просто собирал информацию. А поскольку это Google а не разработчик Вася Пупкин из Петушков, они и выкатили продукт в Internet, просто потому что могут. Жизненный цикл этого продукта к жизненному циклу HL7 никакого отношения не имеет пока.
Безусловно, с точки зрения технологии вопросов к актуальности такой работы нет. Но вот с мета-уровня, с точки зрения конечных целей (обмен медицинской информацией)…
Я сам с интересом возился с Google health — там можно было вести историю различных жизненных показателей, анализов, диагнозов, выбирать врачей или целые медучереждения (были подстыкованы сотни больниц), услуги… предоставлять им доступ ко всей или части накопленной информации… то есть очень красивая и, казалось бы, интересная и нужная система.
И когда Google заявил о прекращении проекта, мне, честно говоря, было совсем не понятно, что там не срослось и почему проект был закрыт. Казалось бы такой интересный и нужный!
Именно поэтому движение в сходном направлении и вызывает опасение в его потенциальной бесполезности — потому что Гугл пробовал и несмотря на свою мощь ничего с этим сделать не смог :(
Я сам с интересом возился с Google health — там можно было вести историю различных жизненных показателей, анализов, диагнозов, выбирать врачей или целые медучереждения (были подстыкованы сотни больниц), услуги… предоставлять им доступ ко всей или части накопленной информации… то есть очень красивая и, казалось бы, интересная и нужная система.
И когда Google заявил о прекращении проекта, мне, честно говоря, было совсем не понятно, что там не срослось и почему проект был закрыт. Казалось бы такой интересный и нужный!
Именно поэтому движение в сходном направлении и вызывает опасение в его потенциальной бесполезности — потому что Гугл пробовал и несмотря на свою мощь ничего с этим сделать не смог :(
Так ведь тут речь о стандарте, а не продукте одной компании. Если стандарт уже много где используют, то он так просто не умрёт.
Тут надо понимать, что в той стране, где живёт Google, существуют медицинские системы трёх типов — EHR, EMR и PHR. Отличия и схожесть я описывал в своём блоге (ссылку давать не буду). Так вот, Google пытался реализовать PHR и, естественно, это ни кому не нужно, потому что пользователь, тем более в штатах, о своих болезнях почти ни чего не знает, ему, кроме температуры, давления, роста-веса, больше ни чего измерять не приходится и ни каких особых данных, акромя демографических, он по определению ввести не может. А зачем Google эти данные, их и так на каждом углу как гуталлина (там есть агрегаторы, которые совершенно легально, по номеру телефона, позволяют вытащить все остальные данные о человеке).
О! Туман начинает проясняться!
Ага. Более того, подозреваю у каждого штата и провинции в Северной Америке (а в первую очередь на них был направлен сервис) есть свои собственные законы, запрещающие медицинской информации покидать пределы юрисдикции. Хотелки Google могли натолкнутся на жестские правила понаписанные в HIPAA Privacy Rule для каждого штата, либо в PIPEDA для провинций.
Да в Штатах, по сравнению с Европой, вообще средневековье. У них для многих медицинских областей почти нет стандартов. И пользуются бумажками. К примеру, в реанимацию и анестезию софт продать не получилось, так как нет стандарта, регулирующего работу софта в этих департаментах.
Там может быть 1000 и одна причина почему сторонний софт отказались брать. Например, в одном из тендеров (для западного рынка) представленный некой компанией продукт был хорош во всех отношениях и бил таких конкурентов как Oracle в своей узкой нише. Но финансовый аналитик посетовал, что доходы этого вендора меньше, чем всего лишь одного из подразделений, не говоря о всей организации, куда они хотят поставить свой софт. Компанию завернули.
Sign up to leave a comment.
Что такое HL7 Continuity of Care Document (CCD)