Issues with Latest Spec

Technical (archive)
1

Hello Everyone,

I discovered the following issues in the latest spec. I would appreciate your perspectives on them.

1. DV_PARAGRAPH does seem to make any sense as a data type. This is more of a rendering issue. A paragraph can contain multiple observations, but the spec indicates that only DV_TEXT can be in the paragraph. In my opinion, a paragraph is a higher level construct than ENTRY and seems more synonymous with a SECTION. On page 24 of the RIM model it shows an example of DV_PARAGRAPH. However it only shows DV_TEXT items possible in the prose. What if you want to put other data types in the narrative prose?

<DV_TEXT>blah, blah, blah</DV_TEXT><DV_DATE>July 16, 1999</DV_DATE><DV_TEXT>blah, blah, blah</DV_TEXT>....

I feel that if you go so far as to make DV_PARAGRAPH a data type, you should also create DV_SENTENCE, DV_BLOCK_QUOTE, DV_HEADER, DV_FOOTER, etc. (which also doesn't make sense IMHO). This is just the tip of an "iceberg" that I have spoken of before. openEHR needs a standardized spec for rendering visual representations of archetypes (i.e. an agreed upon style sheet language w/ a mandatory mapping to the RIM).

2. I can not find the class CONTENT_ITEM detailed in the EHR Information Model. This class is the superclass of ENTRY, but the fields (i.e. name, meaning, etc.) are not described.

You feedback is appreciated.

Cheers,

Matias

2

Hi Matias,

I'll reply properly in a few days, but essentially DV_PARAGRAPH is a minimal
construct for grouping blocks of text forming unstructured narrative. Obviously
you want to use structured entry as much as possible for processibility; or else
post-process narrative into structured (i;e; SECTOIN; ENTRY etc) as they do at
Mayo. But don'ty forget you can always post-process structured data into
readabl narrative. Philippe Ameline can talk more about this - his system does it.
So DV_PARAFGRAPH is really only for capturing large amounts of unstructured
narrative, and allowing the additoin of a bit of hyperlinking; minimal for,atting etc.
I personally suspect we might get rid of it one day and just use
DV_ENCAPSULATED to contain word-processor text or HTML or whatever
instead.

- thomas

3

Hi Matias

Tom is on leave so it is a bit late coming...

I discovered the following issues in the latest spec. I would appreciate your perspectives on them.

1. DV_PARAGRAPH does seem to make any sense as a data type. This is more of a rendering issue. A paragraph can contain multiple observations, but the spec indicates that only DV_TEXT can be in the paragraph. In my opinion, a paragraph is a higher level construct than ENTRY and seems more synonymous with a SECTION. On page 24 of the RIM model it shows an example of DV_PARAGRAPH. However it only shows DV_TEXT items possible in the prose. What if you want to put other data types in the narrative prose?

This area is an issue - DV_PARAGRAPH was added to allow formating and mixing of coded and non-coded text. It was not for the sort of purpose you have shown - which is mixing text and non-text data. It is not meant to be like a section - just giving a richer text.

<DV_TEXT>blah, blah, blah</DV_TEXT><DV_DATE>July 16, 1999</DV_DATE><DV_TEXT>blah, blah, blah</DV_TEXT>....

We believe that a date amongst the text is not processable anyway - but it is felt that some complex text may be possessable - or might be the result of a natural language processor. We have not used this class in any applications as yet and you may be right.

I feel that if you go so far as to make DV_PARAGRAPH a data type, you should also create DV_SENTENCE, DV_BLOCK_QUOTE, DV_HEADER, DV_FOOTER, etc. (which also doesn't make sense IMHO). This is just the tip of an "iceberg" that I have spoken of before. openEHR needs a standardized spec for rendering visual representations of archetypes (i.e. an agreed upon style sheet language w/ a mandatory mapping to the RIM).

I think this is a reasonable statement and we need to decide how openEHR will address the structure text situation. Tom and I have talked about the possibility of having a MIME class as an optional display form on locatable. This would allow ENTRYs and SECTIONs to have data that is just for display - much like CDA v2. The other advantage is that legacy data can still be dealt with and displayed - even if it cannot be processed.

2. I can not find the class CONTENT_ITEM detailed in the EHR Information Model. This class is the superclass of ENTRY, but the fields (i.e. name, meaning, etc.) are not described.

OK - these two fields always cause difficulty. Things have moved on since these two attributes were 'named'. Both are now internal codes - ensuring that there is no language dependence.

The 'meaning' is an 'atnnnn' code that identifies that node in the archetype - it is the design time or archetype path identifier - and is described in the 'term definitions' section of the archetype ontology.

The archetype path (or design time path) is expressed largely in terms of these codes \atnnnn\atnnn1. Each code is guaranteed to be unique at that level in the path.

The 'name' is now an 'acnnnn' code - and is optional in the archetype. It is described in the constraint definitions section of the ontology. This code describes any constraints on the 'name' or 'runtime label' - ie a text or term that is seen by the user.

The 'name' as a DV_Text forms the runtime or 'data' path.

\"first reading"\[SNOMED-CT::234567]\

This is important to be able to access data - as any node that has an upper limit of occurrences of greater than 1 will be accessed specifically in queries by the 'name' value - rather than the 'meaning value'.

An example might be in the microbiology archetype - when looking for sensitivities to penicillin....or looking for sensitivies of E. Coli.

I hope this is helpful,

Sam Heard

4

Matias Klein wrote:

Hello Everyone,

back from holidays, with a few more answers...

I discovered the following issues in the latest spec. I would appreciate your perspectives on them.

1. DV_PARAGRAPH does seem to make any sense as a data type. This is more of a rendering issue. A paragraph can contain multiple observations, but the spec indicates that only DV_TEXT can be in the paragraph. In my opinion, a paragraph is a higher level construct than ENTRY and seems more synonymous with a SECTION. On page 24 of the RIM model it shows an example of DV_PARAGRAPH. However it only shows DV_TEXT items possible in the prose. What if you want to put other data types in the narrative prose?

<DV_TEXT>blah, blah, blah</DV_TEXT><DV_DATE>July 16, 1999</DV_DATE><DV_TEXT>blah, blah, blah</DV_TEXT>....

If your software could generate this string of xml, it could clearly generate the 'orthodox' openEHR structured data. Something like the above would be an xml rendition of it - it might even be the way you store it (assuming that the xml conforms to the openEHR XML-schema).

I feel that if you go so far as to make DV_PARAGRAPH a data type, you should also create DV_SENTENCE, DV_BLOCK_QUOTE, DV_HEADER, DV_FOOTER, etc. (which also doesn't make sense IMHO). This is just the tip of an "iceberg" that I have spoken of before. openEHR needs a standardized spec for rendering visual representations of archetypes (i.e. an agreed upon style sheet language w/ a mandatory mapping to the RIM).

this idea of a paragraph is more to do with the idea of word processing; it is not what we had in mind to replicate in openEHR, since there are already all kinds of tools that generate this sort of output. There is already a type DV_ENCAPSULATED for capturing the such tools which do this, including in HTML or XML format.

2. I can not find the class CONTENT_ITEM detailed in the EHR Information Model. This class is the superclass of ENTRY, but the fields (i.e. name, meaning, etc.) are not described.

There are currently no attributes or functions defined for CONTENT_ITEM, so it is just shown as a single compartment box, not a the proper 3-compartment box in the UML diagrams. You are right that there is no CONTENT_ITEM class definition in the text - a CR will be raised to remedy this.

- thomas beale