Northern Region Implementation Guide
0.4.6 - CI Build

Northern Region Implementation Guide, published by healthAlliance. This guide is not an authorized publication; it is the continuous build for version 0.4.6 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7NZ/northernRegion/ and changes regularly. See the Directory of published versions

Home

Official URL: http://fhir.org.nz/ig/northernregion/ImplementationGuide/fhir.org.nz.ig.northernregion Version: 0.4.6
Active as of 2024-10-16 Computable Name: NorthernRegionIG

Background

This is the draft the Northern Region Implementation Guide.

Currently it covers all the FHIR design work being done for the Northern Region - in effect it describes the capabilities of the API's being developed to expose data from internal sources across the Northern Region. Currently, these are read-only. In the future, it is possible that further guides will be developed to cover specific sets of use cases with specific requirements particularly where update via API is supported.

Guide for use

General notes

In general terms, this guide is targetted towards those wishing to implement applications that access the data exposed through the Northern Region RESTful APIs, and assume a familiarity with FHIR. However, there are also aspects that will be of interest to Clinical Informaticians and Business Analysts.

  • The FHIR specification is quite readible, and has many links to details of the spec. There are a number of guides on the front page that give a summary to different audiences

If you are a Clinician / BA:

The Use Cases give examples of how the API's are intended to be used. The term 'API' (stands for Application Programming Interface) describes the technical details of how an external application (or 'client') can access the data being exposed.

The Design Notes page will be of interest to clinicians interested in informatics. It describes the resource types that are available, and some of the background around the choice of resource - as there are often different ways to do something in FHIR, depending on the exact requirements.

If you are an Implementer:

  • The Artifact Index lists all FHIR artifacts in the guide, with links to details on each one. The most significant ones at present are

    • The API describes the different API's exposed by the solution and the contents of tab is directly generated from the CapabilityStatement resource, which is the machine readible description of the API.
    • The profiles that describe the structure of the resource instances returned by queries are found on the Artifact Index page (as are all the other FHIR artifacts). Like logical models, the snapshot tab is the most useful summary, but there is a lot of detail about each profile. Each profile page also contains links to examples of resource instances conformant to the profile.

Tabs in this guide

  • The Table of contents lists all tabs and page headings. It is automatically generated by the tooling
  • The Use Cases form the 'technical' requirements of the API from a business perspective. They are derived from more detailed Use cases and
  • Design Notes are notes to implementers about how to implement the guide. In particular it has diagrams that show how the resources connect with each other in graphs to represent specific Use Cases
  • The Artifact Index is also generated by the tooling and lists all the FHIR profiles, extensions and termibology defined by the guide. It also has the Logical Models which represent the information being expressed by the profiles in a more easy to understand manner.
  • The API tab describes the different API's exposed by the solution. These are the actual RESTful queries that a client can make.
  • The Support dropdown has a number of links - specifically a link to the FHIR specification (release 4) and a download of all the FHIR artifacts
  • the Development tab contains links and documentation used in the development of the guide. Once complete, these will be removed.

'Must Support'

Elements in FHIR profiles have the concept of 'must support' which is indicated in both the models and the profiles with a red 'S' as the flag. The definition of what this means is vague in the spec, and is generally used to indicate elements of particular importance. In this guide, the expectation is that a client must understand what the meaning of these elements are, and have a strategy to deal with them - they cannot be ignored if present. Generally this will be making the user aware of their value.

This is not the same as a required element, as 'must support' may still be absent. For example, if 'language' is marked as must support, then it should be displayed in the User Interface, but may not be present for every patient.

Security

This is to be added.