There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html
As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives.
Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any):
What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes.
Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out.
There's also an opensource project called EHRFlex, which is an
archetype-based clinical registry system (EHR) independent of a
particular reference model. It uses clinical archetypes as guidelines
for the automatic generation of web interfaces, oriented to a clinical
use and data introduction.
Currently only supports ISO/CEN EN13606 archetypes (but could be
extended to work with archetypes of any other reference model) and
doesn't support templates yet
This is an excellent suggestion. With respect to ADL 1.5, the
operational template is, I think, the key artefact. It is the 'close
to run-time' data definition, and can act as the start point for a
great deal of downstream tooling support. It would be interesting t
know how readily other local template-based openEHR projects can
generate an operational template, since this not only gives a pivot
oint for GUI directives etc but makes it possible to switch back-end
persistence very easily.
Ian
Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I’ve been waiting for since I first viewed this list a couple of years ago.
Then, as a next step one could start discussing various extensions, directives etc.
I agree this is a significant missing piece of the reference model and
I am not sure how close the overall ADL 1.5 spec is to being finalised
but the operational template definition appears to be very stable and
can act as a reference point for coalescing various local template
implementations and tooling developments. Thomas has already added
ADL1.5 support to the ADL Workbench and the specs seem to me to be
stable enough to start implementation in Java. I think the issue is
lack of time/resource, rather than immaturity of the specifications -
it would be interesting to get Rong's take on this but I suspect he
implemented a great deal of the current Java model prior to a stable
RM being specified. Indeed I would only expect a truly stable
specification to emerge after some implementation experience.
IMO most real-world implementations which strive for interoperability
and maximally-defined archetypes will almost all work via operational
templates for validation, code -generation GUI integration. I don't
think we have to wait for the full ratification of ADL1.5 and template
spec to start doing interesting things in downstream support, assuming
that the opt definition is pretty stable. The issues of extra
directives and extensions are important at this stage as arguably some
should be supported in the operational template, as I discussed above.
Ian
Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
IMO templates are an implementation specific issue and should not be
part of the reference model. Archetypes that express a concept as a
maximal dataset are sufficient for interoperability. Local templates
are just that; local templates. Certain implementations may share
templates between applications but I dare say any attempt to 'standard'
across implementations is wheel-spinning.
If people are expecting magic pop-out-of-the-box applications then they
are taking something mind-altering.
Yes and no… we used to think that templates would be only local, but it is now clear that governments want a way to standardise whole data-sets, which is what an (ADL 1.5) template is - effectively an archetype that grabs bits of other archetypes and puts them together to create a specific data set, e.g. mixture of data captured in a specific kind of consultation, or lab result, or a discharge summary or whatever. These templates are very likely to be standardised, and offer a much better way to do this than the current way of doing it which is generally via ad hoc XML schemas. An ADL 1.5 template can be expressed as an XSD of course, but this is a downstream tool generated schema, not a hand-designed one.
Further it turns out that a lot of institutions really do want to share templates, so a shareable formalism is actually important here.
I am happy to read this opinion and I do fully agree on this.
This makes it possible to use templates for any purpose desired.
I already had thought of some template enrichments which work with CSS.
Now that there is template parsing software in Java, I am thinking of further developing/implementing it.
Next step will be a repository with archetyped controls, like a GUI building developing tool, it even could be an eclipse or visual studio plugin, or write an own development environment, and so enabling a drag and drop development tool for people close to the medical professions.
The templates could be the base of a Windows-executable GUI, or Mono, or Java, or PHP, or Javascript/HTML (AJAX), a client application that changes, depending on the template loaded. It is all a matter of just work to do.
Maybe I am jumping too many steps in one time, but something like that is my bit further goal.
Well we are pretty close with ADL 1.5, and I would expect that the Java project could safely start implementing what is in the current draft of ADL 1.5 and the Template document. So, hopefully not too many months now.
It is not just governments who will want to use templates to define
agreed minimum datasets. At present all decent attempts at
interoperability are essentially project-driven and often quite local
e.g. Diabetes shared care dataset, Palliative care message, Emergency
care summary. The difficulty has always been to ensure that each
project does not end up defining variant semantics for the same core
concept as they all tend to have slightly differing end-requirements.
Templates turn out to be an excellent way to allow these specific
use-case datasets to be defined whilst ensuring that the underlying
semantics do not end up in silos since they are expressed in the
underlying archetypes. Even when semantic differences cannot be
resolved, it helps to express genuine disparity within the same
archetype e.g differing pain scales, as it helps to concentrate any
on-going debate into the enclosed scope of a single archetype.
Ian
Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
We had a similar discussion at the EN13606 web page. These are the conclussions I got.
We should distinguish two types of templates:
Structural templates (specific use). Artefacts that constrain archetypes for specific uses or aggregate them in order to build more complex structures. These are the current openEHR templates.
Visualization templates (local use). These are a new idea. Local templates are just for visualization configuration (for example, positioning of the elements, definition of the size of a field, selection of a visual representation for a class or selection of the interface language).
The important here is to distinguish “specific use” from “local use”. In my mind, a specific use is to define a use case where only a part of the archetypes or several archetypes are used. This is related to data structures. For example, to keep only the part of the blood pressure archetype that is important for the Primary Care measurement of vital signs. This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. On the other hand, a local use is when you define constraints that are only useful for your own use or specific system. This is related to GUIs. These visualization templates are not meant to be shared outside your institution.
ADL 1.5 is enough for defining the structural templates. Visualization templates needs something else to be defined. I would not recommend the use of those GUI-directives mixed with the structural templates, but to define a new level (maybe a specific model) for them. As some of you said, maybe these visualization or local templates do not need to be a part of “standardized” architecture since they are local implementations, but I think that it is possible to design a kind of common framework to deal with them together with archetypes and structural templates.
I definitely agree with this separation into what you call structural and visualization templates.
It would be really nice if the structural ones became a reality and were implemented into for instance the
Java reference implementation. These were almost finished a couple of years ago and seem to still be almost finished.
Then one could use these as the basis for looking into ways of doing the visualization templates.
This would be cleaner then having many different variations on the structural templates with different kinds of hints etc.
if someone designs a template that has say a more limited set of Snomed or other codes on a field than the original archetypes had, then querying the data may be enabled with the template at hand, since it would tell you what (reduced) set of code values could be possible in that field. This is one of the most common uses of templates we are finding. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. This is distinct from any ‘visual template’ stuff, which I agree should be a distinct artefact and probably formalism.
if someone designs a template that has say a more limited set of
Snomed or other codes on a field than the original archetypes had,
then querying the data may be enabled with the template at hand, since
it would tell you what (reduced) set of code values could be possible
in that field.
So are you introducing some mind reading into this situation? Otherwise
I cannot see any other outcome. Because what you are telling me is
that it is somehow meaningful in discovering the rational for choosing a
Snomed code from a set as opposed to choosing the same Snomed code from
some subset. Hopefully, my healthcare provider is choosing their codes
based on science. Therefore they choose the correct one either way. Of
course if the correct one was subsetted out; that just equals BAD
TEMPLATE.
This is one of the most common uses of templates we are finding.
So somehow knowing the possible choices somehow affects the actual code
in the field you are querying?
I can imagine other thing, e.g. coding of fields that were just
DV_TEXT in the archetype.
While I still think that this is a bad idea anyway. After all; it is
either free text or coded text. Pick one. I still don't understand how
knowing what set was available is meaningful to the code chosen.
In ADL 1.5-land, a template is just another layer of archetyping, with
some extra features.
I still fail to see the need. It seems to me to be a useless layer of
complexity. But, I am still interested in a use case where templates
are 'needed' to 'fully interpret' the data.
This is distinct from any 'visual template' stuff, which I agree
should be a distinct artefact and probably formalism.
And this level is dependent on implementation choices. Only
applications built using the same framework can share these templates.
If an entity is going to dictate presentation options and layout then
they are likely (IMO) going to do so in the context of the same
framework.
This is one of the most common uses of templates we are finding.
So somehow knowing the possible choices somehow affects the actual code
in the field you are querying?
in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype.
I can imagine other thing, e.g. coding of fields that were just
DV_TEXT in the archetype.
While I still think that this is a bad idea anyway. After all; it is
either free text or coded text. Pick one. I still don't understand how
knowing what set was available is meaningful to the code chosen.
well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template.
In ADL 1.5-land, a template is just another layer of archetyping, with
some extra features.
I still fail to see the need. It seems to me to be a useless layer of
complexity. But, I am still interested in a use case where templates
are 'needed' to 'fully interpret' the data.
you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful.
This is distinct from any 'visual template' stuff, which I agree
should be a distinct artefact and probably formalism.
And this level is dependent on implementation choices. Only
applications built using the same framework can share these templates.
If an entity is going to dictate presentation options and layout then
they are likely (IMO) going to do so in the context of the same
framework.
sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable.
Hi All, late to respond but here are a few thoughts:
While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function.
I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘change’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view
I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations.
I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with.
My 4 cents…Cheers,
-koray
P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community…he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions…
Hmmm,I am very interested in hearing about a use case where these
templates are 'needed' to 'fully interpret' the data.
Thanks,
Tim
Maybe I do not have the knowledge to give a valid clinical example but
it is reasonable to think that constraining an archetype in the way a
template does can influence the interpretation of the data.
Imagine you have a set of archetypes and you define a template
constraining some items to not allowed. You use that template to fill
some data and then you require the collaboration of a physician from
an external organisation. You share the archetypes but not the
template. And then the other physician fills some more data (including
the one you marked as not allowed) and returns it to you. There is the
problem, when you revise the data using again your own template you
will never see part of the new data and that can affect your
interpretation of it.
That's why structural templates must be also shared in some cases.
Maybe I do not have the knowledge to give a valid clinical example but
it is reasonable to think that constraining an archetype in the way a
template does can influence the interpretation of the data.
What is reasonable is subjective; but okay.
Imagine you have a set of archetypes and you define a template
constraining some items to not allowed.
Okay.
You use that template to fill
some data and then you require the collaboration of a physician from
an external organisation. You share the archetypes but not the
template. And then the other physician fills some more data (including
the one you marked as not allowed) and returns it to you.
Okay.
There is the
problem, when you revise the data using again your own template you
will never see part of the new data and that can affect your
interpretation of it.
It that *is* a problem then ==> Bad application design.
That's why structural templates must be also shared in some cases.
#1. You do not revise data in a health record. You version it with
additional information.
#2. Any well designed archetype / template combination is going to use
the same 'data structure'. Irregardless of the available options.
#3. The templates you use should only restrict data entry. It should
not filter existing data of the same structure. If it does; there goes
interoperability. Along with the entire premise for the use of and
purpose of archetypes.
