Комментарии 4
Реквестирую пост про SNOMED CT, LOINC, международное кодирование clinical observations и особенно ситуацию с нероманскими языками.
см ниже
Собрался тут с мыслями немного. Чтобы ответить на твой вопрос, можно целую отдельную статью написать. Так как в очередной раз не говорится о версии стандарта, то я подразумеваю, что использован 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.
Смысл примерно следующий, для случая 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.
Общими словами написать конечно можно, но в реальности всё очень специфично для каждой реализации. Вот тебе пример использования одного и того же кода с разными значениями.
<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"/>
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
<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"/>
Так что одной из проблем пресловутой интероперабилити (совместимости) на семантическом уровне и уровне процессов как раз использование одних и тех же кодов всех участвующих сторон. Это уже не столько проблемы стандартов, сколько проблемы на уровне взаимодействия разных организаций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестовые данные для HL7 сообщений