Is anyone else having trouble opening the review or review content for https://ckm.openehr.org/ckm/archetypes/1013.1.6366/reviewscontent - ? I just get a blank screen.
@ian.mcnicoll its working fine for me (i am using brave)
…working fine for me. Any more details? Browser etc?
chromium edge browser. Macos. Worked ok with Chrome but was very slow loading initially. Other reviews in edge are fine. Very odd.
Working now - managed to save my review but still very slow to load again, unlike all my other recent reviews on other archetypes that reload instantaneously. Very weird
I think I see what you mean now, not the overview page itself is slow to load, but loading your individual review is?
I can reproduce that - is that what you mean?
I had a look at the backend and the asset that holds your review is in itself retrieved very quickly so there must be something else going on here and we need to take a closer look.
I believe I know what they problem is here.
I first thought it was an indexing problem, but this does not seems to be the case.
However, this archetype has introduced a pattern for slots which is problematic.
There are 4 slots in the archetype that use a slot constraint that effectively says
All archetypes (the .*) + the organisation archetype + the address archetype.
Example:
This causes CKM to calculate all archetypes available for that slot (and the three other ones) so that they can be displayed when you click on the “Included” button.
And this is what takes a long time (and that x4 because of 4 slots).
The only reason why displaying the archetype itself (standalone, without any reviews) is fast (but displaying a review with the archetype is slow) is because the standalone display is cached.
Technically, this slot constraint is not necessary and I believe problematic.
As long as the slot exclusion is not set to exclude everything else, the stated inclusion is a recommendation only anyway.
We can possibly do something in CKM to identify special inclusion patterns such as this one and then stop identifying all available archetypes in cases like this, but I can only recommend to not use slot patterns like this.
Changing the 4 slots from e.g.
allow_archetype CLUSTER[at0021] occurrences matches {0..1} matches { -- Origin
include
archetype_id/value matches {/.*|openEHR-EHR-CLUSTER\.organisation\.v1|openEHR-EHR-CLUSTER\.address\.v1/}
}
to
allow_archetype CLUSTER[at0021] occurrences matches {0..1} matches { -- Origin
include
archetype_id/value matches {/openEHR-EHR-CLUSTER\.organisation\.v1|openEHR-EHR-CLUSTER\.address\.v1/}
}
will fix this without changing the meaning of the slot statement.
Yes that was it- just the indivbidual review - makes sense . As you say this inclusion pattern is redundant. I’ll feed back to the archetype Editor - @MartinMilde
Thanks for the heads up. This might be an issue with the UI of Archetype Designer. I’ll discuss this with the team.
With next release, we will be picking this special case up in CKM and just say it is (effectively) all Cluster archetypes, so that it “works” (but I maintain that this is an anti-pattern).
We’ve also finetuned the display to make it clearer what “Include” and “Exclude” actually mean according to the specification.
-
See Origin Slot - the “include” (non-)constraint just means “all Cluster archetypes”.
-
Also see the “Structured place of admission” Slot where the include constraint has been adjusted/corrected.
This Slot is still open to other archetypes (because there is no “exclude” constraint), but it identifies two specific slot archetypes which can be understood as strong recommendations. -
Finally, if the slot is closed (because there is an exclude all constraint), it would also tell you that explicitly as in this example from a different archetype:
Feedback very welcome - I thought a while about the different cases and hope that this is more intuitive while still faithful to the spec.