dbojicic-agency
commented
3 years ago Analysis of codes from ObservationStatus
| Code | In / Out for vital signs | Rationale |
|---|---|---|
| registered | Out | Does not serve the purpose of sharing a vital sign. |
| preliminary | Out | Does not serve the of sharing a vital sign. |
| final | In | Supports use case of of of sharing a vital sign. |
| amended | Out | The utility for sharing a vital sign or vital sign panel for amended is not obvious. |
| corrected | In | Supports use case where a vital signs has been determined as inaccurate and a replacement vital signs observation "corrected" is sent. |
| cancelled | Out | Does not serve the purpose of reporting of results. |
| entered-in-error | In/Out | This serves the use case of updating a grouper e.g. a list or a document, to indicate the entry that is incorrect - this may be paired with a 'corrected' entry. |
| unknown | Out | Does not serve the purpose of sharing a vital sign. |
The shallow analysis suggests
- code "final", "corrected", "entered-in-error" are relevant; in most circumstances only "final" is relevant. Only where the intention is to cater for the correction of vital sign observations and making clear
dtr-agency
Prerequisites
The issue
We need to support the exchange of observations of vital signs between consumers, healthcare providers, and between consumers and healthcare providers and the My Health Record system infrastructure in Australia.
In order to support this exchange we need to consider a more constrained set of values for the status of the observation than is available by definition.
In support of FHIR specifications the values must be drawn from the required ObservationStatus ValueSet. Possibly the new ValueSet may contain the codes of "preliminary", "final", "amended", "corrected" excluding "registered", cancelled", entered-in-error" & "unknown". Another possibility is that the Observation.status has a value of "final".
This constrained set of values may be used directly in CDA implementation guides, or may be supported by v3 Value Set ActStatus.
What it actually enables people to do
Clarifies to implementers requirements for the state of an observation in the electronic exchange of vital signs between healthcare providers, and between healthcare providers and the My Health Record system infrastructure in Australia. Provision of management of the set of values in a governed manner that is reusable across multiple profiles.
How awesome would it be?
Pretty awesome - clarity of requirements is always desired, and management by terminology binding is the preferred means in CI Agency profiles of specifying more than one allowed values for an element. This contributes to minimising the risk of inappropriate, invalid or obsolete clinical content.
Workarounds
There are other means of specifying controls on the membership of values including invariants, or alternatively only implementation guidance could be provided instead of a machine processable format.
Additional context
This is a part of https://github.com/AuDigitalHealth/ci-fhir-r4/issues/106.
Constraints applied in other FHIR implementation guides: