Comments have previously been made in Sprint 1 that a UK Core ValueSet should be considered for the PractitionerRole.specialty element, and further comments supporting that position have been made against the release 0.1.0 HL7UK ballot.

The ballot comment is due to be discussed at weekly reconciliation meetings by members of the HL7UK board and others.

Given the restriction to just a single instance of this data, one additional concept that may have a use in the UK is "urgent follow-up".

Create a UKCore-AppointmentReasonCode ValueSet consisting of the entirety of the standard v2.0276 and UKCore-AppointmentReasonCode CodeSystems.

Change the binding of Appointment.appointmentType to the new UKCore-AppointmentReasonCode ValueSet with an "extensible" binding strength.

Elements in other UK Core profiles where the <<71388002 (Procedure) SNOMED CT hierarchy is used have a binding to the UKCore-ProcedureCode ValueSet (ValueSet UKCore-ProcedureCode), which refers to both the <<71388002 (Procedure) and <<129125009 (Procedure with explicit context) SNOMED CT hierarchies.

Include guidance to not use the "referral by [person/service] / referral to [person/service]" type concepts if the data is covered by other elements.

Include guidance to explain the SNOMED Expression Constraint Language (ECL) used in the ValueSet definition.

Use the "preferred" binding strength.

Some Sprint 5 Call 3 discussion points:

• Adding concepts to the ValueSet which include context depends to some extent on whether the lifecycle of the ServiceRequest resource is covered by other elements within the resource (e.g. status, intent, doNotPerform).
• It is understood that the Procedure hierarchy should cover all things that are likely to be requested e.g. enrolment on a care plan, referral for physiotherapy.
• As the ServiceRequest resource is intended to be used for general referrals, there could be duplication of context carried within the .code element as well as other elements but this is not considered an issue.
• The hierarchy with explicit context will include "referral by [person/service]" and "referral to [person/service]" concepts there is potentially overlap with further elements of the ServiceRequest resource. If any such concepts are not appropriate for the .code element then it would be expected that systems would recognise this rather than it being appropriate to explicitly exclude parts of this hierarchy within a ValueSet definition.

The use of text might be considered more appropriate for the type of data that the definition describes.

Currently there is no BARS use case for this element.

Clinicians often use investigation results as a reason for a referral. Similarly with events. Whilst it is possible to convey some of these kinds of information via a reference to another resource with that data using the reasonReference element, it may suit some implementers to be able to carry the same data within the reasonCode element instead, and therefore the ValueSet should explicitly identify further sets of concepts to support this.

Change the binding for ServiceRequest.reasonCode to the new UKCore-ServiceRequestReasonCode ValueSet with an "extensible" binding strength.

Change the binding of Questionnaire.code to the new UKCore-SNOMEDCT ValueSet. This reflects a more preferred default CodeSystem for the UK Core than LOINC but may require further discussion in the future.

For the Questionnaire.item.code element, SNOMED CT is not a suitable default CodeSystem. In the absence of any specific CodeSystem requirements at this level, the proposal is to remove the current FHIR standard binding and leave this element unbound.

Update 12/05/2022:
- The ValueSet used for binding to the Questionnaire.code element has been called UKCore-QuestionnaireQuestionCodes.
- No change to the binding of the Questionnaire.item.code element has been made as it has not been possible to revert to unbound where a binding has already been specified in the FHIR standard profile.