I have some proposals that might improve some aspects of the AE:
For composition archetypes
by default start on the “content” area instead of the “context” area. (some of my students have problems with this, and defined the internal structure of the composition inside the context.other_context structure, and that structure sshould be on composition.content).
allow to define sections and entries directly on the “content” instead of only allow slot definitions. (when prototyping complete archetypes are very useful, i.e. archetypes without slots that model complete clinical documents with only one adl file).
Spanish translation improvement
the translation is very poor, how can I translate the GUI terms? (Thomas told me how to do it some time ago, I can’t find his instructions)
The AE is capable of consuming web services
is there some way to do a search on the AE GUI that consumes a search service on the CKM to find, download and edit/specialize archetypes from the CKM directly from the AE?
Add DV_IDENTIFIER as a type for ELEMENT.value
it’s not possible to define a constraint to DV_IDENTIFIER and I think this is a valid archetypable class that can be used in many situations. Now some archetypes uses DV_TEXT or DV_CODED_TEXT to model identifiers and those should be modelled using DV_IDENTIFIER.
I have some proposals that might improve some aspects of the AE:
...
- the translation is very poor, how can I translate the GUI terms?
That would be great, Pablo.
Under the directory where Archetype Editor is installed, there's a directory called "Terminology". You can edit the terminology.xml that you find there. It's pretty straightforward to edit the XML directly, but there's a program called openEHR_Translation.exe in the same directory which you'll probably find makes it easier.
If you send me your improved copy of terminology.xml, I'll commit your changes to the Archetype Editor Subversion repository.
- is there some way to do a search on the AE GUI that consumes a search service on the CKM to find, download and edit/specialize archetypes from the CKM directly from the AE?
A few weeks ago some of us had a look at the openEHR terminology, and identified some of the problems on this wiki page. One of the (obvious) conclusions was that the Archetype Editor ‘terminology’ needs to be its own thing, since it is full of GUI terms. The rest of the terminology (derived from the openEHR Terminology spec) needs to be treated differently.
In the long term, some of it might be replaced by SNOMED CT terms for some of the things like ‘participation types’; some of it will remain, and would go into an openEHR SNOMED CT extension.
In the shorter term we have to be more pragmatic, and the obvious approach seems to be to start from the Java project version of the terminology files, now located in the knowledge2 repository.
On inspection of these, there are some obvious errors and shortcomings, notably a new ‘multimedia types’ group in the openEHR terminologies containing extra IANA media types (aka MIME types) that should have gone into the IANA media types codeset in the other file. We need to address these problems ASAP, and I think that can be done simply. We also need to decide on the file format, and translation approach. The wiki page gives some ideas on this.
The Archetype Editor should therefore start using these standard files for the main openEHR vocabularies and codesets, and limit the contents of its own terminology to its own (localisable) UI strings & error messages, as for any normal application. This probably should morph into the standard i18n format for Microsoft applications, rather than maintaining its own form.
4. It is possible to add a constraint on DV_IDENTIFIER. You need to
click on the (+) button, which gives you the full list of possible
element constraints.
I agree we should make more use of DV_IDENTIFIER, rather than DV_TEXT
I extracted data sets from XML file and made rails app. http://openterminology.herokuapp.com/
At this time, data were not protected, but they can be restored as
default anytime.
What about this for translation?
I didn't read this whole thread, but please put suggestions for change on the Archetype Editor issue tracker <http://www.openehr.org/issues/browse/AEPR>\. I suggest each feature = 1 separate issue. This issue tracker is public and useful for any 'archetype editor' tool, not just the one you are referring to. But of course, to get the changes implemented means registering them, otherwise developers do not see the requests.
