I am somewhat confused by the current implementation for archetype slots in the LiU and Ocean editors.
Whilst within SECTION archetypes, the full range of archetype slots can be embedded (OBSERVATION,EVALUATION.ACTION …), within, for example, an EVALUATION archetype the LiU editor supports only simple structural concepts such as list, tree and table whilst the Ocean editor supports only Element or Cluster style archetypes. Are these limitations of the editor implementations or are these restrictions in the underlying model? I have looked at the AOM document but cannot see any such restriction.
I have a particular use case where I am trying to replicate our national Laboratory standard messaging structures by specialising the OpenEHR Laboratory archetype. Part of the local requirement is a structure called Evidence which refers to manually-held, non-electronic material relevant to the lab result e.g. a wet film x-ray or paper record. This is potentially a reusable concept and should exist as a separate archetype. I am confused!! I have currently constructed Evidence as an OBSERVATION archetype (It is a simple list of 3 TEXT elements). Would this be better expressed as a CLUSTER? I am still a bit hazy as to when use of cluster archetypes is appropriate.
I am somewhat confused by the current implementation for archetype slots in the LiU and Ocean editors.
Whilst within SECTION archetypes, the full range of archetype slots can be embedded (OBSERVATION,EVALUATION.ACTION …), within, for example, an EVALUATION archetype the LiU editor supports only simple structural concepts such as list, tree and table whilst the Ocean editor supports only Element or Cluster style archetypes. Are these limitations of the editor implementations or are these restrictions in the underlying model? I have looked at the AOM document but cannot see any such restriction.
You can embed a structure in an evaluation or action but as these are the data attribute this is not usually sensible. Structures are useful for embedding in Instruction activity description and Action description when these are shared.
The element and cluster archetypes can only be in a structure or a cluster - the Ocean editor allows you to do this in the data or state or protocol structures.
I have a particular use case where I am trying to replicate our national Laboratory standard messaging structures by specialising the OpenEHR Laboratory archetype. Part of the local requirement is a structure called Evidence which refers to manually-held, non-electronic material relevant to the lab result e.g. a wet film x-ray or paper record. This is potentially a reusable concept and should exist as a separate archetype. I am confused!! I have currently constructed Evidence as an OBSERVATION archetype (It is a simple list of 3 TEXT elements). Would this be better expressed as a CLUSTER? I am still a bit hazy as to when use of cluster archetypes is appropriate.
Clearly a cluster is appropriate as you want to use it in other observations. It would help to see what the evidence data is and when you would like to use it. I suspect that it is likely to be used in an evaluation??? An example would help.
I have not seen any of the editor authors reply to you yet about their editor capabilities, but to respond to you on the principle, I would favour the use of the Cluster as the starting node to contain the three Elements since
a) the Evidence is itself not a complete Entry, but complementary to the main data for which it is the evidence
b) it is ideally something that could be used my many different Entry archetypes
However, your three Elements might not be enough to be the most perfect generic meet-all-needs evidence data structure. Maybe such a thing ought not to exist, and several different kinds of evidence structure are needed for different scenarios. All this means for now is to request that, when you design this Cluster archetype, you are as clear as you can be in the description about the kinds of Entry for which you believe it is a well-tailored evidence structure (e.g. if meant only for lab data). Other potential users can then critique it (if you ask them) with that particular scope in mind rather than any other scope for evidence, and later down the line others will be better able to tell if it might also meet their needs.
More specifically, though, from your e-mail I could not tell if your notion of evidence is what I would call the clinical indication, other relevant clinical background, or the justification for the test (which might be supplementary to the indication). I don’t need to know, but this is the kind of clarification that will help others to critique/reuse it.
I am somewhat confused by the current implementation for archetype slots in the LiU and Ocean editors.
Whilst within SECTION archetypes, the full range of archetype slots can be embedded (OBSERVATION,EVALUATION.ACTION …), within, for example, an EVALUATION archetype the LiU editor supports only simple structural concepts such as list, tree and table whilst the Ocean editor supports only Element or Cluster style archetypes. Are these limitations of the editor implementations or are these restrictions in the underlying model? I have looked at the AOM document but cannot see any such restriction.
Ian,
archetype slots can appear anywhere in an archetype. The object types
allowed at the node where the slot is defined are those allowed by the
underlying reference model, i.e. using slots doesn't allow archetypes to
go outside what the RM allows.
I have a particular use case where I am trying to replicate our national Laboratory standard messaging structures by specialising the OpenEHR Laboratory archetype. Part of the local requirement is a structure called Evidence which refers to manually-held, non-electronic material relevant to the lab result e.g. a wet film x-ray or paper record. This is potentially a reusable concept and should exist as a separate archetype. I am confused!! I have currently constructed Evidence as an OBSERVATION archetype (It is a simple list of 3 TEXT elements). Would this be better expressed as a CLUSTER? I am still a bit hazy as to when use of cluster archetypes is appropriate.
this sounds like you need the DV_IDENTIFIER type, which is a type used
for referring to external entities. Whether it needs to be a separate
archetype depends on its complexity, whether it is likely to be reusable
exactly as designed, and other similar factors. I don't know if the
editors currently support DV_IDENTIFIER, but they soon will. Can you
provide some more details as to the modelling requirement?