There are at least two common scenarios in dealing with
Compositions which would be enabled by the addition of a status
The first is a user's need to save something in 'draft' state,
e.g. because they have run out of time to finish writing part of
the Composition, or due to an emergency. In hospitals this may
well be a common occurrence. Such draft Compositions cannot be
saved locally on the client machine, since this represents a
security risk (a small client-side database would be much easier
to hack into than a secure server). They must therefore be
persisted on the server, either in the actual EHR, or in a
'holding bay' which was recognised as not being part of the EHR
proper. Either way, the author would have to explicitly retrieve
the Composition(s) and after further work or review, 'promote'
them into the EHR as 'active' Compositions; alternatively, they
might decide to throw them away.
The second scenario is the need to be able to represent states
like 'active', 'inactive' and 'deleted' of Compositions in a system.
(The 'deleted' state is of course only logical - in a
medico-legally safe record, nothing can be actually deleted).
In both scenarios, it should be possible to change the status of a
Composition without actually changing the Composition itself -
i.e. without creating a new version.