Is there a date of publication in an archetype?
Not afaik. But CKM does keep history of itās archetypes. Under the āarchetype historyā tab. You can see the version that been pubished including the date. Whatās your use case, is this sufficient?
(Please note after major changes you need to open the preceding archetype to find the original date of publication)
well, no, thatās not a really a good answer for me - unless CKM has a public API I can find out on, I guess. Weāll discuss later elsewhere whether thatās a problem for anyone downstream from me
CKM has an API, I donāt know whether itās public and contains the version history, @sebastian.garde can tell you more.
Now Iām extra curious for your goals.
well, Iām working on converting archetypes to FHIR profiles, and looking for an equivalent of FHIR StructureDefinition.date.
Iāll leave the wider ramifications of why Iām doing that to elsewhere.
2 Likes
The API is public, yes - see https://ckm.openehr.org/ckm/rest-doc
When you GET the metadata for one archetype it also returns the modification time of the requested revision of the archetype (by default the latest revision, which may be published/stable or unstable/in development).
1 Like
Reading the definition of structuredefinition.date ā The date (and optionally time) when the structure definition was last significantly changed. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the structure definition changes.ā
Iām not sure the publication date of an archetype is the best mapping. For example archetypes are often updated with small (and sometimes major) changes after the original publication date.
And the publication date saus more about the last time itās community reviewed, which in theory could be totally separate from the changes in the ADL.
The date of the last change of the CKM archetype is also easier to get. I think the āmodificationTimeā on the /archetypes endpoint is a pretty good match. Although Iām not familiar with the exact behaviour of that attribute. It might be updated when some meta data of the archetype changes without a change in the ADL. If this is a problem, Sebastian will probabaly be willing to help you.
P.s. are you aware of the CKM-mirror on GitHub, it should also have the information you are looking for.
I agree. For any revision of an archetype (for example https://ckm.openehr.org/ckm/rest/v1/archetypes/1013.1.6153?asset-version=4) the modificationTimeis the datetime that revision was committed to trunk. Every revision has a SemVer 2.0 revision, so you can tell whether the revision is
- draft (0.0.1-alpha)
- initial publication (1.0.0)
- a breaking change after initial publication (X.0.0)
- for example removal or changed data type of an element
- a non-breaking change after initial publication (X.Y.0)
- for example addition of an element
- a non-semantic change after initial publication (X.Y.Z)
- for example addition of a translation or fixing a typo
2 Likes
I think it would be really nice to get the modification time in the archetype metadata. Is that possible?
Not currently from the archetype itself, only from the ckm or GitHub api. Are your suggesting changing the archetype (meta) model to add this attribute? I could see the use of that. It would be a change to probably the authored resource class in the BASE spec. Resource Model.
Starting point would be a Problem Report on https://openehr.atlassian.net/ and then for the SEC to pick it up.
I think it would be interesting to see if we can make this resource model spec more compatible with FHIR. And maybe even make it a singular/jointly governed model.
Timing is quite good for this I think. Given that for our adl2.4 migration itās relevant.
1 Like
I thought it would be just another piece of metadata, and it wouldnāt need a spec change? At least, not to the reference model?
In the shorter term, it could be added as a new element in RESOURCE_DESCRIPTION/other_details ?
2 Likes
Well. If we go the route of Siljeās suggestion it wouldnāt need a spec change. But it would be implementation specific. Eg only works for CKM. I wouldnāt mind doing it for short term. But experience is it will diverge. So if we do the one I think we should seriously consider doing the spec change too. This type (adding an attribute with clear and distinct semantics) is usually quite straightforward though.
1 Like
We should do both - Siljeās suggestion for ADL1.4 but have it formally added to ADL2. As you say, it is not particularly controversial
2 Likes
It could be in other_details for now and as Joost said, doing this as a spec change in base for adl2 is probably straightforward.
The main question to me [for archetypes governed in a CKM] is whether this is
- a manually curated field of the archetype, i.e. updated in responsibility of the uploader or
- the - automatically available - modification date from CKM (which is the time of upload to CKM / commit to trunk), serialised into the archetype.
The latter makes more sense to me generally and practically speaking but there may use cases for the first option as well.
If the latter, we already have ārevision = 1.0.2ā as part of meta data managed by CKM, and it probably fits best with that. Then it should be named accordingly, e.g. ārevision_dateā.
3 Likes
Iād do it automatically every time revision is bumped.
2 Likes
I agree on doing both but I suggest getting a bit of experience from CKM first. I agree automatic makes most sense for CKM. I assume meaning, this might be different for different archetype management tools. But I think in niche cases it might be useful to overrule an automatic change. But I donāt think this would be a priority feature for CKM. So I would like to hear the experience from @grahamegrieve from the FHIR world. And for the description of the new attribute to leave some room to change it manually.
Yes - it should be the date that any semver was created/amended. Not necessarily any build change.
That makes it easier to manage in local projects too - it would up to tooling to update the revision number if the server changes but not otherwise.
2 Likes
well, I havenāt heard of it being used algorithmically - we always use versions and dependencies for things like that. But Iāve regularly heard/seen the discussion that goes along the lines of āhow old is this design?ā. For insiders, the version always tells you that, because you know the version history. But for non-insidersā¦ they have to go look it up, where as a date, they donāt (one might argue that they donāt know what to make of the date, and outsiders donāt. But casually involved observers can and do)
3 Likes