medTech IG
0.1.0 - CI Build

medTech IG, published by medtech. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of https://github.com/HL7NZ/medtech/ and changes regularly. See the Directory of published versions

General

This page has general notes about the API.

Clinical Summary

The summary is retrieved using a custom operation - for example:

[host]/Patient/$summary?patient.identifier = https://standards.digital.health.nz/ns/nhi-id {nhi number}

Clinical Notes

Clinical (Consultation) notes are returned as DocumentReference resources, with the note itself in the content.attachment.data element as a base64 encoded string. The LOINC code for the resource is 11488-4.

Clinical notes can consist of a subjective and an objective note - each of which is represented in a single content elements. The content.format element distinguishes between the two using the following LOINC values:

  • 61150-9 Subjective Note
  • 61149-1 Objective Note

In the situation where there is only a Subjective or an Objective (but not both) then only the one available will be shown.

If there is neither subjective nor objective, then there is a single content element with the data absent reason extension having the value of ‘unknown’.

see the examples pages for examples.

External Documents

The DocumentReference resource is also used to refer to external documents such as discharge summaries. THe LOINC code is 34109-9. The content may either be in the attachment directly, or a url which is a reference to the Binary endpoint. The client can retrieve that document directly if needed.

Appointments

The APi supports appointment listing, creating and deletion.

Listing appointments for a patient

This is done using a search on Appointment, using the patient parameter.

GET [host]/Appointment?patient.identifier = {system} {value}

A bundle of matching appointments (which may be empty) is returned.

Creating an appointment

This is generally performed in 2 stages.

First the client determines which appointment slots are available to be booked. This is done by a query against the Slot endpoint, using a chained parameter on schedule to indicate the Practitioner desired. For example

GET [host]/Slot?schedule:actor.identifier={}&date=ge{date}&date=le{date}&status=free

Note that not including the status parameter would result in all slots over the period being returned, which is generally not desired.

Next, the actual appointment is created. This is done by creating an Appointment resource with the status element set to ‘proposed’ and POSTing it to the Appointment endpoint.

  • If the appointment can be created, then the updated Appointment (status=booked) will be returned with an http status code of 201 (created)
  • If the appointment cannot be created (for example if there is insufficient detail in the Appointment resource, or the requested time has been booked by another) then the query will be rejected with an http status code of 422 (Unprocessable entity)

Cancelling (deleting) an appointment

Appointments are cancelled using the DELETE verb. The id of the appointment must be known, so generally a search for the patient appointments must be done first.

Lab data

Laboratory information is returned as DiagnosticReport resources, with the contents contained in the .presentedForm element.

Structured data in the form of Observations are not yet supported (other than results which are mapped to screening data - for example a cholesterol result).

Screening data

Screening data is represented as Observation resources.

In the situation where a screening observation has been derived from a lab result, the lab result (a DiagnosticReport resource) will have a reference to the Observation in the DiagnosticReport.result element.