Appt Avail Mgmt - FHIR Changes: 'Schedule' Resource, Value Sets Uplift - Booking Org Type, Practitioner Role, Delivery Channel

[jackiebarnes]

Need Extensible Value Sets:

Org Type GP Practice Urgent Care

Practitioner Role GP Practice Nurse Healthcare Assistant Phlebotomist Pharmacist

Delivery Channel In-person Telephone Video

'Schedule' resource to be uplifted to include extensions for Practitioner Role and Delivery Channel

Updated: (following Comment content below)

Changes to be made:

1. Schedule Resource

   • Extension for Practitioner Role, cardinality = Must Support, referencing SDS-Job-Role value set (Can't use Prac Role on the Practitioner Resource, as this is not mandatory on Schedule resource, therefore must be extension)

   • Extension for Delv Channel, cardinality = Must Support, referencing new value set

2. CareConnect-GPC-Organization-1

   • Bind 'Type' element within the resource to the new Booking Org Type valueset as it currently has an example valueset, and make Must Support

3. Value Set for Booking Org Type = GP Practice, Urgent Care - with Dave to confirm

4. Value Set for Delv Channel = In-person, Telephone, Video

5. Value Set for Prac Role to be SDS-Job Role (for info: restricted for GP Connect within business rules to values:

R0260 | General Medical Practitioner R0620 | Staff Nurse R1480 | Healthcare Assistant

[jackiebarnes]

Dave to consult as to Org Type contents and standardisation across other domains

[james-answer]

We have just had a discussion around the valueset and how it would appear in the profile. We feel like the valuesets should be extensible and we will put buisness rule in to stop provider populating the element with codes which are not in the valueset.

The reason we think it should be extensible is so that we can add new values for requirements which come out of FOT or as part of work with other programs such as urgent care but without having to change the specification version as consumers will expect potentially different values than the one that were in the valueset at the time they implement their solution.

[DaveBarnet]

The Roles you have should come from the "Care Connect SDS Job Role Name" valueSet (https://fhir.nhs.uk/STU3/ValueSet/CareConnect-SDSJobRoleName-1). For delivery channel we will have to make up a FHIR valueSet

@james-answer - we have Practitioner as an optional element on Schedule already - and SDS-Role-Profile-ID - can we use this? - find the correct subset?

[jackiebarnes]

@james-answer

Do we include Booking Org Type as an element on Appt resource - Booking Org already added as an ext? - haven't specified this to D Stds as yet?

Should these be mandatory or optional?

See prev comment for question as to SDS-Role Profile - and using a subset of this?

Should Practitioner Role and Delivery Channel on the Schedule resource be mandatory/Must Support/Optional? this is to be populated by Provider; if these data items are not a mandatory requirement for the end-user to select when creating the cross-org booking profile, then they will potentially not bother, thereby invalidating some of the potential bens from standardisation; if only some GP practices use them, then they become unreliable for any future reporting, or even for reliability of info when a consumer comes to book

[james-answer]

@jackiebarnes

We could bind 'type' element within the CareConnect-GPC-Organization-1 resource to the new valueset as it currently has an example valueset. We could then put in the business rules that this should be populated if they have it.

In the profiles the 'type' elment should be optional so the organization resource can be used for other things.

I think the SDS-Role should be fine, we would want to restrict the set as if the list is too long people will not choose from it.

The practitioner role and delivery channel was discussed in the decision log and people came to the agreement that they should be optional in the profile despite the risk that people might not choose an option. We should make it must support so if a provider has it then they should include it in the profile. We can word the specification to say that providers should make users select an option for practitioner and delivery channel. I agree that if we say that it is optional for the user they might not and the risk as you have said is that if the information is un-reliable people will not use it.

[jlellison]

Please can you confirm the status of the new ValueSets etc. do you want these to be 'active' like the existing Appointments and Slots?

[james-answer]

I think we can make the ValueSets 'active' like the existing ones for appointments as we are going to have providers and consumer build against them.

[jlellison]

@jackiebarnes @james-answer

Is tehre any reason you didn't choose the codes for a Phlebotomist and a Pharmacist from the SDS Job Role Code CodeSystem? I am creating a ValueSet for GP Connect that uses this CodeSystem but cherry picks the relevant codes. Do you want me to add R1290-Pharmacist and R1590-Phlebotomist?

From JB: we decided and just reviewed in a Clinical Assurance mtg that the three we've specified will be sufficient for now

[jlellison]

If you want to review any of the new ValueSets and CodeSystems created for the release they are in the following repository: https://github.com/nhsconnect/STU3-FHIR-Assets/tree/feature/GPConnectAppointments

[james-answer]

Thanks, they look ok to me.

The reason we did not choose Pharmacist or Phlebotomist is because for our FOT it is unlikely that there will be a Pharmacist or Phlebotomist at the GP Practice so would not be likely to be used for bootking appointments into the GP Pactice. We assume the list will get longer after we get feedback from the FOTs.

[jlellison]

That's fine, if things need adding to the CodeSystem later down the line this is a relatively quick minor change to make.

[jlellison]

Updated profiles released to https://fhir-test.nhs.uk/ for review.

[james-answer]

Changes look good, we will close this issue off once the changes go to live.

[jlellison]

Released to live.

[jackiebarnes]

@james-answer The 'Type' element is not currently Must Support; we did prev agree on this - is there any reason why it shouldn't be this card.? If not can we move it back into 'For Data Stds' on project Kanban board and ensure Jen is notified

[james-answer]

@jackiebarnes We can use this ticket and move it back for data stds to make the change.

[jackiebarnes]

@jlellison Please can you make the 'Type' element Must Support - have moved the ticket back to your column

[jlellison]

Hi @jackiebarnes I will have to pick this up when I return from leave the w/c 26th March

[jackiebarnes]

Confirmed with Data Stds that this change will be made

[jackiebarnes]

Using SDS-Roles as the values within the GP Connect Practitioner Role valueset is causing confusion when Providers also use the SDS Roles within their Appointment Book configuration.

Need to change the existing values within our GP Connect 'set' to be more generic and distinct from SDS roles. Should be no other impact other than on the actual values:

R0260 | General Medical Practitioner = 0001: General Practitioner R0620 | Staff Nurse = 0002: Nurse R1480 | Healthcare Assistant = 0003: Healthcare Assistant

[james-answer]

After talking to other TA's about this valueset there is a strong feeling that we should open up the full list and use the care connect valueset for job roles:

https://fhir.nhs.uk/STU3/ValueSet/CareConnect-SDSJobRoleName-1

Then on the Additional Provider Requirements put a SHOULD requirement that the providers restrict this list down to only the relevant job roles for the practice on which the appointment book is being created. This is to try and tackle the issue of giving the end user two many options when setting up the appointment book.

There is a general concensus that allowing for more variation should not cause any problems for the consumer as they are generally aware of the different job roles and most of the job role names that are likely to be shared through gp connect are going to be obvious from the name so this should not cause a problem.

The benefit of allowing the whole list on the api level is that it allows for greater flexibility without having to change the specification.

[jlellison]

@james-answer just to clarify the new change request... do you now want the Practitioner Role Extension from the schedule resource to use the SDS Job Role Code ValueSet (https://fhir.nhs.uk/STU3/ValueSet/CareConnect-SDSJobRoleName-1) instead of the GP Connect Practitioner Role ValueSet (https://fhir.nhs.uk/STU3/ValueSet/GPConnect-PractitionerRole-1) with the amended ValueSets that Jackie listed above?

[james-answer]

Hi @jlellison I think there is still some disagreement as to which way we should be going, opening up the valueset or creating a very generic valueset not linked to the SDS roles. Do you and Dave have an opinion on this from a Data Standards perspective?

[briandiggle]

Or..option 3) create a "primary care" valueset which is a subset of https://fhir.nhs.uk/STU3/ValueSet/CareConnect-SDSJobRoleName-1 whose values exclude roles which will never be found in GP practices.

[DaveBarnet]

At the moment both https://fhir.nhs.uk/STU3/**ValueSet**/CareConnect-SDSJobRoleName-1 and https://fhir.nhs.uk/STU3/**ValueSet**/GPConnect-PractitionerRole-1 are based on the same https://fhir.nhs.uk/STU3/**CodeSystem**/CareConnect-SDSJobRoleName-1 code system. Practitioner Role just selects certain values from the SDSJobRoleName codeSystem, which reflects Brian's post exactly. In terms of what I'd recommend, this would be the as-is situation (as outlined here - i.e. both the SDSJobRoleName & PractitionerRole valueSets based on the same code system (SDSJobRoleName codeSystem). This seems most sensible, as both valueSets represent job roles of practitioners. However, if there's a compelling business reason to use a different valueSet for Practitioner Role, then we must listen to the business & react accordingly. However, in this case I can't see why using PractitionerRole (based on a subset of SDSJobRoleName) is an issue. Having a different codeSystem for PractitionerRole would mean that PractitionerRole is a different concept. If this is a different concept then we should have a different codeSystem, if PractionerRole is the same concept as SDSJobRoleName, it should be from the SDSJobRoleName codeSystem.

[jackiebarnes]

@james-answer Based on Dave's comment above, and outcome from meeting with Jonny, Brian, Richard today, I think the conclusions are:

Keep using the codeSystem SDSJobRoleName Do we then use SDSJobRoleName-1 or GPConnect-PractitionerRole-1?

• presumably the latter, but add more values, so that it can still represent a GP Practice-related subset, but be a more comprehensive list, as requested by EMIS?

[jackiebarnes]

Decision:

Continue to use the codeSystem SDSJobRoleName Continue to use the GPConnect-PractitionerRole-1

Validating the following enhanced list of values for the GP Connect subset with EMIS & TPP

R0260 | General Medical Practitioner R0270 | Salaried General Practitioner R0410 | Student Practice Nurse R0600 | Specialist Nurse Practitioner R0610 | Sister/Charge Nurse R0620 | Staff Nurse R0680 | Midwife R0690 | Community Practitioner R0700 | Community Nurse R0790 | Dietitian R1290 | Pharmacist R1300 | Psychotherapist R1310 | Clinical Psychologist R1330 | Social Worker R1450 | Health Care Support Worker R1480 | Healthcare Assistant R1550 | Counsellor R1590 | Phlebotomist R6200 | GP Registrar R6300 | Sessional GP

[jackiebarnes]

@jlellison - please could you extend the value set GPConnect-PractitionerRole-1 to include the added values above

[jlellison]

Released to production server: https://fhir.nhs.uk/STU3/ValueSet/GPConnect-PractitionerRole-1