Closed serefarikan closed 6 years ago
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).
@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.
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.
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..)
I love it! Will reword like you suggest.
The documentation for the post operation (to create an EHR) suggests that if no ehr_status attribute is provided in the body, an instance should be created with is_queryable and is_modifiable fields. It then states:
The subject property of Ehr_Status is mandatory. The subject can have a null external_ref but I think the subject should still exist.