Я бы сказал «и в людях, и в стандартах». Менять устоявшиеся бизнес процесс мало кому хочется, даже если в какой-то организации полный бардак. Тем не менее, этот бардак как-то же работает. Проблемы начинаются, когда они хотят обмениваться неполными данными с другой подобной организацией, у которой свой такой же конкретный бардак. В результате тратится по полгода только чтобы согласовать как должен называться показатель в каком-то отчёте только потому, что каждая из организацией (их ведь может быть больше чем две участвующих в обмене данными) хочет его видеть таким, какой он у них в данный момент.
Разработчики стандарта тоже особо ни куда не торопятся. У ведущих HL7 Education Working Group я как-то спрашивал, что мешает им написать понятнее какие секции Normative Edition нужны для сертификации, ибо их «Data Types» в стандарте встречается в двух местах – абстрактное описание типов данных и описание реализации (ITS). Неужели двух-страничный листок с описанием этапов подготовки к сертификации трудно написать четко и ясно. Нет, так и не захотели исправить.
Ну и всякие прочие факторы. В софтверной индустрии для этого придумали рефакторинг, чтобы как в анеке про парикмахера «А, не получается ничего!» и бритвой по черепу крест-накрест. В индустрии стандартизации такое сходу не пройдёт. Вот сейчас со своим FHIR бегают, хотя messaging и documents в нём как-то очень криво получаются. Посмотрим, как потом это всё в реальном случае будет работать.
Общими словами написать конечно можно, но в реальности всё очень специфично для каждой реализации. Вот тебе пример использования одного и того же кода с разными значениями.
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
Советую посетить любую рабочую группу HL7 чтобы понять кто и как там работает. Ближайшее начнётся 10-го мая в Париже, не далеко.
Кстати, я всё таки возьму смелость перевести, что в Wiki написано с небольшими добавлениями: "В настоящий момент границы между системами хранения узкоспециализированных мед данных на стороне мед провайдера, системами хранения простейших данных о пациенте когда за хранение отвечает сам пациент и приложениями для отображения этих данных очень расплывчаты." По мне так в Wiki мягко говоря бред написан, по той простой причине, что вся эта область зарегулирована всякими актами и законами. Когда что-то происходит и мед данные становятся достоянием общественности, ответственность наступает очень конкретная, а не расплывчатая.
Ну давай возьмём хотя бы определение из Wiki: Currently, the lines between an EMR, a PHR, and a patient portal are blurring. For example, Intuit Health and Microsoft HealthVault describe themselves as Personal Health Records (PHRs), but they can interface with EMRs and communicate through the Continuity of Care Record standard, displaying patient data on the Internet so it can be viewed through a patient portal.
Т.е. хранение данных не выходит за пределы трёх вышеперечисленных систем, а patient portal только для отображения данных, которые туда попадают через CCD скорее всего, а не CCR.
Не понятно, о чём мы спорим. Тем не менее, изначально было "бери заказы по 50 баксов и сплавляй индусам не изменив ни буквы по 20 баксов". Заказ ассоциируется с проектом, а не с часовой ставкой. Что касается рейта в 150-200 баксов, то да, это действительно рейты консалтеров в серьёзных проектах (речь про IT, в других отрослях могут быть совершенно другие рейты). Это внешние рейты. Внутренние рейты, в зависимости от жадности рекрутера, могут быть от 25 до 50% от этой суммы. $300К в год доход, и что, бывает и такое. У какого-нибудь фин аналитика это может быть и месячной зряплатой.
Ну а так, всяческих благ твоему другу, больше проектов больших и разных.
По каждому из пунктов критики можно написать анти-критику. Складывается такое ощущение, что Адам послушал пару часовых вебинаров про HL7v3, ни чего не понял, и разродился критикой по этому поводу. По поводу HL7 существуют гораздо более серьёзные замечания, например, что не существует средств позволяющих однозначно сказать, что человеко-читаемая часть данных соотвествует закодированной для машинной обработки. Это не HTML по HTTP переслать.
У тебя несколько упрощённое представление о том, что делается в США. Начало верное — открыл фирмочку, аккаунт и всё такое. А вот дальше — набрал кучу резюме всяких контрактников и знай себе продавай их за 150-200 баков в час в разные компании, а контрактникам отдавай примерно половину.
Там может быть 1000 и одна причина почему сторонний софт отказались брать. Например, в одном из тендеров (для западного рынка) представленный некой компанией продукт был хорош во всех отношениях и бил таких конкурентов как Oracle в своей узкой нише. Но финансовый аналитик посетовал, что доходы этого вендора меньше, чем всего лишь одного из подразделений, не говоря о всей организации, куда они хотят поставить свой софт. Компанию завернули.
Ага. Более того, подозреваю у каждого штата и провинции в Северной Америке (а в первую очередь на них был направлен сервис) есть свои собственные законы, запрещающие медицинской информации покидать пределы юрисдикции. Хотелки Google могли натолкнутся на жестские правила понаписанные в HIPAA Privacy Rule для каждого штата, либо в PIPEDA для провинций.
Тут надо понимать, что в той стране, где живёт Google, существуют медицинские системы трёх типов — EHR, EMR и PHR. Отличия и схожесть я описывал в своём блоге (ссылку давать не буду). Так вот, Google пытался реализовать PHR и, естественно, это ни кому не нужно, потому что пользователь, тем более в штатах, о своих болезнях почти ни чего не знает, ему, кроме температуры, давления, роста-веса, больше ни чего измерять не приходится и ни каких особых данных, акромя демографических, он по определению ввести не может. А зачем Google эти данные, их и так на каждом углу как гуталлина (там есть агрегаторы, которые совершенно легально, по номеру телефона, позволяют вытащить все остальные данные о человеке).
Разработчики стандарта тоже особо ни куда не торопятся. У ведущих HL7 Education Working Group я как-то спрашивал, что мешает им написать понятнее какие секции Normative Edition нужны для сертификации, ибо их «Data Types» в стандарте встречается в двух местах – абстрактное описание типов данных и описание реализации (ITS). Неужели двух-страничный листок с описанием этапов подготовки к сертификации трудно написать четко и ясно. Нет, так и не захотели исправить.
Ну и всякие прочие факторы. В софтверной индустрии для этого придумали рефакторинг, чтобы как в анеке про парикмахера «А, не получается ничего!» и бритвой по черепу крест-накрест. В индустрии стандартизации такое сходу не пройдёт. Вот сейчас со своим FHIR бегают, хотя messaging и documents в нём как-то очень криво получаются. Посмотрим, как потом это всё в реальном случае будет работать.
<maritalStatusCode code="A" codeSystem="2.16.840.1.113883.5.2" displayName="Annulled" codeSystemName="MaritalStatusCode"/>
<maritalStatusCode code="A" codeSystem="2.16.840.1.114222.4.11.809" displayName="Separated" codeSystemName="PHVS_MaritalStatus"/>
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
и как раз утверждает, что они первоначально заточены под создание мед систем, а не коммуникации между ними. Может быть опишу это как-нибудь.
Кстати, я всё таки возьму смелость перевести, что в Wiki написано с небольшими добавлениями: "В настоящий момент границы между системами хранения узкоспециализированных мед данных на стороне мед провайдера, системами хранения простейших данных о пациенте когда за хранение отвечает сам пациент и приложениями для отображения этих данных очень расплывчаты." По мне так в Wiki мягко говоря бред написан, по той простой причине, что вся эта область зарегулирована всякими актами и законами. Когда что-то происходит и мед данные становятся достоянием общественности, ответственность наступает очень конкретная, а не расплывчатая.
Т.е. хранение данных не выходит за пределы трёх вышеперечисленных систем, а patient portal только для отображения данных, которые туда попадают через CCD скорее всего, а не CCR.
Ну а так, всяческих благ твоему другу, больше проектов больших и разных.