FHIR: Причины назначения в качестве ресурса?

В настоящее время я внедряю FHIR, и у меня проблемы с объяснением причин назначения.

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

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

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

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


hl7-fhir dstu2-fhir hapi-fhir
person user2462805    schedule 08.02.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

person Lloyd McKenzie    schedule 08.02.2017
comment
Я имел в виду, что мои пользователи записываются на прием по определенной причине в моем приложении. Они не могут просто записаться на прием, не уточнив причину, и это делается путем уточнения причины (например, стоматологическая консультация). Похоже, я мог бы использовать ProcedureRequest, но у меня нет темы, связанной с причиной, поэтому похоже, что я не смогу ее использовать. Могу ли я представить новое расширение на уровне ресурса, например (расширение resourceType)? Я также не использую шаблон запроса, поскольку перед запросом выполняется проверка доступности между платформами. - person user2462805; 09.02.2017
comment
Уже есть возможность использовать код или строку с использованием типа данных CodeableConcept в элементе Appointment.reason для указания причины. Однако в вашей постановке проблемы говорилось, что вам нужно использовать ресурс. Поэтому я спрашиваю, какой именно ресурс вы хотите использовать. Если вы не уверены, можете ли вы объяснить, какого рода причины вы собираетесь фиксировать и поддерживать (и, что наиболее важно, ссылаться) отдельно? - person Lloyd McKenzie; 09.02.2017
comment
Я не использую указанные вами четыре ресурса, потому что они не подходят для архитектуры моего приложения. Вот как выглядит причина в моем приложении: pastebin.com/nECvfxqh Это автономный ресурс с ссылки на сами специальности, привязанные к расписаниям. Пользователь (например, практик) может использовать CRUD для причины. Как мои причины должны быть связаны с FHIR? - person user2462805; 09.02.2017
comment
Похоже, что для этого было запланировано что-то в DSTU1 под названием другое: stackoverflow.com/questions/18218866/ - person user2462805; 09.02.2017
comment
Назначения в STU1 не было. Ваш первый шаг - выяснить, какой ресурс вы используете по своей отдельной причине, на которую можно указать несколько встреч. Не понимая этого, трудно дать указания, как назначение должно указывать на это. - person Lloyd McKenzie; 09.02.2017
comment
Мне нужны отдельные причины, потому что на это могут указывать не только встречи, но и другие ресурсы, такие как расписание или слот, например. Я хотел бы знать, могу ли я создать свои собственные причины resourceType вместо использования схемы набора значений. Возможно ли это? - person user2462805; 13.02.2017
comment
Вы не можете создать свой собственный тип ресурса, хотя можете использовать Basic. На самом деле концепция разума - это связь между двумя вещами, поэтому ресурс под названием «разум» не имеет особого смысла. У вас могут быть условия, процедуры, встречи и всевозможные другие вещи, которые могут служить причиной для чего-то другого. Какие данные вы бы собирали в своем ресурсе разума? У вас есть примеры? - person Lloyd McKenzie; 13.02.2017
comment
Причина в моем приложении - это мотив посещения или мотив встречи (здесь посещение и встреча - это одно и то же). Конечно, мотив моего визита связан с моей встречей, но это также отдельный ресурс в моем приложении, потому что вы можете использовать CRUD. Набор значений не позволяет мне выполнять все эти действия с мотивами моего посещения, поэтому я не могу его использовать и почему я прошу создать новый resourceType. Вот схема моего посещения Motive, также известная как причина: pastebin.com/nECvfxqh - person user2462805; 13.02.2017
comment
Хорошо, это не столько причина, сколько определение услуги - то есть указатель на стандартное предложение услуги, которое имеет имя и описание, идентифицирует типы лиц или требуемых ресурсов, определяет ожидаемую продолжительность, связанные с этим затраты и т. Д. (Цвет казался немного странно в вашем примере?) С таким пониманием, теперь разбираемся в проблеме. Я попрошу кого-нибудь из РГ по работе с пациентами дать вам конкретную рекомендацию. - person Lloyd McKenzie; 14.02.2017
comment
Цвет присутствует, потому что, когда я беру встречи, чтобы отобразить их в расписании, поле встречи имеет цвет мотива посещения (так читатель может легко понять, что будет дальше). Спасибо, что нашли время, это золото! - person user2462805; 14.02.2017
comment
В этом есть смысл. Цвет почти наверняка будет расширением, какой бы ресурс ни был рекомендован, но это вполне разумное расширение. - person Lloyd McKenzie; 14.02.2017

arrow_upward
0
arrow_downward

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

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

person Cooper    schedule 09.02.2017
comment
Я понимаю, и это причина, по которой я хотел бы реализовать точку зрения пациента. Мне кажется, HealthcareService немного перегружен тем, что я хочу реализовать. Причина в моем приложении также не связана с конкретным местоположением, поэтому я думаю, я не смогу реализовать ее как HealthcareService. Как я могу реализовать это с точки зрения пациента? - person user2462805; 09.02.2017