I believe null flavour codes can be extended by the implementation, then harmonized with the openEHR terminology, because we need first the examples from the use cases to start defining new codes.
Current codes are few …
… and semantics are not well defined in the specs AFAIK:
https://specifications.openehr.org/releases/RM/Release-1.1.0/data_structures.html#_overview_2
Data values are connected to spatial structures via the value attribute of the ELEMENT class of the representation cluster. This class also carries the attribute null_flavour, whose value indicates how to read the contents of the value attribute. Values from the openEHR null flavours vocabulary, including 253|unknown|, 271|no information|, 272|masked|, and 273|not applicable| are used to populate it. Only a small number of generic codes are defined, in order to avoid complex processing for most data instances, for which this simple classification of null is sufficient.
In some circumstances however, additional detail is required in addition to the null flavour code. Examples include reporting and where specific reasons for lack of data have medico-legal ramifications, e.g. ‘patient was unconscious’, ‘patient refused to tell me’, ‘no reason provided’. For these situations, the optional null_reason field may be used to record a specific reason.