Maybe I've been looking for something that isn't there, so for now
I've solved it to add a date and time of measurement field to the AT
data section. That's the only place where I can add such a field by
using the OI archetype editor. I started to look in the 'event'
section since this date/time filed option isn't available in the dev
AT's (both the 'general' and the NHS-UK ones) and I couldn't imagine
that such a 'basic' parameter was missing.
Can anybody tell us whether we're on the right track.
Cheers,
Stef
PS how big is the group of 'active clinical implementers' in this
community? I don't know if I'm the only one who has this feeling, but
it feels like there aren't too many.
Especially since I don't have an ICT background and most manuals and
suggestions are rather 'technical' I find it very hard to tackle some
of the issues we're encountering.
If the number of clinical implementers is indeed low, isn't possible
to organize some sort of a 'clinical implementers boot camp' to
discuss/tackle/solve issues people are running into. At the same
time a broader group of specialist who share some common values is
created which then are capable of transferring knowledge to others/
newcomers in this community.
Prof. David Ingram stated that that 'the three things that matter, as
I’ve said before, are implementation, implementation and
implementation!'. I couldn't agree more and wanted to add to that the
fourth thing that matter is knowledge sharing.
When any class name is mentioned in an archetype (such as OBSERVATION,
HISTORY, EVENT etc), all the attributes from the openEHR reference model
are assumed to be there. The archetype only needs to mention those
attributes that make sense to constrain ahead of time - typically this
does not include date/time attributes or other specifics of locale or
context.
My view on this is simpler and more concrete - there will be a
date/time field displayed in the software User Interface (that comes
directly from the reference model, and that we don't need to
archetype). The default for that date/time may be now, but can be
changed to something else.
Therefore don't need to archetype date and time separately.
only imagine that what they see in the archetype will be what can
possibly be displayed on their User Interface. It would be ideal if we
can work to make the 'unseen' magic that comes from the reference model
clearer, as the UML diagram is (almost) totally unintelligible to
others, like me, and even if it can be understood, they may not
neccessarily be able to make the leap from the diagram to how it will
work in practice (ie a UI).
Perhaps the apparently 'hidden' reference model stuff should perhaps
even be displayed, in an uneditable format, in the Archetype Editor and
Template Designer - to make this design process more transparent and
help bridge the clinical/technical divide just a little.
Perhaps the apparently 'hidden' reference model stuff should perhaps
even be displayed, in an uneditable format, in the Archetype Editor and
Template Designer - to make this design process more transparent and
help bridge the clinical/technical divide just a little.
This very much matches my point of view. Ideally archetype editors etc
should be delivered with a built in mini-EHR system for simple testing
purposes (security, scalability etc would not be in focus then). I
think such a solution will come from somewhere eventually. I'd love
provide something like that in the LiU Archetype Editor. I wish we had
enough time and resources to implement that, currently we have to
focus on other more urgent things. We do have engineering students
doing master thesis work around openEHR-based GUIs though and with
some luck that might provide some parts of the suggested solution.
Maybe I've been looking for something that isn't there, so for now
I've solved it to add a date and time of measurement field to the AT
data section.
you don't need to so this - it is already in the reference model - not
every attribute in the reference model classes are mentioned in
archetypes. The reference model classes for History, Event etc are
visible here - http://www.openehr.org/uml/release-1.0.1/Browsable/
_9_0_76d0249_1109157527311_729550_7234Report.html
Thanks, that was what I was looking for but didn't know where to find
Ocean is working on making the participations archetypeable in the ENTRY class as this is the most common issue at the moment. The events are archetypeable and appear in the editors. There is still a lot to do in this area and we have been working on the design of a wizard to provide a view a bit like this.
Thanks for your question which is very important because it shows how clinical people understand the archetypes and Reference Model. I am sure you have got all responses to your question. In a word, the event time field is in the reference model which is not shown in the archetype editor. That’s why you confused. I support Heather’s suggestions. Archetype developer doesn’t need to understand/know the reference model classes and all the fields in each class. They should be simply displayed in the archetype editor.
Perhaps the apparently 'hidden' reference model stuff should perhaps
even be displayed, in an uneditable format, in the Archetype Editor and
Template Designer - to make this design process more transparent and
help bridge the clinical/technical divide just a little.
This very much matches my point of view. Ideally archetype editors etc
should be delivered with a built in mini-EHR system for simple testing
purposes (security, scalability etc would not be in focus then). I
think such a solution will come from somewhere eventually. I'd love
provide something like that in the LiU Archetype Editor. I wish we had
enough time and resources to implement that, currently we have to
focus on other more urgent things. We do have engineering students
doing master thesis work around openEHR-based GUIs though and with
some luck that might provide some parts of the suggested solution.
I agree that we need this kind of functionality; it will be implemented
fairly soon in the ADL workbench and Archetype Editor.
Great. Does this also mean that this 'hidden' reference model stuff
will/can be a part of a template? From my point of view I would like
to 'control' (view and/or enter) thing as date/time of measurement
via a template.
Another question related to that. The way I think to understand it
(as a non-technical person:-) ) we can use the XML message's created
by the archetype editor to display and post data to and from a UI/
website.
But here again, this XML message comprises only the classes that are
created in the archetype but not the 'hidden' stuff.
Is there an 'overhead' XML message in which the 'specific' AT XML
message can be embedded/nested so one has access to all available data?