Stream: implementers
Topic: Scheduling Service Type Representation
Cooper Thompson (Sep 22 2021 at 16:08):
Which method would you intuitively used to represent a service that is being scheduled? Is a simple CodeableConcept sufficient (e.g. Schedule.serviceType), or would you want a full resource (e.g. HealthcareService, CatalogEntry, ActivityDefinition, a new resource, etc.)?
Note that I'm not asking what should be used in the current spec. I'm asking what seems to be the most intuitive.
Lloyd McKenzie (Sep 22 2021 at 16:17):
I suspect it depends what you have available and what detail you need to refine - same sort of thing as medications. If you've got a registry of stuff, pointing to that registry is useful. If all you've got is a code system, that's what you'll use. And if you need to (and have the capability to) create a customized version specific for what you're doing, that might exist as a contained or even a custom instance in the registry
Cooper Thompson (Sep 22 2021 at 16:34):
We are considering making serviceType a CodeableReference to HealthcareService, such that HealthcareService is the resource that represents the set of schedulable services. This gives HealthcareService a dual meaning, so we'd have a "class" (name tbd) property to differentiate.
Lloyd McKenzie (Sep 22 2021 at 16:48):
HealthcareService is not about a 'specific' service, but more a capability. So you might have a HealthcareService for "imaging" or "lab", but you'd never have a HealthcareService instance for "Head CT scan" or "Hemoglobin".
Lloyd McKenzie (Sep 22 2021 at 16:48):
Those sorts of things, if defined at all, would likely exist as ActivityDefinition instances or ObservationDefinition instances.
Cooper Thompson (Sep 22 2021 at 17:34):
Many implementers do create HealthcareService resources for stuff like CT scans. The problem is that everyone except insider standards nerds intuitively arrive at HealthcareService as the resource to use (based on several Jira trackers, some chat.fhir threads, and personal experience). So PA is considering making that "official" so that the the standards nerds and everyone else are aligned.
Lloyd McKenzie (Sep 22 2021 at 18:14):
I'd rather that we change the name of HealthcareService if there's that much confusion. Much of the elements on HealthcareService make zero sense when you're talking about fine-grained service definitions.
Lloyd McKenzie (Sep 22 2021 at 18:44):
Also, for fine-grained, we already have a resource for ActivityDefinition, ObservationDefinition and ChargeItemDefinition, so if we wanted ayet another resource that lived at that same granularity, its purpose would need to be clearly distinct.
Cooper Thompson (Sep 22 2021 at 19:08):
I actually took a full pass at the HealthcareService properties, and they almost all line up with exactly what we have in our schedulable service (which we call a visit type). That is why we (Epic) landed on HealthcareService - it wasn't because of the name.
Cooper Thompson (Sep 22 2021 at 19:12):
But the point of this topic was to get input from implementers, not for standards nerds to debate. I think we've failed at that, as folks skimming the topic so far will get the bias we wanted to avoid :(.
Peter Jordan (Sep 22 2021 at 19:52):
Lloyd McKenzie said:
HealthcareService is not about a 'specific' service, but more a capability.
One of the example uses of HealthcareService stated in the spec is for National Service Directories - and that's how it's being used in NZ. This usage does require details of specific services (including granular availability details) and a fair number of extensions. Maybe an additional resource might better serve this use case but IMO , and for R4 anyway, HealthcareService is the best resource for service directories.
Mikael Rinnetmäki (Sep 23 2021 at 07:10):
Cooper Thompson said:
But the point of this topic was to get input from implementers, not for standards nerds to debate. I think we've failed at that, as folks skimming the topic so far will get the bias we wanted to avoid :(.
Luckily you can also use a retrospective approach. :)
In Finnish specification (https://simplifier.net/FinnishSchedulingR4) HealthcareService is referenced. It is profiled to refer to a national code system of healthcare service types (see https://simplifier.net/guide/FinnishSchedulingR4ImplementationGuide/Scopeandbasicscenario).
Mikael Rinnetmäki (Sep 23 2021 at 07:12):
When browsing through the results of the Simplifier query https://simplifier.net/search?text=scheduling, there seem to be other references to HealthcareService too.
Cooper Thompson (Sep 23 2021 at 14:43):
@Mikael Rinnetmäki Brilliant!
Brian Postlethwaite (Sep 23 2021 at 16:20):
This was the issue that we discussed, and the resolution on the change that we're putting into R5 to permit a more detailed catalog. https://jira.hl7.org/browse/FHIR-22687
Mike Ryzhikov (Nov 09 2021 at 11:52):
Hello! Who can provide an up-to-date summary of this discussion? What are the next practical steps?
1) The FHIR community is going to rename the HealthcareService resource and leave the scope of resource as "class of service" (like "lab", "imaging", etc.)
2) or extend (add ref) the scheduling resources like slot, schedule, appointment, and use HealthcareService as a specific service item (CT scan, MRI, etc.). - https://jira.hl7.org/browse/FHIR-22687
@Lloyd McKenzie @Cooper Thompson @Brian Postlethwaite - Thanks
Brian Postlethwaite (Nov 09 2021 at 20:52):
The details in the item are quite explicit as to what we're changing. Maybe need to click more details to see the disposition in jira if viewing on mobile.
Lloyd McKenzie (Nov 15 2021 at 04:13):
How can one differentiate between HealthcareService instances that are "service catalog" type things vs. what the resource was originally created for - a high-level capacity available at a specific site (e.g. imaging, emergency, etc.)? Some of the attributes on HealthcareService (e.g. endpoint, availabilityTime) really make no sense when you're talking about a catalog entry at a detailed procedure code level.
Lloyd McKenzie (Nov 15 2021 at 04:13):
(@Brian Postlethwaite)
Last updated: Apr 12 2022 at 19:14 UTC
