openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[system]

Hi!

I hope you don’t mind breaking out a side thread with a concrete harmonisation sugestion. First an openEHR change request, then an ISO 13606 change request.

Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see:
http://www.openehr.org/mailarchives/openehr-technical/msg04994.html

I’m not saying we should go exactly by the letter in Sam’s CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementetion complexity. It would also shorten paths (and thus storage depth) one step - a possible performance gain.

Probably letting the “data” atribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best.

If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using either…
a) a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pdf
b) a new attribute in the CLUSTER or ITEM class
c) …some other way i have not thought of

Suggestion a means the hint might not be available in instance data, only in the archetype, that

Shortcuts to UML diagrams for comparison:
CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf
openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gif

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

[system]

Oops, I intended to push the save-button, not the send-button on that last message. Now we’ll just have to make a fire, shovel some snow, milk our goats, say good morning to cat and chickens, fix a leaking car tire, get kids to school and myself and my wife to work before I can continue writing. Sorry about spamming the list.

// Erik

[ian.mcnicoll]

Hi Eric,

I thought the original post was pretty complete!!

I would strongly support this proposal. In practice we have almost
wholly abandoned using anything other than ITEM_TREE as the top-level
archetype structures, for all the reasons suggested by Sam. Tables are
useful but generally within the body of the archetype,rather than as
the top-level structure. A good example is neural reflexes, for which
a table structure is appropriate but which would be better expressed
within a CLUSTER archetype, rather than ENTRY, to cope with variations
in Examination recording practice.

We are also finding that the use of embedded archetypes based on
ITEM-TREE is a little cumbersome. There is considerable value in
having child archetypes which can be re-used in different parent ENTRY
archetypes e.g. Medication details or Specimen details, but using
CLUSTER gives us much more flexibility.

Some kind of simplification around the use of CLUSTER, with the
ability to define TABLES within a CLUSTER or ITEM_TREE would give us
some simpler modelling constructs and, as you suggest, flatten the
data path.

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 wHi Eric,ww.phcsg.org

[system]

Hello again!

Here comes a more complete version of the mail I happened to send unfinished this morning.

I hope you don’t mind me breaking out a side thread with concrete harmonisation suggestions. First an openEHR change request (CR), then an ISO 13606 change request.

1. item_structure (openEHR CR)

[thomas.beale]

I will offer both some agreement and a counter-opinion. Everyone always wants things ‘simpler’, and without foresight, it is very easy to make them too simple. Let’s take the two cases: ITEM_STRUCTURE data structures, and Observation.data (of type HISTORY). It turns out that the discipline in structures we thought existed in clinical data - Lists, Tables, Trees etc, is less clear in reality, and apparently clinical modellers want to just make everything a tree-like structure. I personally am still somewhat sceptical that this is really true, because in the many tabular, particular bilateral information structures (reflexes, audiogram, much ophthalmology, and so on), throwing out the ability to define a Table structure in the data simply means that tabular structures may get built in different ways be different groups. Internationally standard archetypes can remove this problem partly, but software still has the job of working out how to correctly put the data on the screen and also capture it, in ways familiar to clinical people. But - let’s assume that, all things considered, this simplification was to prove useful, and the consequential downstream costs were acceptable. We could in that case make some small simplification of the current models.

Now consider the counter-examples: Observation.data, the structure of Action and Instruction. Let’s stick with the first one for the moment. As mentioned in previous posts, we chose to define a History data structure in the RM because it is absolutely ubiquitous in observational data, no matter whether it is one or many samples, and no matter what part of medicine or science it comes from. Here are some paths from the Apgar archetype - you can see where they contain ‘events[1 minute]’, ‘events[5 minute]’ etc…

– note that everything below shows English language translations of terms
/data: HISTORY
/data/origin: DV_DATE_TIME
/data/duration: DV_DURATION
/data/period: DV_DURATION
/data/events[1 minute]: EVENT
/data/events[1 minute]/offset: DV_DURATION
/data/events[1 minute]/data/items[Heart Rate]/value: DV_ORDINAL
/data/events[1 minute]/data/items[Respiratory effort]: ELEMENT
/data/events[1 minute]/data/items[Respiratory effort]/value: DV_ORDINAL
/data/events[1 minute]/data/items[Muscle tone]/value: ELEMENT
…
/data/events[2 minute]/data/items[Heart Rate]/value: DV_ORDINAL
…
/data/events[5 minute]/data/items[Heart Rate]/value: DV_ORDINAL

For an archetype containing Interval_events, e.g. any rolling BPs, temperature etc, you get paths like:
/data/events[any event]/offset: DV_DURATION
/data/events[any event]/width: DV_DURATION
/data/events[any event]/sample_count: Integer
/data/events[any event]/math_function: DV_CODED_TEXT – e.g. value could be a code for ‘average’

These paths correspond to formal data structures, as you can see here. Have a close look at these classes. Everything here can be archetyped. The INTERVAL_EVENT class for example provides attributes for sample width, sample_count (allowing data compression from ICU and other devices), and math_function. In all there are around a dozen formally specified attributes here that would not exist in a simple Entry.data: Cluster model. That’s not just 12 things that both archetype specifiers have to invent, but also 12 things implementers have to invent - i.e. find names for, decide on types, and structure (hint: there are not just 12 ways of doing this, but hundreds of millions).

History tells us that organisations in the latter group will do this differently every time. Note that it took probably 4 years to get this model into its current form, where it works for everything we can throw at it now. I have to ask - why go back through that pain? Why go to a model that is too simple, only to discover too late a whole raft of problems that this model takes away? If anyone doubts this, just have a go at remodelling 20 or so of the most common Observation archetypes you can find on CKM, in the 13606 model. You can try this in the existing openEHR tools by either using an Evaluation structure (which does happen to be a tree) or the openEHR Generic_entry type. Any such archetype can be validated and viewed in the ADL Workbench or Archetype Editor.

Let’s see what would happen to the paths and types if you do this:

Fred’s version of Apgar based on Cluster/Element structures:
/data: CLUSTER
/data/items: CLUSTER
/data/items[origin]: ELEMENT
/data/items[origin]/value: DV_DATE_TIME
/data/items[duration] – not defined by Fred
/data/items[period]/value: Real – oops - Fred prefers ‘Real’ here
/data/items[1 minute]: CLUSTER
/data/items[1 minute]/time: DV_DATE_TIME – oh no… Fred wants absolute time points, not offsets
/data/items[1 minute]/items: CLUSTER
/data/items[1 minute]/items/items[Heart Rate]/value: Integer – Hm. Fred just wants to use an Integer here
/data/items[2 minute]/items/items[Muscle Tone]/value: Integer – Hm. Fred just wants to use an Integer here

Janes’s version of Apgar based on Cluster/Element structures**:**
/data: CLUSTER
/data/items: CLUSTER
/data/items[origin]: CLUSTER – oh no, Jane wants to use a CLUSTER here!
/data/items[origin]/value: DV_DATE_TIME
/data/items[duration]: Real – Jane decided on a Real here
/data/items[period]/value – not defined by Jane
/data/items[Any time]: CLUSTER – Jane is not going to control the times at all
/data/items[Any time]/timepoint: ELEMENT-- Jane records the time in this new attribute
/data/items[Any time]/items: CLUSTER
/data/items[Any time]/items/items[Heart Rate]/value

Bob’s version of 24h BP based on Cluster/Element structures**:**
/data/items[4 hour]/items[diastolic]/value: Real – Bob has collapsed the path here; Fred’s software that
understood Fred’s structure of logical ‘history of events’ data now won’t work on Bob’s data.

…
X 1,000 other clinical modellers around the world
X 1,000 other archetypes
X 10,000 software developers around the world.
= 10 billion more incompatible combinations than we have today

Now consider the internal structures of Instruction and Action (here). Consider just the simple fact that Action is a conjunction of ‘time’ (would anyone argue against this?), ‘description’ (ditto), and various other details to do with the Instruction state machine. I am not saying that this model is perfectly correct; maybe it needs a ‘other_details’ attribute as is used elsewhere in openEHR. But again, just do the thought experiment of having nothing but a Cluster/Element structure to work with. You immediately have to a) work out a model of where you will record time and description, b) if you want it to be interoperable, you will have to get into some kind of standards discussion with other people to agree on the same structure and c) you then have to complicate all the tooling software and also downstream software in order for it to ‘know’ that this particular Cluster/Element structure is really an Action structure, and to diplay it as such. The downstream complications will be quite significant. It is the difference between giving a software developer UML pictures like the above, or … a completely generic tree structure, which is as good as giving them nothing.

In summary: there is a strong argument in my view for avoiding all this modelling and downstream complexity. A challenge to the health informatics community is to actually show how it will be better for modelling and software to just go to a simple Cluster/Element model (or in HL7 terms, Act/Act-relationship). If it can be done and save time and trouble compared to what we have done in openEHR, I will be the first to embrace it.

Note: flatter data paths are aesthetically pleasing to humans, but computers don’t care about them. They care about consistent path structures.

• thomas

(attachments)

[system]

Tom, did I really express myself in such an unclear way or did you not read properly? Or did you respond to the wrong thread somehow? Perhaps i misinterpret your tone and arguments so please clarify if you have problems with the following:

1. tables, clusters etc

I did not suggest that we should avoid having a single fixed way of defining table structures in openEHR. I suggested using a new attribute to indicate if a cluster is conceptually/graphically to interpreted as a table, list etc. instead of using separate classes for this purpose. Of course we need strict definitions of allowed values for this attribute (an enumeration or a list in the openEHR terminology, just as in other parts of openEHR presently). Of course specifications should include exactly how to interpret the clusters as rows and columns.

Ian and Sam indicate that this would also have the benefit of allowing tables anywhere in a cluster hierarchy instead of only at top level. Do you have any objection against this provided that it is introduced in a well defined manner as described in the previous paragraph?

Your argumentation sounds like somebody suggested that tables are not needed in openEHR at all or that they should be defined in random different ways.

2. Observations etc.

I suggested that ISO 13606 gets extended with the openEHR ENTRY subclasses. Here I did not suggest changes to openEHR. (Even though I tried to say the class names can be confusing if you for some reason strongly believe that a technical class name only can be used for exactly what your own perception of that English word means.) Perhaps your OBSERVATION examples are just your way of expressing that you support my idea and why it is important to have the ENTRY subclasses to encourage consistency.

The part about automatically converting openEHR ENTRY subclass structures to 13606, was definitely not a suggestion to remove them from openEHR. Instead it was more of an enquiry if it was at all possible in a non-destructive way. If it is, then openEHR archetype modeling, queries etc could after auto-conversion be used somewhat safely in a setting where you only have 13606 available.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

[SEABURY_Tom_NHS_DIGI (SEABURY, Tom (NHS DIGITAL))]

I cannot claim to be an implementer of openEHR but I am still interested to understand the proposed use of Tables.

Can anyone point me to a place where this is already explained with examples, the abstract discussion is a little hard to follow.

My simple reading of this is that what are currently trees would instead be expressed as a sparsely populated arrays – is that the point?

Tom Seabury

NHS Data Standards & Products

[thomas.beale]

Tom, did I really express myself in such an unclear way or did you not read properly? Or did you respond to the wrong thread somehow? Perhaps i misinterpret your tone and arguments so please clarify if you have problems with the following:

Apologies - I responded after reading the first version of your post, which had no point 2, but I was also trying to respond to more general criticisms (other people have said get rid of tables etc), not specifically just your post.
(It took me a while to write that post, and I did not see your final version in time - seems we are in fierce agreement

your point about the class names is of course a good one. We chose names that came from the ontological analysis, which some people will disagree with (or agree with, but hate our choice of names!). But in the end, the meaning (and therefore arguably the best name) of a class comes from its intentional definition, and nothing else. So your painful class name proves exactly this point. I would of course argue for a shorter name, but going on your approach, Observation could be named in 13606 as something like ‘DataHistory’ or so. Personally, I would rather stick with ‘Observation’, because intuitively most people get the fact that it is about data in the past, and they generally immediately understand why it has a time-series structure. But I accept that this is only one way of seeing this, and would not be religious about it.

‘Evaluation’ as it turns out is an even more contentious name; we originally proposed ‘Assessment’, ‘Opinion’ and other similar names. Sticking with your theory, it possibly should be called ‘AnythingYouLike’, ‘GenericEntry’ or somesuch, but the problem going down this road is that it then obscures the link between the ontological model (I mean the problem-solving model of doing healthcare, that gives rise to categories like Observation, Evaluation, Instruction, Action, and all other similar models, like G-EPJ, the Swedish process model and so on) and the information model, and it makes it harder (in my view) for newcomers to know which Entry class to use for what.

For those unaware, we started the openEHR/13606 mapping here, and you can see if you look carefully that there is an initial description of where a purely automated conversion algorithm that Erik is talking about goes.

• t

(attachments)

[thomas.beale]

I cannot claim to be an implementer of openEHR but I am still interested to understand the proposed use of Tables.

Can anyone point me to a place where this is already explained with examples, the abstract discussion is a little hard to follow.

My simple reading of this is that what are currently trees would instead be expressed as a sparsely populated arrays – is that the point?

[ian.mcnicoll]

Just for info the only current example of a CKM archetype which uses
ITEM_TABLE is

Tendon and Babinski reflexes

http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.256_1

and the Audiogram example in Thomas's link shows exactly why
ITEM_TABLE in an archetype root is unhelpful, since it needs a number
of other non-lateralised statements, such as Normal statements,
clinical description, multimedia etc. Having the Findings cluster
expressed as a table would make perfect sense, although it would also
have to support layering of detail below that, which might make
tabular representation difficult in all cases.

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

[system]

Hi!

My simple reading of this is that what are currently trees would instead be
expressed as a sparsely populated arrays – is that the point?

Just to clarify it is has not already been clarified enough by others:
Everything that is currently a tree in openEHR archetypes would most
likely remain a tree. What would change is that the rarely used class
ITEM_TABLE would no longer be needed. The data in an ITEM_TABLE
already today is represented as a cluster internally.

So, no, what are currently trees won't become sparsely populated arrays.

Hope that helps.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

P.s. to Tom: those PAINFULLY_LONG_CLASSNAME_SUGGESTIONS were only
intended to make a point, not as a final suggestion. openEHR probably
does not need to change anything as long as the potential confusion is
well described in specifications and presentations. (See the post
http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html for
details again.) If CEN/ISO still have problems with the names after
such an explanation then one could assume that they will be the ones
suggesting better alternatives.

--- warning, irony below this line ---

I remember the infection around the word "ontology" at a
SemanticMining event where it became the "o-word" Perhaps the
OBSERVATION will meet the same fate? O-ENTRY? And EVALUATION ->
E-ENTRY?

[system]

Hi All

The HISTORY class is an absolute godsend - could be a bit simpler but really
it is one of the reasons openEHR is going ahead. Once people get to use the
INSTRUCTION and ACTION classes there will be another leap of understanding.
Our recent work with the instruction index is making managing health
information in a distributed environment possible.

We have learned a lot over the past few years - but I am a practicing
clinician and the following should be read with that in mind!

There are two things that we cannot achieve with ADL alone:

1. Restrict a cluster to a list; and
2. Create a consistent representation of tables which have allow pivots as
this is the main form required for clinical data (row headings and column
headings).

I believe that in the interests of existing data we made DATA_STRUCTURE
inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and
deprecate TREE and SINGLE. This would keep things moving ahead. The data
attribute would then be a cluster rather than an item_structure.

This would respect the existing data and allow the change of archetypes over
time but existing data would remain compatible (except ITEM_SINGLE which is
not used).

It would mean a change to the RM in the area of data_structure. I do not see
any need for Item_Structure and History to inherit from this class and I do
not believe this inheritance is used to advantage within the RM. So changing
Instruction.activity.description, Observation.History.Event.data,
Action.description and evaluation.data to cluster would be the first step.
History would be a stand alone locatable class and ITEM Structure inherit
from cluster.

Functions associated with ITEM_TREE are relevant for CLUSTER and could be
subsumed. The functions of ITEM_LIST could also be subsumed although the
return value would be ITEM (The ITEM_LIST could provide the constraint of
these functions to ELEMENT). The 'as hierarchy' feature becomes the 'items'
of CLUSTER.

ITEM_TABLE has a lot of features and no data - I believe that it needs some
added data around the pivot expression. While this may be considered only a
display feature, it is critical to the interpretation.

That is my change request and one that will align openEHR and CEN 13606 more
deeply with benefit to both. It will make CLUSTER archetypes available as
the root for some ENTRIES (what is called embedded in the Archetype Editor)
and as further down the tree in others. These will be available for CEN and
openEHR.

There is one more thing I would advocate for: Calculation of the max and min
cardinality of the cluster and not setting it. This is problematic from the
point of view of future revision. To illustrate:

If I have one mandatory element (1..1) and four optional ones (0..1) then
people argue that I could set the cardinality of that list to 1..5. The
problem is if next week one of the optional ones becomes 0..* - quite likely
with terminologists about. Now the cardinality is wrong and we need a new
version. I would argue that we should not set the cardinality of clusters
unless we are forcing a choice between two sets - Tom has been looking at a
way to do this anyway and if that arrives I would argue that we should not
allow cardinality statements in clusters at all. They are redundant.

Cheers, Sam

Cheers, Sam

[system]

You can find here the related work to this problem from our colleagues at the University of Murcia.

An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes.
Catalina Martínez-Costa, Marcos Menárguez Tortosa, Jesualdo Tomás Fernández-Breis
Journal of Biomedical Informatics 43(5): 736-746 (2010)

David

2010/11/10 Thomas Beale <thomas.beale@oceaninformatics.com>

[Tim_Cook2 (Tim Cook)]

While a lot has been learned. The universe of people actually
developing archetypes is rather small when compared to healthcare
professionals globally.

I believe that Tom will concur that those structures were all included
because they make sense from an engineering stand-point. At this point
in the evolution, I do not believe that we even know all that we don't
know about building knowledge structures.

When Albert Einstein said; "Make everything as simple as possible, but
no simpler." he likely stressed the last phrase.

As far as the comment about the ENTRY sub-classes intruding on the
ontological space. They do not intrude, that is a point of intersection
where one represents knowledge and the other gives it structure. Both
are a requirement for interoperability.

My 2 cents.

--Tim

[thomas.beale]

As far as the comment about the ENTRY sub-classes intruding on the
ontological space.  They do not intrude, that is a point of intersection
where one represents knowledge and the other gives it structure. Both
are a requirement for interoperability.

well said

[Heath_Frankel3 (Heath Frankel)]

Hi Erik,

Interestingly, this is the same proposal I put to Thomas about 8 years ago and I go the same response. I do understand his rationale for making a table a class rather than an attribute with additional conformance statements to ensure a table is represented consistently, but we know how well implementation guides get followed by developers. In addition we would be missing the functions on the class that which make it more pertinent.

My concern at this point is that we do already have patient data being collected using openEHR and collapsing the ITEM_STRUCTURE would be a breaking change, I think it would need to be a 1.1 or 2.0 change if it was going to happen.

Having said that, looking at the requirements from the clinicians it seems that the need for TABLE is actually at the ITEM level rather than the DATA_STRUCTURE level and Sam’s proposal of extending CLUSTER for TABLE and LIST (although I would suggest inheriting from the abstract ITEM) would not be quite as bad as we can simulate the same levels of structure for legacy data (although the class names would still be different unless we included all of the ITEM_STRUCTURE types as a type of ITEM to retain backward compatibility).

I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. The effort required to implement this would have been much greater if these classes were not specifically modelled. I guess as openEHR penetrates the market, the more likely CEN 13606 would be updated with these enhancements. To be honest I think this is the right standards process, standardising of implementations that are known to work in practice. I am sure we will learn more and improve the ENTRY subclasses further before they go into the CEN standard, then the standard will be more useful.

Heath

[thomas.beale]

Hi Erik,

Interestingly, this is the same proposal I put to Thomas about 8 years ago and I go the same response. I do understand his rationale for making a table a class rather than an attribute with additional conformance statements to ensure a table is represented consistently, but we know how well implementation guides get followed by developers. In addition we would be missing the functions on the class that which make it more pertinent.

My concern at this point is that we do already have patient data being collected using openEHR and collapsing the ITEM_STRUCTURE would be a breaking change, I think it would need to be a 1.1 or 2.0 change if it was going to happen.

probably 2.0. The nice thing is, even if it is a breaking change, the data migration of older data (or equivalent on-the-fly processing) would be very simple.

Having said that, looking at the requirements from the clinicians it seems that the need for TABLE is actually at the ITEM level rather than the DATA_STRUCTURE level and Sam’s proposal of extending CLUSTER for TABLE and LIST (although I would suggest inheriting from the abstract ITEM) would not be quite as bad as we can simulate the same levels of structure for legacy data (although the class names would still be different unless we included all of the ITEM_STRUCTURE types as a type of ITEM to retain backward compatibility).

I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. The effort required to implement this would have been much greater if these classes were not specifically modelled. I guess as openEHR penetrates the market, the more likely CEN 13606 would be updated with these enhancements. To be honest I think this is the right standards process, standardising of implementations that are known to work in practice. I am sure we will learn more and improve the ENTRY subclasses further before they go into the CEN standard, then the standard will be more useful.

exactly!

• thomas

[pablo (Pablo Pazos)]

Hi,

I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information.

This complexity may be tackled with a good Service Model ,when it’s completed. I think that we are looking too much at the model to solve all our problems, but we have a Service Model in draft status that can help to solve issues on the using of the model.

The effort required to implement this would have been much greater if these classes were not specifically modelled.

Obs., Eval., Inst. & Act. are a great ontologic division of the clinical information, with them it’seasy to understand and easy to map to real concepts, I doubt that removing them from the model can help in any way. If these classes weren’t modelled, we have to model them in all of our implementations, that’s a waste of good modelling.

just a couple of opinions.

Kind regards,
Pablo.

[thomas.beale]

this is a good point actually. The general idea for things like the Instruction Index is to make it a combination of specific openEHR structures, and rules for using those structures (e.g. about where/when LINKs have to be created etc). To make this properly useful, the structures and rules should be mostly hidden, and instead a business service exposed, specific to this function, which we can think of as ‘care plans’. There are other services/APIs that can be defined for specific business purposes as well, which enable the application programmer to easily create and interrogate complex underlying data. Hopefully we will see a draft description of the Instruction Index, and some ideas for APIs like ‘care plan’ and so on. It would be very interesting to see other service models in this area.

• thomas beale

[system]

Hi!

I now noticed that my message with the pencil-modified UML diagram
bounced four days ago because of attachment size. Now it's edited
below to only include link to the image
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg

After that mail was written Heath indicated that one of Tom's reasons
for keeping e.g. TABLE as a class is that it would introduce rigour
etc. This will only be true for GUIs connected to purely object
oriented RM-implementations using DBC or other mechanisms to implement
what the specs say in the free text and "invariant" sections. The same
functionality might just as well be implemented in a separate
validator analysing the cluster structure before letting it in to the
system.

Also, in many GUI frameworks there is already built in support for
creating adapters to go between the GUI frameworks' table model and
your own data model - so the extra utility of having all those
TABLE-methods in the RM is questionable.

I can see the problem with breaking changes in a 1.0.3 release - that
goes against conventions, but I think the change should be included in
discussions regarding the road map to 1.1 since it, as Tom says, is
such an easy conversion in this case.

Now to the original mail that bounced, Thu, Nov 11, 2010 at 12:41:

Hi!

... University of Murcia.
An approach for the semantic interoperability of ISO EN 13606 and OpenEHR
archetypes.

David: Thanks for an interesting reference and thanks to the Murcia
team, I hope you don't mind harmonisation suggestions that could make
your conversion research easier

Sam: your overall thoughts and intentions I think have gotten through
to us tech-people, but your more detailed remodelling suggestions do
sound a bit confusing.
1. You are not using correct names for some classes & packages.
2. If we are looking for simplification, then removing classes must be
more desirable than switching inheritance order.
If you find that my suggestions are missing something, then feel free
to comment (preferably after talking to some software-person if you
have one nearby). Since current patient data is versioned and includes
RM-version it is actually possible to non-backward-compatible changes
in openEHR and keep old data accessible. In practice that complicates
GUIs etc so I'd guess that many deployments that want to upgrade to
the simplified version would import and auto-convert the old
structures to new ones if there is a change like this.
3. What do you mean by pivot in tables in this case? Is it just that a
table is rotated somehow or is it pivot table as in
http://en.wikipedia.org/wiki/Pivot_table. Is it something that is not
supported in openEHR currently? Is it primarily about GUI or semantics
(or both)?

All: I ran my UML image through the fast and famous pencil remodelling
tool and [...] put the scanned result at:
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg

As you (hopefully) can see, six classes are removed and attributes
previously referring to ITEM_STRUCTURE or ITEM_TREE would now instead
refer directly to ITEM. All this hopefully without losing semantic
expressibility power in openEHR data.

In the class PARTY_RELATIONSHIP in the demographics package, in some
earlier versions of the RM (like the one the diagram is based on) the
attribute "details"points to a DATA_STRUCTURE (see also
http://www.openehr.org/uml/release-1.0.1/Printable/Printable101.html#_9_0_76d0249_1109068473559_951109_4589
) this seems to have been a mistake rather than a design choice and in
the latest specs it points to ITEM_STRUCTURE instead. I think this
means that the class DATA_STRUCTURE could also be removed if it's
method "as_hierarchy" is pushed down to the HISTORY class instead.
HISTORY and ITEM would then inherit directly from LOCATABLE. Are these
assumptions about DATA_STRUCTURE correct or am I missing something?

One of the things left to discuss is the name of the new marker
attribute in ITEM (or possibly CLUSTER), probably of type
DV_CODED_TEXT and it's permissible valueset. I assume "list" and
"table" are two permissible values at present. The default for a
CLUSTER if the marker attribute is not used, could be to be
interpreted as a tree. Using an ELEMENT by itself I presume would be
the default way of expressing a what ITEM_SINGLE previously did.
Another way is of course to always use the marker attribute and extend
the set with "single" and "tree".

If we for some reason in the future would find the need to explicitly
express other structures than single, list, tree and table, by
allowing more marker values, then the change to the RM, querying,
storage etc would be minimal, but GUIs would of course need change.

Many of the methods (not attributes) in the RM are of limited use in
implementations or parts of implementations (e.g. storage & messaging)
that are more data-centric that object-orientation-centric, so I think
it's generally good if some of the helper methods like the ones in
ITEM_TABLE can be moved out from the core to some optional
utility-package instead (if the need for having them standardised
remains). If looking outside the item_structure package this actually
already seems to be the case - there are pretty few methods. Good.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

P.s. Tim, I'd be interested how these changes suggestions, in your
wiew, relate to "Keep everything as simple as possible; but no
simpler." that you qoute on the philosophy part of
http://www.oship.org/