Constant Values and "sub" Elements

Technical (archive)
1

Hello!

Within the context of my bachelor thesis, i am trying to transform a domain
model into an archetype, but now i am having some problems and i hope maybe
some of you here can help me.

My first question is, is it possible to define constant or "hard coded"
values ie. constant text which contains a description?
So far I am trying to add a CODED_TEXT that matches a defined constraint
ac0001, but i am not sure if this is a valid solution.

  ITEM_TREE[at0003] matches { -- ITEM_TREE
    items cardinality matches {0..*; unordered} matches {
      CLUSTER[at0004] occurrences matches {0..1} matches { -- Top
        items cardinality matches {0..*; unordered} matches {
          ELEMENT[at0005] occurrences matches {0..1} matches { -- SpokenDefault
            value matches {
              DV_CODED_TEXT matches {
                defining_code matches {[ac0001]} -- Top
                }
              }

and the other question
How do i add "sub-elements", is it even possible? ie. I have a Text field
"Top" and i want to add a Text field "SpokenDefault" to it, which shows how
to pronounce the word Top. the way i do it right now is creating a cluster
for every "element" which is not very effective.

thanks in advance
TimmyX

2

Hi TimmyX

an acXXXX constraint has been designed for defining terminology value
sets by query.

In your case several constraining the text ELEMENT to several at codes
should do the job (the Archetype Editor supports that via 'internal
codes' in the constraints tab right to the definition area.

Something like that should do

ITEM_TREE[at0003] matches { -- Tree
                items cardinality matches {0..*; unordered} matches {
                  CLUSTER[at0004] occurrences matches {0..1} matches { -- Top
                    items cardinality matches {0..*; unordered} matches {
                      ELEMENT[at0005] occurrences matches {0..1} matches { --
Default Spoken
                        value matches {
                          DV_CODED_TEXT matches {
                            defining_code matches {
                              [local::
                              at0006, -- bla
                              at0007] -- blub
                            }
                          }
                        }
                      }
                    }
                  }
                }

Regarding sub elements you were right: CLUSTERS are the way to do that
in Archetypes! If you have a pattern which is always the same, you
could create a CLUSTER-Archetype and reuse it...

Cheers, Thilo

3

Hi Timmy,

Can you explain the domain model in a little more detail?

Ian

4

Hi,

sure, it consist of a parent node and several child nodes, which describes the appearance of a patient.

structured by
-common information
weight
birthdate
height
-face
–eyes
color
–mouth
–nose

and so on
all elements have an attribute which says how it should be pronounced which is constant.

Thanks for the quick replies.
Timmy

5

Timmy,

I guess in your case with so littel elements I would bite the bullet
and model the 'spoken default' explicitly with a text ELEMENT that is
preset to the constant value.

An option would be to model a generic element as a CLUSTER-archetype
(including the 'spoken default' element) and specialize an from it for
every element you need. These specialised CLUSTERS could be assembled
in an OBSERVATION archetype via slots. But it think this would be to
complex for such a simple model and the specialisation would not
provide much added value.

Cheers, Thilo

6

Thanks Thilo,

although this might not be worth it, i will try to model a generic element as cluster-archetype.

also i dont quite understand what you meant with
“model the ‘spoken default’ explicitly with a text ELEMENT that is
preset to the constant value.”

how would i do that if i wanted to add a “spoken default field” to a date field?

thanks in advance
Timmy

7

Thanks Timmy,

I am still struggling to understand the purpose of the
'pronounciation' attribute. Does this have to be computable or is it
just for designer/user guidance? Can you give little more background
to your project?

Ian

8

Sorry for being that unspecific.. The project i am working on is about
speech recognition. A Software which allows med. experts to fill out a
Form with speech only, so currently the xml File with the Domain Model
generates a Form with Checkboxes, date Fields and so on and it
includes also a spokendefault value which tells the speech recognition
how this Element Name Sounds like. In the End the generated Form can
be controled or navigated with speech.

I would say it has to be computable.

Thanks,
Timmy

9

Thanks Thilo,

although this might not be worth it, i will try to model a generic element
as cluster-archetype.

you can try it, but I think in this case it is more complex (takes
longer) and doesn't have added value. Also the archetype editor
currently can't view assembled structures (templates).

also i dont quite understand what you meant with
"model the 'spoken default' explicitly with a text ELEMENT that is
preset to the constant value."

how would i do that if i wanted to add a "spoken default field" to a date
field?

similar to what I send you before just a date element in the cluster

10

Timmy,

I think this speech recognition stuff is more an interface thing and
IMHO it doesn't belong into an archetype (if you see an archetype as a
means to share interoperable health information). You could have a
seperate XML file that tags every appropriate field to a
'spokendefault' value(what would be the format? - sound file, phonetic
spelling,...) via the atXXXX code.

Lets see what others think

-Thilo

11

I sent the following yesterday, but it didn't make it to the list for whatever reason...I had this a couple of times now that my emails to the openehr lists don't arrive...maybe you can check Thomas?
In essence I agree with you Thilo...not sure this should be in the archetype

12

Thilo,

I think you’re right, this actually really doesn’t make sense, my current approach somehow mixes information with knowledge.
Which is kind of the opposite of the two-level modelling and the whole archetype architecture.

Actually my project is to check if the “domain model” can be transformed into a archetype.

I guess I’m still having problems understanding openehr.

Timmy

13

Ok I guess pronunciation wasn’t the best description of it.

in my project sample domain model the concept name really is the spoken default.

as I’ve heard it will be used in the future as a common word for a concept, i guess some medical terms which are used by med. experts which are not the official term, like abbreviations.

ie. saying MRI instead of Magnetic Resonance Imaging.

i guess it would be a better approach to model a generic archetype which shows how the domain model should be structured and add information at runtime, does this make sense?

Thanks in advance
Timmy

14

Timmy,

It seems to me that your 'spoken default' corresponds to the description associated with a SNOMED terminology code.

i.e. the SNOMED code has an english description, a french description, etc.
For speech recognition you would need to store a phonetic representation (e.g. a markov model) of each term for each language/dialect to be recognised.
No small task!

Regards,
Colin Sutton

15

Sorry but I don’t understand what you mean with “Spoken default corresponds to the description associated with a SNOMED terminology code.”

Timmy

16

i think that’s a very good idea to make a seperate XML-File if i understand it correctly.

i.e. i have a textfield [at0003] which is referencing to values in a global XML-File (containing all SpokenDefaults of all nodes of the domain model).

similar to SNOMED term_binding or is it something completely different?

term_binding = <
		["SNOMED-CT"] = <
			items = <
				["at0000"] = <[SNOMED-CT::19019007]>
				["at0002"] = <[SNOMED-CT::162408000]>

so SpokenDefault is still computable and i can use it in the Application but instead of parsing it from the archetype, i get the SpokenDefault via Referencing?

thanks in advance,
Timmy