some question while testing FerroEHR default RM=1.2.0

Implementation Platform
1

1- The example from template contains only the context part
curl -v -u ferroehr:ferroehr -H ‘Accept:application/openehr.wt.flat+json’ http://localhost:8080/ferroehr/rest/openehr/v1/definition/template/adl1.4/PAM_UC_Covid_Report/example

but the result is very minimal, that is restricted to context only:

{“ctx/language”:“en”,“ctx/territory”:“US”,“ctx/composer_name”:“Example composer”,“ctx/time”:“2022-02-03T04:05:06Z”,“ctx/setting”:“238”,“pam_uc_covid_report/category|value”:“event”,“pam_uc_covid_report/category|code”:“433”,“pam_uc_covid_report/category|terminology”:“openehr”}
2-When I try to insert a composition (that works in EHRbase) in FLAT format it does not recognize time, width and math_function fields belonging to the event part of each Observation
e.g., “pam_uc_covid_report/patient_characteristics/age/time”: “2022-02-03T04:05:06”,

Screenshot_20261021_173230
Screenshot_20261021_1732301558×640 100 KB

3-Error in a datetime element that passes in EHRbase

{“message”:“1 validation error(s)”,“validationErrors”:[“/content[openEHR-EHR-SECTION.adhoc.v1,‘Molecular diagnosis’]/items[openEHR-EHR-OBSERVATION.laboratory_test_result.v1,‘SARS-CoV-2 molecular test’]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0015,‘Date of collection’]/value: temporal value ‘2022-02-03T04:05:06’ does not satisfy the pattern ‘yyyy-mm-ddTXX:XX:XX’”],“error”:“Unprocessable Entity”}
4-Observation’s encoding and language apparently ignored. They are in the submitted composition but not in the retrieved one
5- history_origin added to each Observation with current time value

2

Thanks again for testing FerroEHR so thoroughly. Here are all five points in one place, plus the start-time follow-up, which turned out to be a real bug.

1. The template example shows only context fields

That’s the default level of detail. The example endpoint takes detail_level with required, medium or complete, and FerroEHR defaults to required. That level contains only what the template makes mandatory. In your template all the clinical content is optional, so only the context is left. Ask for the full example instead:

GET /ferroehr/rest/openehr/v1/definition/template/adl1.4/PAM_UC_Covid_Report/example?format=FLAT&detail_level=complete

The complete example also shows the exact FLAT path FerroEHR expects for every element, which helps with point 2.

2. time, width and math_function in the event part are not recognised

FerroEHR builds its FLAT paths from the web template, and the event fields hang under the event node, for example …/age/any_event:0/time. When EHRbase accepts …/age/time directly under the observation, the two web templates name that event differently for your template.

The detail_level=complete example from point 1 shows the paths FerroEHR uses for your template. If they still don’t fit, please open an issue at Issues · FerroHEALTH/FerroEHR · GitHub with the OPT attached, and I’ll pick it up from there.

3. '2022-02-03T04:05:06' does not satisfy pattern 'yyyy-mm-ddTXX:XX:XX'

FerroEHR is right to refuse this. The constraint comes from your template. In an openEHR date/time pattern, XX means “not allowed” and ?? means “optional”. So yyyy-mm-ddTXX:XX:XX allows a date and no time at all. A value with 04:05:06 breaks that constraint. EHRbase accepts it because it doesn’t check temporal patterns that strictly.

You can fix it from either side:

  • send the date alone (2022-02-03), which is what the template asks for;
  • or change the template to allow a time, for example yyyy-mm-ddTHH:MM:SS, or yyyy-mm-ddT??:??:?? to make the time optional.

The current message doesn’t say which parts are required, optional or not allowed. That’s being improved under A temporal pattern refusal does not say which date or time parts are required, optional or not allowed · Issue #3918 · FerroHEALTH/FerroEHR · GitHub.

4. Observation language and encoding missing from the FLAT you get back

They’re stored. Fetch the same composition as canonical JSON and you’ll find them on every observation, with the values you sent. The FLAT output leaves them out on purpose. In the Simplified Formats spec, each entry’s language defaults to ctx/language and its encoding to UTF-8 (the “Language and Territory” section). Your values are exactly those defaults, so FerroEHR writes them only when they differ, which keeps a FLAT round trip stable. Sending them does no harm.

5. A history_origin with the current time on each observation

HISTORY.origin is mandatory in the RM, so FerroEHR fills it when the input doesn’t. The Simplified Formats spec says an unset origin is set to the time of the earliest event. FerroEHR takes, in order:

  1. ctx/history_origin;
  2. the earliest event time in that observation;
  3. the composition’s context time.

Your observations have no event time (see point 2), so they fell through to the third.

The follow-up: your context/start_time is ignored for those defaults

You were right about this one, and it’s a bug. pam_uc_covid_report/context/start_time and ctx/time name the same value. FerroEHR stores the path form correctly as the composition’s start time. But the defaults that hang off it, each observation’s history origin and event time, are worked out only from ctx/time. Without ctx/time, FerroEHR used the moment of the commit, which is why every origin showed yesterday’s time.

It’s filed as A FLAT context/start_time path spelling does not feed the history-origin and event-time defaults · Issue #3919 · FerroHEALTH/FerroEHR · GitHub. The fix makes the path form feed the same defaults as ctx/time. Until it ships, any one of these gives the right origins:

  • send "ctx/time": "2022-02-03T04:05:06", in place of or beside the context/start_time path;
  • set the event times, so each origin follows its earliest event;
  • set ctx/history_origin once, or …/history_origin on each observation.

None of these points comes from RM 1.2.0 itself: they’re template constraints, Simplified Formats defaults. Thanks again for reporting these :slight_smile: