HL7 Norway FHIR DSTU-2 implementation guide

Package 'Rekvirent Service'

This section contains all the formal descriptions of how to apply HL7 FHIR to implement a Rekvirent client and service. These descriptions are collectively called 'conformance resources' in FHIR, and describe how Resources and the REST interface are adapted for use with the Rekvirent Service.

The following sections expect some familiarity with the conformance and profiling concepts of FHIR. If you want to learn more about these, you can read the background information in the FHIR specification. More information on how to develop software with FHIR in general and a FAQ can be found in the Help section of this guide.

Client and Server interactions

Data about prescribers is exchanged between a Rekvirent Repository and a Rekvirent Client. The Rekvirent Repository exposes the information about the prescribers for interested clients using the FHIR REST interface. The Rekvirent Client can contact the Rekvirent Repository to query information about prescribers, either by searching on names or identifiers or by asking for any changes on the server since a point in time.

The client and server use the FHIR REST interface according to the current (May 2015) DSTU2 specification.

The formal responsibilities for both these actors are described in the following FHIR ConformanceStatements:

  • Rekvirent Repository, which are the formal requirements for a system acting as the Rekvirent Repository.
  • Rekvirent Client, which are the formal requirements for a system acting as a client to the the Rekvirent Repository.

Structures

In this usecase, anyone or anything who can prescribe is called a 'rekvirent', and these rekvirents are more or less treated equally as rows in the DipsLinkViews.DLREKVIRENT view. In the FHIR interface however, the data in the view are split across three distinct Resources: Practitioner (rekvirents that are persons), Organization (rekvirents that are organizations) and HealthcareService.

Which parts of these resources are relevant for the usecase and what additional constraints on their use are defined by this package, is described in the following FHIR StructureDefinitions:

API extensions

There are two types of client that use the FHIR interface: a) those that understand the difference between Practitioners, Organizations and HealthcareServices and can handle searching and retrieval of resources using the specific FHIR endpoints for these resources and b) clients that collapse these notions and treat all data as 'rekvirents', corresponding to a single row in the view.

To support the second type of client, this package defines two extra search operations on top of the default FHIR searches. These searches allow a client to search for any Practitioner, Organization or Service based on a name or identifier, without having to call out to the separate FHIR endpoints for these resources. The extra operations are specified in FHIR OperationDefinitions:

  • rekvirentbyid, to search for any type of rekvirent using its Rekvirentcode, HERID, HPRnummer and Organisasjonsnummer.
  • rekvirentbyname, to search for any type of rekvirent by its Rekvirentnavn.
  • rekvirent, combines rekvirentbyid and rekvirentbyname
  • rekvirentbyrole, to search for all information about a rekvirent by it's role-id (Rekvirentcode, HERID).

For clients that do use the specific FHIR endpoints, this package has defined an extra search parameter for the Practitioner resource:

  • qidentifier, defines a way to search Practitioners by their qualification identifier, which is used to find Practitioners by their HPRnumber.
  • role-identifier, defines a way to search Practitioners by their role identifier, which is an extension used for Practitioner's HERID, and rekvirentnumber.
  • healthcareservice-identifier, defines a way to search HealthcareServices by their identifier.

Value Sets

This package defines one additional Value Set for this usecase:

  • rekvirenttype, which has codes for Norwegian specific coding of the type of rekvirent, used to code the kind of role of the Practitioner in FHIR.

Identifier systems

The data maintained by the Rekvirent Service has multiple data elements that represent Norwegian national identifiers for Practitioners and Organizations like HPRnumbers and HERids. These identifiers are represented in FHIR by unique numbers within identifier systems, which themselves are registered names. Although these are not specific to this usecase and will ultimately be hosted on a national registry for such identifying systems, this implementation guide maintains a list of Norwegian identifier systems used for this usecase for the convenience of implementers.