I have been discussing the slot assertions off line and want to make sure the clinical requirements in this space are understood by the clinical guys. At the moment the Ocean tools work on the same basis as the Apache url include and exclude statements but I won’t go into that.
My view on the slots is that they have to be open by default (ie let other archetypes in) as the archetype is an absolute rule which cannot be broken. If we close slots in the usual case then people who specialise archetypes and make new ones will have to negotiate the slot authors in other archetypes. This means that the include statements are generally guidelines and help people compose sensible information structures.
We do, however, want to close some archetype slots - I will give two examples:
SECTION: Vital Signs
It is clear that vital signs section should only contain a limited set of observations - although this might change over many years with the introduction of Oxygen sats for example. Even then, perhaps a specialisation of the archetype is better - or a new one. So here the slot may allow temperature, pulse, blood pressure, respirations and O2 sats.
So we may need to say here that no other archetypes are allowed.
CLUSTER: Symptom
The proposed symptom cluster has a cluster for associated symptoms - and these can only be symptom cluster archetypes. This seems sensible.
There are many examples where we will not want to limit the inclusions, such as the O: heading in SECTION: SOAP where almost any observation might be required, though we might have the most usually used archetypes specifically included (in the archetype or the template). I do not believe that we will know at design time all the suitable archetypes for a slot - but we might know many that are definitely suitable.
BUT, we do need to say when one or more archetypes is not suitable - and we need to say when the set is closed (ie no more).
What do others think about the requirements for slots?
One thing that's not clear with me is the very issue you ask which is
fundamental requirement: why to restrict/limit slots? I guess possibly
due to licensing issues and also data integrity and interoperability. So
I see this issue mainly as how much control is kept in openEHR space or
some authority like NHS, and how much will be given to others. So
closing mainstream and well accepted archetypes like O:SOAP as you had
mentioned is a good idea to keep outsiders modifying it at will and thus
breaking up interoperability at large. But there are some risks. I would
appreciate to have some clearance on this issue.
As with Gerard, I was also wondering if an intermediary solution is
possible like not depicting individual archetypes but their types or
even subtypes. I assume it would be possible to define many useful
classifications to be used in slots in the multi-axial archetype
identifier. So it would be much more easier and flexible to reference
archetypes. En example is: X archetype; it is an ENTRY type describing
some Surgery in Neurosurgery speciality. If the repository has a good
design for archetype identification then it would be possible to
reference this archetype from at least ENTRY (type), Surgery (procedure
type) and Neurosurgery axes.
So if I summarize thoughts on requirements:
1) Define reasons to close or open slots and find a balance among those:
These points have to be clarified and discussed. I will post on this later
2) Need to define rules for closing or opening and maybe in between
like: high>medium>low restriction by perhaps depicting classifiers.
3) SH: we do need to say when one or more archetypes is not suitable ==>
I assume "exclude" serves for this purpose. If not definitely needed
4) SH: we need to say when the set is closed (ie no more). ==> I assume
putting a very strict "include" will do that. But if you are thinking a
dynamic process, I guess a flag is needed to say it is open or closed.
Then I guess a multilevel access system has to be present so as to
define who can close or even reopen them. So maybe at the highest level
openEHR Clinical Review Board might control, then comes some
national/regional authority and maybe individual archetype authors an so on.
Excludes and Includes, open/closed might serve most requirements. We do need certain rules as well, e.g. can we set a slot which “excludes all”.
Like Gerard and Koray had mentioned, I agree to have a way to categorise the archetypes. That would make the includes and excludes lots easier. I guess an ontology might play a role here.
The first thing to say is that any slot always declares the openEHR class - this is a restriction in itself. Second, it is a regular expression so we can allow any specialisations. I have suggested that it remain open unless an exclude all is set - so it becomes a suggested set in this case. I think the concerns suggested make me feel that everyone wants to be very careful about slots being too restrictive.
When we get to the cluster level things get a little different. The proposed inspection, palpation and auscultation clusters for physical exam are examples of clusters that should only appear here and no where else (they must have an object declared in the calling archetype to give context). Reuse at different levels in the physical exam is appropriate. So at times we will need to be tight about it.
There are ‘types of archetypes’ that must be free, with suggestions perhaps.
And there are ‘types of archetypes’ that will for (clinical) reasons be restricted.
The Archetype Ontology helps make selections of what archetypes can be used.
The Archetype ontology will fulfill the role Snomed does for codes.
Gerard
– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands