openEHR / specifications-ITS-REST

openEHR REST API Specifications
https://specifications.openehr.org/releases/ITS-REST/latest
Apache License 2.0
18 stars 15 forks source link

Create EHR request defines invalid RM data for Ehr_Status #63

Closed serefarikan closed 6 years ago

serefarikan commented 6 years ago

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:

All other attributes will be left empty (null)

The subject property of Ehr_Status is mandatory. The subject can have a null external_ref but I think the subject should still exist.

ehrscape commented 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).

serefarikan commented 6 years ago

@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.

bostjanl commented 6 years ago

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.

serefarikan commented 6 years ago

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..)

bostjanl commented 6 years ago

I love it! Will reword like you suggest.