subject:"13606 revisited \- list proposal"

Hi. 

Several comments:

  We put it in because Grahame Grieve had identified a use case where there 
 was something like an image that summarised the data in the time series in 
 some visual way. 

Right. But had I know then what I know now, I would've held out for a less 
limited summary that could contain structured data summarization of the series.

 Protocol' has a clear purpose and gets used for that purpose as far as I can 
 see in most archetypes: it contains the method of performing Observation / 
 Evaluation / Instruction etc

Umm, but how do you handle the situation where data produced by the observation 
is structurally related to the protocol? The NEHTA pathology and radiology 
archetypes have data in the protocol for this reason.

 The question of display I don't see as important
 the minute we start sliding toward undisciplined data models, we start 
 heading back toward the non-computable data we have today

Really? Because we know better than the people who collect and use their data 
what they need? I think that sometimes we actually do, but nevertheless this is 
very slippery ground. There's a reason why we have what we have today. As for 
display, data is no good unless it is displayed...

Grahame

On 27/03/2012, at 1:23 AM, Thomas Beale thomas.beale at oceaninformatics.com 
wrote:

 
 
 Indeed we had something like this in Release 0.95 of openEHR - see from the 
 old spec. This HISTORY model worked badly for multi-valued data. 
 
 ebgbhgab.png
 
 
 However, if we are going to make a change, I think the correct model is not 
 just to add a different variant of HISTORY but a different variant of 
 OBSERVATION, with a single EVENT. This might be called SINGLE_OBSERVATION or 
 similar. Note that the EVENT could still be a POINT_EVENT or an 
 INTERVAL_EVENT. 
 
 The reason we defined the current model with the time-series is that it means 
 software is simpler: there is only one model of all Historical (i.e. 
 observation) data: a History of Events. If we make the change we are talking 
 about here, the software becomes more complicated, and the data become more 
 varied, but overall, smaller. Also, archetype modellers might see the choice 
 of an explicit SINGLE_OBSERVATION as being more obvious for some Observation 
 types (tools should have supported this anyway from day 1, and just built a 
 normal OBSERVATION, but this wasn't done)
 
 So what we are talking about are essentially differing optimisations - 
 greater software complexity, greater data variation, smaller data versus 
 simpler software but (slightly) less space-efficient data,. I personally 
 don't mind too much which way we go here - adding a single-event OBSERVATION 
 type will fit well in the 'clinical investigator model' ontology which 
 underpins the openEHR Entries. Many archetypes, including all patient story  
 POMR 'subjective' Observations are of the single-event type.
 
 I don't think we should be pulling apart the rest of the model semantics 
 though (lower data structures are a different matter; see my other posts). 
 'Protocol' has a clear purpose and gets used for that purpose as far as I can 
 see in most archetypes: it contains the method of performing Observation / 
 Evaluation / Instruction etc. If this is not being done, there is a problem 
 in the modelling. The question of display I don't see as important. What is 
 important is that protocol doesn't change the meaning of the data+state in 
 any routine data situation (e.g. just show me all the arterial BPs) . It can 
 be ignored for normal computing purposes. However, for purposes relating to 
 the method itself (e.g. should we measure BP on both arms to get proper 
 values? Is this instrument/kind of instrument broken?), which are often data 
 quality and/or research questions, the protocol can be very useful, and 
 having it separated will help - it means that no queries to do with the other 
 parts of the data will be disturbed by the protocol data. 
 
 HISTORY.summary has nothing at all to do with this. We put it in because 
 Grahame Grieve had identified a use case where there was something like an 
 image that summarised the data in the time series in some visual way. Here's 
 the definition from the current release.
 
 hjgjjiaj.png
 
 In sum, I think the minute we start sliding toward undisciplined data models, 
 we start heading back toward the non-computable data we have today. Being 
 able to computably reason about data requires defined structure and solid 
 theory underlying it. I don't see why we should throw that out the window. If 
 we say 'everything is a tree', we just get everyone's personal tree structure 
 preference, and no community agreements on anything. The whole point of a 
 community in my view is to generate agreements that the wider user base an 
 use and rely on.
 
 I would urge people to largely forget aesthetics (i.e. the kind of ridiculous 
 subjective preferences one hears in XML schema modelling committee

13606 revisited - list proposal

2012-03-27 Thread Sam Heard

Hi Graham

 

The summary of the time series can be as structured as you like. No limit ? 
just archetypes. The fact that the first requirement you expressed was a 
graphic as part of the report, but it has never been archetyped.

 

Protocol began as there is a lot of data about how information is captured that 
is of secondary importance. This does not mean it is not important to some key 
users. The good part about having this set of data is that it can be agreed 
that by clinicians that they do not want this data ?in their face? when looking 
at the EHR. This means that there can be a generic display archetype for the 
different entries that can group this data and make it available through a 
click, mouse over or whatever. It is pragmatic in a world where we start to 
share structured data that is not known to a particular system (at least not 
until a later release.)

 

Cheers, Sam

 

From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Grahame Grieve
Sent: Tuesday, 27 March 2012 5:24 AM
To: For openEHR technical discussions
Cc: openehr-technical at lists.openehr.org
Subject: Re: 13606 revisited - list proposal

 

Hi. 

 

Several comments:

 

 We put it in because Grahame Grieve had identified a use case where there was 
something like an image that summarised the data in the time series in some 
visual way. 


Right. But had I know then what I know now, I would've held out for a less 
limited summary that could contain structured data summarization of the series.

 

Protocol' has a clear purpose and gets used for that purpose as far as I can 
see in most archetypes: it contains the method of performing Observation / 
Evaluation / Instruction etc





Umm, but how do you handle the situation where data produced by the observation 
is structurally related to the protocol? The NEHTA pathology and radiology 
archetypes have data in the protocol for this reason.







The question of display I don't see as important

the minute we start sliding toward undisciplined data models, we start heading 
back toward the non-computable data we have today





Really? Because we know better than the people who collect and use their data 
what they need? I think that sometimes we actually do, but nevertheless this is 
very slippery ground. There's a reason why we have what we have today. As for 
display, data is no good unless it is displayed...



 

Grahame


On 27/03/2012, at 1:23 AM, Thomas Beale thomas.beale at oceaninformatics.com 
wrote:



Indeed we had something like this in Release 0.95 of openEHR 
http://www.openehr.org/releases/0.95/roadmap.html  - see from the old spec 
http://www.openehr.org/releases/0.95/architecture/rm/data_structures_im.pdf . 
This HISTORY model worked badly for multi-valued data. 

ebgbhgab.png


However, if we are going to make a change, I think the correct model is not 
just to add a different variant of HISTORY but a different variant of 
OBSERVATION, with a single EVENT. This might be called SINGLE_OBSERVATION or 
similar. Note that the EVENT could still be a POINT_EVENT or an INTERVAL_EVENT. 

The reason we defined the current model with the time-series is that it means 
software is simpler: there is only one model of all Historical (i.e. 
observation) data: a History of Events. If we make the change we are talking 
about here, the software becomes more complicated, and the data become more 
varied, but overall, smaller. Also, archetype modellers might see the choice of 
an explicit SINGLE_OBSERVATION as being more obvious for some Observation types 
(tools should have supported this anyway from day 1, and just built a normal 
OBSERVATION, but this wasn't done)

So what we are talking about are essentially differing optimisations - greater 
software complexity, greater data variation, smaller data versus simpler 
software but (slightly) less space-efficient data,. I personally don't mind too 
much which way we go here - adding a single-event OBSERVATION type will fit 
well in the 'clinical investigator model' ontology which underpins the openEHR 
Entries. Many archetypes, including all patient story  POMR 'subjective' 
Observations are of the single-event type.

I don't think we should be pulling apart the rest of the model semantics though 
(lower data structures are a different matter; see my other posts). 'Protocol' 
has a clear purpose and gets used for that purpose as far as I can see in most 
archetypes: it contains the method of performing Observation / Evaluation / 
Instruction etc. If this is not being done, there is a problem in the 
modelling. The question of display I don't see as important. What is important 
is that protocol doesn't change the meaning of the data+state in any routine 
data situation (e.g. just show me all the arterial BPs) . It can be ignored for 
normal computing purposes. However, for purposes relating to the method itself 
(e.g. should we measure BP on both arms

13606 revisited - list proposal

hi Sam

 The summary of the time series can be as structured as you like. No limit ?
 just archetypes. The fact that the first requirement you expressed was a
 graphic as part of the report, but it has never been archetyped.

except that the definition is optional summary data expressing e.g. text
or image which summarises entire history. I don't think this definition is
sufficiently broad, and I always get unaccountably uncomfortable when
people ignore the restrictions imposed by definitions.

 Protocol began as there is a lot of data about how information is captured
 that is of secondary importance. This does not mean it is not important to
 some key users. The good part about having this set of data is that it can
 be agreed that by clinicians that they do not want this data ?in their face?
 when looking at the EHR. This means that there can be a generic display
 archetype for the different entries that can group this data and make it
 available through a click, mouse over or whatever. It is pragmatic in a
 world where we start to share structured data that is not known to a
 particular system (at least not until a later release.)

except that we face the situation where the structuring data is protocol,
the details are very much in the face kind of stuff, and therefore this
coupling of paradigm and not in the face breaks down.

Grahame

13606 revisited - list proposal

Hi Grahame,

I am struggling a little to understand your concern about the Summary
attribute (other than that is is not supported in the tools!). The current
definition optional summary data expressing e.g. text
or image which summarises entire history. seems to me to meet your needs
perfectly. I am obviously misunderstanding your requirement or we have
different interpretations of the definition. How would you like to broaden
the definition?

Apologies if this is old ground for some people, but I think the discussion
is useful to a wider audience, in the context of a bit of blue-sky thinking
for openEHR 2.0 and 13606 alignment.

Ian

On 27 March 2012 03:30, Grahame Grieve
grahame at healthintersections.com.auwrote:

hi Sam

The summary of the time series can be as structured as you like. No
limit ?
just archetypes. The fact that the first requirement you expressed was a
graphic as part of the report, but it has never been archetyped.

except that the definition is optional summary data expressing e.g. text
or image which summarises entire history. I don't think this definition is
sufficiently broad, and I always get unaccountably uncomfortable when
people ignore the restrictions imposed by definitions.

Protocol began as there is a lot of data about how information is
captured
that is of secondary importance. This does not mean it is not important
to
some key users. The good part about having this set of data is that it
can
be agreed that by clinicians that they do not want this data ?in their
face?
when looking at the EHR. This means that there can be a generic display
archetype for the different entries that can group this data and make it
available through a click, mouse over or whatever. It is pragmatic in a
world where we start to share structured data that is not known to a
particular system (at least not until a later release.)

except that we face the situation where the structuring data is protocol,
the details are very much in the face kind of stuff, and therefore this
coupling of paradigm and not in the face breaks down.

Grahame

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation
www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/7e7f/attachment.html

13606 revisited - list proposal

Sorry Grahame forgot to add,

I probably have some sympathy for your view on protocol but I wasn't quite
sure what you meant by  we face the situation where the structuring data
is protocol - can you give a concrete example.

It is quite clear to me that many of the attributes and structures
introduced by the ENTRY sub-classes are necessary, and that the ontological
background of the 'clinical investigator model' is about as good as it
gets, but that in some circumstances the structural requirements and
ontology can be orthogonal, which leads to the kind of lengthy debate and
philosophical discussion that can bedevil other clinical modelling
formalisms. Some of that is unavoidable, as you said on your blog, clinical
information is complex. We cannot avoid that complexity, just hide it or
move it elsewhere. I think openEHR has made a pretty good job of hiding the
complexity, or at least presenting it to the correct audience, but I think
we can do better. In particular, I think we need to try to reduce the
burden on new entrants i.e make it easier to get started and feel confident
that any models devloped are not 'wrong' from the outset but can gradually
be made more sophisticated over time, as experience grows.

I take Sam's point about he value of 'protocol'. It is a very valuable way
of organising complex data within an archetype but can be a matter of fine
judgement and debate amongst clinicians and is important to get right since
we are making a structural commitment which is going to break queries if we
decide to change our mind later. It can also cause problems in OBSERVATION,
since occasionally 'protocol' items really merit being in the 'state'
structure and vice versa, from a temporal perspective.

It also has only 'soft' semantic value, a kind of guideline rather than
anything which is going to be queried directly. It is valuable but  wonder
we can deliver this more flexibly by annotating the item, rather than a
structural attribute, in much the same way as we are proposing to deal with
ITEM_STRUCTURE.

This overlaps somewhat with the discussion on ADMIN_ENTRY and EVALUATION
and generic ENTRY - I think we need to retain the ontology but I don't
think this needs to be absolutely tied to the structural definitions. At
the moment we force archetype authors to make a very early commitment to a
specific class and the class structure and ontological classification are
intextricably bound. In most cases this is not an issue, the decision is
easy. In other cases, the decision is very hard but important , and lengthy
discussion unavoidable. What concerns me are the cases where the decision
is somewhat arbitrary and debatable but actually inconsequential, in terms
of future querying. I think this can be real barrier to uptake since it
switches off the many who just want to get a job done, worst still becomes
a bone of contention for those who favour a different ontologcal view of
the world. If ontology and structure were less entwined, we might minimise
this problem.

Just to be clear, we do need the more complex structures provided by the
ENTRY sub-classes and we do no need the 'clinical investigator' ontology,
but we do have to recognise that there is resistance to this complexity and
an intellectual burden for new entrants. I think we might be able to reduce
the resistance and intellectual burden without losing the value.

 Ian



On 27 March 2012 09:12, Ian McNicoll Ian.McNicoll at 
oceaninformatics.comwrote:

 Hi Grahame,

 I am struggling a little to understand your concern about the Summary
 attribute (other than that is is not supported in the tools!).  The current
 definition   optional summary data expressing e.g. text
 or image which summarises entire history.  seems to me to meet your needs
 perfectly. I am obviously misunderstanding your requirement or we have
 different interpretations of the definition. How would you like to broaden
 the definition?

 Apologies if this is old ground for some people, but I think the
 discussion is useful to a wider audience, in the context of a bit of
 blue-sky thinking for openEHR 2.0 and 13606 alignment.

 Ian


 On 27 March 2012 03:30, Grahame Grieve grahame at healthintersections.com.au
  wrote:

 hi Sam

  The summary of the time series can be as structured as you like. No
 limit ?
  just archetypes. The fact that the first requirement you expressed was a
  graphic as part of the report, but it has never been archetyped.

 except that the definition is optional summary data expressing e.g. text
 or image which summarises entire history. I don't think this definition
 is
 sufficiently broad, and I always get unaccountably uncomfortable when
 people ignore the restrictions imposed by definitions.

  Protocol began as there is a lot of data about how information is
 captured
  that is of secondary importance. This does not mean it is not important
 to
  some key users. The good part about having this set of data is that it
 can
  be agreed that by clinicians

13606 revisited - list proposal

Hi Thomas,

I definitely agree here. While I think there is huge merit in having some
kind of simplified single Event OBSERVATION, there is absolutely a need to
handle the increasing numbers of device mediated multiple event
observations.

As a modeller though, I really do not want to have to commit to one class
or another. I want to be able to start with a simple model and
'unconstrain' that when and if the individual or generic use cases emerge.
Given the complexity of multiple event handling I suspect that is a pretty
tough ask but if you don't ask you don't get :-) That is why I was
interested in what Marand are doing which is essentially flattening or
hiding the complexity of the mutliple event Observation - simple API vs.
Complex API where the simple API just hides the complexity for the 80% of
use-cases. Is that feasible?

openEHR archetypes are still easily the best way to manage the very
difficult task of identifying clinical content requirements and gradually
developing these as new use-cases and complexities appear but I think we
can do more to make that process one where we can start simple and
gradually add complexity in a backward compatible manner.

Ian

On 26 March 2012 20:47, Thomas Beale thomas.beale at
oceaninformatics.comwrote:

On 26/03/2012 19:49, pablo pazos wrote:

Hi Thomas,

A while ago, we gave this issue a big thought when designing the EHRGen
framework.

Periodic event records are needed when recording certain studies and
when monitoring a patient, but this can be recorded as single point events,
and using a query to get all the points in a series.

it can but that's very inefficient, and doesn't correctly represent what
is happening, when you are talking about multiple samples in a series, e.g.
coming from vital signs monitors, orthostatic BP, apgar, and many others.

From the GUI perspective is very difficult to record periodic events,
because you have to login, select a patient, select a record, select the
section of that record that contains the periodic data, enter a new item to
the time series.

and presumably enter another, and another. That doesn't sound like a
problem - it's how normal GUI for Apgar and multi-sample manual BP
collection work. Don't forget, we are talking about time series in the
seconds to minutes domain here. Although Glucose tolerance test data would
make more sense to be entered as one time series, after the fact.

The other option is to have the patient's record always open, and that
is not possible in all scenarios (for technical or security reasons).

well ifyou are talking about long period of time, like repeated nursing
observations, you should be committing those 1 sample at a time.

In the other hand, in the majority of cases of clinical record through a
GUI, the data is recorded as a single point event, e.g. at a patient visit.
So we design the EHRGen just to use point events, and if you want to record
a series of events, a service should be provided to get the data from other
systems (e.g. a LAB system), but not from the GUI.

that and vital signs monitors are certainly a common source of time-based
data. But whether the source of the data is the GUI or somewhere else
doesn't change the semantics of the model, or the need for it. Like I said
elsewhere, I have no problem with adding a single-event Observation as
well. But having only that will completely cripple many hospital apps and
efficient data representation and querying related to this data.

- thomas

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

*Primary Health Info 23 ? 25th April in Warwick ? are you
coming?http://www.primaryhealthinfo.org/
*

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/8bca2576/attachment.html

13606 revisited - list proposal

On 27/03/2012 10:41, Grahame Grieve wrote:
hi Ian

It meets perfectly the requirements I was aware of at the time, but now I have
a more perfect (ahh, less imperfect) knowledge. If I have a series of
observations,
I may provide some interpretation of them, that becomes the observation.
This occurs with several diagnostic tests. But these cases
don't summarise the entire history, in that they analyse the data.
Perhaps I am splitting hairs, but isn't that what definitions are for? I'd
like it relaxed a little.

can you post a Problem Report here
http://www.openehr.org/issues/browse/SPECPR?

And tooling support, too, of course ;-) (though I suppose I could add
that myself)

Generally, in the NEHTA context, we've struggled with the openEHR RM here.
Partly it's tooling (AE and CKM) - it doesn't support the things we want to
do.

is there a definitive list of shortcomings or unmet needs?

We've ended up pretending that the event series doesn't exist in the
observation RM
for the purposes of the archetype, both (partly) in how the design was done,
and (completely) in how we convert the archetype to a DCM.

what's a 'DCM' in Nehta?

Partly that was a
pragmatic decision to do with tooling limitations, but it's not
obvious to me that
it would've played out differently if the tooling wasn't limited.

I assume there are not yet any Nehta archetypes for data that are
natural time-series, like vital signs, Apgar, OGTT etc (I would expect
the main openEHR ones of these to work fine).

One issue I have is that the event series imposes the same data at each point,
which is not necessarily the case.

well it is the case for the History/Event structure - by definition. If
you have a situation where it is not the case - there are many! - then
this is not the data structure to use; just use separate Observations
(possibly with LINKs between them).

And also, (back to protocol)
repeating observations
is protocol? (how they were each done), and this summary thing - is it
critical
to display, or just an adjunct? Better just to model the content in
data and be sure...

but in that case, you can think of the protocol section as just more
data. Note that in 90% of archetypes, it is used in the originally
intended way, so I would not want to destroy the coherence of the 90%
for the sake of 10% ambiguous cases (which I still don't understand by
the way).

- thomas

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/86b98fea/attachment.html

13606 revisited - list proposal

 Summarisation

 I think I probably have a somewhat more liberal interpretaion of
 'summarisation' , which would include analysis or interpretation of the
 data, to include 'tissue/lab/x-ray diagnosis' but short of clinical
 diagnosis.

well, clarification would help. (so would tooling!)

 Our model identifies five distinct stages of clinical summarization: (1)
 Aggregation, (2) Organization, (3) Reduction and/or Transformation, (4)
 Interpretation and (5)
 Synthesis?http://www.sciencedirect.com/science/article/pii/S1532046411000591

yes, that's a nice model.

 I?think?we also recognise that we need some way of simplifying OBSERVATION
 for the 80% of single event uses and for integration without sacrificing the
 less common but significant need for multiple event handling. (I think this
 + associated tooling) would resolve most of the issues you had in the NEHTA
 context.

also an easy way of constraining it. The problem is that the general lab model
may or may not include an event series

 One issue I have is that the event series imposes the same data at each
 point, - can you give an example?

umm. getting hazy now. There's one challenge (synacthen?) where you
measure the hormone regularly, and keep track of the state of the patient
by measuring something metabolic every so often. (glucose? so not synacthen?)
My knowledge grows ever more imperfect by the day...

 and by repeating observations?is protocol do you mean situations where the
 method changes at each Event e.g. First blood pressure taken with cuff,
 second with a machine?

yes. or posture changes, or some such.

 If so, I probably agree. In most cases the ontology and structure coincide
 but there are cases where something that ontologically is protocol needs to
 be in an event and vice-versa.

right. We have imperfect separation. (Imperfect appears to be my word
of the day)

 I don't want to lose protocol. I think there is value in making the
 distinction as part of the authoring process, if only as a way of making an
 archetype easier to view, and as Sam suggests to underpin a generic view,
 but I don't think we need to tie it to structure.

I'm not sure what I want. I just think that there's a few different
things bundled together here.
Sometimes - even most of the time - that's useful, and sometimes it gets in
the way. Would a more complicated model still be useful? I suspect not. I guess
I feel as though I want a simpler model, since the more complex model is useful
but not always right - a bad thing to have in a reference model

Grahame

13606 revisited - list proposal

On 27/03/2012 10:42, Ian McNicoll wrote:
 Hi Thomas,

 I definitely agree here. While I think there is huge merit in having 
 some kind of simplified single Event OBSERVATION, there is absolutely 
 a need to handle the increasing numbers of device mediated multiple 
 event observations.

 As a modeller though, I really do not want to have to commit to one 
 class or another. I want to be able to start with a simple model and 
 'unconstrain' that when and if the individual or generic use cases 
 emerge. Given the complexity of multiple event handling I suspect that 
 is a pretty tough ask but if you don't ask you don't get :-)

I am having a hard time understanding when the modeller would not know 
if there was a series of events or not. Surely all vital signs should be 
modelled as that (even if in some instances in the data, there is only 
one event)? There seems no other obvious way to model Apgar or OGTT; I 
would expect some ECG and blood glucose to be in time-series form as well.

 That is why I was interested in what Marand are doing which 
 is essentially flattening or hiding the complexity of the mutliple 
 event Observation - simple API vs. Complex API where the simple API 
 just hides the complexity for the 80% of use-cases. Is that feasible?

that was actually the intention of the original design - to support APIs 
that would allow a 'nice' way to create a single event Observation 
(indeed, it should have been defined in the Observation class itself). 
But if we want a single-event Observation class as a new variant, no 
reason why not.


 openEHR archetypes are still easily the best way to manage the very 
 difficult task of identifying clinical content requirements and 
 gradually developing these as new use-cases and complexities appear 
 but I think we can do more to make that process one where we can start 
 simple and gradually add complexity in a backward compatible manner.

personally I think a lot more work is required on the tooling...

- thomas


 *
 * 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/6d30f05a/attachment.html

13606 revisited - list proposal

2012-03-27 Thread Erik Sundvall

Hi!

When looking for the summary attribute (an ITEM_STRUCTURE) I found
that it was missing some of my diagram printouts.

It is clearly defined on page 31 of...
http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf
... but missing in the diagram (figure 8) on page 25 ind that document
and missing on all relevant diagrams (including mine) on
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model

That can definitely be confusing. Or have I missed something else?

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


On Tue, Mar 27, 2012 at 10:12, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 I am struggling a little to understand your concern about the Summary
 attribute (other than that is is not supported in the tools!). ?The current
 definition? ?optional summary data expressing e.g. text
 or image which summarises entire history.??seems to me to meet your needs
 perfectly. I am obviously misunderstanding your requirement or we have
 different interpretations of the definition. How would you like to broaden
 the definition?

13606 revisited - list proposal

 Perhaps I am splitting hairs, but isn't that what definitions are for? I'd
 like it relaxed a little.

 can you post a Problem Report here?

ok, I'll do that.

 Generally, in the NEHTA context, we've struggled with the openEHR RM here.
 Partly it's tooling (AE and CKM) - it doesn't support the things we want to
 do.

 is there a definitive list of shortcomings or unmet needs?

no. partly because... we're not very definitive by nature. But more because
you trade between approach and tooling and options.

 what's a 'DCM' in Nehta?

sort of take an archetype, and represent it in a neutral format
which isn't supposed to take any experience except UML to understand.
Take out all the openEHR-ness, really. It's useful, because it makes
a lot of RM stuff explicit, and we really need to be able to do that in
archetypes (comment on the meaning in a context, make limitations
on the possible values)

 I assume there are not yet any Nehta archetypes for data that are natural
 time-series, like vital signs, Apgar, OGTT etc (I would expect the main
 openEHR ones of these to work fine).

Don't think so. we don't model at that level of specificness. Partly this is
EHR vs general clinical modeling.

 well it is the case for the History/Event structure - by definition. If you
 have a situation where it is not the case - there are many! - then this is
 not the data structure to use; just use separate Observations (possibly with
 LINKs between them).

well, currently, that means that we have to break up what is a simple single
archetype otherwise into a set of archetypes, and we have poor binding between
them. This should be one archetype, but as far as I can tell, neither AE nor
CKM allow this to be the case. In ADL 1.4, we'd have to depend on Regex
linking the parts together... not good. And now I've got another
problem - I want
one observation which is a cluster of observations... I've run into issues with
the RM now.

Grahame

13606 revisited - list proposal

2012-03-27 Thread Peter Gummer

Grahame Grieve wrote:

 well it is the case for the History/Event structure - by definition. If you
 have a situation where it is not the case - there are many! - then this is
 not the data structure to use; just use separate Observations (possibly with
 LINKs between them).
 
 well, currently, that means that we have to break up what is a simple single
 archetype otherwise into a set of archetypes, and we have poor binding between
 them.

I don't think Thomas was suggesting multiple archetypes. I think he was saying 
that you would have multiple data instances of the one OBSERVATION archetype.

Peter

13606 revisited - list proposal

 well, currently, that means that we have to break up what is a simple single
 archetype otherwise into a set of archetypes, and we have poor binding 
 between
 them.

 I don't think Thomas was suggesting multiple archetypes. I think he was 
 saying that you would have multiple data instances of the one OBSERVATION 
 archetype.

That's what I thought he meant. And that would mean that we'd need to
take what is one logical and actual archetype now and break it into
several parts to allow this to happen.

Grahame

13606 revisited - list proposal

I am having a hard time understanding when the modeller would not know
if there was a series of events or not

Well for an experienced modeller it is not too hard, although there are
still quite a number of grey areas. Heather and I still have discussions
and disagreements about the correct Class or use of class attributes. The
point is that for beginners or casual users, it *is* hard. Just look at
Pablo's or Saso's experience. I want to improve the architecture and, I
agree, definitely the tooling, so that people are not forced to think about
the hard stuff until they are good and ready or the use-cases emerge, but
confident that they are not making a 'wrong' decision which stops their
work being shared with a wider community in due course.

Pablo's experience is not at all unusual - most groups find it hard to
think beyond the boundaries of their own experience, and it is costly to
think ahead in terms of design decisions. You forget just how much
expertise and detailed consideration that you have given to this problem
space. Even with training and experience it will take some time for others
to catch up (including myself!). I want people to be able to hit the ground
running and not be intimidated by the technology or the ontological
philosophy. openEHR does a pretty good job on both counts but I think we
can do better. Tooling improvements certainly but tooling is ultimately
driven by the RM and based on the experiences of implementation and
training over several years I think now is good opportunity to take stock
and find some ways of further reducing buy-in without compromising on the
excellent work done to date.

Ian

On 27 March 2012 11:51, Thomas Beale thomas.beale at
oceaninformatics.comwrote:

On 27/03/2012 10:42, Ian McNicoll wrote:

Hi Thomas,

I definitely agree here. While I think there is huge merit in having
some kind of simplified single Event OBSERVATION, there is absolutely a
need to handle the increasing numbers of device mediated multiple event
observations.

I am having a hard time understanding when the modeller would not know if
there was a series of events or not. Surely all vital signs should be
modelled as that (even if in some instances in the data, there is only one
event)? There seems no other obvious way to model Apgar or OGTT; I would
expect some ECG and blood glucose to be in time-series form as well.

That is why I was interested in what Marand are doing which
is essentially flattening or hiding the complexity of the mutliple event
Observation - simple API vs. Complex API where the simple API just hides
the complexity for the 80% of use-cases. Is that feasible?

that was actually the intention of the original design - to support APIs
that would allow a 'nice' way to create a single event Observation (indeed,
it should have been defined in the Observation class itself). But if we
want a single-event Observation class as a new variant, no reason why not.

personally I think a lot more work is required on the tooling...

- thomas

*
*

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

*Primary Health Info 23 ? 25th April in Warwick ? are you
coming?http://www.primaryhealthinfo.org/
*

13606 revisited - list proposal

? I am having a hard time understanding when the modeller would not know
 if there was a series of events or not? 

 Well for an experienced modeller it is not too hard, although there are
 still quite a number of grey areas.

particularly if you are modeling general cases rather than very specific
cases. i.e. NEHTA needs a general laboratory archetype, rather than
100s of specific ones.

Grahame

13606 revisited - list proposal

Hi Grahame,

Some, actually most, of the issues you mentioned in the context of the
NEHTA work are familiar, and I think apply to many implementation
situations. Thomas and I have been discussing some possible solutions.

1. The ability to expose parts of the RM which are of particular
significance to a particular audience, clinical or technical, to assist in
clinical review or implementation guidance, along with contextual
descriptions or name overrides. e.g If in a Dischage document we are using
the ACTION.time attribute to carry the Date Procedure performed as
described in the original requirements, I want to be able to express that
in a template, so it is clear to developers and clinical reviewers. One
option we discussed was to allow an RM attribute to be annotated and
associated with an at-code, which would allow a local nameDate of
Procedure and a description to be overlaid. This would be in design-time
i.e the name overlay would not appear in data.

2. The problem of openEHR archetype constructs being over-granular for
summarised reports, mostly in the integration space but we do also need
this in the EHR space at times. As an example I might want to record a
Medication instruction in a summary, along with a couple of key events e.g
Date of first prescription, Date of last prescription. Currently we need to
use a further 2 ACTION archetypes, which feels clunky to developers and
looks clunky in the tooling, as it requires encapsulation within a SECTION
or written documentation.

I think we can largely resolve this with better tooling but we do lack any
easy way of asserting the relationship between the Instruction archetype
and the child Action archetypes. We can do this with links but I think we
should explore a very simple link concept that asserts a 'contains'
relationship between a parent and child ENTRIES and is regarded as
equivalent to a slot containment in querying terms. I think that might also
help the similar situation where novice modellers always want to nest
height and weight within a BMI, if there are good reasons not to allow
nested entries. We still need tooling to flatten out and hide the unwanted
child detail but that is relatively simple if we can assert or simulate the
parent-child relationship

The committment to model archetypes for EHR implementation is IMO correct
but we do need to recognise and support the need to provide a summarised.
flattened representation, even within EHRs. I think this is doable and will
resolve a lot of resistance from integration-focused developers who feel
the openEHR approach is over complex, particularly once we get ADL1.5 going
properly.

Ian

On 27 March 2012 12:37, Grahame Grieve
grahame at healthintersections.com.auwrote:

well, currently, that means that we have to break up what is a simple
single
archetype otherwise into a set of archetypes, and we have poor binding
between
them.

I don't think Thomas was suggesting multiple archetypes. I think he was
saying that you would have multiple data instances of the one OBSERVATION
archetype.

That's what I thought he meant. And that would mean that we'd need to
take what is one logical and actual archetype now and break it into
several parts to allow this to happen.

Grahame

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

*Primary Health Info 23 ? 25th April in Warwick ? are you
coming?http://www.primaryhealthinfo.org/
*

13606 revisited - list proposal

Thanks,

13606 revisited - list proposal

On 27/03/2012 11:46, Grahame Grieve wrote:
 One issue I have is that the event series imposes the same data at each
 point, - can you give an example?
 umm. getting hazy now. There's one challenge (synacthen?) where you
 measure the hormone regularly, and keep track of the state of the patient
 by measuring something metabolic every so often. (glucose? so not synacthen?)
 My knowledge grows ever more imperfect by the day...

but the EVENT has a state property, so you can record state that changes 
with every event.


 and by repeating observations is protocol do you mean situations where the
 method changes at each Event e.g. First blood pressure taken with cuff,
 second with a machine?
 yes. or posture changes, or some such.

these are state, not protocol - and can change over time with the data.
*
* - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/28f895c7/attachment.html

13606 revisited - list proposal

2012-03-27 Thread Erik Sundvall

Thanks!

On Tue, Mar 27, 2012 at 12:53, Erik Sundvall erik.sundvall at liu.se wrote:
 When looking for the summary attribute (an ITEM_STRUCTURE) I found
 that it was missing some of my diagram printouts.
...
On Tue, Mar 27, 2012 at 16:54, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 this one?


Yes that one. Thanks.

On Tue, Mar 27, 2012 at 12:53, Erik Sundvall erik.sundvall at liu.se wrote:
 That can definitely be confusing. Or have I missed something else?

I had obviously missed something when only looking inside the boxes ;-)
Nice to have a partial blindness cured over the Internet without too much
pain ;-)

// Erik
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/eff733fc/attachment.html

13606 revisited - list proposal

On 27/03/2012 13:12, Grahame Grieve wrote:
Some, actually most, of the issues you mentioned in the context of the NEHTA
work are familiar, and I think apply to many implementation situations.
Thomas and I have been discussing some possible solutions.

1. The ability to expose parts of the RM which are of particular
significance to a particular audience, clinical or technical, to assist in
clinical review or implementation guidance, along with contextual
descriptions or name overrides. e.g If in a Dischage document we are using
the ACTION.time attribute to carry the Date Procedure performed as
described in the original requirements, I want to be able to express that in
a template, so it is clear to developers and clinical reviewers. One option
we discussed was to allow an RM attribute to be annotated and associated
with an at-code, which would allow a local nameDate of Procedure and a
description to be overlaid. This would be in design-time i.e the name
overlay would not appear in data.
Right. that would be very nice.

already implemented in ADL 1.5 some time ago, based on Ian's complaints ;-)

It doesn't yet allow the note to include coding, but Linda Bird has
suggested it should. Still thinking about that.

you can define LINKs between Entries, but I am not sure what
relationship Ian is referring to here exactly.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/00fd6625/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: baedfcif.png
Type: image/png
Size: 13275 bytes
Desc: not available
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/00fd6625/attachment-0002.png
-- next part --
A non-text attachment was scrubbed...
Name: badiehjc.png
Type: image/png
Size: 11164 bytes
Desc: not available
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/00fd6625/attachment-0003.png

13606 revisited - list proposal

2012-03-26 Thread Sašo Rutar

Hi Thomas,

Indeed, our practice confirms the need for a simpler form of single 
event observations. We are compensating for this with our Java TDO 
generator that detects history instances with event count constrained to 
single and merges a history and event objects into one event-history 
object that sort of represents a union of both classes. This way our 
developers end up with a less boiler-plate code to deal with and the rm 
model is preserved.


best regards,
Saso Rutar


Date: Fri, 23 Mar 2012 14:25:34 +
 From: Thomas Bealethomas.beale at oceaninformatics.com
 To: openehr-technical at openehr.org
 Subject: Re: 13606 revisited - list proposal
 Message-ID:4F6C87DE.8090004 at oceaninformatics.com
 Content-Type: text/plain; charset=iso-8859-1; Format=flowed


 In the thread below, Pablo asked whether Action should have as its data
 not just an ItemStructure but a History, like Observation. Does anyone
 else have evidence supporting this need?

 A related question is: is there a need for an Observation type that only
 has one Event in it, i.e. one time-point? Obviously quite a few
 observations in real life, including 'patient story' are of this form.
 Our original motivation was to make all Observation data structures the
 same, hence the current data structures. Introducing more types makes
 code more complex and therefore error-prone, but generally makes data
 simpler/smaller overall.

 thoughts?

 - thomas

 On 13/02/2012 21:31, pablo pazos wrote:
 Hi Thomas,

 Sorry for the delay, I'm working on several projects right now and
 have little time to follow discussion here.


  I'm also thinking about the ENTRY model, to lift up the
  data/description attributes from all entry subclasses to the
  ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all
  subentries could define the data as ITEM_STRUCTURE or as a HISTORY.


 We did think about this a long time ago, but it did not seem useful.
 But I assume you are thinking of doing it because you want to make
 ENTRY a concrete class which could have 'any' structure.

 Nope, is because I see a common pattern on concreate ENTRY subclases.

 In theory doing this breaks a basic modelling rule, which is that a
 superclass whose descendants define the possible data space should
 not itself be concrete.

 I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is
 in fact a more specific ENTRY class, but is still a generic one that
 could be specialized in many ways. In my (maybe biased) experience,
 all subclasses from ENTRY would make use of this attribute since a
 structure is needed to record information.

 The argument here I suppose is that we want to build in a 13606-style
 'uncommitted' kind of ENTRY. In fact we already have this - it's
 currently called GENERIC_ENTRY
 http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html.
 This doesn't get used at the moment (although it has been there for
 years), and if we want to make it a subtype of ENTRY, that could be
 done. The main thing to solve I guess is the conversion of any of the
 specific openEHR kinds of ENTRY into a generic ENTRY structure defined
 by 13606. This can actually be formally specified by an algorithm. It
 doesn't require that the parent abstract ENTRY become concrete either.
 I am unclear if there are other reasons to make the ENTRY parent type
 concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY
 to be a subtype, which seems more obvious to me.


  Maybe to have the flexibility to define ACTIONS and other entries
  to have a data attribute of class ITEM_STRUCTURE or HISTORY to
  track time of events instead of inventing DV_DATE/DV_DATETIME
  ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good
  idea. What do you think?


 Well then I think we risk making the model ambiguous, and different
 people will use such flexible structures to do the same thing in
 different ways, which was the thing we were originally trying to avoid.

 I disagree here, the model semantics could be defined in the specs. My
 argument is that we are giving a more flexible IM is adding
 flexibility (not ambiguity) to archetypes, and giving knowledge
 modelers more options. Then, when they create a concrete archetype,
 there is no ambiguity because an archetype models a concept in one
 way, and if abstract classes are used in archetypes, the archetype
 needs specialization to make is usable on a real environment (software
 can't instantiate abstract classes, and could not make the decision
 between using subclass A or subclass B).

 The HISTORY class is very nicely designed to represent complex
 time-series data that has the same protocol and was captured in an
 uinterrupted series. It does not try to model sequences of different
 types of data - in that case, you just have multiple observations.

 I totally agree.

 It deal well with point values, averaged interval values, max, min

13606 revisited - list proposal

2012-03-26 Thread Ian McNicoll

Hi Thomas,

I think that a simpler single-event model would be very helpful, as very
many observation archetypes will only ever require a single event. This
complicates the archetyping and adds a layer of complexity to training. I
like the sound of what Saso is doing whic is essentially to flatten out /
hide the complexity, rather than lose it altogether and create a new
archetype class. Not sure how this could be done in practice.

More controversially, I wonder if we need to rethink state and protocol,
particularly protocol, given that we do already have 'summary' with in the
history class which captures information pertinent to all Events. I
increasingly feel that protocol is useful as a design directive but should
not have semantic/structural meaning. We never search for 'elements under
protocol' or obey firm rules like 'you never need to display items within
protocol' . By all mean allow authors to express these kind of
classifications against particular elements but they do not IMO need to be
semantically or structurally hard-wired. There are stronger semantic
arguments for State. Let the debate begin!!

Ian

On 26 March 2012 12:34, Sa?o Rutar saso.rutar at marand.si wrote:

Hi Thomas,

Indeed, our practice confirms the need for a simpler form of single event
observations. We are compensating for this with our Java TDO generator that
detects history instances with event count constrained to single and merges
a history and event objects into one event-history object that sort of
represents a union of both classes. This way our developers end up with a
less boiler-plate code to deal with and the rm model is preserved.

best regards,
Saso Rutar

Date: Fri, 23 Mar 2012 14:25:34 +

From: Thomas Bealethomas.beale@**oceaninformatics.comthomas.beale at
oceaninformatics.com

To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal
Message-ID:4F6C87DE.8090004@**oceaninformatics.com4F6C87DE.8090004 at
oceaninformatics.com

Content-Type: text/plain; charset=iso-8859-1; Format=flowed

In the thread below, Pablo asked whether Action should have as its data
not just an ItemStructure but a History, like Observation. Does anyone
else have evidence supporting this need?

A related question is: is there a need for an Observation type that only
has one Event in it, i.e. one time-point? Obviously quite a few
observations in real life, including 'patient story' are of this form.
Our original motivation was to make all Observation data structures the
same, hence the current data structures. Introducing more types makes
code more complex and therefore error-prone, but generally makes data
simpler/smaller overall.

thoughts?

- thomas

On 13/02/2012 21:31, pablo pazos wrote:

Hi Thomas,

Sorry for the delay, I'm working on several projects right now and
have little time to follow discussion here.

I'm also thinking about the ENTRY model, to lift up the
data/description attributes from all entry subclasses to the
ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all
subentries could define the data as ITEM_STRUCTURE or as a HISTORY.

We did think about this a long time ago, but it did not seem useful.
But I assume you are thinking of doing it because you want to make
ENTRY a concrete class which could have 'any' structure.

Nope, is because I see a common pattern on concreate ENTRY subclases.

In theory doing this breaks a basic modelling rule, which is that a
superclass whose descendants define the possible data space should
not itself be concrete.

I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is
in fact a more specific ENTRY class, but is still a generic one that
could be specialized in many ways. In my (maybe biased) experience,
all subclasses from ENTRY would make use of this attribute since a
structure is needed to record information.

The argument here I suppose is that we want to build in a 13606-style
'uncommitted' kind of ENTRY. In fact we already have this - it's
currently called GENERIC_ENTRY
http://www.openehr.org/uml/**release-1.0.1/Browsable/_9_5_**
1_76d0249_1140530578205_**529440_4046Report.htmlhttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html
.

This doesn't get used at the moment (although it has been there for
years), and if we want to make it a subtype of ENTRY, that could be
done. The main thing to solve I guess is the conversion of any of the
specific openEHR kinds of ENTRY into a generic ENTRY structure defined
by 13606. This can actually be formally specified by an algorithm. It
doesn't require that the parent abstract ENTRY become concrete either.
I am unclear if there are other reasons to make the ENTRY parent type
concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY
to be a subtype, which seems more obvious to me.

Maybe to have the flexibility to define ACTIONS and other

13606 revisited - list proposal

2012-03-26 Thread Thomas Beale



Indeed we had something like this in Release 0.95 of openEHR 
http://www.openehr.org/releases/0.95/roadmap.html - see from the old 
spec 
http://www.openehr.org/releases/0.95/architecture/rm/data_structures_im.pdf. 
This HISTORY model worked badly for multi-valued data.




However, if we are going to make a change, I think the correct model is 
not just to add a different variant of HISTORY but a different variant 
of OBSERVATION, with a single EVENT. This might be called 
SINGLE_OBSERVATION or similar. Note that the EVENT could still be a 
POINT_EVENT or an INTERVAL_EVENT.

The reason we defined the current model with the time-series is that it 
means software is simpler: there is only one model of all Historical 
(i.e. observation) data: a History of Events. If we make the change we 
are talking about here, the software becomes more complicated, and the 
data become more varied, but overall, smaller. Also, archetype modellers 
might see the choice of an explicit SINGLE_OBSERVATION as being more 
obvious for some Observation types (tools should have supported this 
anyway from day 1, and just built a normal OBSERVATION, but this wasn't 
done)

So what we are talking about are essentially differing optimisations - 
greater software complexity, greater data variation, smaller data versus 
simpler software but (slightly) less space-efficient data,. I personally 
don't mind too much which way we go here - adding a single-event 
OBSERVATION type will fit well in the 'clinical investigator model' 
ontology which underpins the openEHR Entries. Many archetypes, including 
all patient story  POMR 'subjective' Observations are of the 
single-event type.

I don't think we should be pulling apart the rest of the model semantics 
though (lower data structures are a different matter; see my other 
posts). 'Protocol' has a clear purpose and gets used for that purpose as 
far as I can see in most archetypes: it contains the method of 
performing Observation / Evaluation / Instruction etc. If this is not 
being done, there is a problem in the modelling. The question of display 
I don't see as important. What is important is that protocol doesn't 
change the meaning of the data+state in any routine data situation (e.g. 
just show me all the arterial BPs) . It can be ignored for normal 
computing purposes. However, for purposes relating to the method itself 
(e.g. should we measure BP on both arms to get proper values? Is this 
instrument/kind of instrument broken?), which are often data quality 
and/or research questions, the protocol can be very useful, and having 
it separated will help - it means that no queries to do with the other 
parts of the data will be disturbed by the protocol data.

HISTORY.summary has nothing at all to do with this. We put it in because 
Grahame Grieve had identified a use case where there was something like 
an image that summarised the data in the time series in some visual way. 
Here's the definition from the current release.



In sum, I think the minute we start sliding toward undisciplined data 
models, we start heading back toward the non-computable data we have 
today. Being able to computably reason about data requires defined 
structure and solid theory underlying it. I don't see why we should 
throw that out the window. If we say 'everything is a tree', we just get 
everyone's personal tree structure preference, and no community 
agreements on anything. The whole point of a community in my view is to 
generate agreements that the wider user base an use and rely on.

I would urge people to largely forget aesthetics (i.e. the kind of 
ridiculous subjective preferences one hears in XML schema modelling 
committee meetings), and concentrate instead on computability and 
software quality. Failure to do this got us where we are today...

- thomas


On 26/03/2012 13:33, Ian McNicoll wrote:
 Hi Thomas,

 I think that a simpler single-event model would be very helpful, as 
 very many observation archetypes will only ever require a single 
 event. This complicates the archetyping and adds a layer of complexity 
 to training. I like the sound of what Saso is doing whic is 
 essentially to flatten out / hide the complexity, rather than lose it 
 altogether and create a new archetype class. Not sure how this could 
 be done in practice.

 More controversially, I wonder if we need to rethink state and 
 protocol, particularly protocol, given that we do already have 
 'summary' with in the history class which captures information 
 pertinent to all Events. I increasingly feel that protocol is useful 
 as a design directive but should not have semantic/structural meaning. 
 We never search for 'elements under protocol' or obey firm rules like 
 'you never need to display items within protocol' . By all mean allow 
 authors to express these kind of classifications against particular 
 elements but they do not IMO need to be semantically or structurally 
 hard-wired. There are stronger

13606 revisited - list proposal

2012-03-26 Thread pablo pazos


Hi Thomas,
A while ago, we gave this issue a big thought when designing the EHRGen 
framework.
Periodic event records are needed when recording certain studies and when 
monitoring a patient, but this can be recorded as single point events, and 
using a query to get all the points in a series.
From the GUI perspective is very difficult to record periodic events, because 
you have to login, select a patient, select a record, select the section of 
that record that contains the periodic data, enter a new item to the time 
series. The other option is to have the patient's record always open, and that 
is not possible in all scenarios (for technical or security reasons).
In the other hand, in the majority of cases of clinical record through a GUI, 
the data is recorded as a single point event, e.g. at a patient visit. So we 
design the EHRGen just to use point events, and if you want to record a series 
of events, a service should be provided to get the data from other systems 
(e.g. a LAB system), but not from the GUI.
I don't know if I'm clear here, but hope that helps.
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez

Date: Fri, 23 Mar 2012 14:25:34 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal

  



  
  


In the thread below, Pablo asked whether Action should have as its
data not just an ItemStructure but a History, like Observation. Does
anyone else have evidence supporting this need? 



A related question is: is there a need for an Observation type that
only has one Event in it, i.e. one time-point? Obviously quite a few
observations in real life, including 'patient story' are of this
form. Our original motivation was to make all Observation data
structures the same, hence the current data structures. Introducing
more types makes code more complex and therefore error-prone, but
generally makes data simpler/smaller overall. 



thoughts?



- thomas



On 13/02/2012 21:31, pablo pazos wrote:

  
  
Hi Thomas,



Sorry for the delay, I'm working on several projects right now
and have little time to follow discussion here.


  

  

  
  I'm also thinking about the ENTRY model, to lift up
the data/description attributes from all entry
subclasses to the ENTRY, to have a
ENTRY.data:DATA_STRUCTURE attribute, so all subentries
could define the data as ITEM_STRUCTURE or as a HISTORY.

  
  

   We did think about this a long time
ago, but it did not seem useful. But I assume you are
thinking of doing it because you want to make ENTRY a
concrete class which could have 'any' structure.


  
Nope, is because I see a common pattern on concreate ENTRY
  subclases.


  
In theory doing this breaks a basic
modelling rule, which is that a superclass whose descendants
define the possible data space should  not itself be
concrete.


  
I think this is not the case, having a ENTRY.data :
  DATA_STRUCTURE is in fact a more specific ENTRY class, but is
  still a generic one that could be specialized in many ways. In
  my (maybe biased) experience, all subclasses from ENTRY would
  make use of this attribute since a structure is needed to
  record information.


  
The argument here I suppose is that
we want to build in a 13606-style 'uncommitted' kind of
ENTRY. In fact we already have this - it's currently called
GENERIC_ENTRY. This doesn't get used
at the moment (although it has been there for years), and if
we want to make it a subtype of ENTRY, that could be done.
The main thing to solve I guess is the conversion of any of
the specific openEHR kinds of ENTRY into a generic ENTRY
structure defined by 13606. This can actually be formally
specified by an algorithm. It doesn't require that the
parent abstract ENTRY become concrete either. I am unclear
if there are other reasons to make the ENTRY parent type
concrete, to mimic 13606 ENTRY, rather than simply move
GENERIC_ENTRY to be a subtype, which seems more obvious to
me.

  

  

  

  
  Maybe to have the flexibility to define ACTIONS and
other entries to have a data attribute of class
ITEM_STRUCTURE or HISTORY to track time of events
instead of inventing DV_DATE

13606 revisited - list proposal

2012-03-26 Thread Thomas Beale

On 26/03/2012 19:49, pablo pazos wrote:
Hi Thomas,

A while ago, we gave this issue a big thought when designing the
EHRGen framework.

Periodic event records are needed when recording certain studies and
when monitoring a patient, but this can be recorded as single point
events, and using a query to get all the points in a series.

it can but that's very inefficient, and doesn't correctly represent what
is happening, when you are talking about multiple samples in a series,
e.g. coming from vital signs monitors, orthostatic BP, apgar, and many
others.

From the GUI perspective is very difficult to record periodic events,
because you have to login, select a patient, select a record, select
the section of that record that contains the periodic data, enter a
new item to the time series.

and presumably enter another, and another. That doesn't sound like a
problem - it's how normal GUI for Apgar and multi-sample manual BP
collection work. Don't forget, we are talking about time series in the
seconds to minutes domain here. Although Glucose tolerance test data
would make more sense to be entered as one time series, after the fact.

The other option is to have the patient's record always open, and that
is not possible in all scenarios (for technical or security reasons).

well ifyou are talking about long period of time, like repeated nursing
observations, you should be committing those 1 sample at a time.

In the other hand, in the majority of cases of clinical record through
a GUI, the data is recorded as a single point event, e.g. at a patient
visit. So we design the EHRGen just to use point events, and if you
want to record a series of events, a service should be provided to get
the data from other systems (e.g. a LAB system), but not from the GUI.

that and vital signs monitors are certainly a common source of
time-based data. But whether the source of the data is the GUI or
somewhere else doesn't change the semantics of the model, or the need
for it. Like I said elsewhere, I have no problem with adding a
single-event Observation as well. But having only that will completely
cripple many hospital apps and efficient data representation and
querying related to this data.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/09b309e7/attachment.html

13606 revisited - list proposal

2012-03-24 Thread Timothy Cook

On Fri, Mar 23, 2012 at 08:25, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

  Our original motivation was to make all Observation data structures the
 same, hence the current data structures. Introducing more types makes code
 more complex and therefore error-prone, but generally makes data
 simpler/smaller overall.

 thoughts?



The code is written and validated once.  The data, many times.

-- 

Timothy Cook, MSc   +1 713 254 3643
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120324/8a3a6a54/attachment.html

13606 revisited - list proposal

2012-03-23 Thread Thomas Beale

In the thread below, Pablo asked whether Action should have as its data
not just an ItemStructure but a History, like Observation. Does anyone
else have evidence supporting this need?

thoughts?

- thomas

On 13/02/2012 21:31, pablo pazos wrote:
Hi Thomas,

Sorry for the delay, I'm working on several projects right now and
have little time to follow discussion here.

We did think about this a long time ago, but it did not seem useful.
But I assume you are thinking of doing it because you want to make
ENTRY a concrete class which could have 'any' structure.

Nope, is because I see a common pattern on concreate ENTRY subclases.

In theory doing this breaks a basic modelling rule, which is that a
superclass whose descendants define the possible data space should
not itself be concrete.

The argument here I suppose is that we want to build in a 13606-style
'uncommitted' kind of ENTRY. In fact we already have this - it's
currently called GENERIC_ENTRY
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html.

Maybe to have the flexibility to define ACTIONS and other entries
to have a data attribute of class ITEM_STRUCTURE or HISTORY to
track time of events instead of inventing DV_DATE/DV_DATETIME
ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good
idea. What do you think?

I disagree here, the model semantics could be defined in the specs. My
argument is that we are giving a more flexible IM is adding
flexibility (not ambiguity) to archetypes, and giving knowledge
modelers more options. Then, when they create a concrete archetype,
there is no ambiguity because an archetype models a concept in one
way, and if abstract classes are used in archetypes, the archetype
needs specialization to make is usable on a real environment (software
can't instantiate abstract classes, and could not make the decision
between using subclass A or subclass B).

The HISTORY class is very nicely designed to represent complex
time-series data that has the same protocol and was captured in an
uinterrupted series. It does not try to model sequences of different
types of data - in that case, you just have multiple observations.

I totally agree.

It deal well with point values, averaged interval values, max, min,
sample compression and a few other things. But it's no good with a
succession of different kinds of patient events. Any such timeline for
that kind of thing has to be constructed post-hoc, when the actual
events have already occurred.

That's the model semantics that should be defined on the specs.
Knowing that, not misuse should happen. In the other hand, tools
should not permit this to happen, and this could be implemented as
semantic validation of RM instances (BTW this should be done with the
current model also).

13606 revisited - list proposal

2012-02-13 Thread pablo pazos


Hi Thomas,

Sorry for the delay, I'm working on several projects right now and have little 
time to follow discussion here.



I'm also thinking about the ENTRY model, to lift up the
  data/description attributes from all entry subclasses to the
  ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all
  subentries could define the data as ITEM_STRUCTURE or as a
  HISTORY.
  



We did think about this a long time ago, but it did not seem useful.
But I assume you are thinking of doing it because you want to make
ENTRY a concrete class which could have 'any' structure.
Nope, is because I see a common pattern on concreate ENTRY subclases.
In theory
doing this breaks a basic modelling rule, which is that a superclass
whose descendants define the possible data space should  not itself
be concrete.
I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is in fact a 
more specific ENTRY class, but is still a generic one that could be specialized 
in many ways. In my (maybe biased) experience, all subclasses from ENTRY would 
make use of this attribute since a structure is needed to record information.
The argument here I suppose is that we want to build in
a 13606-style 'uncommitted' kind of ENTRY. In fact we already have
this - it's currently called GENERIC_ENTRY.
This doesn't get used at the moment (although it has been there for
years), and if we want to make it a subtype of ENTRY, that could be
done. The main thing to solve I guess is the conversion of any of
the specific openEHR kinds of ENTRY into a generic ENTRY structure
defined by 13606. This can actually be formally specified by an
algorithm. It doesn't require that the parent abstract ENTRY become
concrete either. I am unclear if there are other reasons to make the
ENTRY parent type concrete, to mimic 13606 ENTRY, rather than simply
move GENERIC_ENTRY to be a subtype, which seems more obvious to me.




  



Maybe to have the flexibility to define ACTIONS and other
  entries to have a data attribute of class ITEM_STRUCTURE or
  HISTORY to track time of events instead of inventing
  DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION
  archetypes is a good idea. What do you think?

  



Well then I think we risk making the model ambiguous, and different
people will use such flexible structures to do the same thing in
different ways, which was the thing we were originally trying to
avoid.
I disagree here, the model semantics could be defined in the specs. My argument 
is that we are giving a more flexible IM is adding flexibility (not ambiguity) 
to archetypes, and giving knowledge modelers more options. Then, when they 
create a concrete archetype, there is no ambiguity because an archetype models 
a concept in one way, and if abstract classes are used in archetypes, the 
archetype needs specialization to make is usable on a real environment 
(software can't instantiate abstract classes, and could not make the decision 
between using subclass A or subclass B).
The HISTORY class is very nicely designed to represent
complex time-series data that has the same protocol and was captured
in an uinterrupted series. It does not try to model sequences of
different types of data - in that case, you just have multiple
observations.
I totally agree.
It deal well with point values, averaged interval
values, max, min, sample compression and a few other things. But
it's no good with a succession of different kinds of patient events.
Any such timeline for that kind of thing has to be constructed
post-hoc, when the actual events have already occurred. 


That's the model semantics that should be defined on the specs. Knowing that, 
not misuse should happen. In the other hand, tools should not permit this to 
happen, and this could be implemented as semantic validation of RM instances 
(BTW this should be done with the current model also).


I can see a theoretical argument to wanting HISTORY in ACTION,
instead of just a single point time, but in practice, noone has ever
been able to come up with an example where a series of ACTIONs needs
to look like a structured series, mainly because ACTIONs usually
need to get recorded when they are done.
IMO ACTION.time:DV_DATE_TIME could have the same semantics as 
ACTION.data.events[0].time, if ACTION.data:HISTORY and events[0]:POINT_EVENT.
The easier example is a repetitive INSTRUCTION like give 5mg of XXX for 10h 
every 30m:The ACTION would register the same information structureThe proposed 
POINT_EVENT of the ACTION could record the information like the current 
ACTION.time attributeThere is a series of ACTIONS recorded for the same 
INSTRUCTION (instead of creating one ACTION instance for each XXX

13606 revisited - list proposal

2012-02-05 Thread Thomas Beale

On 31/01/2012 16:43, pablo pazos wrote:
Hi Thomas, I've added a proposal to the page on the wiki
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model

I'm also thinking about the ENTRY model, to lift up the
data/description attributes from all entry subclasses to the ENTRY, to
have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could
define the data as ITEM_STRUCTURE or as a HISTORY.

We did think about this a long time ago, but it did not seem useful. But
I assume you are thinking of doing it because you want to make ENTRY a
concrete class which could have 'any' structure. In theory doing this
breaks a basic modelling rule, which is that a superclass whose
descendants define the possible data space should not itself be
concrete. The argument here I suppose is that we want to build in a
13606-style 'uncommitted' kind of ENTRY. In fact we already have this -
it's currently called GENERIC_ENTRY
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html.

This doesn't get used at the moment (although it has been there for
years), and if we want to make it a subtype of ENTRY, that could be
done. The main thing to solve I guess is the conversion of any of the
specific openEHR kinds of ENTRY into a generic ENTRY structure defined
by 13606. This can actually be formally specified by an algorithm. It
doesn't require that the parent abstract ENTRY become concrete either. I
am unclear if there are other reasons to make the ENTRY parent type
concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY to
be a subtype, which seems more obvious to me.

Maybe to have the flexibility to define ACTIONS and other entries to
have a data attribute of class ITEM_STRUCTURE or HISTORY to track time
of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on
ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you
think?

Well then I think we risk making the model ambiguous, and different
people will use such flexible structures to do the same thing in
different ways, which was the thing we were originally trying to avoid.
The HISTORY class is very nicely designed to represent complex
time-series data that has the same protocol and was captured in an
uinterrupted series. It does not try to model sequences of different
types of data - in that case, you just have multiple observations. It
deal well with point values, averaged interval values, max, min, sample
compression and a few other things. But it's no good with a succession
of different kinds of patient events. Any such timeline for that kind of
thing has to be constructed post-hoc, when the actual events have
already occurred.

I can see a theoretical argument to wanting HISTORY in ACTION, instead
of just a single point time, but in practice, noone has ever been able
to come up with an example where a series of ACTIONs needs to look like
a structured series, mainly because ACTIONs usually need to get recorded
when they are done. For example, a regular IV drug administration
_could_ in theory be represented by an ACTION with a HISTORY, each of
whose events described the action (say: admin Morphine 20 mg IV) but to
achieve this you would have to wait until all the administrations were
done before writing the data. So for some hours it would look like no
drugs were being administered, then a long series of them would suddenly
appear in the EHR stretching back... days?

I am not saying ACTION is perfect - there have been suggestions for
example that an ACTION + link + OBSERVATION structure should be
available for when the prescribed 'action' was in fact a new
observation, such as 'check patient reaction to drug'.

Another question of time comes up with EVALUATION - e.g. the diagnosis
archetype. This is full of times, and tries to follow a disease course
model. Currently there is no RM class for this, but if a standardised
temporal disease model were agreed across medicine, I suppose there is
no reason why not. But it also is not a simple HISTORY - it is more
'bumpy'... and I don't know if there is any agreed standard model of this.

Anyway, these are my thoughts for now. Let's continue the discussion,
and continue to work on the wiki page
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120205/18c19726/attachment.html

13606 revisited - list proposal

2012-01-31 Thread pablo pazos


Hi Thomas, I've added a proposal to the page on the wiki 
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model
 
I'm also thinking about the ENTRY model, to lift up the data/description 
attributes from all entry subclasses to the ENTRY, to have a 
ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as 
ITEM_STRUCTURE or as a HISTORY.
Maybe to have the flexibility to define ACTIONS and other entries to have a 
data attribute of class ITEM_STRUCTURE or HISTORY to track time of events 
instead of inventing DV_DATE/DV_DATETIME ELEMENTs on 
ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think?
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Thu, 15 Dec 2011 15:48:07 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal


  



  
  


I have started a wiki
  page for this 'lower RM' simplification. The top contains the
existing models, feel free to add to the 'problem' list (why are we
simplifying?). If you have a candidate solution to offer, please put
it under a new heading - you will see a 'Candidate B' ready to be
used by someone. If we proceed in that fashion, I think we can keep
the proposals clear. 



NOTE: I have only half done my proposal, Candidate A, so don't
bother looking at it yet.



- thomas



On 15/12/2011 14:54, pablo pazos wrote:

  
  
Hi Erik,




  I want to implement some simplifications of the
item_structure in the EHRGen (
http://code.google.com/p/open-ehr-gen-framework/ ) we talked
about this:
http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html 
  

  
  My focus is on the persistence layer, because we persist
data using an ORM (object-relational mapping) component, and
the complexity of the relational schema is proportional to
the complexity of the object model.
  

  
  BTW, the EHRGen has the complete cicle of information
implemented: automatic gui generation (based on archetypes
and our gui templates), data validation against archetype
constraints, data binding (creation of RM structures from
user data input and archetypes), persistence of those
structures, and getting data to show on a GUI.
  

  
  Now I'm experimenting with semantic queries (common SQL
but based on arcehtype ids and paths).
  

  
  

  
  Regards,
  Pablo.
  

   Regarding the RM I know Tom is experimenting with
simplified

 ITEM_STRUCTURE as a BMM-schema for the AWB. Are there
any other

 RM-redesign experiments going on anywhere?

 

 What is happening in the 13606-world regarding thoughts
about

 practical datatypes?

 

 What about (optional) reusable ENTRY subtypes in the
13606 world? (see


http://www.openehr.org/mailarchives/openehr-technical/msg05285.html

 under the heading 2. OBSERVATION et. al. (ISO 13606
CR))



  

  



  


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical 
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/d3898636/attachment.html

13606 revisited - list proposal

2012-01-17 Thread Nadim Anani

Dear Thomas,

Are there any documents that one could already look at regarding the rule-based 
Entry Index you mention below?

Sincerely,
Nadim


Nadim Anani, MSc, PhD student
Centrum f?r h?lsoinformatik / Health Informatics Centre (HIC)
LIME
Karolinska Institutet
SE-17177 Stockholm, Sweden


From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: den 16 december 2011 13:52
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal

On 16/12/2011 11:06, Erik Sundvall wrote:





if you want to truly bi-directionally share things ...

the semantics of the end point systems will need to be aligned sooner

or later.



Anyway it wouldn't hurt if a new or refreshed internationally

recognized standard could be used by those vendors and system owners

that actually _want_ to agree on the internal clinical semantics of

efficiently implementable systems all the way down to some of the

technical (e.g. openEHR inspired) details. I think there is now a

market for such a standard (or new standard part) helping those that

have given up beliefs in mapping of incompatible semantics.

Although openEHR is designed for aligning semantics of the data inside and 
between systems, real sytems/products are not so much deficient in this area 
(well, actually they usually are) as focussing on higher levels of computing, 
such as medication list management, prescription tracking, care plan management 
and so on. They generally have to implement such things with hard-wired logic 
and dedicated DB tables etc because there is no generalised data architecture 
that provides the platform for such functionality.

In the standards arena, we have to deal with these upper levels of 
functionality at some point, but doing so will be easier having defined a 
'proper' data architecture (I don't mean to say today's version is perfect, 
just that it is probably in the right ballpark of structure/semantics to 
support upper layers of logic).

One of the forthcoming proposals we have been working on for some time is a 
generalised rule-based 'Entry Index' system which enables higher level 
structures like medication lists and care plans to be completely specified in 
terms of the low level openEHR Entry types we know today (or whatever they 
become). This facility is based on AQL rule patterns and output notifications / 
events, so it is a higher level of sophistication than what currently exists in 
openEHR.

I foresee such tings (the above is just one example) being slowly standardised, 
in a flexible way, so that one day medication lists, doctor's appointment 
schedules and patient care plans can be widely shared across products and 
jurisdictions. Secondly, decision support and business intelligence will 
finally have something solid to work on. In my view, that is the real promise 
of openEHR. The current models are just a foundation.







I suspect this is an intentional difference between current 13606 and

openEHR; to faithfully capture the current (incompatible) situation

versus aiming to change the current situation.  Can those different

goals really meet in one RM or do we need two standardized RMs?

http://dilbert.com/strips/comic/2011-08-02/

I should perhaps point out that openEHR has a perfectly usable generic Entry 
typehttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html
 that does the same as 13606 Entry. This Entry type is designed for weakly 
structured data.

I would suggest that it is not an argument between inside-system logic V 
between system logic, but that there is a continuum of structure+semantics, and 
our models have to cater for that. Some otherwise primitive systems happen to 
be very good at time-series data (e.g. most vital signs monitors) and creating 
openEHR Observations in messages for these data sources is in fact easy. So 
Observation is not specifically an 'inside-system' concept, just a standardised 
way of representing time-series data that is useful for sharing information.


Could one add a new part (13606 part-6 or 1b?) to the specification containing 
detailed RM semantics (inspired by openEHR) and at the same time align that new 
part and a more general healthcare a-specific model (a revised 13606 
part-1(a)?)

that could be a useful idea.

There are other probably more important challenges in the current 13606 though. 
I have put a few notes 
herehttp://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120117/96dbac38/attachment.html

13606 revisited - list proposal

2012-01-17 Thread Thomas Beale


Hi Nadim,

it is one of the many things I have been struggling to find time to 
document and upload. Maybe best to email me personally for the moment.

- thomas

On 17/01/2012 03:00, Nadim Anani wrote:

 Dear Thomas,

 Are there any documents that one could already look at regarding the 
 rule-based Entry Index you mention below?

 Sincerely,

 Nadim


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120117/8c7385dd/attachment.html

13606 revisited - list proposal

2011-12-20 Thread Peter Gummer

Erik Sundvall wrote:

 [ABSTRACT_CARE_ENTRY]^[CARE_ENTRY|data: ITEM]
 [CARE_ENTRY]-[note:CARE_ENTRY Replaces both ADMIN_ENTRY and EVALUATION.]
 [ABSTRACT_CARE_ENTRY]^[OBSERVATION|data: EVENTS;0..1 state: EVENTS]
 [ABSTRACT_CARE_ENTRY]^[INSTRUCTION]
 [ABSTRACT_CARE_ENTRY]^[ACTION]

Hi Erik,

So the basic distinction between ADMIN_ENTRY and the clinical entry types would 
be lost. This feels strange to me, to be using the same CARE_ENTRY class for 
clinical and non-clinical entries.

I'm particularly nervous that EVALUATION, the product of an important step in 
patient care, would disappear into the same class as administrative entries. 
Apart from not feeling nice when I look at a class diagram, mightn't this have 
the practical consequence of making it difficult to write AQL queries to search 
for clinical evaluations? Maybe not ... in AQL, you normally select from some 
archetype by its id, which includes the concept as well as the class ... so it 
would be select from openEHR-EHR-CARE_ENTRY.risk.v1, instead of select from 
openEHR-EHR-EVALUATION.risk.v1. I'm not sure whether it's even possible to 
select from all evaluations without mentioning their concepts.

- Peter

13606 revisited - list proposal

2011-12-20 Thread Sam Heard

Hi David

 

While I agree with your sentiment as a technical guy, the fact is that
sharing health information will be more important than the application space
relatively soon. This is like document sharing now ? you can have the best
word processor on the planet but if it doesn?t do word then it isn?t really
much use.

 

Things can only change slowly once standardisation creeps in ? so we want to
liberate the application from the EHR. Providers and consumers owning the
EHR and vendors the application spaces.

 

Cheers, Sam

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner
Sent: Friday, 16 December 2011 10:55 PM
To: For openEHR technical discussions
Subject: Re: 13606 revisited - list proposal

 

Hi,

2011/12/16 Erik Sundvall erik.sundvall at liu.se

Hi!

 

As you know, if you want to truly bi-directionally share things for
which it is impossible to define deterministic conversion
algorithms/programs (thus maintaining patient safety in automated
conversions), then just defining a standard message- or extract format
will be a lost cause (no matter how determined politicians are and no
matter how much you pay IT-consultants to try to do the job). Instead
the semantics of the end point systems will need to be aligned sooner
or later.

 

I completely agree. But aligned does not mean that the have to be exactly
the same. Conversions between models and standards will always be needed.

 

Anyway it wouldn't hurt if a new or refreshed internationally
recognized standard could be used by those vendors and system owners
that actually _want_ to agree on the internal clinical semantics of
efficiently implementable systems all the way down to some of the
technical (e.g. openEHR inspired) details. I think there is now a
market for such a standard (or new standard part) helping those that
have given up beliefs in mapping of incompatible semantics.

 

 

The problem is that a unique solution will never be used by all actors (due
to the human nature of divergence). The need of interoperability between
different solutions and systems will always exist and then we have to give a
solution for this scenario. Best practices maybe will commonly accepted, but
no specific solutions probably.

 

 From our
 experience, interoperability between legacy systems (standard-based or
not)
 is much easier using a generic model for exchange. The harsh truth is that
 the quality of the data and the design of information structures in
existing
 EHR systems is quite bad or unclear, thus making really complicated the
 process of automatically transforming it to a very specific reference
model.
 This is not the case when we use 13606.

I suspect this is an intentional difference between current 13606 and
openEHR; to faithfully capture the current (incompatible) situation
versus aiming to change the current situation.  Can those different
goals really meet in one RM or do we need two standardized RMs?
http://dilbert.com/strips/comic/2011-08-02/

 

I talked of this with Thomas last August in Oslo. For me, the ideal solution
would be to have a unique model that covers both needs. It should include
generic classes such as those of 13606 and inherit from them specific
classes for building EHR systems, as those of openEHR. Technically it should
be possible to have, for example, a generic
COMPOSITION-ENTRY-CLUSTER-ELEMENT structure that can be instantiated, but
also a COMPOSITION-OBSERVATION-ITEM_TREE-ELEMENT structure inherited from
it. An implementer could choose then to just create instances of the generic
classes (e.g. for exchange) or instances of the specific ones, that are
compatible (e.g. for operational systems). Note that this is currently not
possible since ENTRY is an abstract class in openEHR.

 

A side-track question: Do you feel that the archetyped approach with
13606 really helps in the current mappings/transformations that you
work with more than what just using e.g. RDF+OWL would help? Or does
the archetype stuff and RM mostly complicate things?

 

 

It definitely helps. On the one hand because we deal with data
transformations and then it is essential to have a clearly defined reference
or information model to shape the data that is going to be communicated. And
on the other hand, archetypes are the target schema for these data. We will
all agree that the dual model is the best way to have together the three
basic ingredients of semantic interoperability: the data structure, the
concept definition and the binding to terminologies.

 

 A different thing is if 13606 scope changes during the revision. In that
 case, I agree that reducing layers of modelling by introducing specific
 classes will make the systems more efficient.

Is there an opening for scope-change or not within the formal
13606-revision or would one need to start a completely new standard in
order to define a standard for aligning internal EHR system semantics?

 

I have no idea

13606 revisited - list proposal

2011-12-19 Thread Erik Sundvall

Hi!

Could we discuss some openEHR+13606 2.0 ideas also using UML-ish diagrams
via e.g. http://yuml.me/ if it helps in some cases? (Don't worry it has
nothing to do with YAML despite the name...)

I'll try to provoke some thoughts by inserting a start diagram as a png in
the message now...

...but if it fails to get through the mailservers you also have it at
http://yuml.me/386f608e
The yellow stuff is what I guess could be in a 13606-1(a?) healthcare
a-specific update and the rest in a new 13606-6 or 13606-1b
healthcare-specific part.

I have likely missed some details (and did not have time to add datatypes
to all attributes, but they are in the openEHR specs).

The online editable sourcecode is attached by the end of this mail and
also versioned at
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model.
It can be edited there to add or change things in order to describe
alternative approachess, and then pasted to
http://yuml.me/diagram/scruffy/class/draw2 . So dig in and hack on... :-)

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

Diagram source code used at http://yuml.me/diagram/scruffy/class/draw2:

[note: No change suggestions in ACTION and INSTRUCTION except that
ITEM_STRUCTURE type is replaced by ITEM]
[CONTENT_ITEM{bg:yellow}]]^[SECTION|0..* items: List
CONTENT_ITEM{bg:yellow}]
[CONTENT_ITEM]^[ENTRY|data: ITEM{bg:yellow}]]
[CONTENT_ITEM]^[ABSTRACT_CARE_ENTRY|0..1 protocol: ITEM;0..1 guideline_id:
OBJECT_REF;0..1 workflow_id: OBJECT_REF;language: CODE_PHRASE;encoding:
CODE_PHRASE;subject: PARTY_PROXY;0..1 provider: PARTY_PROXY;0..1
other_participations: List PARTICIPATION; ]
[ABSTRACT_CARE_ENTRY]^[CARE_ENTRY|data: ITEM]
[CARE_ENTRY]-[note:CARE_ENTRY Replaces both ADMIN_ENTRY and EVALUATION.]
[ABSTRACT_CARE_ENTRY]^[OBSERVATION|data: EVENTS;0..1 state: EVENTS]
[ABSTRACT_CARE_ENTRY]^[INSTRUCTION]
[ABSTRACT_CARE_ENTRY]^[ACTION]
[ENTRY]-[note:ENTRY replaces GENERIC_ENTRY and is intended also for
'healthcare a-specific' stuff as indicated useful by 13606 experiences]
[EVENTS|origin;0..1 period;0..1 duration]++-events[EVENT|time;0..1 state:
ITEM; data: ITEM]]
[EVENTS]-[note: HISTORY renamed to EVENTS]
[EVENT]^[INTERVAL_EVENT|width;0..1 sample_count;math_function]
[ITEM{bg:yellow}]^[ELEMENT|0..1 null_flavor;0..1 value
DATA_VALUE{bg:yellow}]
[ITEM]^[CLUSTER|1..* items: ITEM;0..1 structure: CODE_PHRASE{bg:yellow}]
[CLUSTER]-[note: 'structure' indicates if the cluster is to be validated
and interpereted as e.g. a table or list - defaulting to tree if not
provided]
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111219/066471db/attachment.html

13606 revisited - list proposal

2011-12-17 Thread Peter Gummer

On 17/12/2011, at 8:43, Diego Bosc? wrote:

 I am reading 1.0.2 IM and it says CARE_ENTRY, not GENERIC_ENTRY. which
 one is the good one?

GENERIC_ENTRY is described in the integration_im.pdf. It's a sibling of ENTRY 
in the inheritance hierarchy.

- Peter

13606 revisited - list proposal

2011-12-16 Thread David Moner

2011/12/16 Erik Sundvall erik.sundvall at liu.se



 If so, why do you want to turn the 13606/openEHR into something
 healthcare a-specific? Wouldn't that be an enormous deviation from
 the current 13606 thinking and purpose? Was not 13606 intended exactly
 for healthcare?



Well, in fact current EN13606 RM is nearly healthcare independent, except
the EHR_EXTRACT class name, the attributes ehr_system, ehr_id,
subject_of_care and healthcare_facility and the demographic model. The
class and attribute names can be easily changed to drop the EHR part and
for the demographic package I think that the one of openEHR is much better
and, in fact, it is already healthcare independent.

In any case, this generic design is a result of the current scope of 13606:
EHR exchange and not a complete EHR implementation specification. From our
experience, interoperability between legacy systems (standard-based or not)
is much easier using a generic model for exchange. The harsh truth is that
the quality of the data and the design of information structures in
existing EHR systems is quite bad or unclear, thus making really
complicated the process of automatically transforming it to a very specific
reference model. This is not the case when we use 13606.

A different thing is if 13606 scope changes during the revision. In that
case, I agree that reducing layers of modelling by introducing specific
classes will make the systems more efficient.

David
-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/43915127/attachment.html

13606 revisited - list proposal

2011-12-16 Thread Erik Sundvall

Hi!

On Fri, Dec 16, 2011 at 09:32, David Moner damoca at gmail.com wrote:
 In any case, this generic design is a result of the current scope of 13606:
 EHR exchange and not a complete EHR implementation specification.

Thanks for reminding me.

I tend to forget that the 13606 purpose never was to make internal
system semantics interoperable. It's easy to forget the intentional
13606 focus when usually thinking of mappings and interoperability
issues based on examples like the ones on slides 12 and 13 of...
http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf

As you know, if you want to truly bi-directionally share things for
which it is impossible to define deterministic conversion
algorithms/programs (thus maintaining patient safety in automated
conversions), then just defining a standard message- or extract format
will be a lost cause (no matter how determined politicians are and no
matter how much you pay IT-consultants to try to do the job). Instead
the semantics of the end point systems will need to be aligned sooner
or later.

Anyway it wouldn't hurt if a new or refreshed internationally
recognized standard could be used by those vendors and system owners
that actually _want_ to agree on the internal clinical semantics of
efficiently implementable systems all the way down to some of the
technical (e.g. openEHR inspired) details. I think there is now a
market for such a standard (or new standard part) helping those that
have given up beliefs in mapping of incompatible semantics.

 From our
 experience, interoperability between legacy systems (standard-based or not)
 is much easier using a generic model for exchange. The harsh truth is that
 the quality of the data and the design of information structures in existing
 EHR systems is quite bad or unclear, thus making really complicated the
 process of automatically transforming it to a very specific reference model.
 This is not the case when we use 13606.

I suspect this is an intentional difference between current 13606 and
openEHR; to faithfully capture the current (incompatible) situation
versus aiming to change the current situation.  Can those different
goals really meet in one RM or do we need two standardized RMs?
http://dilbert.com/strips/comic/2011-08-02/

A side-track question: Do you feel that the archetyped approach with
13606 really helps in the current mappings/transformations that you
work with more than what just using e.g. RDF+OWL would help? Or does
the archetype stuff and RM mostly complicate things?

 A different thing is if 13606 scope changes during the revision. In that
 case, I agree that reducing layers of modelling by introducing specific
 classes will make the systems more efficient.

Is there an opening for scope-change or not within the formal
13606-revision or would one need to start a completely new standard in
order to define a standard for aligning internal EHR system semantics?

Could one add a new part (13606 part-6 or 1b?) to the specification
containing detailed RM semantics (inspired by openEHR) and at the same
time align that new part and a more general healthcare a-specific
model (a revised 13606 part-1(a)?) in a way that clearly defines a
deterministic (and tested) conversion algorithm from the detailed
clinically focused RM (6 or 1b) to the healthcare a-specific RM
(1a)?

It would be nice to have the different parts under the same roof, a
revised 13606, since they could share an AM based on AOM 1.5.

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

13606 revisited - list proposal

2011-12-16 Thread Koray Atalag

+1

BTW in an ideal world the 13606-openEHR divergence shouldn't have happened in 
first place. I seriously think we can't afford to fall apart and go our own 
ways. But never mind...

-koray

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Adolfo Mu?oz Carrero
Sent: Thursday, 15 December 2011 11:14 p.m.
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal

Dear Thomas,

I also think it's a good idea.

Regards,

 Adolfo Mu?oz

El 15/12/2011 11:04, Rong Chen escribi?:
 Great idea, Thomas!
 /Rong

 On 15 December 2011 10:29, Isabel Rom?n Mart?nezisabel at trajano.us.es  
 wrote:
 Dear Thomas,
 I think it is a good idea.
 Best Regards,
 Isabel

 El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?:

 Dear Thomas,

 The creation of this list will be an excellent contribution to
 promote the harmonization process. In my opinion the alignment of
 these two initiatives is a concrete step to achieve interoperability among 
 EHR systems.

 Best regards,

 Marcelo

 2011/12/15 Seref Arikanserefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
 thomas.beale at oceaninformatics.com  wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether
 the openEHR and 13606 reference models can be brought together for
 part 1 of the revision and b) in finalising ADL/AOM 1.5 for providing
 a new snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


--
Adolfo Mu?oz Carrero
Instituto de Salud Carlos III
Unidad de Investigaci?n en Telemedicina y eSalud Avda. Monforte de Lemos 5 - 
Pabell?n 14
28029 Madrid
Tfno: +34 918222182
FAX: +34 913877567


* AVISO LEGAL *
Este mensaje electr?nico est? dirigido exclusivamente a sus destinatarios,
pudiendo contener documentos anexos de car?cter privado y confidencial.
Si por error, ha recibido este mensaje y no se encuentra entre los
destinatarios, por favor, no use, informe, distribuya, imprima o copie su
contenido por ning?n medio. Le rogamos lo comunique al remitente y borre
completamente el mensaje y sus anexos. El Instituto de Salud Carlos III no
asume ning?n tipo de responsabilidad legal por el contenido de este mensaje
cuando no responda a las funciones atribuidas al remitente del mismo por la
normativa vigente.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6712 (20111214) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6716 (20111216) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6716 (20111216) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

13606 revisited - list proposal

2011-12-16 Thread David Moner

Hi,

2011/12/16 Erik Sundvall erik.sundvall at liu.se

 Hi!

 As you know, if you want to truly bi-directionally share things for
 which it is impossible to define deterministic conversion
 algorithms/programs (thus maintaining patient safety in automated
 conversions), then just defining a standard message- or extract format
 will be a lost cause (no matter how determined politicians are and no
 matter how much you pay IT-consultants to try to do the job). Instead
 the semantics of the end point systems will need to be aligned sooner
 or later.


I completely agree. But aligned does not mean that the have to be exactly
the same. Conversions between models and standards will always be needed.

Anyway it wouldn't hurt if a new or refreshed internationally
 recognized standard could be used by those vendors and system owners
 that actually _want_ to agree on the internal clinical semantics of
 efficiently implementable systems all the way down to some of the
 technical (e.g. openEHR inspired) details. I think there is now a
 market for such a standard (or new standard part) helping those that
 have given up beliefs in mapping of incompatible semantics.


The problem is that a unique solution will never be used by all actors (due
to the human nature of divergence). The need of interoperability between
different solutions and systems will always exist and then we have to give
a solution for this scenario. Best practices maybe will commonly accepted,
but no specific solutions probably.


  From our
  experience, interoperability between legacy systems (standard-based or
 not)
  is much easier using a generic model for exchange. The harsh truth is
 that
  the quality of the data and the design of information structures in
 existing
  EHR systems is quite bad or unclear, thus making really complicated the
  process of automatically transforming it to a very specific reference
 model.
  This is not the case when we use 13606.

 I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized RMs?
 http://dilbert.com/strips/comic/2011-08-02/


I talked of this with Thomas last August in Oslo. For me, the ideal
solution would be to have a unique model that covers both needs. It should
include generic classes such as those of 13606 and inherit from them
specific classes for building EHR systems, as those of openEHR. Technically
it should be possible to have, for example, a generic
COMPOSITION-ENTRY-CLUSTER-ELEMENT structure that can be instantiated, but
also a COMPOSITION-OBSERVATION-ITEM_TREE-ELEMENT structure inherited from
it. An implementer could choose then to just create instances of the
generic classes (e.g. for exchange) or instances of the specific ones, that
are compatible (e.g. for operational systems). Note that this is currently
not possible since ENTRY is an abstract class in openEHR.


 A side-track question: Do you feel that the archetyped approach with
 13606 really helps in the current mappings/transformations that you
 work with more than what just using e.g. RDF+OWL would help? Or does
 the archetype stuff and RM mostly complicate things?


It definitely helps. On the one hand because we deal with data
transformations and then it is essential to have a clearly defined
reference or information model to shape the data that is going to be
communicated. And on the other hand, archetypes are the target schema for
these data. We will all agree that the dual model is the best way to have
together the three basic ingredients of semantic interoperability: the data
structure, the concept definition and the binding to terminologies.


  A different thing is if 13606 scope changes during the revision. In that
  case, I agree that reducing layers of modelling by introducing specific
  classes will make the systems more efficient.

 Is there an opening for scope-change or not within the formal
 13606-revision or would one need to start a completely new standard in
 order to define a standard for aligning internal EHR system semantics?


I have no idea. I don't know the internal rules of ISO.


 Could one add a new part (13606 part-6 or 1b?) to the specification
 containing detailed RM semantics (inspired by openEHR) and at the same
 time align that new part and a more general healthcare a-specific
 model (a revised 13606 part-1(a)?) in a way that clearly defines a
 deterministic (and tested) conversion algorithm from the detailed
 clinically focused RM (6 or 1b) to the healthcare a-specific RM
 (1a)?


From what I have heard, it is possible to add new part to the standard.


David


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)

13606 revisited - list proposal

2011-12-16 Thread Thomas Beale

On 16/12/2011 11:06, Erik Sundvall wrote:

if you want to truly bi-directionally share things ...
the semantics of the end point systems will need to be aligned sooner
or later.

Anyway it wouldn't hurt if a new or refreshed internationally
recognized standard could be used by those vendors and system owners
that actually _want_ to agree on the internal clinical semantics of
efficiently implementable systems all the way down to some of the
technical (e.g. openEHR inspired) details. I think there is now a
market for such a standard (or new standard part) helping those that
have given up beliefs in mapping of incompatible semantics.

Although openEHR is designed for aligning semantics of the data inside
and between systems, real sytems/products are not so much deficient in
this area (well, actually they usually are) as focussing on higher
levels of computing, such as medication list management, prescription
tracking, care plan management and so on. They generally have to
implement such things with hard-wired logic and dedicated DB tables etc
because there is no generalised data architecture that provides the
platform for such functionality.

In the standards arena, we have to deal with these upper levels of
functionality at some point, but doing so will be easier having defined
a 'proper' data architecture (I don't mean to say today's version is
perfect, just that it is probably in the right ballpark of
structure/semantics to support upper layers of logic).

One of the forthcoming proposals we have been working on for some time
is a generalised rule-based 'Entry Index' system which enables higher
level structures like medication lists and care plans to be completely
specified in terms of the low level openEHR Entry types we know today
(or whatever they become). This facility is based on AQL rule patterns
and output notifications / events, so it is a higher level of
sophistication than what currently exists in openEHR.

I foresee such tings (the above is just one example) being slowly
standardised, in a flexible way, so that one day medication lists,
doctor's appointment schedules and patient care plans can be widely
shared across products and jurisdictions. Secondly, decision support and
business intelligence will finally have something solid to work on. In
my view, that is the real promise of openEHR. The current models are
just a foundation.

I suspect this is an intentional difference between current 13606 and
openEHR; to faithfully capture the current (incompatible) situation
versus aiming to change the current situation. Can those different
goals really meet in one RM or do we need two standardized RMs?
http://dilbert.com/strips/comic/2011-08-02/

I should perhaps point out that openEHR has a perfectly usable generic
Entry type
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html

that does the same as 13606 Entry. This Entry type is designed for
weakly structured data.

I would suggest that it is not an argument between inside-system logic V
between system logic, but that there is a continuum of
structure+semantics, and our models have to cater for that. Some
otherwise primitive systems happen to be very good at time-series data
(e.g. most vital signs monitors) and creating openEHR Observations in
messages for these data sources is in fact easy. So Observation is not
specifically an 'inside-system' concept, just a standardised way of
representing time-series data that is useful for sharing information.

Could one add a new part (13606 part-6 or 1b?) to the specification
containing detailed RM semantics (inspired by openEHR) and at the same
time align that new part and a more general healthcare a-specific
model (a revised 13606 part-1(a)?)

that could be a useful idea.

There are other probably more important challenges in the current 13606
though. I have put a few notes here
http://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals.

- thomas

**
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/a022ed5f/attachment.html

13606 revisited - list proposal

2011-12-16 Thread Gerard Freriks

Dear Erik,

My personal thoughts and reactions.

It is based on off-line discussions in the EN13606 Association.
We will collect our thoughts and ideas, present them next year to the community 
and discuss them in February during our annual meeting in Seville.
Until then my personal ideas only.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 16 dec. 2011, at 12:06, Erik Sundvall wrote:

 Hi!
 
 On Fri, Dec 16, 2011 at 09:32, David Moner damoca at gmail.com wrote:
 In any case, this generic design is a result of the current scope of 13606:
 EHR exchange and not a complete EHR implementation specification.
 
 Thanks for reminding me.
 
 I tend to forget that the 13606 purpose never was to make internal
 system semantics interoperable. It's easy to forget the intentional
 13606 focus when usually thinking of mappings and interoperability
 issues based on examples like the ones on slides 12 and 13 of...
 http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf
 
 As you know, if you want to truly bi-directionally share things for
 which it is impossible to define deterministic conversion
 algorithms/programs (thus maintaining patient safety in automated
 conversions), then just defining a standard message- or extract format
 will be a lost cause (no matter how determined politicians are and no
 matter how much you pay IT-consultants to try to do the job). Instead
 the semantics of the end point systems will need to be aligned sooner
 or later.
 
 Anyway it wouldn't hurt if a new or refreshed internationally
 recognized standard could be used by those vendors and system owners
 that actually _want_ to agree on the internal clinical semantics of
 efficiently implementable systems all the way down to some of the
 technical (e.g. openEHR inspired) details. I think there is now a
 market for such a standard (or new standard part) helping those that
 have given up beliefs in mapping of incompatible semantics.

I agree.
This is what I wanted in the first place.
In the standardisation process it was felt to be more safe to obtain 
experiences first this the present scope.
Some wording in the present scope hints at this more extended use outside of 
the EH-Extract.

Although I agree, I think, that the 13606 Reference Model should not be a model 
on how to implement it in a very detailed way in a system.
It must stay a generic and logical model that provides features that help 
vendors to produce such internal proprietary implemented models.

 
 From our
 experience, interoperability between legacy systems (standard-based or not)
 is much easier using a generic model for exchange. The harsh truth is that
 the quality of the data and the design of information structures in existing
 EHR systems is quite bad or unclear, thus making really complicated the
 process of automatically transforming it to a very specific reference model.
 This is not the case when we use 13606.
 
 I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized RMs?
 http://dilbert.com/strips/comic/2011-08-02/

It is/was a matter of scope.

I see no reason why we can NOT have one logical model that can serve the 
purpose of use inside IT-systems and outside an IT-system.
A different matter is whether the present openEHR RM is acceptable or not.
And who owns the spec.



 
 A side-track question: Do you feel that the archetyped approach with
 13606 really helps in the current mappings/transformations that you
 work with more than what just using e.g. RDF+OWL would help? Or does
 the archetype stuff and RM mostly complicate things?

When it is possible to design and implement using 13606 and archetypes in less 
than a week a common patient summary between two different hospitals, or a 
system that transforms a proprietary EHR to the CDISC-ODM format,
is that enough of an answer?
My answer is that the present 13606 fulfills its scope and is very functional.



 
 A different thing is if 13606 scope changes during the revision. In that
 case, I agree that reducing layers of modelling by introducing specific
 classes will make the systems more efficient.

David and I agree.

 
 Is there an opening for scope-change or not within the formal
 13606-revision or would one need to start a completely new standard in
 order to define a standard for aligning internal EHR system semantics?

In the EN13606 Association community there are openings to do that.
But whether the CEN/ISO representatives want it, is to be found out.


 
 Could one add a new part (13606 part-6 or 1b?) to the specification
 containing detailed RM semantics (inspired by openEHR) and at the same
 time align that new part and a more general healthcare a-specific
 model (a revised 13606 part-1(a)?) in a way that clearly defines a
 deterministic (and tested) conversion algorithm

13606 revisited - list proposal

2011-12-16 Thread David Moner


  I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized 
 RMs?http://dilbert.com/strips/comic/2011-08-02/


 I should perhaps point out that openEHR has a perfectly usable generic
 Entry 
 typehttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.htmlthat
  does the same as 13606 Entry. This Entry type is designed for weakly
 structured data.


It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is
now only complicates de model by creating a standalone branch. Instead of
that, I would prefer to look for a solution where the ENTRY class is
directly instantiable. Thus, an implementer can choose to use it if the
lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs.
Moreover, it would be easy to cast an ENTRY instance into any of its
descendants when needed.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/120f3d44/attachment.html

13606 revisited - list proposal

2011-12-16 Thread Thomas Beale


Hi David,

On 16/12/2011 18:48, David Moner wrote:


 I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized RMs?
 http://dilbert.com/strips/comic/2011-08-02/

 I should perhaps point out that openEHR has a perfectly usable
 generic Entry type
 
 http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html
 that does the same as 13606 Entry. This Entry type is designed for
 weakly structured data.


 It is not exactly the same as what I was proposing. The GENERIC_ENTRY 
 as is now only complicates de model by creating a standalone branch.

do you mean in the inheritance tree? Well, that's true, but that's 
normal object modelling...

 Instead of that, I would prefer to look for a solution where the ENTRY 
 class is directly instantiable. Thus, an implementer can choose to use 
 it if the lower OBSERVATION, INSTRUCTION, etc. classes do not 
 accommodate his needs. Moreover, it would be easy to cast an ENTRY 
 instance into any of its descendants when needed.

I think this is looking at it from too low a level. The structures of 
ENTRY, OBSERVATION, INSTRUCTION etc are quite different. The ENTRY 
concept in openEHR does not on its own define a meaningful object; the 
structure of the data have to be defined in specific subclasses. The 
descendants (today) are: ADMIN_ENTRY, OBSERVATION, EVALUATION, 
INSTRUCTION, ACTION and GENERIC_ENTRY. So GENERIC_ENTRY is just one of 
the sibling possibilities for representing data. (I realise that it's a 
bit annoying that we use 'ENTRY' as the abstract parent type, whereas 
13606 uses it as the name of the concrete type, but I can't see any easy 
way around that).

I think this is a normal modelling outcome. I can't see how in openEHR, 
the ENTRY class could do its main job, which is to define the common 
attributes (we can think of them as meta-data attributes) of all ENTRY 
types, and also have some kind of commitment to data, which would then 
be somehow redefined to other specific data structures somehow - casting 
only works when the physical data don't change, but are interpreted 
differently (and anyway, casting should always be avoided - it means the 
software is potentially violating the type system). The normal OO 
approach is that a parent class such as ENTRY stays abstract, and its 
children exhaustively define the possibility space.

However, what I can imagine is a function on ENTRY, something like 
'as_standard_representation: CLUSTER', which /generates /a standardised 
CLUSTER/ELEMENT hierarchy of the 13606 variety (complete with logical 
data structure markers to indicate the intention of lists, tables etc).

This would allow the openEHR model to stick to normal OO modelling 
conventions, but also have a fully formally defined transform to the 
simple CLUSTER/ELEMENT structure from each of its ENTRY subtypes. 
Calling this function during a traversal of a COMPOSITION would enable 
something very close to a 13606 COMPOSITION to be generated.

As I mentioned in another post, I think a greater challenge is dealing 
with the differences in the base classes - my notes on this so far are 
here 
http://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals.

- thomas


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/02eabe28/attachment.html

13606 revisited - list proposal

2011-12-16 Thread Diego Boscá

I am reading 1.0.2 IM and it says CARE_ENTRY, not GENERIC_ENTRY. which
one is the good one?
By the way, both ENTRY and CARE_ENTRY are abstract in openEHR. I don't
think you could only make ENTRY non-abstract without making CARE_ENTRY
non-abstract too (I think it has no sense to inherit an abstract class
from non abstract).
Looking at CARE_ENTRY, I don't really get why ADMIN_ENTRY is not able
to inherit from it. 'protocol' attribute meaning changes according to
the instantiated class (as the pdf says, describes 'how' was arrived
the information) and it is optional, as 'guideline_id'. Why don't make
ADMIN_ENTRY as a child of CARE_ENTRY as protocol could be also used
(why not using it for stating how was the ADMIN_ENTRY information
arrived? or what where the social/legal requirements to led to this
entry).
'guideline_id' could be used to state if this ADMIN_ENTRY was a result
from a clinical guide step (I can be wrong at this one, but that's
what I understand from the specifications). And the specifications say
that this one is only used 'if relevant', so it isn't always used
anyway.

If you do this you can remove CARE_ENTRY and focus on the ENTRY itself :)

2011/12/16 Thomas Beale thomas.beale at oceaninformatics.com:

 Hi David,


 On 16/12/2011 18:48, David Moner wrote:



 I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized RMs?
 http://dilbert.com/strips/comic/2011-08-02/


 I should perhaps point out that openEHR has a perfectly usable generic
 Entry type that does the same as 13606 Entry. This Entry type is designed
 for weakly structured data.


 It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is
 now only complicates de model by creating a standalone branch.


 do you mean in the inheritance tree? Well, that's true, but that's normal
 object modelling...


 Instead of that, I would prefer to look for a solution where the ENTRY class
 is directly instantiable. Thus, an implementer can choose to use it if the
 lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs.
 Moreover, it would be easy to cast an ENTRY instance into any of its
 descendants when needed.


 I think this is looking at it from too low a level. The structures of ENTRY,
 OBSERVATION, INSTRUCTION etc are quite different. The ENTRY concept in
 openEHR does not on its own define a meaningful object; the structure of the
 data have to be defined in specific subclasses. The descendants (today) are:
 ADMIN_ENTRY, OBSERVATION, EVALUATION, INSTRUCTION, ACTION and GENERIC_ENTRY.
 So GENERIC_ENTRY is just one of the sibling possibilities for representing
 data. (I realise that it's a bit annoying that we use 'ENTRY' as the
 abstract parent type, whereas 13606 uses it as the name of the concrete
 type, but I can't see any easy way around that).

 I think this is a normal modelling outcome. I can't see how in openEHR, the
 ENTRY class could do its main job, which is to define the common attributes
 (we can think of them as meta-data attributes) of all ENTRY types, and also
 have some kind of commitment to data, which would then be somehow redefined
 to other specific data structures somehow - casting only works when the
 physical data don't change, but are interpreted differently (and anyway,
 casting should always be avoided - it means the software is potentially
 violating the type system). The normal OO approach is that a parent class
 such as ENTRY stays abstract, and its children exhaustively define the
 possibility space.

 However, what I can imagine is a function on ENTRY, something like
 'as_standard_representation: CLUSTER', which generates a standardised
 CLUSTER/ELEMENT hierarchy of the 13606 variety (complete with logical data
 structure markers to indicate the intention of lists, tables etc).

 This would allow the openEHR model to stick to normal OO modelling
 conventions, but also have a fully formally defined transform to the simple
 CLUSTER/ELEMENT structure from each of its ENTRY subtypes. Calling this
 function during a traversal of a COMPOSITION would enable something very
 close to a 13606 COMPOSITION to be generated.

 As I mentioned in another post, I think a greater challenge is dealing with
 the differences in the base classes - my notes on this so far are here.

 - thomas



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

13606 revisited - list proposal

2011-12-15 Thread Thomas Beale


At the CIMI meeting last week and elsewhere, I have noticed a lot of 
interest in the ISO 13606 2012 revision, specifically in a) whether the 
openEHR and 13606 reference models can be brought together for part 1 of 
the revision and b) in finalising ADL/AOM 1.5 for providing a new 
snapshot to ISO for part 2.

It seems to me that it would be useful to have a dedicated place to 
discuss this, so I would like to propose a new mailing list, 
13606-alignment at openehr.org

Does this seem like a useful idea?

- thomas beale

13606 revisited - list proposal


Great! this will be THE opportunity to think about an IM 2.0, and the first 
topic on my wishlist is the simplification of ITEM_STRUCTURE  children :D 

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

 Date: Thu, 15 Dec 2011 00:49:20 +
 From: thomas.beale at oceaninformatics.com
 To: openehr-technical at openehr.org
 Subject: 13606 revisited - list proposal
 
 
 At the CIMI meeting last week and elsewhere, I have noticed a lot of 
 interest in the ISO 13606 2012 revision, specifically in a) whether the 
 openEHR and 13606 reference models can be brought together for part 1 of 
 the revision and b) in finalising ADL/AOM 1.5 for providing a new 
 snapshot to ISO for part 2.
 
 It seems to me that it would be useful to have a dedicated place to 
 discuss this, so I would like to propose a new mailing list, 
 13606-alignment at openehr.org
 
 Does this seem like a useful idea?
 
 - thomas beale
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/41c00947/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Diego Boscá

technically speaking, CLUSTER is already simpler in current 13606 model :)

2011/12/15 pablo pazos pazospablo at hotmail.com:
 Great! this will be THE opportunity to think about an IM 2.0, and the first
 topic on my wishlist is the simplification of ITEM_STRUCTURE  children :D

 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos

 Date: Thu, 15 Dec 2011 00:49:20 +
 From: thomas.beale at oceaninformatics.com
 To: openehr-technical at openehr.org
 Subject: 13606 revisited - list proposal



 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

13606 revisited - list proposal

2011-12-15 Thread David Moner

Hello Thomas,

The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
:-) will start next February at the EN 13606 Association General Assembly
in Seville with an open and public consultation. Before that, to prepare a
draft starting point, during January a consultation will be made to key
actors, implementers and users of the standard, including openEHR.

There is more information at
http://www.en13606.org/index.php/activities/general-assembly-2012

As you know, my opinion is that an harmonisation or at least a seamless
transition between 13606 and openEHR is a key element to succeed.

David


2011/12/15 Thomas Beale thomas.beale at oceaninformatics.com


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/82893545/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Seref Arikan

Hi Tom,
Yes, such a list would be good.

Regards
Seref


On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/92bebd9c/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Marcelo Rodrigues dos Santos

Dear Thomas,

The creation of this list will be an excellent contribution to promote the
harmonization process. In my opinion the alignment of these two initiatives
is a concrete step to achieve interoperability among EHR systems.

Best regards,

Marcelo

2011/12/15 Seref Arikan serefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale 
 thomas.beale at oceaninformatics.com wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/abbb9c23/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Isabel Román Martínez

Dear Thomas,
I think it is a good idea.
Best Regards,
Isabel

El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?:
 Dear Thomas,

 The creation of this list will be an excellent contribution to promote 
 the harmonization process. In my opinion the alignment of these two 
 initiatives is a concrete step to achieve interoperability among EHR 
 systems.

 Best regards,

 Marcelo

 2011/12/15 Seref Arikan serefarikan at kurumsalteknoloji.com 
 mailto:serefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
 thomas.beale at oceaninformatics.com
 mailto:thomas.beale at oceaninformatics.com wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a
 lot of
 interest in the ISO 13606 2012 revision, specifically in a)
 whether the
 openEHR and 13606 reference models can be brought together for
 part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated
 place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org mailto:13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 mailto:openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org mailto:openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/54823acb/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Rong Chen

Great idea, Thomas!
/Rong

On 15 December 2011 10:29, Isabel Rom?n Mart?nez isabel at trajano.us.es 
wrote:
 Dear Thomas,
 I think it is a good idea.
 Best Regards,
 Isabel

 El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?:

 Dear Thomas,

 The creation of this list will be an excellent contribution to promote the
 harmonization process. In my opinion the alignment of these two initiatives
 is a concrete step to achieve interoperability among EHR systems.

 Best regards,

 Marcelo

 2011/12/15 Seref Arikan serefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
 thomas.beale at oceaninformatics.com wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

13606 revisited - list proposal

2011-12-15 Thread Adolfo Muñoz Carrero

Dear Thomas,

I also think it's a good idea.

Regards,

 Adolfo Mu?oz

El 15/12/2011 11:04, Rong Chen escribi?:
 Great idea, Thomas!
 /Rong

 On 15 December 2011 10:29, Isabel Rom?n Mart?nezisabel at trajano.us.es  
 wrote:
 Dear Thomas,
 I think it is a good idea.
 Best Regards,
 Isabel

 El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?:

 Dear Thomas,

 The creation of this list will be an excellent contribution to promote the
 harmonization process. In my opinion the alignment of these two initiatives
 is a concrete step to achieve interoperability among EHR systems.

 Best regards,

 Marcelo

 2011/12/15 Seref Arikanserefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
 thomas.beale at oceaninformatics.com  wrote:


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- 
Adolfo Mu?oz Carrero
Instituto de Salud Carlos III
Unidad de Investigaci?n en Telemedicina y eSalud
Avda. Monforte de Lemos 5 - Pabell?n 14
28029 Madrid
Tfno: +34 918222182
FAX: +34 913877567


* AVISO LEGAL *
Este mensaje electr?nico est? dirigido exclusivamente a sus destinatarios,
pudiendo contener documentos anexos de car?cter privado y confidencial.
Si por error, ha recibido este mensaje y no se encuentra entre los
destinatarios, por favor, no use, informe, distribuya, imprima o copie su
contenido por ning?n medio. Le rogamos lo comunique al remitente y borre
completamente el mensaje y sus anexos. El Instituto de Salud Carlos III no
asume ning?n tipo de responsabilidad legal por el contenido de este mensaje
cuando no responda a las funciones atribuidas al remitente del mismo por la
normativa vigente.

13606 revisited - list proposal

2011-12-15 Thread Gerard Freriks

Dear Pablos,

Internally in the EN13606 Association I started to work on this renewal.
The EN13606 Association will start to think about all 5 parts of the standard.

With respect to 13606 part 1 - the reference model- I think we will have
discussions on topics such as:
- scope
- Folders
- Semantic links
- the structure below the Entry Class
- the type of relationships between the Composition/section classes used to
structure documents and the Entry, Cluster and Element classes that define the
clinical content.

Possibly other members will have their own topics they want to put on the table.
In our EN13606 Association meeting in February in Seville we start the
discussions after a consultation phase.
openEHR will be part of this consultation phase. Any input from openEHR is
welcomed.
A WIKI page will be started anytime soon on our website.
After these discussions our suggestions will be submitted to CEN/tc251 and
ISO/tc215.

For more information about the EN13606 Association and the Seville meeting I
refer to:
www.en13606.org
Non-members that want to participate in this meeting are invited to subscribe.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 dec. 2011, at 05:03, pablo pazos wrote:

Great! this will be THE opportunity to think about an IM 2.0, and the first
topic on my wishlist is the simplification of ITEM_STRUCTURE children :D

--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/0d9c5f74/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Stef Verlinden

I asume there is no subscription fee for openEHR members.

Cheers,

Stef


Op 15 dec. 2011, om 11:33 heeft Gerard Freriks het volgende geschreven:

 For more information about the EN13606 Association and the Seville meeting I 
 refer to:
 www.en13606.org
 Non-members that want to participate in this meeting are invited to subscribe.

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/163939c0/attachment.html

13606 revisited - list proposal

2011-12-15 Thread David Moner

Hi Stef,

There are no subscription fees, all activities are open to the public. The
only requirement is to confirm the attendance in advance because the space
will be limited.

David


2011/12/15 Stef Verlinden stef at vivici.nl

 I asume there is no subscription fee for openEHR members.

 Cheers,

 Stef


 Op 15 dec. 2011, om 11:33 heeft Gerard Freriks het volgende geschreven:

 For more information about the EN13606 Association and the Seville meeting
 I refer to:
 www.en13606.org
 Non-members that want to participate in this meeting are invited to
 subscribe.



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/59a07d26/attachment.html

13606 revisited - list proposal

2011-12-15 Thread Chang, Wo L.

Dear Thomas,

Wonderful and much appreciated for setting the special reflector for it, thanks!
Can you kindly provide the link how to join the new reflector?

Thanks!

--Wo

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Wednesday, December 14, 2011 7:49 PM
To: Openehr-Technical
Subject: 13606 revisited - list proposal


At the CIMI meeting last week and elsewhere, I have noticed a lot of interest 
in the ISO 13606 2012 revision, specifically in a) whether the openEHR and 
13606 reference models can be brought together for part 1 of the revision and 
b) in finalising ADL/AOM 1.5 for providing a new snapshot to ISO for part 2.

It seems to me that it would be useful to have a dedicated place to discuss 
this, so I would like to propose a new mailing list, 13606-alignment at 
openehr.org

Does this seem like a useful idea?

- thomas beale

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

13606 revisited - list proposal

2011-12-15 Thread Erik Sundvall

Hi!

On Thu, Dec 15, 2011 at 08:52, David Moner damoca at gmail.com wrote:
 The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
 :-) will start next February at the EN 13606 Association General Assembly in
 Seville with an open and public consultation.

Is there any formal link between the 13606 Association and the actual
standardisation process or is the pre-SDO process to be seen as
traditional lobbying?

Perhaps the best thing would be if the 13606 Association and openEHR
could bring forward a unified co-authored suggestion to the SDO
process rather than two suggestions? Perhaps we can use the new
mailing list Thomas suggested for mail conversations combined with the
wiki of the EN 13606 Association, instead of having separate mailing
lists and separate wikis for the alignment discussions in each
community?

 Before that, to prepare a
 draft starting point, during January a consultation will be made to key
 actors, implementers and users of the standard, including openEHR.

A great thing would be to actually have at least two independent
_implementations_ of change suggestions (both AM and RM) after initial
discussions but before any revisions to the standard are made. That is
how some other SDOs work with technical artefacts and it could avoid
some of the previous suboptimal approaches.

I assume AOM 1.5 is a candidate for AM? Is anybody already working on
an AOM 1.5 implementation in addition to Tom's Eiffel version? Are
there people interested in updating the Java implementation (or some
other implementation) before or during the SDO process?

Regarding the RM I know Tom is experimenting with simplified
ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other
RM-redesign experiments going on anywhere?

What is happening in the 13606-world regarding thoughts about
practical datatypes?

What about (optional) reusable ENTRY subtypes in the 13606 world? (see
http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
under the heading 2. OBSERVATION et. al. (ISO 13606 CR))

 As you know, my opinion is that an harmonisation or at least a seamless
 transition between 13606 and openEHR is a key element to succeed.

I totally agree.

Bringing the communities tighter together is another important thing.
The way some leaders sometimes talk of the other organisation's
approaches might not be helpful in that sense. Those of you having
formal powers in each organisation please ask your leaders to speak as
honestly and nicely as possible of each others
organisations/communities/approaches, or else please change leaders.

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

13606 revisited - list proposal


That's the simplification we need to the IM 2.0! :D

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

 From: yampeku at gmail.com
 Date: Thu, 15 Dec 2011 08:30:46 +0100
 Subject: Re: 13606 revisited - list proposal
 To: openehr-technical at openehr.org
 
 technically speaking, CLUSTER is already simpler in current 13606 model :)
 
 2011/12/15 pablo pazos pazospablo at hotmail.com:
  Great! this will be THE opportunity to think about an IM 2.0, and the first
  topic on my wishlist is the simplification of ITEM_STRUCTURE  children :D
 
  --
  Kind regards,
  Ing. Pablo Pazos Guti?rrez
  LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
  Blog: http://informatica-medica.blogspot.com/
  Twitter: http://twitter.com/ppazos
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/242f8ce5/attachment.html

13606 revisited - list proposal


Hi Gerard, is good to know! please publish the link to the wiki discussion when 
available.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Subject: Re: 13606 revisited - list proposal
From: gf...@luna.nl
Date: Thu, 15 Dec 2011 11:33:17 +0100
To: openehr-technical at openehr.org



Dear Pablos,
Internally in the EN13606 Association I started to work on this renewal.The 
EN13606 Association will start to think about all 5 parts of the standard.
With respect to 13606 part 1 - the reference model- I think we will have 
discussions on topics such as:- scope- Folders- Semantic links- the structure 
below the Entry Class- the type of relationships between the 
Composition/section classes used to structure documents and the Entry, Cluster 
and Element classes that define the clinical content.
Possibly other members will have their own topics they want to put on the 
table.In our EN13606 Association meeting in February in Seville we start the 
discussions after a consultation phase.openEHR will be part of this 
consultation phase. Any input from openEHR is welcomed.A WIKI page will be 
started anytime soon on our website.After these discussions our suggestions 
will be submitted to CEN/tc251 and ISO/tc215.
For more information about the EN13606 Association and the Seville meeting I 
refer to:www.en13606.orgNon-members that want to participate in this meeting 
are invited to subscribe.

Gerard Freriks+31 620347088gfrer at luna.nl



On 15 dec. 2011, at 05:03, pablo pazos wrote:Great! this will be THE 
opportunity to think about an IM 2.0, and the first topic on my wishlist is the 
simplification of ITEM_STRUCTURE  children :D 

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical 
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/b2b20f4b/attachment.html

13606 revisited - list proposal