openEHR-clinical Digest, Vol 11, Issue 3

Clinical (archive)
1

Hi Heather,

Thanks for your reply.

In general ISO 13972 describes what good models should look like, not how my models should look. Sorry to see that misunderstanding repeated.

And it specifies characteristics of the models. If CKM is the means of implementation, why bother. If you version the models you new the requirements of ISO for instance.

OpenEHR is even based on these foundations that you refer to other parts for particular characteristics.

So I could not disagree more about such matters. And that is why the governance is in and separated from the model.

E.g. If it says that any DCM should have an ID, in normal situations it must be in the file or in the file and. But there are other means to guarantee the uniqueness.

I am afraid you are judging the DCM work too much from an current CKM implementation side. Please go back a step to the principles: why do we need these characteristics? Because there are alternative s to archetypes. That is why this TS 13972 exists, to facilitate the 99% of EHR systems that cannot manage archetypes.
You already have the 13606 series you can refer to.

Vriendelijke groet,

William Goossen

2

Hi William,

Perhaps you can clarify better if I use a concrete example such as 5.8.12.2.2 which is a SHALL (or mandatory) statement. There is a subcomponent within this normative statement labelled: “Publication Status of the detailed clinical model”, with a description: “This is the status of the detailed clinical model in relation with publication in the registry or repository: Not For Use (i.e. teaching); Approved for testing; Approved for Production Use; Withdrawn; Superseded; Rejected(en); Obsolete.”

I interpret this as saying it is mandatory for a clinical model specification to contain a statement about the model’s publication status.

openEHR archetypes currently don’t contain the publication status within the archetype specification itself. So I conclude that, at present, openEHR archetypes cannot be compliant with 13972 in regards to this normative statement.

I know that some other detailed clinical models contain a version history that incorporates a publication status as well, but that is not the case with the archetype as a logical model.

Regards

Heather

3

Dear Heather

Apart from implementation issues and current compliance, the question to answer for this particular example is whether or not it is useful to know what the status of an artifact is? When someone sends me an archetype in ADL, it is relevant for me to know what the status of that archetype is. It will allow me to make an informed decision how to use (or not to use) that archetype. Although it may be in the email to which the archetype was send, later on, that email may get lost. So it is better to have it as meta data of the archetype. (At least from my perspective).

More in general, 13972 should specify the useful components of detailed clinical models. We all want interoperability and safe use of clinical models. I think the most constructive approach is to argue why certain SHALL statements may not be necessary (or too mandatory) to support these goals. The argument that "My current implementation is not compliant, hence it has to change" is less compelling for others. Any standardization work implies for some (if not all) approaches that work needs to be done to become compliant.

BTW, I have noticed that the "Dutch DCM" approach has evolved over the years to accomodate what has been in successive drafts of 13972, not that the drafts followed what was put in the "Dutch DCM" approach.

Regards

Jan

4

William, Jan,

My intent with previous emails was simply to encourage a broader group
within the modelling community to participate in feedback for DTS 13972,
which has been sorely lacking in previous ballots.

You're both making reasonable points. We are all seeking interoperability.
That's why we've all be working on this for so many years now.

I don't want to have detailed arguments in this forum.

I don't necessarily think openEHR has it right in this area. BUT whether
statements should be SHALL or SHOULD is a reasonable debate. Might it be
acceptable to provide strong guidance with SHOULD and allow it to be
tightened up further to a SHALL statement if and when there is clear
community consensus?

Some SHALL statements in the current 13972 will mean openEHR archetypes
appear to be non-compliant. If they remain as such, and they could well do
so, then the questions for us become... does it matter? Will we choose to do
anything about it?

Heather

5

I think, the way we think about archetypes needs to be revised, that the archetypes cannot be compliant in 13972 is one reason, but I have another. A few weeks ago I had an interesting discussion about archetypes on this mailinglists, and by chance, also with Dipak Kalra about the same subject. This discussion is recorded on Youtube. After some confusion and help from other participants, and we came to the point I wanted to make. I think, this is related to the situation around archetypes, semantic interoperability and therefore in this discussion. Bert

6

This kind of thing in 13972 is a worry. Obviously some publication / lifecycle status is useful. Where it is recorded is another matter, and also the list of possible values is a further question. I can't imagine how there could be an ISO standard mandating either of these things before industry is even close to working out best practices. That would need to be changed for ISO 13972 to be of any use in a standards sense.

Personally I can't see the utility of trying to standardise this area for some years yet; industry will provide things that work, eventually, and that entails a period of experimentation and evolution. It's hard to imagine any other practical approach.

- thomas

7

Jan,

Dear Heather

Apart from implementation issues and current compliance, the question to answer for this particular example is whether or not it is useful to know what the status of an artifact is? When someone sends me an archetype in ADL, it is relevant for me to know what the status of that archetype is. It will allow me to make an informed decision how to use (or not to use) that archetype. Although it may be in the email to which the archetype was send, later on, that email may get lost. So it is better to have it as meta data of the archetype. (At least from my perspective).

I don't disagree that it makes sense. Archetypes have a lifecycle field; it just isn't always set properly due to tools. Currently only CKM sets the field properly. It is only very recently that a workable set of lifecycle states have been worked out in archetype-land / CKM (i.e. there is no claim that the lifecycle used here is the right one for DCMs or other content model types).

More in general, 13972 should specify the useful components of detailed clinical models. We all want interoperability and safe use of clinical models. I think the most constructive approach is to argue why certain SHALL statements may not be necessary (or too mandatory) to support these goals. The argument that "My current implementation is not compliant, hence it has to change" is less compelling for others. Any standardization work implies for some (if not all) approaches that work needs to be done to become compliant.

ok, but 'standardisation work' is not where the actual work on these things gets done. You don't solve difficult problems like this by confabulations in the discussion rooms at ISO meetings. They are solved in the real world - in competent academic and industry locations where real implementation work is going on.

As I have said many times before, the only utility of 'standards' is if they are defined by choosing / adapting working solutions that emerge from these real world locations. Aspirational standards are worse than useless; they waste people's time and inevitably have to be debugged by the real world anyway.

So until there are compelling, working implementations of a given concept, a standard for such a concept is just nonsense.

- thomas

8

When you talk about lifecycle nor being set properly, do you mean that
the set of values in not correct or that the lifecycle management
process in not correct?

9

Hi Jan, William, Heather and others,

Just a thought about having governance metadata inside or outside the knowledge artifact (e.g. archetype / DCM).

Having that metadata outside the artifact creates the necessity of a centralized governance system, and having it inside the artifact doesn’t. We work in distributed environments where the centralized view doesn’t fit. The CKM is a proof of that, there is a global instance, an AUS instance and a SWE instance, they share some archetypes and others are developed locally.

The 3rd scenario is having the metadata outside the knowledge artifacts, and support a distributed governance environment. That is just an open door for chaos, because it’s impossible to keep track of all artifacts, all modifications/versions and statuses, because each governance system will have different metadata about the conceptually equal artifacts (they represents the same concept).

What do you think?

10

Hi Pablo, that’s only a problem if the artefacts are not tracked properly, i.e. with unique ids and potentially checksums / MD5s. You can’t put everything in the artefact, because you create dependencies of the artefacts on things which may be of local or specific significance, e.g. how they are classified in an ontology, what the relationship between parts of the artefact and the national data dictionary are and so on. If we put everything in the artefact, we will end up with a BP measurement archetype containing 50k of references to NHS data dictionary items, Nehta ISO 11179 elements, ontology markers for different types of CKMs etc. The lifecycle will be tracked properly in archetypes, it is just waiting for tools to make more progress, and also to finalise what the lifecycle actually is. But not everything can be. So there is no way out of having proper governance tools - whether centralised or distirbuted… - thomas

11

Hi Diego,

Both!!

The set of values is not correct - it was originally drawn, I think, from the world of paper standards and does not fit the archetype development cycle particularly well. The values are also not applied very consistently (although we now do this with in CKM).

I am currently finishing a fairly long document which tries to bring together a number of these issues - archetype identifiers, namespacing, lifecyle versions etc, which I will aim to get up into the public space within the next couple of weeks.

Regards,

Ian

12

Hi Thomas, I mentioned only “governance metadata”, like identification attributes (conceptual: id, name, code, definition, purpose, …; physical: hashes, checksums, …), state attributes (current development state, publish state, revision state, version, …), autorship attributes, …

Since this is a discussion about an standard and the problems they are solving, I prefer to center on a more usable and difficult scenario: distributed governance. I’m not saying that a centralized scenario is bad in all cases, just that is a far more simpler scenario to resolve.

13

I see your point, but I would say that already happens with
translations (translations with different degrees of 'maturity' may
exist on the same archetype)

14

Since I am an other,

There should not be any modifications or versions. Once a clinical
model is distributed, it is concrete. There may be instances created
against it. They are permanent and should never be changed.

--Tim

15

Hi Diego,

This is a good point. I think we will probably have to label translations with metadata on authoring state and the revision/build against which that state was set. It will be important for people to know if a translation has been performed/reviewed against the current revision (or not).

Ian

16

ok - I wasn’t clear, since there is all kinds of other ‘governance metadata’ which people have proposed in the past, and which we do use, e.g. for searching, which are not in the artefacts themselves. But in a more strict use of the word ‘governance’, I agree. I think distributed governance is the only realistic possibility. - thomas

17

Hi All

I am wading in here because I am very aware that the full technical requirements for safe use of clinical models depends on a great deal of checking. At present we have a couple of checks in CKM – an MD5 on the full archetype (this will change if you change anything) and an MD5 on the structure which allows word smithing, translations etc. For systems using archetypes which are evolving rapidly, these two checks are useful.

Clearly an archetype, once released for use, is a high risk artefact, regardless of the metadata. We saw in the UK that people changed the archetype and did not resubmit it. The MD5 checks do allow repositories to assess the type of change.

The publication status is a complex thing as well. Stand alone publication of an archetype is one thing, but most important is being part of a release set for a particular jurisdiction. Clearly all archetypes in a release set will be published. But the same archetype can be published over and over with more translations, additional features etc, all the while being backwardly compatible.

So there is a lot to manage and I am not sure that the proposed meta –data will help a great deal. It is, actually, possible to put the status in the archetype. These have not been standardised as yet as it is still not clear which are needed. The governance pathway in CKM is now well tried and tested, but will have some new issues to deal with now we have subdomains and incubators.

Cheers, Sam

18

Because I partially initiated this discussion, I want to summarize my view on it again, but I did not think it over very well. I am too busy with other things to follow these discussions. I am sorry for that. So regard it is as my two cents while make a good and wise decision about how it will be. My idea is to furnish archetypes with more MD5 keys, one for the definition, and one for each language-section in the ontology. Now a locatable stores the ArchetypeDetails to indicate which archetype is used, then ArchetypeDetails should store these keys. It is of course the responsibility of a system-owner to save the archetypes belonging to a specific keys. Backwards-compatibility can not be defined in keys, if that needs to be defined, there must be a metadata-section for that. Regarding to the archetypeID, the term “ID” suggest that it can be used to identify something. If one wants to use the term ID, it must contain information to identify the archetype, in that case, it should contain a key, MD5 f.e., which is The information (RM-model, domain, concept, etc) that is now hidden in the archetype-ID must be provided in metadata-sections, so that the ID will not be longer need to contain any necessary information. I think the ID will be superfluous. It should not be part of the ArchetypeDetails. The archetypeID will not be needed anymore in the information-structure, users are free to assign any name to an archetype. And we also need a humanly expressable name for an archetype, for that purpose, a name-design can be provided, as long as it is clear that the name does not verifiable and uniquely identifies an archetype.

19

I think distributed governance is the only realistic possibility.

Fully agree.

Greetings from Vienna,

Stefan Sauermann

Program Director
Biomedical Engineering Sciences (Master)

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
P: +43 1 333 40 77 - 988
M: +43 664 6192555
E: stefan.sauermann@technikum-wien.at

I: www.technikum-wien.at/mbe
I: www.technikum-wien.at/ibmt
I: www.healthy-interoperability.at

20

Hi Bert,

Whilst I understand and agree with the need for very precise identification of a particular archetype via MD5 or some other ‘meaningless identifier/locator’, it is also necessary to clearly identify the version, revision and build of an archetype for authoring and governance purposes, as well as in early stages of development and testing.

During the authoring phase, where archetypes and templates can be very fluid, and have multiple dependencies, our experience has been that MD5 hashing is very difficult to manage since it forces very strict dependencies, where in practice we perhaps only want to ensure that the archetype Version is correct, and temporarily ignore Revision changes or minor ‘Build’ changes, until publication/deployment. In terms of regular software development, imagine the consequences if all of your source code files were MD5 hashed, and each dependency MD5 tagged, resulting in a compile failure if there is a mismatch between the dependent files.

I am not convinced that abandoning the existing archetypeID mechanism is the right approach but even if it were I think we would still need to support it for legacy purposes. Let’s also leave aside the OID vs ReverseURI issue for now (there is a possible case for supporting both).

As I said in a previous post, I am working on some proposals I am working on, based on earlier discussions, Thomas’s wiki material, the suggestions for Semantic Versioning at semver.org and experience from both CKM and non-CKM repository governance.

The suggestion will be to introduce an extendedArchtypeID, composed of …

OriginalDomain: The originating Domain namespace where the archetype was first governed e.g. org.openehr but could be an OID. This never changes even when the archetype is transferred to a different repository.

ArchetypeID: The current archetypeID (including Version) e.g. openEHR-EHR-OBSERVATION.blood_pressure.v1

RevisionNumber: The revision number e.g ‘2’ starting from base 0 with each new Version

NonOperationalModifier: A state suffix e.g. (initial, draft, rc, inactive).

BuildID: This is repository-defined. In the case of CKM it might be the ‘citeable-ID’ e.g. 1031.1.1296_2 but it could equally be an MD5 Hash for a non-CKM repository. The only stipulation is that any archetype made visible by the repository must increment the BuildID, whenever ANY change is made to the archetype.

So the full ID for a published archetype might look something like

org.openEHR::openEHR-EHR-OBSERVATION.blood_pressure.v1.0+build1031.1.1296_2

or for the same archetype taken back into review

org.openEHR::openEHR-EHR-OBSERVATION.blood_pressure.v1.1-draft+build1031.1.1296_7

The nomenclature is closely based on semver.org with some modifications

The metadata should also carry :

AuthoringLifeCyle: (Initial, Draft, Team Review, Suspended Review, Published, Rejected, Superseded, Moved). This is effectively a superset of the operational states to account for authoring and governance requirements which do not affect the operational status of the archetype. i.e an archetype which moves from Draft to Team Review and then Review Suspended, remains a ‘beta’ archetype from an operational perspective.There is a direct mapping between the operational states and one or more Author lifecycle states.

CurrentDomain: identifier for the current controlling domain, to allow for situations where control/governance of the archetype is transferred.

We can probably carry all of the necessary extra metadata within the current ADL1.4 specification under other_details.

In general I would expect archetypes and templates to refer to dependent archetypes or templates using the full extended identifier, but associated tools could choose to ignore e.g build or even revision incompatibilities where appropriate, and update the references automatically to point to the currently used artifacts, if modelling is still at a stage where loose coupling is necessary.

In terms of the original discussion, I think my main concern is that not that the state of understanding of how DCMs/archetypes should be managed.governed and versioned is still very much in the early phases of understanding, particularly in the very distributed governance environment that I think we all agree will be required. openEHR archetypes (? also FHIR resources) are a bit of a special case since we expect these to form the basis of persisted, queryable data, not just as messaging definitions. This makes the challenge of versioning / governance rules much harder but I think we are pretty close to having an implementable solution.

More soon … and would be interested in others thoughts about the BuildID, particularly in the context of Git or Subversion-based repositories.

Ian