# Default for EHR commit isQueryable and isModifiable

**Category:** [ITS](https://discourse.openehr.org/c/its/41)
**Created:** 2023-04-17 17:10 UTC
**Views:** 450
**Replies:** 12
**URL:** https://discourse.openehr.org/t/default-for-ehr-commit-isqueryable-and-ismodifiable/3865

---

## Post #1 by @ian.mcnicoll

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

---

## Post #2 by @pablo

IIRC both `true` is the default when no EHR_STATUS is provided.

---

## Post #3 by @pablo

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

https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2/ehr.html#ehr-ehr-post

---

## Post #4 by @birger.haarbrandt

@ian.mcnicoll  which version of EHRbase are you using? I just tried it and the defaults are "true" as well.

---

## Post #5 by @ian.mcnicoll

0.24 - defaults to false

---

## Post #6 by @birger.haarbrandt

Not on my computer  :eyes:

---

## Post #7 by @ian.mcnicoll

POST EHR
```
      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

        }
```

Response:

```
      "archetype_node_id": "openEHR-EHR-EHR_STATUS.generic.v1",
        "uid": {
            "_type": "HIER_OBJECT_ID",
            "value": "b9d349d4-cd0c-4460-8649-6542c392026e::freshehr.cloud.org::1"
        },
        "is_modifiable": false,
        "is_queryable": false
    },
```

```
<status>
    <ehrbase_version>0.24.0-SNAPSHOT</ehrbase_version>
    <openehr_sdk_version>1.24.0-SNAPSHOT</openehr_sdk_version>
    <archie_version>2.0.1</archie_version>
    <jvm_version>Eclipse Adoptium 17.0.5+8</jvm_version>
    <os_version>Linux amd64 5.19.0-23-generic</os_version>
    <postgres_version>PostgreSQL 13.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424, 64-bit</postgres_version>
</status>
```

---

## Post #8 by @birger.haarbrandt

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.

---

## Post #9 by @ian.mcnicoll

[quote="birger.haarbrandt, post:8, topic:3865"]
However, I’m not sure if this is properly defined how to behave
[/quote]

that why I was asking here first. :frowning:

---

## Post #10 by @pablo

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

---

## Post #11 by @ian.mcnicoll

[quote="pablo, post:10, topic:3865"]
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.
[/quote]

I agree with that.

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%!!

---

## Post #12 by @pablo

[quote="ian.mcnicoll, post:11, topic:3865"]
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.
[/quote]

Do you need to use postman?

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.

---

## Post #13 by @birger.haarbrandt

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
```

---


**Canonical:** https://discourse.openehr.org/t/default-for-ehr-commit-isqueryable-and-ismodifiable/3865
**Original content:** https://discourse.openehr.org/t/default-for-ehr-commit-isqueryable-and-ismodifiable/3865