We're updating the issue view to help you get more done. 

POST /ehr body format doesn't comply with JSON schema


We need to define valid payloads in JSON and XML for the POST endpoints that don't have a format defined. This leads to different representation of the same resource on different implementations.

Current body documented on https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#ehr-ehr-post

"_type": "EHR_STATUS",
"subject": {
"external_ref": {
"id": {
"_type": "GENERIC_ID",
"value": "ins01",
"scheme": "id_scheme"
"namespace": "ehr_craft",
"type": "PERSON"
"other_details": {
"_type": "ITEM_TREE",
"items": []
"is_modifiable": "true",
"is_queryable": "true"

Is not compliant with the JSON schema:


+ EHR_STATUS.name is mandatory on the schema
+ EHR_STATUS.archetype_node_id is mandatory on the schema

And a related item is to clarify the use for the _type field when the object doesn’t need it but the object is the root in the payload, like it happens on POST /ehr with the payload being EHR_STATUS, the EHR_STATUS._type is not required because the endpoint already know the expected type.

I think the _type documentation needs to clarify this case, current documentation for _type is: “Metadata attributes (those that are not also RM attributes) will always be prefixed by a '_'. One example is the _type attribute, which should be used to specify the RM type whenever polymorphism is involved or the underlying definition in RM type is abstract (dynamic type is different from the static type). This follows same rule as for XML typing. The value of this attribute MUST be the uppercase class name from the RM specification.“

REF: https://specifications.openehr.org/releases/ITS-REST/latest/index.html#design-considerations-data-representation


+ update the JSON examples for POST /ehr
+ clarify usage of _type for root objects in payloads where no polymorphism is present





Pablo Pazos