So we’ve had some interest in New Zealand concerning Provider registries – locations where the details of providers and the services they provide can be maintained and discovered. There are a lot of potential uses for such a registry, but the two that we’ve been discussing are locating targets for referrals, and locating providers by specialty as part of Care Pathways.
Typical query use cases could include:
- Find a Provider by name (or other personal detail)
- Find a Provider by specialty – eg a physiotherapist
- Locate a Service provided by a facility like a hospital
There are lots more of course, but these will get us started.
So looking at FHIR, there are a number of resources that we’re going to need.
(Note that we’ll use the STU3 candidate version from January this year as this is the version currently on the public HAPI3 server which we’ll use for this. There are a number of differences planned for the final release of STU3 – most notably the removal of role information from the Practitioner resource – but these won’t affect this discussion.)
Here are the resources of interest (the links are to the current build – I’ll update them to the final STU3 version once that is released):
The Practitioner resource represents a person involved in the delivery of healthcare – a doctor, nurse, physio, receptionist – pretty much any human (or animal for that matter). This is a human Provider.
The PractitionerRole resource. This represents the role/s that a Practitioner can be in – details of the role, where they perform it, the times they are available and so forth. This is a new resource and was split off from the Practitioner specifically to support this kind of use. (See Brian Postlethwaites blog for more discussion on this point, and why the change was made which was driven by practical experience at Connectathons). Note that a single Practitioner can have multiple roles
The HealthcareService describes an actual service (rather than a person) that is provided by some organization. For example a Cardiology outpatient clinic at a hospital, or a primary care service. This is a service Provider.
The Organization represents the grouping of people or companies that are delivering care. It’s a rather abstract thing that isn’t the actual place where care is delivered (that’s the location) – rather the entity that organizes the care (hence the name I guess)
The Location is the actual place where care is delivered – the physical hospital or Primary Care/ambulatory care clinic.
Note that the term ‘Provider’ applies both to people (Practitioners) and services (HealthcareService). We’ll use the specific FHIR term in the following discussion.
Here’s an image of how the resources inter-relate:
This was generated using the Scenario Builder in clinFHIR. I set the Conformance and Data server to the public HAPI3 server and added a single instance of each resource type to the scenario. Then, I set the various references between resources, added some data to them and saved the lot to the Data server so I could check the queries. There are references to other resources of course, and the diagram does not indicate the multiplicity of the references – but it’s easy for you to do this yourself if you want to experiment further.
As you can see there are 2 main resources that pull everything together – the PractitionerRole (which lets us find individual Practitioners) and the HealthcareService, which is about Services rather than people.
Let’s think about what queries we’ll need to meet our Use Cases.
Before we do this, just a reminder that each resource type has a number of search parameters defined in the specification. A server is not obliged to support all of them (it indicates which ones using the CapabilityStatement resource), and can support others (which it documents using the SearchParameter resource)
Find a Practitioner by name
To start with, let’s assume we know the Practitioners name, and just want their personal details (like phone number or email). In this case we’re just querying the Practitioner resource. Here’s a sample query we could use:
http://fhirtest.uhn.ca/baseDstu3/Practitioner?name=welby
It will return all the Practitioners whose name is Welby. Simple. And, of course, we could use any of the defined search parameters that are supported by the registry.
Note that this query will not return any role based information (this is one place where the final STU3 version will differ from the candidate version that we are using) – see the link to Brians post above for more information on why this was done.
Find a Practitioner with a given specialty
Moving on, let’s think how we can find Practitioners by specialty.
Because the specialty is associated with the PractitionerRole and not the Practitioner, our query will be on PractitionerRole. (Note that a single Practitioner can have multiple PractitionerRoles of course). Here’s a query that will return the Practitioner roles for cardiology (where 394579002 is the SNOMED term for cardiology).
http://fhirtest.uhn.ca/baseDstu3/PractitionerRole?specialty=394579002
(Note that you should really specify the system when doing a lookup on coded elements – so the more accurate query would be:
http://fhirtest.uhn.ca/baseDstu3/PractitionerRole? specialty=http://snomed.info/sct|394579002
but I’ll leave that out to keep the queries more understandable.
This will return a bundle of PractitionerRole resources – useful, but we really want the names of the Practitioners. We could do separate queries for each Practitioner of course, but we could also take advantage of the _include search parameter. The following query will return the PractitionerRoles, but will also include the referenced Practitioners in the bundle as well:
http://fhirtest.uhn.ca/baseDstu3/PractitionerRole? specialty=394579002&_include=PractitionerRole:practitioner
and why stop at the Practitioner? Let’s get the Organization and Location as well:
http://fhirtest.uhn.ca/baseDstu3/PractitionerRole? specialty=394579002&_include=PractitionerRole:practitioner& _include=PractitionerRole:organization& _include=PractitionerRole:location
This will return all the needed resources in a single query (assuming server support of course).
Find services
If we want to locate services rather than people, then a query on HealthcareService is required. There are a number of different coded elements that we could use:
- serviceCategory
- serviceType (eg the specialty of the service)
- specialty
as well as other query parameters such as
- location
- providedBy
- coverageArea
so the queries used are going to be very dependent on the actual implementation.
For the purposes of this post, let’s assume we’ve used the service type as the element to query on – eg Cardiology clinic or Physiotherapy service. The following query will return all the HealthcareService resources where the type is Cardiology.
http://fhirtest.uhn.ca/baseDstu3/HealthcareService? servicetype=http://hl7.org/fhir/service-type|165
Note that the ValueSet (and hence system) used for the serviceType is different to the specialty ValueSet used by Practitioner.
Of course we can use the _include search parameter to include referenced resources in the query – location and providedBy (Organization) would seem two likely candidates.
Last thoughts
So we’ve taken a – very – superficial look at how we could implement a Provider registry in FHIR. The design of a real system will be a lot more complex of course, and careful thought will need to be given on which relationship are important.
I suspect that the main issues in implementing such a registry will not be technical, but rather around governance – who has the right to update and access this information.
One thing that did stand out for me as I was preparing this post was how there are a number of coded elements with ValueSets that will need to be chosen and defined for a particular implementation – such as PractitionerRole.service or Healthcareservice.category (there are lots of others, and don’t even think about extensions!)
This is, of course, where profiling comes in to play…
Cheers…
BTW – if you’re interested in a ‘real’ Implementation guide for a Provider Directory, check out the Argonaut Provider Directory . (Note that this is the development version – I’ll replace with the ‘released’ version when that is ready).