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 > > ============ > Matias Klein > President, CTO > Ethidium Health Systems > 3993 Huntingdon Pike - Suite 108 > Huntingdon Valley, PA 19006-1927 > USA > Office: (215)938-8630 > Fax: (866)583-8018 > http://www.ethidium.com > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
