ECG archetypes

[Mie Faerch Jensen]

Greetings all;

We are two graduate students from Aalborg University, Denmark, taking our 
master in Biomedical Engineering and Informatics. In this semester ?our 
finale, we are working with complex data interoperability to an Electronic 
Health Record (EHR). We are following the openEHR?s EHR architecture standard, 
and therefore also working with archetypes. 
We have a few questions we would like you to help us deal with.

- What we are trying to investigate is how to represent a recorded ECG-signal 
in an archetype, and therefore we are wondering what the status is on dealing 
with ECG-signals as an archetype? So far we haven?t been able to locate an ECG-
archetype, only the description of it as an observation-entry.

- We have described workflows and clinical information guidelines for the 
observation and clinical evaluation of an incoming ECG-signal, but we are a 
bit confused on how to map the clinical information guidelines to an 
archetype. Can anyone give us an example on how this mapping is done?


Best regards

Mie F?rch Nielsen og Louise Pape S?rensen 
Aalborg University, Denmark, 
Master in Biomedical Engineering and Informatics,
10th semester
Reply-email: 06gr956d at miba.auc.dk


-
This mail sent through IMP: http://horde.org/imp/

___
openEHR-clinical mailing list
openEHR-clinical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

terminology

[Rahil Qamar]

Hi Bert

I had a read through your posting. I have one query though. Which 
terminology are you planning to use? The openEHR terminology is very 
small and limited in scope and content which makes it fine to be 
available in the current Terminology.xml file. However if you are 
planning to use one of the larger, more widely published and used 
terminologies such as SNOMED CT, LOINC, ICD, NANDA, and the rest, you 
might run into problems with trying to convert the terminologies to the 
XML format used for the openEHR terminology. How are you planning to 
handle relationships and concept definitions using the present XSD?

I might have caught the wrong end of the stick but on initial look this 
is what came to my mind.

Regards
Rahil

Bert Verhees wrote:

> I found it out, partly, myself. The document
> RC1.1/publishing/architecture/computable/terminology/Terminology.xsd.html
> (in my local copy of the repository) was very helpful.
>
> I, now, more or less understand the structure of classes which form 
> the terminology.
>
> *Please correct me if I am wrong.*
>
> It all boils down to the concept/language which will be represented in 
> the terminology-access.
>
> This looks like this
>
> id: String
> all_codes: Set
> codes_for_group_id (group_id: String): Set
> codes_for_group_name (name, lang: String): Set
> rubric_for_code (code, lang: String): String
>
> So, the groups (grouper) are visible in Group_id, which can be 
> retrieved by querying the OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS Class.
>
> The openehr terminologies are all in the file terminology.xml, 
> organised in the structure which is described in the above html-file. 
> This is very good.
>
> There is one minor problem, the group_id's in the class do not sync 
> 100% with the group-id's in the xml-file.
>
> Here is a question
> *Which one will prevail, that from xml, or that from PDF?
> *
> I found out, that there are some codes which have a structure that 
> does not fit in terminology_access, because they have more "fields" 
> like territory and terminologyidentifier, mediatype.
> *How to handle these?
>
> *Finally, there is the property-unit-propertyuntit structure. It looks 
> like, but I am not sure, that these are for, I can guess. But maybe my 
> guess is wrong, the terminolgoyaccess class does not offer space for 
> properties.
> *How to handle these, what are these for
>
> *Thanks for your attention
>
> Bert
>
>
>
>___
>openEHR-technical mailing list
>openEHR-technical at openehr.org
>http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>  
>

-- 
Rahil Qamar

Ph.D. Student
Medical Informatics Group
Room LF1 Kilburn Building
University of Manchester
Work number: +44 (0) 161 275 0663
Email: qamarr at cs.manchester.ac.uk
Website: http://www.rahilqamar.com/

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070308/0c60cddd/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CEN meeting and data types

[Thomas Beale]

Grahame Grieve wrote:
> Hi
>
>   
>> * there is always the possibility that it can't - because the class 
>> model commits to one idea of terminology coordination, while the syntax 
>> approach leaves it open
>> 
>
> do we know of any case?
>   
I don't have a concrete one - so fair enough
>   
>> * the information model shouldn't dictate to the terminology environment 
>> how to represent its artefacts.
>> 
>
> I have some sympathy for this. I have been tempted to toast the qualifier
> and push everything into code as you guys have done, for the same reasons.
> But I haven't found any case where the existing qualifier syntax is a
> problem, and there is accepted requirements for originalText on the
> qualifiers (at least, HL7 has accepted them). SO I didn't toast it, but
> I did say in the openEHR mapping that you'd collapse the qualifiers into
> the code phrase. I don't have a strong feeling for whether this would be
> necessary or appropriate for 13606
>   
I don't have a problem; I just think we need a clear description of the 
equivalence so mappings are safe.

- thomas
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical