Indeed, and probably correct. This bit of the spec is obviously naive, and should either be considered a logical database schema, with the computational form being an active object with built-in cursors and so on.
I suggest that the simplest thing to do right now given the specs is to document the EHR object as a logical DB structure, and make it clear that the model shown in the RM is distinct from that in the REST API.
That’s the point: it’s NOT unexpected.
The REST spec shows the requests and responses, where some are full RM and some are “API RM”, objects which should be formally defined in the SM (Service Model) and have their own JSON Schemas if you want a proper, fully compliant implementation.
Side note: in our JSON schemas we do have an API flavor, so you can do a diff and reveal which types change in the API. That is what I use to validate payloads in my REST API implementation in Atomik.
I didn’t mean to post anymore, but while implementing the REST API I stumbled upon this section in the REST API specifications:
Clients MAY request that object references (e.g., OBJECT_REF) be resolved into full or partial representations by specifying:
Prefer: return=representation, resolve_refs
This is particularly useful when retrieving lists of COMPOSITION resources within an EHR, where the default behavior is to return only reference links.
Let me quote the last sentence 
:
This is particularly useful when retrieving lists of COMPOSITION resources within an EHR, where the default behavior is to return only reference links.
@richard.kavanagh was correct afterall:
@Seref @pablo Argumentation without linking to the specifications is just an opinion. It is dangerous when an authority figures do it.
My opinion is that text should be changed, since to retrieve linked objects for an EHR in full is not practical for the number of potential objects that could be linked to an EHR. I believe whoever redacted that was thinking more of providing an example than a hard rule. If you look at the get EHR by id endpoint, the response doesn’t have linked objects.
This is what’s expected (last version):
{
"system_id": {
"value": "d60e2348-b083-48ce-93b9-916cef1d3a5a"
},
"ehr_id": {
"value": "7d44b88c-4199-4bad-97dc-d78268e01398"
},
"ehr_status": {
"id": {
"_type": "OBJECT_VERSION_ID",
"value": "8849182c-82ad-4088-a07f-48ead4180515::openEHRSys.example.com::1"
},
"namespace": "local",
"type": "EHR_STATUS"
},
"ehr_access": {
"id": {
"_type": "OBJECT_VERSION_ID",
"value": "59a8d0ac-140e-4feb-b2d6-af99f8e68af8::openEHRSys.example.com::1"
},
"namespace": "local",
"type": "EHR_ACCESS"
},
"time_created": {
"value": "2015-01-20T19:30:22.765+01:00"
}
}
This is what was expected from version 1.0.0 (I think this was from 2017 when we released the first spec):
{
"system_id": {},
"ehr_id": {},
"ehr_status": {},
"time_created", "...",
... // to be defined, possibly counts of compositions, contributions, etc.
}
Found: OpenEHR REST EHR API
Some key aspects:
If that’s is what’s expected, then that’s not RM, and I think the wording on the paragraph you shared is what’s inconsistent, not the response payload.
Again, what we lack, beside this part says this and that part says that, is a formal spec of the objects managed in the API, requests and responses, not only responses, and that’s the role of the SM, which most don’t even consider when implementing and testing openEHR and I find it a very rich place to specify formal APIs, which also allows conformance testing.
One small thing to note: in previous versions of the REST API spec, the endpoint wasn’t called “get EHR by id”, it was called “get EHR summary by id”, still the response payload is the same. I find the “summary” part has special meaning here since it’s explicitly saying “this is not the full EHR”. EHR API
PS: I do like to link specs 
The response example shows them as OBJECT_REFs.
The response example still looks like an EHR RM class to me (except without contributions, compositions, folders attributes).
I miss _type property on every object. Even if REST API doesn’t use RM classes, it would be immediately clear which non-RM class is used.
This is what Richard and I were saying but everyone ignored it. We don’t mind what the SEC decides to change. We were just trying to point out the inconsistencies.
The linked OpenAPI YAML file documents the requests in 4898 lines 
The fact that it is missing its own types for the responses might mean that all the responses use RM classes 
That’s weird, I pasted the response examples in the previous message and there is no object_ref mentioned.
Anyway, I think all positions are clear.
What I would suggest is you @borut.jures or @richard.kavanagh to raise a ticket in the openEHR JIRA with your findings, we can add/discuss there.
Continuing discussing about what we consider to be correct when it’s clear the specs needs improvements is futile.