При подобном анализе штатовских вакансий я бы сразу выкинул soft skills, такие как communication, team player и прочую мутотень которую добавляют «до кучи».
Далее указал это full-time или contract позиция, т.к. это очень важно — зряплата может отличаться в разы. Наиболее репрезантивная выборка может быть по contract positions, т.к. там указывают не просто «технология А», а весьма конкретно «технология А версии 1.1». На контрактной позиции нет времени подстраивать работника под реалии заказчика.
Далее имеет смысл сравнить рынок труда по технологиям .NET vs Java vs <прочее>. А также front-end vs back-end vs <прочее>. А также по отрослям, наример, finance vs healthcare vs <прочее>.
Уровень зряплаты вообще ни о чём даже внутри США. В Калифорнии одни рейты, в какой-нибудь Алабаме совершенно другие. Тоже самое касается России — одно в Москве, другое в регионах.
Разве Эрик Липперт работает в российском отделении Microsoft? Ну тогда забираю свои слова обратно. В противном случае, всё сказанное мной основывается на собственном и многочисленном опыте других.
Пол-года, годик поработают на лесопилке или на разноске газет (реальные истории), и не только не расплачуться, но и выучат ответы штук на 100-200 подобных вопросов так, что от зубов будет отлетать. Конечно, возможно вариации, но если компания достаточно большая, то первая линия защиты будет примерно такой.
Elevator Pitch в статье выше и есть вопрос «Tell me about yourself», на который ожидается вполне определённый ответ (минут на 5-ть). Если кандидат начнёт что-то вроде «в ХХ-ых годах я пошёл в детский сад, потом в школу, потом...» то вероятно на нём тут же поставят крестик, хотя и продолжат интервью.
Описанное интервью, это где-то примерно третье интервью на пути потенциального кандидата. Большинство (не знакомых с особенностями интервью в западных компаниях) не прорвётся даже через первые вопросы первого интервью, которые будут звучать примерно как «Tell me about yourself», «Tell me about a time when you failed», «Tell me how you deal with a conflict situation» и т.д. и т.п. на протяжении часа.
И стоит сказать, что в данном случае Россия в весьма выгодном положении, так как legacy systems с кучей V2 сообщений, под которые были затрачены миллионы, нет. V3 поднимать можно, но экспертизы мало, да и смысла тоже мало, а тут как раз FHIR на подходе. Но реализация сообщений и документов в FHIR пока очень слабо прописана.
Что касается прибалтийских стран, то, при всём уважении, у них население как в одном среднем городе. Для тестовых имплементаций как раз пойдёт.
Я спрашивал не про движки, а про работающие системы со всем их «зоопарком» медицинских требований. А так, HAPI-V2 тоже неплохо развивается.
Для лучшего понимания, из недавней рассылке по CDA: "How can one express the properties of a medical device in a MedicalEquipment Section of a CDA?
The CDA, like FHIR last September, is simply too limited to properly describe some of the most basic features about a medical device. The FHIR limitations made it impossible to map a PCD-01 message to a FHIR document. We are running into the same problem trying to map PCD-01 to the PHMR. The problem really boils down to the following very limited schema for a Device..."
И хотя у меня есть понимание как это надо делать и в FHIR, и в CDA, но чем дальше в лес, тем больше будет подобного. И наличие HAPI-FHIR, или чего-то ещё, тут ни как не помогает.
Про «множество реализаций» чуток по-подробнее, пожалуйста. Только не ссылками на тестовые серверы, которые поддерживают несколько ресурсов относящихся к данным по пациенту, а про покрытие какого-то, пусть самого простого, процесса в клинике. Пока что я слышал только про австралийскую достаточно простую реализацию под руководством Grahame Grieve.
Да, FHIR это (очередная) попытка решить проблемы HL7v3. В настоящий момент стандарт всё ещё в состоянии DSTU, т.е. не нормативный и его принятие произойдет не ранее 2016-2017 года. Пожалуй, в следующей статье я про него и напишу.
Собрался тут с мыслями немного. Чтобы ответить на твой вопрос, можно целую отдельную статью написать. Так как в очередной раз не говорится о версии стандарта, то я подразумеваю, что использован v3. Для v2 будет нечто похожее.
Смысл примерно следующий, для случая HL7v3, – кодирование, о котором ты говоришь, обычно выполняется элементом code с типом данных Concept Descriptor (CD). Этот тип данных, кроме всего прочего, имеет опциональные элементы displayName, originalText, qualifier и translation. Испольуя любой «обычный» словарь вроде SNOMED CT или LOINC можно совершенно правильно закодировать нужное понятие, а далее смотреть, что тебе нужно – если просто не-аглицкий перевод, то в displayName, если показать, что там закодировано, то originalText. Если же маппинг на свой собственный словарь, то translation.
В свою очередь каждый из originalText, qualifier и translation тоже сложные типы данных – ED, List и Set соответственно. Так, ED позволяет указать charset и language. Почитай спеку внимательнее вначале по CD, а потом по типам данных его аттрибутов (а потом по аттрибутам аттрибутов, а потом… ). :)
Но опять же, возникает вопрос – а нужно? Нужно обязательно SNOMED CT или LOINC использовать или можно сразу локальный словарь подставить. См мой ранний коммент ниже про maritalStatusCode.
Желательно бы ещё версию HL7 указывать. В начале каждой спеки (будь то chapter в v2 или домены в v3) есть список кто его разрабатывал, так что вполне возможно там есть кто-то из US Department of Veterans Affairs. Другой крупный «поставщик» экспертов — Mayo Clinic.
Как в Одессе любят отвечать вопросом на вопрос, так и я спрошу, а у вас есть спецификации интерфейсов этих "163 hospitals, over 800 clinics, and 135 nursing homes"? В противном случае какая вам польза от того, что вы знаете является ли она референсным воплощением HL7 или нет? Вот один из наших интерфейсов был прототипом одного из доменов HL7v3 NE, но с тех пор прошло много лет, Normative Edition изменился и тот же самый интерфейс стал не нормативным. Будем ли мы его подгонять под стандарт, нет, не будем, вполне устраивает как он сейчас работает. Тоже самое может быть с интерфейсами VistaA — даже если в крайних 90-х они стали прототипами chapters во второй версии, то к v2.7 возможно они уже в пролёте. А может быть и нет, без спеки и внимательного изучения я этого утверждать не могу. Ответил на вопрос?
Я бы сказал «и в людях, и в стандартах». Менять устоявшиеся бизнес процесс мало кому хочется, даже если в какой-то организации полный бардак. Тем не менее, этот бардак как-то же работает. Проблемы начинаются, когда они хотят обмениваться неполными данными с другой подобной организацией, у которой свой такой же конкретный бардак. В результате тратится по полгода только чтобы согласовать как должен называться показатель в каком-то отчёте только потому, что каждая из организацией (их ведь может быть больше чем две участвующих в обмене данными) хочет его видеть таким, какой он у них в данный момент.
Разработчики стандарта тоже особо ни куда не торопятся. У ведущих HL7 Education Working Group я как-то спрашивал, что мешает им написать понятнее какие секции Normative Edition нужны для сертификации, ибо их «Data Types» в стандарте встречается в двух местах – абстрактное описание типов данных и описание реализации (ITS). Неужели двух-страничный листок с описанием этапов подготовки к сертификации трудно написать четко и ясно. Нет, так и не захотели исправить.
Ну и всякие прочие факторы. В софтверной индустрии для этого придумали рефакторинг, чтобы как в анеке про парикмахера «А, не получается ничего!» и бритвой по черепу крест-накрест. В индустрии стандартизации такое сходу не пройдёт. Вот сейчас со своим FHIR бегают, хотя messaging и documents в нём как-то очень криво получаются. Посмотрим, как потом это всё в реальном случае будет работать.
Общими словами написать конечно можно, но в реальности всё очень специфично для каждой реализации. Вот тебе пример использования одного и того же кода с разными значениями.
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
Далее указал это full-time или contract позиция, т.к. это очень важно — зряплата может отличаться в разы. Наиболее репрезантивная выборка может быть по contract positions, т.к. там указывают не просто «технология А», а весьма конкретно «технология А версии 1.1». На контрактной позиции нет времени подстраивать работника под реалии заказчика.
Далее имеет смысл сравнить рынок труда по технологиям .NET vs Java vs <прочее>. А также front-end vs back-end vs <прочее>. А также по отрослям, наример, finance vs healthcare vs <прочее>.
Уровень зряплаты вообще ни о чём даже внутри США. В Калифорнии одни рейты, в какой-нибудь Алабаме совершенно другие. Тоже самое касается России — одно в Москве, другое в регионах.
Elevator Pitch в статье выше и есть вопрос «Tell me about yourself», на который ожидается вполне определённый ответ (минут на 5-ть). Если кандидат начнёт что-то вроде «в ХХ-ых годах я пошёл в детский сад, потом в школу, потом...» то вероятно на нём тут же поставят крестик, хотя и продолжат интервью.
И стоит сказать, что в данном случае Россия в весьма выгодном положении, так как legacy systems с кучей V2 сообщений, под которые были затрачены миллионы, нет. V3 поднимать можно, но экспертизы мало, да и смысла тоже мало, а тут как раз FHIR на подходе. Но реализация сообщений и документов в FHIR пока очень слабо прописана.
Что касается прибалтийских стран, то, при всём уважении, у них население как в одном среднем городе. Для тестовых имплементаций как раз пойдёт.
Для лучшего понимания, из недавней рассылке по CDA: "How can one express the properties of a medical device in a MedicalEquipment Section of a CDA?
The CDA, like FHIR last September, is simply too limited to properly describe some of the most basic features about a medical device. The FHIR limitations made it impossible to map a PCD-01 message to a FHIR document. We are running into the same problem trying to map PCD-01 to the PHMR. The problem really boils down to the following very limited schema for a Device..."
И хотя у меня есть понимание как это надо делать и в FHIR, и в CDA, но чем дальше в лес, тем больше будет подобного. И наличие HAPI-FHIR, или чего-то ещё, тут ни как не помогает.
Смысл примерно следующий, для случая HL7v3, – кодирование, о котором ты говоришь, обычно выполняется элементом code с типом данных Concept Descriptor (CD). Этот тип данных, кроме всего прочего, имеет опциональные элементы displayName, originalText, qualifier и translation. Испольуя любой «обычный» словарь вроде SNOMED CT или LOINC можно совершенно правильно закодировать нужное понятие, а далее смотреть, что тебе нужно – если просто не-аглицкий перевод, то в displayName, если показать, что там закодировано, то originalText. Если же маппинг на свой собственный словарь, то translation.
В свою очередь каждый из originalText, qualifier и translation тоже сложные типы данных – ED, List и Set соответственно. Так, ED позволяет указать charset и language. Почитай спеку внимательнее вначале по CD, а потом по типам данных его аттрибутов (а потом по аттрибутам аттрибутов, а потом… ). :)
Но опять же, возникает вопрос – а нужно? Нужно обязательно SNOMED CT или LOINC использовать или можно сразу локальный словарь подставить. См мой ранний коммент ниже про maritalStatusCode.
Если серьёзно, у нас несколько десятков дополнительных локальных словарей для каждой реализации.
Разработчики стандарта тоже особо ни куда не торопятся. У ведущих 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"/>
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
и как раз утверждает, что они первоначально заточены под создание мед систем, а не коммуникации между ними. Может быть опишу это как-нибудь.