Stream: v2 to FHIR
Topic: SCH-7 and SCH-8 Mapping
Hans Buitendijk (Mar 11 2021 at 16:33):
@Brian Postlethwaite , @Irma Jongeneel : Does PA have any guidance on how the SCH-7 (Appointment Reason) and SCH-8 (Appointment Type) best mapped to Appointment as both seem to best go to Appointment.type given vocabulary where FHIR is using the SCH-7 table, not the SCH-8 table.
Camila Altman (Mar 12 2021 at 15:57):
Adding email that @Craig Newman send to Alex:
Alex,
As part of the v2-to-FHIR transformation project, we ran across an issue that we’d like some clarification on. We’re hoping you can help us.
SCH-7 (Appointment Reason) is defined as “an identifier code for the reason that the appointment is to take place. This field may contain a Universal Service ID describing the observation/test/battery/procedure or other activity that is to take place during the requested appointment. It may also contain a site-specific code describing a pre-defined set of reasons that an appointment may be set to occur.” It uses a user-defined table with suggested values:
image.png
These suggested codes don’t seem to match well with the Appointment Reason but rather seem more relevant to SCH-8 (Appointment Type) which is defined as “the identifier code for the type of appointment”. SCH-8 references a different user-defined tables with suggested values:
image.png
These values are suggestions only; they are not required for use in HL7 messages.
These suggested codes don’t really seem like “types” by the usual definition.
Do you know how systems are using these two fields today? Are these values commonly used?
Our issue comes when we try to map these fields to the FHIR Appointment resource. There is an Appointment.appointmentType element (defined as “The style of appointment or patient that has been booked in the slot (not service type)”) which uses the v2 value set for table 0276 used by SCH-7 (Appointment Reason) even though the definition of the FHIR element is more in line with SCH-8. As well, there is an Appointment.reasonCode element (defined as “Coded reason this appointment is scheduled”) which is bound to a preferred value set containing SNOMED codes for procedures, findings, events, etc.
Any suggestions on how the v2 and FHIR data elements and value sets align with each other? If it’s easier to talk through this, our team meets Mondays from 1-2 Eastern and Tuesdays from 11-12 Eastern and we can add this to the agenda for one of these calls if you can make one of these times.
Thanks
Craig, Camila and Hans
Craig Newman (Mar 22 2021 at 17:10):
@Brian Postlethwaite , @Irma Jongeneel - any thoughts on this topic? We're still not sure how the Appointment.type element is defined relative to the v2 fields. Thanks.
Brian Postlethwaite (Mar 23 2021 at 09:51):
@Cooper Thompson sorry to add you to the stream, do you have any v2 scheduling experience to cover this one?
Cooper Thompson (Mar 23 2021 at 13:30):
We use SCH-7 as the primary field for identifying the type of the visit in v2. We don't use SCH-8 at all. For FHIR, we use Appointment.serviceType for the same content as SCH-7. Examples of what we put in SCH-7/Appointment.serviceType include: Consult to Allergy, Office Visit, Dental Treatment, Well Child, Flu Shot, Renal Biopsy, etc. Appointment.reason seems to map to DG1 (kinda?).
Last updated: Apr 12 2022 at 19:14 UTC
