Northern Region Implementation Guide
0.2.0 - CI Build
Northern Region Implementation Guide, published by healthAlliance. This is not an authorized publication; it is the continuous build for version 0.2.0). This version is based on the current content of https://github.com/HL7NZ/northernRegion/ and changes regularly. See the Directory of published versions
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.
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 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.
Also check out the Logical models. These represent the alterations that made to the individual resource types to suit the needs of the project in a ‘simple to understand format’. For example, new elements are added and others removed. FHIR Profiles represent the information in these models represented in the FHIR conformance artifacts and show the content of the actual data exchanged. (You can think of the Profile as being the technical representation of the Model)
The following models are defined in this guide:
The links above give significant detail of these models. The Snapshot table on each page is the best place to start (Note that model is also called a ‘profile’ in these pages - this is not the same as the FHIR profiles in this guide)
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.
There is also a ‘companion’ application under the support tab that will have a number of features aimed at implementers. This app is not part of the actual IG, but rather is intended to support implementers. Currently there is a single function that allows sample queries to be made against a test server with sample data in it, and then display the result in a number of formats. There are a number of sample queries that can be chosen, but they can be edited by the user as required.
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.
This is to be added.