Link between goals and other clinical concepts

Gerard Freriks gfrer at luna.nl
Thu Jun 26 03:31:51 EDT 2014


Hi al,

Many roads lead to Rome.

At the extremes I can envisage:
- A Reference Model that makes many recurring patterns part of the RM. Observation, Evaluation, Instruction and Action are examples. And leaving a few details to the archetypes.
(Remember the first (1998) HL7v3 RIM’s where on several square meters of paper one needed magnifying glasses to inspect relationships.)
- A highly abstract Reference Model and leaving all details to archetypes and codes. Why not in the extreme a Terminology that is capable to provide one code that represents the full works of Shakespeare.
(Remember the first EHR standard that CEN/tc251 produced in the 1996)

When communities create any consensus it will work fine. Work fine for that community.

Or we come to a solution based on a pragmatic, logical, grounds:
Orthogonal layers and models in the semantic stack (RM, AOM, Archetypes/Templates, Codes, Ontologies)

This means that the scope of the layers are:
- the RM: any Document structure, documenting/archiving these components	(generic)
- the OAM: production of constraints on the RM, meta-data about the archetype/template, exchange format 	(generic)
- Archetypes/Templates: the Semantics - all facilities to safely interpret data 	(clinical and non-clinical semantics)
- Coding system: provide codes and meaning  like any dictionary 	(clinical and non-clinical)
- Ontology: expression of Knowledge helping to define all codes/meanings (words) in the dictionary/coding system 	(clinical and non-clinical)

Each layer its own function.
No overlap of features between the RM and the Archetypes/Templates
No overlap of features between Structures (archetypes/templates) and SNOMED with its pre- and post co-ordination. The 'boundary problem’.
Overlaps always create problems.

All layers intersect, but will not overlap.
They intersect at the Archetype/Template layer.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 25 jun. 2014, at 14:23, Bert Verhees <bert.verhees at rosa.nl> wrote:

> On 25-06-14 11:43, Heather Leslie wrote:
>> Hi all,
>> 
>> I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events. It is not very often I find a requirement that cannot be managed within these structures.
>> 
> 
> Hi Heather,
> 
> If you read well I state more then one time that I think that the OpenEHR information model, this includes also the ENTRY-model, is good.
> 
> The discussion is about if the definition of the information model should be in the reference model. Of course, the reference model will always give a base, so there will always be some semantics in it, but the question is, how much semantics should be in there, and, even more important, which semantics.
> 
> It is not about your requirements, I think most medical information models can meet most of your requirements. The point is that there are more information models, and you cannot use them when you use OpenEHR. One reason for this is because of the semantic structures openEHR defines on the reference model.
> 
> Bert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140626/6ccbb95c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140626/6ccbb95c/attachment.asc>


More information about the openEHR-clinical mailing list