FHIR: добавление пользовательского расширения

Я хотел бы добавить, чтобы добавить собственное расширение к моему ресурсу расписания. В моем приложении в расписании есть мотивы посещения (причины). Я знаю, что есть список секретных встреч/причин встреч, но я хотел бы использовать свой.

У меня есть что-то вроде этого:

{
  "resourceType":"Schedule",
  "identifier":"logical_id",
  "type":"schedule_speciality",
  "actor":{
    "practioner_id":"identifier",
    "practioner_name":"practioner name"
  },
  "external_id":{
    "extension":[
      {
        "url":"http://api.test.com/fhir/schedule/external_id",
        "valueIdentifier":"external_id"
      }
    ]
  },
  "visit_motives":{
    "extension":[
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive1"
      },
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive2"
      },
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive3"
      }
    ]
  },
  "practice_id":{
    "extension":[
      {
        "url":"https://api.test.com/fhir/schedule/practice_id",
        "valueIdentifier":"practice_id"
      }
    ]
  }
}

Я не уверен в этой части:

"visit_motives":{
    "extension":[
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive1"
      },
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive2"
      },
      {
        "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives",
        "valueString":"vist_motive3"
      }
    ]
  }

Правильно ли добавлять расширение таким образом? Всегда есть несколько мотивов посещения для определенного графика, поэтому я должен их перечислить.

Я тоже видел такие вещи:

"visit_motives": {
          "coding": [
            {
              "system": "https://api.test.com/fhir/ValueSet/schedule#visit_motives",
              "code": "visit_motive1"
            }
          ]
        }

Какой из них правильный или я ошибаюсь?


person user2462805    schedule 24.01.2017    source источник


Ответы (1)


Здесь есть несколько проблем:

  1. Кажется странным фиксировать «причину» в расписании. В расписании указано, когда доступен конкретный врач, клиника или другой ресурс. Например. «Доктор Смит принимает встречи с понедельника по среду / пятницу с 13:00 до 16:00». Таким образом, если бы вы зафиксировали причину на ресурсе, это отразило бы «Почему у доктора Смита есть расписание?» Обычно причины фиксируются для индивидуального назначения. Это ресурс, который резервирует определенный слот для запланированного посещения. А в Appointment уже есть элемент Reason, где вы можете использовать свои собственные коды или просто отправлять текст.

  2. У вас есть расширения для передачи идентификаторов, но в расписании уже есть элемент для идентификаторов. Зачем использовать расширения вместо стандартного элемента? Обратите внимание, что вы можете использовать компоненты «система» и/или «тип», чтобы различать разные типы идентификаторов.

  3. Вы отправляете «идентификатор», «тип», «имя» и т. д. в виде простых строк, но это сложные типы данных, поэтому вам нужно сообщить дочерние элементы.

  4. актер имеет тип Reference — это означает, что вам нужно указать на ресурс Practitioner. Вы не можете отправить свойства в строке. (Если Практик существует только в контексте Расписания, вы можете использовать «содержащийся» подход, который будет использовать внутреннюю ссылку, но сдерживание, похоже, не имеет смысла в этом случае использования.

  5. URL-адрес вашего расширения содержит ValueSet, что неверно — все расширения являются определениями структуры. Кроме того, в URL не должно быть символа #.

  6. Ваш синтаксис для расширений неверен. Вы не можете вводить новые свойства в FHIR. Имя свойства для всех расширений просто «расширение». Вы различаете по URL-адресу. Итак, ваш синтаксис должен быть:

{
  "resourceType":"Schedule",
  "id":"logical_id",
  "extension": [
    {
      "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motive",
      "valueString":"vist_motive1"
    },
    {
      "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motive",
      "valueString":"vist_motive2"
    },
    {
      "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motives,
      "valueString":"vist_motive3"
    }
  ],
  "identifier": [
    {
      "system": http://api.test.com/fhir/NamingSystem/external_id",
      "value": "external_id"
    }
    {
      "system": http://api.test.com/fhir/NamingSystem/practice_id",
      "value": "practice_id"
    }
  ]
  "type": {
    "coding": {
      "system": "http://somewhere.org/fhir/CodeSystem/specialties",
      "code": "schedule_speciality"
    },
    "text": "Some text description of specialty"
  },
  "actor":{
    "reference": "http://myserver.org/fhir/Practitioner/12345"
    "display": "Dr. smith"
  }
}
person Lloyd McKenzie    schedule 24.01.2017
comment
Прежде всего, спасибо за подробный ответ! 1. Причины связаны с расписанием в моем приложении. В расписании не может быть встречи, которая не входит в его список причин, и мне нужно, чтобы люди, использующие мой API, знали, какие причины поддерживают расписание. 2. Понял. 3. Моя ошибка, теперь я это понимаю. 4. Понял? 5. Хорошо, понял. 6. Отлично, это именно то, за чем я пришел сюда, но вы только что предоставили гораздо больше информации, большое СПАСИБО! - person user2462805; 24.01.2017
comment
Вы можете подумать о том, чтобы фиксировать причины на уровне слота — это более типичный случай, когда вы устанавливаете ограничения на то, какие встречи могут быть забронированы. Однако, если вам это действительно нужно на уровне расписания, значит, вы используете расширения правильно — они дают вам возможность поддерживать нетипичные требования. - person Lloyd McKenzie; 25.01.2017
comment
Я думаю, что вариант использования здесь — это то, что мы считаем блоками провайдера. Например, доктор Смит может согласиться на визиты здорового ребенка только в возрасте от 8 до 10 лет, а существующие визиты в кабинет пациента — в период с 12 до 5 лет. Он также может принимать новых пациентов из 12-2 (поэтому 12-2 может быть как новым, так и существующим). Интересно, имеет ли смысл повесить ссылку 0..* на HealthcareService вне слота, чтобы вы могли указать, какие услуги может поддерживать слот конкретного поставщика (поскольку ссылка HealthcareService из расписания и действующее лицо имеют значение 1..1, что не соответствует недостаточно для сценария «или-или»). - person Cooper; 27.01.2017
comment
Похоже, Слот — подходящее место. Не стесняйтесь вносить рекомендацию в качестве предложения об изменении. - person Lloyd McKenzie; 27.01.2017