We have found a discrepancy in the way that Better CDR and EhrBase handle EHR_STATUS .isQueryable and .isModifiable when first created, if these are not explicitly derined in EHR_STATUS.
EhrBase defaults to false, whereas Better defaults to true.
//Format the ehrStatus object that needs to be sent in the Request body
const ehrStatus = {
_type: "EHR_STATUS",
archetype_node_id: "openEHR-EHR-EHR_STATUS.generic.v1",
name: {
_type: "DV_TEXT",
value: "ehr status"
},
subject: {
external_ref: {
id: {
_type: "HIER_OBJECT_ID",
value: '{{subjectId}}',
},
namespace: '{{subjectNamespace}}',
type: "PERSON" // This is overwiritten to 'PARTY_REF' in BetterCDR
}
},
// If not specified these default to false in EhrBase and true in BetterCDR
is_modifiable: true,
is_queryable: true
}
To keep things simple I would prefer the default to be true, as it is hard to think why/when you would ever create a ‘dead’ EHR in any normal circumstances but I could also support an argument that these should be made explicitly
const ehrStatus = {
_type: "EHR_STATUS",
archetype_node_id: "openEHR-EHR-EHR_STATUS.generic.v1",
name: {
_type: "DV_TEXT",
value: "ehr status"
},
subject: {
external_ref: {
id: {
_type: "HIER_OBJECT_ID",
value: '{{subjectId}}',
},
namespace: '{{subjectNamespace}}',
type: "PERSON" // This is overwiritten to 'PARTY_REF' in BetterCDR
}
},
// isQueryable and isModified not submitted - If not specified these default to false in EhrBase and true in BetterCDR
}
ah, sorry, I misunderstood and thought that you were referring to create an EHR without any payload (which I agree would be bananas). I see the same behavior. However, I’m not sure if this is properly defined how to behave and (not sure though) this could be related to the way Archie handles these properties.
@ian.mcnicoll the problem with that payload is that is_modifiable and is_queryable, AFAIK, are mandatory, so that payload might have been reported as invalid.
I will test that case on the Atomik CDR, I think it will trigger a JSON Schema error.
OT: I think creating an EHR without providing the ehr_status gives flexibility to the API, in fact is supported explicitly by the API, and allow to provide the subject data later.
I can see different arguments around CDR behaviour for defaults/ error triggering - just wanted to start the discussion so that one way or another we can reach consensus.
@Birger - did you indicate that if EHR_STATUS is not provided in EhrBase, then a default minimal version with isQueryable/Ismodifiable = true, is created. If so, then that may be different to Atomika
My interest is around developing Postman based training scripts that will work against any CDR, and to be able to demonstrate good compliance/alignment across the CDRs. Actually so far it is looking really good, which makes me even more determined to get to near 100%!!
I’m currently developing test cases for the same thing, just using a small openEHR REST Client I’m also building. The idea is to run and forget, then see the test report, but singular test case execution is supported too.
Not sure if I understand your question. EHRbase creates an EHR Status object because it is mandatory according to the RM and the specification of the REST API:
An EHR_STATUS resource needs to be always created and committed in the new EHR. This resource MAY be also supplied by the client as the request body. If not supplied, a default EHR_STATUS will be used by the service with following attributes:
is_queryable: true
is_modifiable: true
subject: a PARTY_SELF object
