Create EHR request defines invalid RM data for Ehr_Status about specifications-its-rest HOT 5 CLOSED

Default for EHR_STATUS.subject is PARTY_SELF - do you think it is sufficient to reword this text to:

When provided it will also be created as part of the same request, otherwise default EHR_STATUS will be created automatically by the service with the following defaults:

is_queryable: true
is_modifiable: true
subject: PARTY_SELF

All other attributes will be left empty (null).

from specifications-its-rest.

@ehrscape yes, that deals with the issue.

Do you think it would be worth suggesting a REST specific set of values for mandatory fields inherited from LOCATABLE? EHR_STATUS should also have a name and an attribute id,

The spec could either suggest values for these, or express that these values should be assigned by the implementing back-end.

If you think about it, "all other attributes will be left empty (null)" should not include name and archetype id.

from specifications-its-rest.

Sorry, realized I am using the wrong half of my split personality ;-)

It will be a real pain to list all of these attributes, how about something like:
When provided it will also be created as part of the same request, otherwise default EHR_STATUS will be created automatically by the service with the following defaults:

is_queryable: true
is_modifiable: true

All other attributes will be created as needed by the backend.

from specifications-its-rest.

I think as long as there is a clear statement that allows implementers understands what to do, all is well. may I suggest the slightly amended version:

All other attributes will be created as needed by the backend to ensure that a valid RM type instance is created.

(I'm a bit explicit when it comes to instructions, your version is just fine too..)

from specifications-its-rest.

I love it! Will reword like you suggest.

from specifications-its-rest.