Matias Klein wrote: > Hello Everyone, > > Before replying I wanted to give this issue some serious thought. > Ultimately I believe this problem comes down to rendering. Since I > feel that proper rendering of archetypes is central to lossless > interchange, IMHO this is going to have a major impact on the > viability of openEHR as a widespread EHR interoperabilty standard. > > Obviously Tom, Sam, and the rest of the openEHR team already recognize > this issue because I noticed that the LOCATABLE class has a > 'presentation' field which is modeled as a String. Unfortunately this > is hardly enough for complete interoperability.
you are right that we do recognise it - and have for a long time. But the 'presentation' attribute is not really a reflection of what we think should be done about it; in fact it has been removed in 0.9 (to be declared officially any second now;-) since no-one can think of a way to define its contents interoperably. The big picture, as we see it (and we are in no way expert on this yet!) is that there needs to be libraries of clinical visual components which can be a) assembled on the screen in real time to make friendly forms, and b) which formally related to underlying archetypes. So for example, you might define 2 visual components to display systemic arterial blood pressure - the typical terse one something like: +--------------+ | / | mmHg +--------------+ and perhaps another one which displays separate edit boxes, the actual words "systolic" and "diastolic", and the patient state and measurement protocol in some particular visual arrangement. The formal relationship between these components and the underlying archetype is to do with the names of leaf attributes - in teh archetype, there are paths which point to xxx/xx/x/systolic, xxxx/x/xxx/diastolic etc (use the GUI ADL validator tool to see these paths properly in the example archetypes); there needs to be a GUI glue language which ties these semantic properties from the archetype to the visual properties of the screen component. Now, if that is achieved, then writing a template consists of: - nominating which archetypes go to make up a form, default values, whiich optional parts to remove etc - and nominating which visual components to associate with each one, where choices exist (like the BP example I just described) As you can see, the idea of a 'template' is becoming a sophisticated idea in its own right. Two companies I know of have done something along these lines (separate developments, so somewhat different approaches). They would probably be happy to discuss their experiences, but of course I need to ask them first. One of these companies has a visual component broker where 'fit' visual components 'compete' at runtime to display semantic information fragments controlled by their archetypes. > > Enhanced viewing of information is essential. What if I want all > users of my archetype to see information in the same way? > > Clearly it's a great step in the right direction to be able to send an > openEHR document to another EHR system and have some degree of semantic > interop, but if the archetype can't be properly rendered, there is > only marginal value in the transaction. or let's say, it's only half the information you want, if your main goal is to get the stuff on the screen, whcih it often is. But if it is to do decision support processing, the visual part won't matter. > > If a structured document fits the openEHR RIM (i.e. FOLDER -> SECTION > -> ENTRY) [FOLDER->]COMPOSITION->SECTION->ENTRY :-) > then I can at least partially render it, but possibly not with > the correct style and context. Unfortunately, the result is only > partial interoperability. correct; as long as your definition of 'interoperability' involves rendering. I can see that a perfectly reasonable definition is of course - since a major goal of moving data around is ultimately to get the same message that was written in one tool into the mind of another person receiving the data, probably using a different tool. > > Coming back to the issue of propositions... A proposition can be > thought of as merely a way to view concepts which are embedded within > the question and answer. Tom already stated this. However, I feel > the EHR should be able to extracted and compose these concepts into a > final concise report or note. > > Think about multi-dimensional questions for a moment: > > - Do you have X? > - If so, when was it diagnoses? > - If before 1930, did you receive procedure Y? > > Granted this can be modeled as a questionnaire list with three separate > questions. However as a GUI designer, you only want to show the > second and third parts when appropriate. yes, this is a very good point. In an ADL archetype, so far we don't quite handle this properly - there is not the idea of 'conditional optionality' but there probably should be. On the matter of reporting from structured data, Philippe Ameline (Odyss?e product) has a lot of experience with this in the endoscopy domain (if he's reading this - maybe you can share some ideas?) > > I know this can be delegated to the software, but if I "hard code" this > into my system, the same functionality will not be available to others. > In addition, on someone else's system, presentation of the complete > tree of non-relevant questions could interfere with the understanding of > the relevant data. I suspect we should put this semantic into ADL, but even then, it doesn't directly connect it to the visual domain. But consider this: even at the moment, bits of a tree which are optional in teh archetype, will cause only those bits of the tree actually used to be stored in the data - so the data transmitted should only reflect the questions actually answered - there is no compulsion by the archetype to retain data trees that were not used, as long as they were defined as optional in the archetype in the first place. > > In Thomas' proposed modeling of the patient questionnaire, each of the > three archetypes has its question modeled as the 'name' of the > archetype. As he noted, this leads to horrible paths (i.e. > /patient1001/history/past/do you have X?/). it does! > > In the end, the concepts we want added to the patient's health record > are: > > Concept 1: Has X (condition) > Concept 2: Received Y (procedure) > > The result is a concise and clear addition to the patient's health > history. Adding the three questions only clutters the practitioners > ability to understand the patient's health. > > I know this issue may be outside the scope of openEHR, but I > think the model should have a more elegant method of supporting it. > Perhaps some type of stylesheet include directive along with strong > suggestion to adhere to an existing presentation standard should be > added? Otherwise maybe some sort of mapping syntax between views and > archetyped structures could be detailed? this latter is where we are going. We have not done too much on it yet, because I am very concerned to get input and experience from people/companies who have implemented frameworks for doing such things, before openEHR goes off into the wild blue yonder inventing a paper solution wildly different from what might work. What openEHR does have is a number of documents where we could start documenting requirements, and some framework for a solution. To do that we need the community involved, especially those who have real experience in this area. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
