0

I'm implementing FHIR at the moment and I'm having trouble dealing with appointment reasons.

I know I can use the value set available here : https://www.hl7.org/fhir/valueset-encounter-reason.html

or implement my own value set for it but it's still problematic because reasons are a resource in my app and practitioners can add, modify and delete them. Reasons also have various fields such as a color, ...

A value set won't be enough for my app.

Do you have any hints / ideas on how could I implement such thing ?

user2462805
  • 1,049
  • 3
  • 11
  • 26

2 Answers2

1

So you want to point to Condition or Observation as a reason? Or perhaps point to a ReferralRequest or ProcedureRequest the appointment is based on? If so, submit a change request - having these things would also be in alignment with the Request pattern which Appointment should be trying to align with. In the meantime, you're free to define an extension to convey the same meaning.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • I meant, my users book an appointment for a specific reason in my app. They can't just book an appointment without precising "why" and this is done by precising a reason (e.g : "Dental consultation"). It looks like I could use a "ProcedureRequest" but I haven't got a "subject" linked to a reason so it looks I won't be able to use it. Could I introduce a new an extension at the level of a resource for example ("a resourceType extension")? I'm also not using the request pattern since there's an availability check between platforms before requesting. – user2462805 Feb 09 '17 at 08:46
  • There's already an ability to use a code or string using the CodeableConcept data type in Appointment.reason element to indicate a reason. However, your problem statement said you needed to use a resource. So I'm asking which resource it is you want to use. If you're not sure, can you explain what sorts of reasons you're expecting to capture and maintain (and most importantly, link) separately? – Lloyd McKenzie Feb 09 '17 at 13:58
  • I am not using the four resources you indicated because it does not fit to my app architecture. Here is what a reason looks like in my app : http://pastebin.com/nECvfxqh It is a standalone resource thats has a link to specialities themselves linked to schedules. A user (a practionner for example) can CRUD the reason. How should my reasons deal with FHIR ? – user2462805 Feb 09 '17 at 14:44
  • It seems that there was something planned for it in DSTU1 called "other" : https://stackoverflow.com/questions/18218866/which-fhir-resource-should-i-use-for-treatment-preferences – user2462805 Feb 09 '17 at 17:34
  • Appointment didn't exist in STU1. Your first step is to figure out what resource you're using for your stand-alone reason that can be pointed to by multiple appointments. Without understanding that, it's hard to give guidance on how Appointment should point to it. – Lloyd McKenzie Feb 09 '17 at 18:32
  • I would like standalone reasons because not only appointments can point to it but also other ressources such as schedule or slot for example. I'd like to know if I could create my own resourceType "reasons" instead of using the value set scheme. Would this be possible? – user2462805 Feb 13 '17 at 12:56
  • You can't create your own resource type, though you can leverage Basic. The concept of "reason" is actually a linkage between two things, so a resource called "reason" wouldn't make much sense. You could have Conditions, Procedures, Encounters and all sorts of other things that could serve as the "reason" for some other thing. What data would you be capturing in your "reason" resource? Do you have examples? – Lloyd McKenzie Feb 13 '17 at 17:03
  • A "reason" in my app is a visit motive or an appointment motive (visit and appointment are the same thing here). Sure, my visit motive is linked to my appointment but it is also a standalone resource in my app because you can CRUD it. A value set doesn't allow me to do all these actions on my visit motives that is why I can't use one and why I'm asking to create a "new resourceType". Here is the schema of my "visitMotive" a.k.a reason : pastebin.com/nECvfxqh – user2462805 Feb 13 '17 at 17:20
  • 1
    Ok, so that's not so much "reason" as "service definition" - i.e. a pointer to a standard service offering that has a name and description, identifies the types of individuals or resources required, identifies the expected duration, associated cost, etc. (Color seemed a little weird in your example?) With that understanding, now understand the problem. I'll get someone from the Patient Administration WG to respond with a specific recommendation. – Lloyd McKenzie Feb 13 '17 at 21:19
  • The color is there because when I fetch appointments in order to display them in a schedule, the appointment box is of the color of the visit motive (that way the reader can easily grasp what's coming next). Thank you for taking the time, it's gold ! – user2462805 Feb 14 '17 at 08:27
  • That makes sense. The color will almost certainly be an extension, whichever resource gets recommended, but it's a perfectly reasonable extension. – Lloyd McKenzie Feb 14 '17 at 12:15
0

For us, the "reason" basically indicates what type of service the appointment is going to provide, so we actually map reasons to services, which we represent reason as a HealthcareService resource.

Basically, from the patient's perspective, they care about the "reason" they are going to the doctor. But from the healthcare provider's perspective, they care about the type of service they will provide to treat the reason.

Cooper
  • 1,267
  • 11
  • 16
  • I understand and this is the reason form a patient's perspective I would like to implement. A HealthcareService seems a bit overkilled for what I want to implement I think. A reason in my app is also not linked to a specific location so I guess I won't be able to implement it as a HealthcareService. How could I implement it from a patient's perspective ? – user2462805 Feb 09 '17 at 08:49