Thomas Beale wrote:
pablo pazos wrote:
Consider this ER scenario: a BP value could be recorded each 30 or so, and
the system could be used 1. for many patients, 2. by many users, 3. on the
same machine.
this is most likely a 1-event-per-Observation scenario. I realise it is not
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
Hi Thomas,
Date: Mon, 26 Mar 2012 20:47:05 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: 13606 revisited - list proposal
On 26/03/2012 19:49, pablo pazos wrote:
Hi Thomas
On 28/03/2012 03:01, pablo pazos wrote:
Consider this ER scenario: a BP value could be recorded each 30 or
so, and the system could be used 1. for many patients, 2. by many
users, 3. on the same machine.
this is most likely a 1-event-per-Observation scenario. I realise it is
not always
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
, 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
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
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
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
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
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
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
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
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
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
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,
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
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
? 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
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
Thanks,
More questions below.
On 27 March 2012 13:12, Grahame Grieve
grahame at healthintersections.com.auwrote:
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.
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
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:
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
-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
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
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
, 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
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
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
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
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
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
+
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
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
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
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
[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
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
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
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
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
...@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
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
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
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.
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
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
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
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
-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 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
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
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
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
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
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
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,
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
-
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
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.
] 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
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
+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
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
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
Dear Erik,
Some personal comments in the text below.
GF
Gerard Freriks
+31 620347088
gfrer at luna.nl
=
On 15 dec. 2011, at 15:02, Erik Sundvall wrote:
Hi!
On Thu, Dec 15, 2011 at 08:52, David Moner damoca at gmail.com wrote:
The unofficial renewal
I have started a wiki page
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model
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
68 matches
Mail list logo
