Provider Registry Implementation Guide
0.1.0 - ci-build
Provider Registry Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
The PR is closely tied to the Facility Registries. Queries such as
are common. Those queries that return Practitioners or PractitionerRoles are specified in this PR guide. There may be subsequent steps to retrieve say an Organization, Service or Location from other Registries.
The Provider Registry data should flow from the medical Councils of Sri Lanka, such as Medical Council into the Provider Registry. Although these interfaces are not explicitly specified in this guide it is anticipated that the interfaces MAY use standard create and update interactions, possibly in a bulk format such as a transaction Bundle. The frequency of updates and exact transport are unknown at this time.
The two primary use cases are:
These use cases are straightforward to implement with FHIR interactions to read, search, create and update. The data is dependent on the Council's data accuracy, pull frequency and timeliness.
The PractitionerRole Resources have been profiled twice by this guide. The LKPractitionerRoleStaffCategory profile is used for Council data that isn't part of the Practitioner Resource such as Staff Category and specialty. The second profile is LKPractitionerRoleServices and is explicitly designed to be associated with Facilities.
The Councils of Sir Lanka may collect contact information for licensing purposes; document delivery and referral contact points are not necessarily collected by the Councils.
Improvement 🔎 If the Provider Registry is to include contact information other than for the Council's purposes this data can be provided by other authorized sources and it's purpose (in FHIR terms, "use") clearly coded. Often the base FHIR set of use codes is not sufficient. E.g. default contact or emergency contact are not explicitly part of the use value set.