FHIR: Назначение по назначению как ресурс?

Я реализую FHIR в данный момент, и у меня возникают проблемы с назначением по назначению.FHIR: Назначение по назначению как ресурс?

Я знаю, что я могу использовать значение, установленное можно посмотреть здесь: https://www.hl7.org/fhir/valueset-encounter-reason.html

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

Набор значений для моего приложения будет недостаточным.

Есть ли у вас какие-либо намеки/идеи о том, как я могу реализовать такую вещь?

источник

2017-02-08 user2462805

Значит, вы хотите указать на условие или наблюдение в качестве причины? Или, возможно, укажите на ReferralRequest или ProcedureRequest, на котором основана встреча? Если это так, отправьте запрос на изменение - эти вещи также будут совпадать с шаблоном запроса, с которым должно совпадать назначение встречи. Тем временем вы можете определить расширение, чтобы передать то же значение.

источник

2017-02-08 14:21:34

Я имел в виду, что мои пользователи заказывают встречу по определенной причине в своем приложении. Они не могут просто записаться на прием, не уточняя «почему», и это делается путем уточнения причины (например: «Консультация в стоматологии»). Похоже, я мог бы использовать «ProcedureRequest», но у меня нет «субъекта», связанного с причиной, поэтому он выглядит так, что я не смогу его использовать. Могу ли я представить новое расширение на уровне ресурса, например («расширение resourceType»)? Я также не использую шаблон запроса, так как перед запросом есть проверка доступности между платформами. – user2462805

Уже существует возможность использовать код или строку, используя тип данных CodeableConcept в элементе Appointment.reason, чтобы указать причину. Однако в заявлении о проблеме говорилось, что вам нужно использовать ресурс. Поэтому я спрашиваю, какой ресурс вы хотите использовать. Если вы не уверены, можете ли вы объяснить, какие причины вы ожидаете захватить и поддерживать (и, самое главное, ссылку) отдельно? –

Я не использую указанные вами четыре ресурса, потому что это не соответствует моей архитектуре приложения. Вот как выглядит причина в моем приложении: http://pastebin.com/nECvfxqh Это автономный ресурс, который имеет ссылку на сами специальности, связанные с расписаниями. Например, пользователь (например, рисователь) может CRUD объяснить причину. Как мои причины касаются FHIR? – user2462805

Для нас «причина» в основном указывает, какой тип службы назначит назначение, поэтому мы на самом деле отображаем причины для услуг, которые мы представляем как ресурс HealthcareService.

В принципе, с точки зрения пациента, они заботятся о «причине», которую они направляют к врачу. Но с точки зрения поставщика медицинских услуг они заботятся о типе обслуживания, которое они будут предоставлять для лечения причины.

источник

2017-02-09 04:55:42 Cooper

Я понимаю, и это причина формы перспективы пациента, которую я хотел бы реализовать. Мне кажется, что HealthcareService немного перегружена тем, что я хочу реализовать. Причина в моем приложении также не связана с определенным местоположением, поэтому, я думаю, я не смогу реализовать его как HealthcareService. Как я мог реализовать его с точки зрения пациента? – user2462805

FHIR: Назначение по назначению как ресурс?

ответ

Смежные вопросы