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


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Reply via email to