4

I would like to add to add a custom extension to my Schedule resource. In my app, Schedule have visit motives (reasons). I know there's a list of classified appointments / encounter reasons but I would like to use mine.

I have something like this :

{
  "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"
      }
    ]
  }
}

I'm not sure about this part :

"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"
      }
    ]
  }

Is it correct to add an extension this way ? There are always multiple visit motives for a specific schedule so I have to list them.

I also have seen this kind of things :

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

Which one is the correct one or am I wrong ?

user2462805
  • 1,049
  • 3
  • 11
  • 26

1 Answers1

4

There are several issues here:

  1. It seems odd to capture a "reason" on a schedule. A schedule says when a particular clinician or clinic or other resource is available. E.g. "Dr. Smith takes appointments Mon/Wed/Fri from 1pm-4pm". So if you were to capture a reason on the resource, it would reflect "Why does Dr. Smith have a schedule?" Typically reasons are captured for an individual Appointment. That's the resource that reserves a particular slot for a planned visit. And Appointment already has an element for reason where you're free to use your own codes or just send text.

  2. You have extensions to convey identifiers, but Schedule already has an element for identifiers. Why would you use extensions instead of the standard element? Note that you can use the "system" and/or "type" components to differentiate different kinds of identifiers.

  3. You're sending "identifier", "type", "name", etc. as simple strings - but they're complex data types, so you need to communicate the child elements

  4. actor is of type Reference - that means you need to point to the Practitioner resource. You can't send the properties in-line. (If the Practitioner only exists in the context of the Schedule, you could use the "contained" approach which would use an internal reference, but containment doesn't seem to make sense in this use-case.

  5. The URL for your extension contains ValueSet, which isn't correct - extensions are all structure definitions. Also, there shouldn't be a # symbol in the URL.

  6. Your syntax for extensions is incorrect. You can't introduce new properties in FHIR. The property name for all extensions is just "extension". You differentiate by the URL. So your syntax should be:

{
  "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"
  }
}
Phillip Copley
  • 4,238
  • 4
  • 21
  • 38
Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • First of all, thank you for you detailed answer! 1.Reasons are linked to a schedule in my app. A schedule can't have an appointment that is out of its reasons list and I need the people who are using my api to know which reasons supports the schedule. 2. Got it. 3. My mistake, I understand it now. 4. Got it ? 5. Ok, got it. 6. Perfect, that's exactly what I came here for but you just provided much more informations, THANK YOU so much ! – user2462805 Jan 24 '17 at 17:12
  • You might consider capturing reasons at a the slot level - that's more typical of where you'd put constraints on what sort of appointments can be booked. However, if you really need it at the schedule level, then you're using extensions correctly - they give you a way to support atypical requirements. – Lloyd McKenzie Jan 24 '17 at 21:07
  • I think the use case here is what we consider provider blocks. For example, Dr. Smith may only want to accept "well child" visits from 8-10, existing patient office visits from 12-5. He can also accept new patient visits from 12-2 (so 12-2 can be either new or existing). I wonder if it would make sense to hang a 0..* reference to HealthcareService off of Slot so you can indicate what services a specific provider's Slot can support (since the HealthcareService link from Schedule and actor are both 1..1, which isn't sufficient for the either-or scenario). – Cooper Jan 26 '17 at 22:35
  • That sounds like Slot is the appropriate location. Feel free to make the recommendation as a change proposal. – Lloyd McKenzie Jan 27 '17 at 04:46