Кодирование Identifier

[Aitem]

Проблема

Одна из самых распространненных задач которая встает перед разработчиками реальных ИС состоит в кодировании идентификационной информации для той или иной
сущности. На пример ДУЛ (Документ Удостоверяющий Личность) для людей, всевозможная финансовая информация - ИНН, БИК, ОГРН, всевозможные федеральные регистрационные номера и т.д. Особенно остро проблема поднимается когда речь заходит о интеграции с стороними системами, когда по той или иной причине приходится ссылаться на ресурсы не через прямой URL ресурса, а через логические ссылки, на пример, прикрепить документ к пациенту по его СНИЛС, или выставить счет организации по её ИНН.

Отчасти FHIR дает ответ на этоту задачу в виде Identifier, и возможности использовать Identifier в Reference - так называемые логические ссылки, а также поиск по ним.

Ниже речь пойдет сугубо о хранении идентификационной информации - пары system/value. Хранение ДУЛ специфичной информации такой как: кем выдано, срок действия и т.п. - тема отдеьного обсуждения.

FHIR

Теперь задача состоит в определении формата и перечня значенений для system и value.

В документации сказано:

Identifier	ΣN		    Element	
... system	Σ	0..1	uri	    The namespace for the identifier value
... value	Σ	0..1	string	The value that is unique

The value SHALL be unique within the defined system and have a consistent meaning wherever it appears.  Identifier.system is always case sensitive. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe.

The system is a URI that defines a set of identifiers (i.e. how the value is made unique). It might be a specific application or a recognized standard/specification for a set of identifiers or a way of making identifiers unique. 

Тип данных uri

uri	- A Uniform Resource Identifier Reference (RFC 3986 ). Note: URIs are case sensitive. 
For UUID (urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7) use all lowercase	
XML Representation:  xs:anyURI	
Regex: \S* 

Формально, данная спецификация полностью развязывает нам руки, и в качестве system value можем использовать все что придет нам в голову. Очень часто, в качестве system используют абсолютный url ,на пример http://my.project/CodeSystem/Passport, что формально не противоречит спецификации. Но это зачастую бывает очень не удобно. На пример при наличие dev stage prod инсталляций, или при интеграции когда из сторонней системы приходит паспорт в системе https://another.project/Passport-RF.

URN

Вместо ипользования URL целесообразнее использовать формат URN. Его основная задача избавиться от недостатков системы URL.

Структура URN:

<URN> ::= "urn:" <NID> ":" <NSS>

NID идентификатор пространства имён (англ. Namespace Identifier)
представляет собой синтактическую интерпретацию NSS, не чувствителен к регистру.
NSS строка из определённого пространства имён (англ. Namespace Specific String).

Если условиться что в качестве формата system для Identifier всегда использовать urn (хотябя в рамках россиийских реалий), то в таком случае задача сводится к формированию списка зарезервированных nid и соответствующих им nss.

NID & NSS

С одной стороны можно обратиться к федеральным справочникам и, на пример,
использовать федеральные OID. Но с ними тоже не все так гладко. Если рассмотреть справочник ДУЛ то он имел за свою историю три OID 1.2.643.5.1.13.13.99.2.48, 1.2.643.5.1.13.13.11.1011, 1.2.643.5.1.13.2.1.1.736. И в добавок они абсолютно не человеко читаемые. И так стараемся всеми силами уйти от XML в сторону упрощения формата данных, и думаю не стоит усложнять сами данные.

Еще в качестве примера можно разделить по ведомствам выдающим соответствующие документы. Примерно так: urn:mvd:passport, urn:nalog:inn, urn:fms:zagran-passport. В данном подходе тоже есть существенный недостаток связанные переформированием различных ведомст, и т.д.

Возможным решением видится формирование списка NID основанном на логической
области применения: документы идентифицирующие людей, финансовые идентификаторы, область для федеральных справочников, области для локального использования и т.д. А для связи с, на пример, федеральными OID - вести отдельный маппин. Это позволит нам быть аболютно независимыми от внешних факторов, а маппинг позволит перевести существующие системы на наш формат.

Возможные примеры:

NID identity - для ДУЛ

urn:identity:passport
urn:identity:enp
urn:identity:snils

NID finance - для около финансовой информации

urn:finance:inn
urn:finance:ogrn
urn:finance:bic

NID miac - для регионального МИАЦ

urn:miac:spb
urn:miac:mo
urn:miac:chu

NID source - для локального использования (интеграция) и идертификации истоника откуда
пришли данные.

urn:source:tfoms
urn:source:miac
urn:source:rmis-1
urn:source:mis-3

Кто занимается лабораторными и учетом мед оборудования, уверен, тоже могут предложить пару систем. Наверняка для определенных видов оборудвания, на пример рентгена, вдется свой учет и номенклатура и есть какие-либо федеральный реестр.

Сразу возникает вопрос о формате написания NID/NSS: транслит или перевод? То есть urn::snils или urn:idintity:inipa? Из-за большого количества аббревиатур перевод практически убивает их читаемость. Так что лично я склоняюсь к транслиту.

Value

Из практики идентификаторы встречаются составные серия + номер + что угодно, либо просто состоящие из одного значения. Причем само значение может содержать в себе не только цифры и буквы, но и пробелы, дефисы и т.д.

Мое предложение

• составные идентификаторы склеивать через разделитель, на пример :
• оставлять все не цифры и буквы в том виде как они записаны в документе

Пример

resourceType: Patient
identifier:
- system: urn:identity:snils
  value: '123-456-789 09'
- system: urn:identity:passport
  value: '12 34:567890'
managingOrganization:
  display: "Детская городская поликлиника №49"
  identifier:
    system: urn:miac:spb
    value: '264'
  
----
resourceType: Organization
identifier:
- system: urn:miac:spb
  value: '264'
- system: urn:federal:oid
  value: '1.2.643.5.1.13.13.12.2.78.8541'

Вопросы:

• Определиться с написанием NID/NSS транслит или перевод? snils или inipa
• Составить список NID и их NSS
• Определить формат value
• Формирование маппинга на существующие системы
• ...

TODO

• Использование type в логических ссылках
• Статья https://www.hl7.org/fhir/managing.html#consistency

[alexander-ivanov]

На Simplifier.net есть несколько национальных профилей, я отобрал по количеству звезд:

1. Finnish PHR (https://simplifier.net/finnishphr/fiphr-patient-stu3)
2. Basisprofil DE (STU3) (https://simplifier.net/basisprofilde/patient-de-basis-0.2)
3. Nictiz STU3 Zib 2017 (https://simplifier.net/nictizstu3-zib2017/nl-core-patient)

В Finnish PHR используется urn:ietf:rfc:3986. Мне кажется это странно, т.к. это rfc для uri. Без примеров я не понимаю, что у них пишется в value.

В Basisprofil DE (STU3) профиль требует использования системы - http://fhir.de/NamingSystem/gkv/kvid-10. Вот ее страница в профиле - https://simplifier.net/basisprofilde/gkv-kvid-10. Она связанна, с кодовой системой (https://simplifier.net/basisprofilde/identifier-type-de-basis-2) и ValueSet (https://simplifier.net/basisprofilde/identifier-type-de-basis-3). На ValueSet стоит посмотреть, там есть полезные идентификаторы.

В Nictiz STU3 Zib 2017 зашита одна система - http://fhir.nl/fhir/NamingSystem/bsn, ее описание - https://simplifier.net/nictizstu3-zib2017/bsn

Фактически две из трех популярных систем используют url, возможно, это уточняет национальный контекст использования.

В целом мне нравится предложение по кодированию value:

1. В чате это вызвало много споров, что есть требование хранить серию и номер отдельно, но реально номер паспорта без серии никому не нужен - весь код серия + номер повсеместно считается единым кодом.
2. Так же потенциально могут возникнуть вопросы - что делать, если в реальном тексте встретится разделитель - ":", думаю надо дождаться такой системы, если он будет можем ввести подход csv.
3. Если мы хотим требовать определенный формат для каждого типа документа, то хорошо бы сделать маски для каждой кодовой системы, например паспорт РФ - \d{2} \d{2}:\d{6}, чтобы это было валидируемо.

[maximalexeev]

Поддерживаю:
1, 2: хранить номер и серию ДУЛ в одном поле, разделитель :
3: маски ввода нужны для основных документов: паспорт, свидетельство о рождении - на них приходится 80-90% документов.

Сюда же: СНИЛС хранить только цифрами без разделителей

[maximalexeev]

В части именно ДУЛ предлагаю использовать следующий справочник:
https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320/passport/1.2
Из всего зоопарка справочников ДУЛ этот единственный актуальный, источник его - ФНС РФ.
Плюс - он совпадает с "исторически сложившейся" во многих МИС кодировкой ДУЛ, где:
1 - Паспорт СССР,
3 - СоР,
14 - Паспорт РФ.

При этом system можно кодировать как [OID справочника].[Код значения в справочнике], т.е. для паспорта РФ: 1.2.643.5.1.13.13.99.2.320.14

В части полиса ОМС важно не забыть о необходимости передачи типа полиса (старый, новый, времянка). Тут можно или поступать по предложению @Aitem :
urn:identity:polis_new - полис единого образца
urn:identity:polis_old - полис старого образца
urn:identity:polis_temp - временное свидетельство,

Или аналогично с ДУЛ, используя справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.245/passport/1.1

По аналогии - system можно кодировать как [OID справочника].[Код значения в справочнике], т.е. для полиса единого образца: 1.2.643.5.1.13.13.99.2.245.3

[Semalexa]

В части именно ДУЛ предлагаю использовать следующий справочник: https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320/passport/1.2

В этом справочнике есть два поля:

1. N_ID, Уникальный идентификатор (УИ), Целочисленный;
2. S_CODE, Код записи, Строчный;
   Верно понимаю, что в качестве кода следует использовать N_ID?

[maximalexeev]

Верно понимаю, что в качестве кода следует использовать N_ID?

Да, верно

[shamilnn-zz]

Аналогично с Patient.name (issue #3), вы уверены, что все системы должны содержать identifier - cardinality 1..?
Или лучше cardinality 0.. и Must Support? Что если пациент не может сообщить ни какого идентификатора?

Я бы также начал со списка всех возможных национальных идентификаторов, потом сгруппировал их и расслайсил Patient.identifier по этим группам, что позволило бы определять extension необходимые для каждой группы отдельно.

[s-shvyrev]

При работе с Документами удостоверяющими личность предлагаю использовать справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.48

[s-shvyrev]

Справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320 является локальным для одной из ИС. Паспорт СССР на сегодняшний день ДУЛ не является.

[s-shvyrev]

Кроме того, предлагаю рассмотреть возможность использовать в качестве идентификаторов не отдельные документы, а само понятие ДУЛ с указанием конкретного типа из справочника. Номер и серию нужно как-то отделять друг от друга.

[s-shvyrev]

В идентификаторе ДУЛ должен обязательно присутствовать тип документа, серия/номер, дата выдачи. Остальные элементы могут быть не обязательны (кем выдан, действителен до... и.т.д.). Для получения полного списка потребуется анализ всего перечня документов.

[maximalexeev]

Справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320 является локальным для одной из ИС. Паспорт СССР на сегодняшний день ДУЛ не является.

Из паспорта данного справочника: (https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320/passport/1.2)
7. Аннотация
Классификатор документов, удостоверяющих личность гражданина Российской Федерации. Используется в подсистемах Единой государственной информационной системы здравоохранения (ЕГИСЗ).

Полагаю, все же лучше использовать именно этот справочник.

[Alvic]

Справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320 является локальным для одной из ИС. Паспорт СССР на сегодняшний день ДУЛ не является.

ФФОМС работает по справочнику F011. Он прописан в приказе 79 "Общие принципы
построения и функционирования информационных систем и
порядок информационного взаимодействия в сфере
обязательного медицинского страхования", по которому идет обмен данным между МО, СМО и ФФОМС

http://nsi.ffoms.ru/#refbookList?refbookList:$active=1&refbookList:$selectedId=981/refbookList.refbookList.view$20v981?menu:filter:dictionaryId=981&menu:filter:readOnly=true&menu:$active=1&menu:$selectedId=undefined&refbookSimple0:$active=1&refbookSimple0:page=1&refbookSimple0:$selectedId=undefined

Похоже, что это и есть 1.2.643.5.1.13.13.99.2.320

[s-shvyrev]

Справочник https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320 является локальным для одной из ИС. Паспорт СССР на сегодняшний день ДУЛ не является.

Из паспорта данного справочника: (https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.320/passport/1.2)
7. Аннотация
Классификатор документов, удостоверяющих личность гражданина Российской Федерации. Используется в подсистемах Единой государственной информационной системы здравоохранения (ЕГИСЗ).

Полагаю, все же лучше использовать именно этот справочник.

Согласен, есть путаница в этих справочниках. В регламентной службе реестра НСИ в этом году будет проведена работа по унификации справочника ДУЛ.

[s-shvyrev]

Паспорт гражданина СССР, в настоящее время ДУЛ не является. Имеет только историческое значение.

[Semalexa]

Вышла новая версия справочника "Документы, удостоверяющие личность" https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.99.2.48

Предлагаю его использовать в Patient.identifier.type вторым элементом coding, первым будет значение из FHIR-справочника (PPN Passport number http://terminology.hl7.org/CodeSystem/v2-0203)