New Zealand Health Terminology Service (NZHTS) Implementation Guide
0.1.0 - ci-build
New Zealand Health Terminology Service (NZHTS) Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
| FHIR Conformance statement for Ontoserver® |
NZHTS instance of Ontoserver implementing the HL7 FHIR terminology server specification |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| New Zealand Immunisation Reaction Event |
An Observation recording an adverse reaction event following a COVID-19 immunisation, where the reaction is coded from a reference set that exists only in the SNOMED CT New Zealand edition. The profile adds one meaningful constraint: a required binding of Reading that URL left to right:
A terminology server holding the NZ edition (such as NZHTS) expands this URL directly, so the reference set does not have to be copied into this IG as an extensional ValueSet - contrast NZSmokingStatus, which enumerates its concepts and must be maintained by hand as the underlying content changes. The binding is what makes the reference set enforceable: a validator configured against a server holding the NZ edition will expand the implicit URL and reject any code that is not a member. Naming the edition in instancesConforming instances must set This is not decoration. It is what lets a validator - or any consumer - determine which terminology server can answer questions about the code. The terminology server registry declares NZHTS authoritative for the pattern: which matches on system and version. A coding that gives only Version pinningBoth the implicit ValueSet URL above and Pinning trades currency for reproducibility: a pinned URI stops resolving once that release is no longer served. This profile and its examples use the unpinned edition URI so that they track the current NZ edition. Use in contextIn R4 an immunisation reaction is referenced from
|
These define sets of codes used by systems conforming to this implementation guide.
| New Zealand Smoking Status |
An extensional, version-pinned representation of the New Zealand smoking status reference set. |
These define new code systems used by systems conforming to this implementation guide.
| SNOMED CT NZ Edition Smoking Status Fragment |
A non-authoritative fragment of the SNOMED CT New Zealand Edition containing the concepts used by the New Zealand smoking status reference set. This resource exists to support local IG publication and validation; SNOMED CT NZ Edition remains the authoritative terminology source. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| COVID-19 Immunisation Example |
The COVID-19 immunisation that the adverse reaction event followed. As with the reaction, |
| Immunisation Reaction Event Example |
An adverse reaction event following a COVID-19 immunisation.
Setting the version is not merely documentation. It is what allows a validator, or any consumer, to
work out which terminology server can answer questions about this code. The
terminology server registry
declares NZHTS authoritative for The version here is the edition URI, with no release appended, meaning "the current release of the
NZ edition". It could be pinned to a specific release - |
These are resources that are used within this implementation guide that do not fit into one of the other categories.
| smoking-status-example |