Term bindings in archetypes and templates

[Sam Heard]

Hi,

This is an interesting discussion. I think we need to keep a sense of
purpose here in what we are doing. We need to understand that the complexity
of biomedicine is probably unsurpassed and the language of health
professionals is a way of dealing with this. It has historical roots which
allows people to drill down when appropriate. The paper by Werner and Barry
on malaria illustrates the difficulties. So we will find, if we look hard
enough, that there are massive imperfections in what clinicians record but
these imperfections are generally understood by those that need to know
about them.

I remember a story about a medical teacher when I was young asking a rather
impertinent student what they knew about the cause of rheumatoid arthritis.
He said "Nothing". And then he asked the student "And what do I know about
the cause?" He again said "Nothing". The teacher nodded and added "But don't
underestimate the gap between what you know about the cause of rheumatoid
arthritis and what I know".

We don't call rheumatoid arthritis idiopathic arthritis because we have
accepted the syndrome and its histological features. We know the prognosis
and outcomes in many situations. Patient's would like to know why - but we
can't tell them. Malaria is actually four diseases - two of which actually
are rather different from the other two. Pneumonia, from the perspective of
causation, is actually 100s of diseases all with a similar pathology. When I
read the paper on malaria by the ontology guys I learned a lot. I have
diagnosed and treated malaria quite a few times in my life but did not know
some features of the life cycle of the plasmodium and the features that
Werner and Barry are describing at times are not of clinical significance.

So where does ontology get in the way of good health care? I would suggest
it is when there is no 'drill down'; that complexity is presented as a flat
knowledge space. Deep knowledge in clinical practice, what is needed to
provide the best care, is not necessarily detailed knowledge - the latter is
usually the preserve of bioscientists and clinicians researching an area.
They might come back to us with more detail that alters the knowledge
required to provide the best care. It is then that deep knowledge shifts.
More detailed knowledge does not necessary lead to more complex deep
knowledge. Asthma is a good example. Treatment used to be a nightmare but as
we have learned more it is really quite simple to manage.

So I just want to challenge the approach of linking to ontologies. I would
like to propose a simplification. If we take the archetypes as the purest
expression available of what clinicians want (or are able) to record then we
have something. We can organise and classify these in future to make them
very available. CKM has started that process and it will get more
sophisticated.

The task then for term_bindings is to link points in archetypes to
terminology so that other people can understand from that perspective what
we are talking about. I would argue that there are two approaches. First is
to find a term in a terminology that says exactly what the archetype is
recording. The second approach is to find the observable entity that is
being recorded.

It becomes absurd at one level to think about the things that you might
describe:
 - the notion of the thing that might be observed (blood CO2 level)
 - the procedure for measuring it (which might be complex) and everything
about that
 - the recording of the value of the thing that has been observed and any
confounding factors
 - the actual value of the thing observed.
The archetype actually records many of these things as well as the value. A
pure ontology for such a thing will get massively complex. Do we have the
procedure for measuring the confounding factors, the recording of the
procedures for measuring them, the actual value of these etc. If we are
measuring the blood gas there may be may features of the measuring process
that we want to record - do we have observable entities for all of these,
procedures for measuring them and recording and values.

I hope you can see where we are going here. We have to stay anchored in what
is useful and effective clinical practice. The fractal nature of this is
becoming clear and we will see just how fractal things get when we start
recording genetic features of cancers (and people).

I think we should start by working purely with term_bindings for the
observable entity that is expressed in the archetype - as a whole and then
for each entry in the data section of the observation if that is helpful.

I find this a very fruitful area of enquiry and I do not want to stifle it
at all - just to point out that what might appear imperfections often are
important kludges that are shared widely and work in real practice.

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-
> technical-bounces at chime.ucl.ac.uk] On Behalf Of Fabrice Camo

Archetypes and XML-Schemas

[Sam Heard]

Hi Leonardo

We are just about to produce a new XML schema for archetypes based on the new 
ADL 1.5 and getting rid of a lot of clutter for XML which was not required.

For example one change I have been promoting is the recording of existence. At 
present in the AOM it is an interval of 0..1 which can be constrained to 0..0 
and 1..1. It is worth considering this carefully as an example of how we could 
simplify the expression in XML just as Thomas does in ADL.

First, the rule is that the reference model sets the minimum constraint. This 
must be either 0..1 (optional) or 1..1 (mandatory) ie attributes in the 
reference model can be optional or mandatory (no other choices). If the 
attribute is mandatory then there is no logical existence constraint that can 
be applied. So the constraint statements in the AOM that are possible for 
optional attributes are:

1) 0..0 (prohibited) and
2) 1..1 (required).

This is a binary constraint. For this reason we are proposing that existence is 
represented as an optional attribute with 2 values 'required' and 'prohibited'. 
This is easy to read and can be transformed into the in memory interval easily 
during de-serialisation. It also means that existence will usually not appear 
in an actual archetype as it is rarely used.

It would be good to have other ideas on simplification of the XML schema as we 
move to the new 2.1 AOM.

Cheers, Sam
 

> -Original Message-
> From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-
> technical-bounces at chime.ucl.ac.uk] On Behalf Of Moretti Leonardo
> Sent: Wednesday, 12 May 2010 2:49 AM
> To: openehr-technical at openehr.org
> Subject: Archetypes and XML-Schemas
> 
> XMLSerializer.output() (xml-serializer-1.0.1.jar) produce XMLs that are
> not compliant with openEHR XML-Schemas
> (http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html).
> Also the xml representation taken from http://openehr.org/knowledge/
> are
> not valid XML instances respect to these schemas (for example
>  OBSERVATION.body_weight.v1.adl>
> openEHR-EHR-OBSERVATION.body_weight.v1
>  OBSERVATION.body_weight.v1.adl>).
> 
> The main problem is that the order of the elements is not equals to
> that
> one specified in  blocks of XSDs.
> 
> What is "wrong", the implementation or the schemas? The order of the
> elements in xml representation of an archetype must be fixed?
> 
> Thanks
> leo
> 
> --
> 
> Ing. Leonardo Moretti
> Senior Analyst
> 
> *NoemaLife S.p.A
> *Via Gobetti, 52
> 40129 Bologna ? ITALY
> T +39 051 4193911
> F +39 051 4193900
> lmoretti at noemalife.com 
> 
> www.noemalife.com 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CR for openEHR RM - Clusters and Data structures

[Sam Heard]

Dear All

 

As an involved clinician I have been thinking about advantages of using
inheritance to relate DATA_STRUCTURES and CLUSTER. This arises from two
things we have learned in clinical modelling:

1)  At almost every point where a DATA_STRUCTURE is currently specified
in the RM it would probably be inappropriate to model any structure other
than a ITEM_TREE. This is because any change to this will invalidate
existing data and we have learned that information models get more complex
with time. So the construct of DATA_STRUCTURE at the moment offers no real
value in return for the complexity it introduces as it stands at the moment.

2)  A ITEM_TABLE or ITEM_LIST 'constraint' can more usefully appear at
any point in the data - even forcing a ITEM_TREE is useful if you can see
that specialisation should always allow hierarchical structures.

 

I am suggesting that we change the model to have ITEM_STRUCTURE inherit from
CLUSTER. This would mean that ITEM_STRUCTUREs always behaved as clusters
(paths etc) but had added features. A ITEM_LIST then becomes a constraint on
a CLUSTER to only allow ELEMENTS. And ITEM_TABLE could now appear anywhere
in the data.

 

For backward compatibility it would mean that ITEM_SINGLE and its 'item'
attribute would have to be made obsolete. In fact an ITEM_LIST with
cardinality of 1 offers the same constraint capability. At the moment
ITEM_STRUCTURE and HISTORY inherit from DATA_STRUCTURE but I am not sure if
that confers any benefit as I do not think that DATA_STRUCTURE is present
anywhere in the model. Thomas may want to elucidate this aspect. It may mean
that we need a new interface with multiple inheritance in Eiffel if that is
important.

 

This does mean that openEHR is more closely aligned with CEN as well - that
is to say all data would be clusters with more attributes where ITEM_TABLE
was used and more features in software.

 

I am interested in the Techo's response to this idea.

 

Cheers, Sam

-- next part --
An HTML attachment was scrubbed...
URL: 

Archetypes and XML-Schemas

[Sam Heard]

Hi Andrew

This is not quite correct as we are talking about constraint. The default is
what is in the RM. The three states are:
1. As in the RM - no statement
2. Required (optional in RM)
3. Prohibited (optional in RM)

Is that sensible - Sam


> -Original Message-
> From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-
> technical-bounces at chime.ucl.ac.uk] On Behalf Of Andrew Patterson
> Sent: Wednesday, 12 May 2010 12:24 PM
> To: For openEHR technical discussions
> Cc: openehr-technical at openehr.org
> Subject: Re: Archetypes and XML-Schemas
> 
> > This is a binary constraint. For this reason we are proposing that
> existence
> > is represented as an optional attribute with 2 values
> > 'required' and 'prohibited'.
> 
> Sam, an optional attribute with 2 values actually allows 3
> states. Of course the default will map to one of the two
> values - but this does allow 2 ways of expressing the
> same concept.
> 
> My two preferences for this situation (representing
> binary constraints)
> 
> a) mandatory attribute with 2 values
> 
> - or -
> 
> b) an optional attribute with ONE possible value, and where
>the absence of the value is the default.
> 
> Andrew
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

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

[Sam Heard]

Hi All

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

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

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

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

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

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

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

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

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

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

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

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

Cheers, Sam





Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Erik Sundvall
> Sent: Thursday, 11 November 2010 3:26 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc
> and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
> 
> Hi!
> 
> On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
> > My simple reading of this is that what are currently trees would
> instead be
> > expressed as a sparsely populated arrays - is that the point?
> 
> Just to clarify it is has not already been clarified enough by others:
> Everything that is currently a tree in openEHR archetypes would most
> likely remain a tree. What would change is that the rarely used class
> ITEM_TABLE would no longer be needed. The data in an ITEM_TABLE
> already today is represented as a cluster internally.
> 
> So, no, what are currently trees won't become sparsely populated
> arrays.
> 
> Hope that helps.
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> 
> P.s. to Tom: those PAINFULLY_LONG_CLASSNAME_SUGGESTIONS were only
> intended to make a point, not as a final suggestion. openEHR probably
> does not need to change anything as long as the potential confusion is
> well described in specifications and presentations. (See the post
> http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html for
> details again.) If CEN/ISO still have problems with the names after
> such an explanation then one could assume that they will be the ones
> suggesting better alternati

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

[Sam Heard]

would then inherit directly from LOCATABLE. Are these
> assumptions about DATA_STRUCTURE correct or am I missing something?
> 
> One of the things left to discuss is the name of the new marker
> attribute in ITEM (or possibly CLUSTER), probably of type
> DV_CODED_TEXT and it's permissible valueset. I assume "list" and
> "table" are two permissible values at present. The default for a
> CLUSTER if the marker attribute is not used, could be to be
> interpreted as a tree. Using an ELEMENT by itself I presume would be
> the default way of expressing a what ITEM_SINGLE previously did.
> Another way is of course to always use the marker attribute and extend
> the set with "single" and "tree".
> 
> If we for some reason in the future would find the need to explicitly
> express other structures than single, list, tree and table, by
> allowing more marker values, then the change to the RM, querying,
> storage etc would be minimal, but GUIs would of course need change.
> 
> Many of the methods (not attributes) in the RM are of limited use in
> implementations or parts of implementations (e.g. storage & messaging)
> that are more data-centric that object-orientation-centric, so I think
> it's generally good if some of the helper methods like the ones in
> ITEM_TABLE can be moved out from the core to some optional
> utility-package instead (if the need for having them standardised
> remains). If looking outside the item_structure package this actually
> already seems to be the case - there are pretty few methods. Good.
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
> 
> P.s. Tim, I'd be interested how these changes suggestions, in your
> wiew, relate to "Keep everything as simple as possible; but no
> simpler." that you qoute on the philosophy part of
> http://www.oship.org/
> 
> On Thu, Nov 11, 2010 at 00:22, Sam Heard
>  wrote:
> > ...
> > 1. Restrict a cluster to a list; and
> > 2. Create a consistent representation of tables which have allow
> pivots as
> > this is the main form required for clinical data (row headings and
> column
> > headings).
> >
> > I believe that in the interests of existing data we made
> DATA_STRUCTURE
> > inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and
> > deprecate TREE and SINGLE. This would keep things moving ahead. The
> data
> > attribute would then be a cluster rather than an item_structure.
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Why is OpenEHR adoption so slow?

[Sam Heard]

Hi All

The adoption of all health standards is very slow; and it is universally so.
Government eHealth programs have embraced HL7v3 or CDA or openEHR or 13606 -
at great cost. Still things go slowly. The fact is that until people want a
shared logical model of the actual EHR (rather than a message or a document)
openEHR will not be centre stage.

Why have openEHR at the centre of a national program? There are a number of
reasons that are potentially persuasive.

1. The core platform as implemented does not describe clinical information.
This allows changes to clinical information to take place in the world of
archetypes (the 99% of standardisation that is yet to be carried out!). The
corollary is that only when there are enough high quality archetypes freely
available does the argument for this separation is compelling. There are
close to 300 archetypes of good quality now available and we are going to
see a rush of validation coming soon.

2. Adopting an EHR service allows applications to come and go without
losing/changing/adapting the health records. For patients, hospitals and
major providers this is a massive benefit - you can keep your health records
for a lifetime. It does, on the other hand, require enough high quality
applications to be available to provide solutions for providers. There is a
growing number - nursing, paediatric hospital, field hospital, infection
control, cancer research - but there is still some way to go.

3. The recording model in openEHR fits with the business process of
healthcare. A lot of things work out of the box from a medico-legal
perspective in a distributed environment. The coherent management of
workflow over a range of applications and services is the next step in this
process and the one that Ocean is concentrating on.

Even if the first argument is only accepted as a logical model for EHR
services, the tooling available now makes it possible to produce different
artefacts for different systems. On this basis people are becoming more
willing to invest resources in developing archetypes through open
collaboration on the internet. The second and third arguments are bringing
some institutions and software vendors along.

Seref is doing a wonderful job and Ocean has some experience in real
implementations to which Seref is party - so he does not make the same
mistakes! Where simplification is beneficial let's do it.

The reality is that openEHR proposes a massive shift in emphasis - from the
message to the EHR. More than 7000 vendors in the USA have invested in their
own data model - which they maintain. Until it is quicker, cheaper and
easier to build a system using openEHR, uptake will be slow. But I guarantee
you, the alternatives will get slower and more expensive by the day. That is
why we should continue: health information is highly complex AND 'you ain't
seen nothing yet'.

Cheers, Sam



> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Erik Sundvall
> Sent: Monday, 15 November 2010 11:29 PM
> To: For openEHR technical discussions
> Subject: Re: Why is OpenEHR adoption so slow?
> 
> Hi!
> 
> On Fri, Nov 5, 2010 at 10:03, Thomas Beale
>  wrote:
> > there are zero paid openEHR people, full-time or part-time.
> 
> That is not such a useful way of looking at openEHR funding. There are
> a lot of people working with openEHR on paid time during working
> hours. They are just not funded by the openEHR foundation. This
> situation is the same for many open source projects etc.
> 
> If you define "openEHR people" as people funded by the foundation you
> are automatically excluding most of the community from being "openEHR
> people". That might not be the smartest thing to do.
> 
> Too often I hear "openEHR needs funding" with the accompanying thought
> that the foundation itself needs a lot of money. Yes the foundation
> might need a little money for server & maintenance costs (if we don't
> want to use "free" services) and for trademark registrations etc. But
> the real need is working hours, not money.
> 
> Certain organisational behaviours make people and companies donate
> working time, while other behaviours do the opposite. Some behaviours
> get the time donations ending up within the original project, other
> behaviours result in related projects more using and indirectly
> contributing to the project via related but organisationally
> independent projects.
> 
> Many other volunteer organisations understand this difference better
> than what the openEHR foundation seems to do, at least judging from
> the few signals one can receive from the not-so-community-present
> foundation board that has nobody to formally answer to but themselves.
> In a volunteer project it can be quite OK with natural self appointed
> leaders, often the founders, but it then has to be matched with other
> attitudes or safeguards such as...
> - being very good at communicating and willing to ac

Could YAML replace dADL as human readable AOM serialization format?

[Sam Heard]

Hi All

 

I am going to say it once more:

 

If there is an expression on occurrences of '0..*' anywhere in ADL then it
is an error, for that is not a constraint - and can only be wrong (ie the RM
may have a narrower constraint). We just need a max int and a min int - both
optional.

 

I won't say it again - but it does keep it simple and it is correct!

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: Monday, 5 December 2011 8:40 AM
To: 'For openEHR technical discussions'
Subject: RE: Could YAML replace dADL as human readable AOM serialization
format?

 

I think previously I had indicated I had no problem with the stringified
interval approach in XML, but I am reverting my thinking on this and feel
that it would be counter intuitive for those who what to use the XML schemas
for code generation purposes.  I think in this case the computable
requirement outweighs the human readable requirement.  I think we can come
up with a much more concise representation of these intervals without
compromising the computable requirement, something similar to XML schema
maxOccurs/minOccurs.

 

Heath

 

please everyone remember that the dADL, JSON and XML generated from AWB all
currently use the stringified expression of cardinality / occurrences /
existence. Now, these are usually the most numerous constraints in an
archetype and if expressed in the orthodox way, take up 6 lines of text,
hence the giant files (e.g. AOM 1.4 based XML we currently use) - and thus
the much reduced files you see on Erik's page, because we are using ADL 1.5
flavoured serialisations not the ADL 1.4 one.

Now, I think we should probably go with the stringified form in all of these
formalisms. The cost of doing this is a small micro-parser, but it is the
same microparser for everyone, which seems attractive to me.

The alternative that Erik mentioned was more native, but still efficient
interval expressions, e.g. dADL has it built in (0..* is |>=0| in dADL), and
YAML and JSON could probably be persuaded to make some sort of array of
integer-like things be used. XML still doesn't have any such support. In
theory this approach would be the best if each syntax supported it properly,
but XML doesn't at all, and the others don't support Intervals with
unbounded upper limit (i.e. the '*' in '0..*'). 

But Erik's exercise certainly proved that efficient representation of the
humble Interval  is actually worthwhile. (Once again thanks for
that page, its quite a good way to get a good feel for these syntaxes very
quickly).

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Questions about the relationship between Instruction, workflow and Action

[Sam Heard]

Hi Pablo,

 

The design principles are that the Instruction should remain unaltered by
people basing actions on this instructions ? as the action and instructions
could be disconnected at any moment. For example, the instruction
(medication order) should not be changed by anyone just to give a medication
etc.

 

So the state of the instruction is carried in the record of the action (if
appropriate). We have decided to name the pathway steps and attach a machine
readable state to that step. This makes it much easier for clinicians to
model and to see what is going on.

 

In our openEHR repository we maintain an instruction index ? that is a
pointer to all instructions and all actions that relate to that instruction
? and the current state of the instruction. 

 

You will see an archetype ACTION in the openEHR repository and the
careflow_steps are archetyped to provide a name and the current state
matches an openEHR code for state. This means that a careflow step being
carried out will set the state to a particular machine state.

 

Hope this helps.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 7 December 2011 9:19 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

Nobody? :'(

Maybe is better just one question at a time, sorry for that.

  _  

From: pazospa...@hotmail.com
To: openehr-clinical at openehr.org; openehr-technical at openehr.org
Subject: Questions about the relationship between Instruction, workflow and
Action
Date: Sun, 4 Dec 2011 15:36:36 -0300

Hi everyone!

 

I'm trying to understand how to execute a state machine of a fully
structured INSTRUCTION, and I have some questions and thoughts to share with
you...

 

 

The first issue is about archetyping an ACTION that execute and ACTIVITY of
an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype
the ACTION.ism_transition attribute, but not the ACTION.instruction_details.
Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are
specializations of PATHABLE, so those shouldn't be archetypable (see
http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).

Is this a bug in the AE or is an issue in the specs?

 

 

If the "ACTION.instruction_details" attribute can't be archetyped in the AE,
how could I know what specific structure the
"ACTION.instruction_details.wf_details" attribute will have?

 

 

Is the "ACTION.instruction_details.wf_details" attribute related somehow
with the "ACTIVITY.description" attribute?

 

 

The description of the "ACTION.instruction_details.wf_details" attribute
says: condition that fired to cause this Action to be done (with actual
variables substituted),

What is the meaning of "with actual variables substituted"? This makes me
think having an ACTIVITY in memory, creating an instance of an ACTION to
record the execution of that ACTIVITY, copying the ACTIVITY.description
structure into the ACTION.instruction_details.wf_details, and the update the
correspondent fields into the wf_details with actual execution data.

 

Does this make any sense? or I'm just to twisted :D

 

 

 

The last one!

Now only ACTIONs can change a state on the ISM, but I think an ADMIN_ESTRY
could change the state also, e.g. to move a "planned procedure" to the
"scheduled" state, there is an administrative step of coordinating date &
time, not a clinical action. Again, does this make any sense?!

 

 

 

Thanks a lot!


-- 
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: 

13606 revisited - list proposal

[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 

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 t

Representing binary values with DV_BOOLEAN

[Sam Heard]

Hi

 

The issue needs to be discussed first in the modelling of the archetype. If
a Boolean is accepted at this level then that is what it is (for the moment)
and how that is displayed on the screen then becomes an issue. I agree that
positive/negative != True/False. 'Test Positive' could have a true/false as
in Test result abnormal in HL7 lab tests.

 

Fabiane's idea that a Boolean defaults to false seems to be an
implementation issue - it is possible to have a tri-state Y/N/Null widget to
cope with the null.

 

This is a worthwhile discussion. 

 

Cheers, Sam

 

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Koray Atalag
Sent: Wednesday, 2 February 2011 12:40 PM
To: For openEHR technical discussions
Subject: Representing binary values with DV_BOOLEAN

 

Hi All, I'd like to get feedback on this issue before we move on with
implementing.

 

In short whether we should use DV_BOOLEAN to represent the result of a Lab
test as Positive/Negative. This particular test can have only two values
(well plus the null case of course). I suspect this wasn't the purpose of
this data type in the first place and was for really no-brainer yes/no items
as you would expect in any computer program. But, as ever, clinical medicine
is wicked and makes me think out of the 'usual' good practice and explore
whether this might be an option.Perhaps this discussion will provide
guidance for others in the community as well. 

 

Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all
occurrences of Boolean will have labels as Yes/No.It can also be True/False,
Present/Absent, Positive/Negative etc. Moreover in difference language
translations they will surely be different. But in ADL no at code is given
for this data type; Yes and No is written implicitly within the definition
section. This means that we cannot set the Text in ontology section and then
have language translations. Has anyone come across such a requirement? If so
what's your solution.

 

Note that I currently model all such data items with DV_CODED_TEXT and had
no problems. But when I wanted to render radio buttons for Yes/No type items
instead of default combobox widget I either need a GUI directive (which we
try to avoid if possible) or set the data type to DV_BOOLEAN so that the
default widget would be radio button and we can use accordingly. 

 

 

Cheers,

 

-koray

 

-- next part --
An HTML attachment was scrubbed...
URL: 

Clinical Documents, openEHR, 13606, CDA and CCR

[Sam Heard]

 already captured in the openEHR
RM. The transformation may require renaming of openEHR RM attributes that
are specific for that the template as CDA documents may have different
labels that are the same thing in an EHR system (e.g. a prescription may
have a 'prescriber' whereas a document may have an 'author' where both are
the legal creator of the document).

2.  An archetype to CDA transform (and back) that labels the CDA data in
a way that it is clear which archetype this CDA data conforms to. This is
needed for each archetype and should be available on CKM.

 

The openEHR RM should also consider adding a CLUSTER to participation to
allow structured data or include participation data in the composition.
Other_participations may be the location for this with IDs that are
referenced within the composition - but this is not the planned use and will
need some consideration. Some may argue that this should be from the
demographic model but I do not think so.

 

Thoughts?

 

Cheers, Sam Heard

 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110105/9787b9ca/attachment.html>

Issue with class PARTICIPATION. Should it be Locatable or Pathable?

[Sam Heard]

Hi Justinas,

 

My clinical input..

 

You are showing an impressive level of knowledge here and have hit an area
where there is still debate. There are a number of requirements:

1.  I think want to maintain the ability to add participations that are
not archetyped. It is clear that systems, wards, clinics etc will want to do
this on an ad hoc basis and formalising participations too much will not be
possible in advance.

2.  Participations have a link to a demographic entity and limited
structure beyond that. Users want a pretty simple way to say that Dr John
Brown was the assistant surgeon and Dr Karl Mitten was the Anaesthetist (or
the like). The tagged PARTY_IDENTIFIED is probably enough but the ID is
contentious. Should this be the national doctor ID? Or the ID used for this
person with the details stored elsewhere in the composition (or extract).
This needs more thought.

3.  Highly structured participations probably need to be archetyped in
the CONTEXT to ensure that you have what you need. We have used the
demographic clusters for this purpose (as they can be shared across the two
models).

 

I am keen to allow multiple instances of a node without a unique name as
these names are for the GUI and get problematic. We are moving to this
approach as it does mean that events do not need a name (they have a time
after all) and simplifies things a good deal. It does require position in
the query syntax.

 

It will be good to hear from the technologists what they see as the
solution.

 

Cheers, Sam

 

 

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Justinas
Prelgauskas
Sent: Saturday, 8 January 2011 12:00 AM
To: openehr-technical at openehr.org
Subject: Issue with class PARTICIPATION. Should it be Locatable or Pathable?

 

Hello,

 

We are having some problems with Reference Model class PARTICIPATION.

We want to define an archetype of COMPOSITION type and state, that it could
have two types of participants: Doctors and Patients; At least one Doctor
and one Patient participant must be specified.

 

After we create an archetype (we use Ocean Archetype Editor v2.2) and
constrain PARTICIPATION.function using "at0007" = Doctor & "at0008" =
Person, we get following XML (I removed all unnecessary elements):

 



  participations

  

PARTICIPATION





  function

  

DV_CODED_TEXT





  defining_code

  

CODE_PHRASE





  local



at0007

  



  



  

  

PARTICIPATION





  function

  

DV_CODED_TEXT





  defining_code

  

CODE_PHRASE





  local



at0008

  



  



  

  

false

false



  true

  false

  true

  0



  



 

The problem with this archetype is this:

There is no "node_id" specified on neither of PARTICIPATION alternatives
(C_COMPLEX_OBJECTs).

Furthermore, in AOM 1.5 specification, C_MULTIPLE_ATTRIBUTE class
description (page 39) is validation rule, that sounds like this:

<...>VACMI: child node identification: any object node added as a child to a
container

attribute must have a node identifier.<...>

And this rule is being violated.

 

My questions are:

1) How would we query & bind those constraints with data if we do not have
node_id neither on constraint nor on data?

2) How would we validate invariant "VACMI" on this C_MULTIPLE_ATTRIBUTE
node?

 

My suggestions for fixing this issue would be:

1) Derive PARTICIPATION class from "Locatable" or "Pathable" so that data
could be attributed with node_id.

2) Get rid of validation rule "VACMI" (this does not solve data <--->
constraint binding issue);

3) Any other suggestions?

 

 

Regards,

Justinas Prelgauskas,

PhD student at Kaunas University of Technology

-- next part --
An HTML attachment was scrubbed...
URL: 

Use of Identifiers in archetypes

[Sam Heard]

Hi

There have been a few issues with DV_IDENTIFIER - largely that all fields
are mandatory. This may mean that users puts stuff in that is not helpful.
There is also no known set of things to use at any point although this could
be expressed in a template (or archetype although this would not be
appropriate).

There is a WORKFLOW_ID on every entry that Ocean have been using to link
data around a particular workflow - this is the PLACER_ID in HL7 v2. It
allows observations, actions etc to be related to a particular instruction.

This is working well and keeps things relatively simple. Feeder_audit is a
great way to find information about feeder systems and is present in 13606
as well. It is not in the archetype (constrained) but should be visible soon
in CKM.

I would also suggest that we allow people to use the HL7/ISO datatype names
for the models to aid use and familiarity. It will be a diminished set
(openEHR compatible) but should meet all the needs of the modellers.

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Ian McNicoll
> Sent: Wednesday, 19 January 2011 8:32 AM
> To: For openEHR technical discussions
> Subject: Re: Use of Identifiers in archetypes
> 
> Hi Grahame,
> 
> The concern about FEEDER_AUDIT related to its use in outgoing service
> requests e.g.  within referrals / lab requests etc. This is
> technically possible but against the intentions within the
> specifications as Thomas suggested in his eralier reply. Personally I
> would be happy to see the specifications change to allow FEEDER_AUDIT
> used in this way.
> 
> Ian
> 
> Dr Ian McNicoll
> office +44 (0)1536 414994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
> 
> Clinical analyst,?Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care ?www.phcsg.org
> 
> 
> 
> 
> On 18 January 2011 20:30, Grahame Grieve 
> wrote:
> > Hi Peter, Tom
> >
> > thanks
> >
> >> Just take care to use FEEDER_AUDIT for ids generated in external
> systems,
> >> rather than assigned within the openEHR system, including by users
> of apps
> >> talking directly to the openEHR system.
> >
> > I'm not sure which way to parse that sentence
> >
> > Generally, about FEEDER_AUDIT, it's something I had missed, so I'll
> go
> > and review it, but how does it manifest in the archetype editor?
> >
> > Ian:
> >
> >> Using FEEDER_AUDIT was actually discussed as part of deciding how
> best
> >> to handle Placer and Filler Order numbers in lab tests etc . The
> >> problem we have is that we also need to add these identifiers to
> >> outgoing order /referral messages (and track those within the EHR),
> >> and FEEDER_AUDIT was deemed unsuitable for this purpose.
> >
> > because the identifiers weren't explicitly identified? Can you say
> why it
> > was deemed unsuitable?
> >
> > thanks
> > Grahame
> > ___
> > 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

AQL VersionedObject Grammar

[Sam Heard]

Wow
You are hot!
Sam

Sent from my phone

On 19/07/2011, at 4:37 PM, Ian McNicoll  
wrote:

> Hi Mahdi,
> 
> SELECT  v/commit_audit/committer/name,
> v/commit_audit/time_committed/value, v/data/uid, v/data/time_created,
> c
> FROM EHR e [ehr_id/value = 'ecfe6e6e-8868-4fc6-8db8-def71cb8a250']
> CONTAINS VERSION v
> CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1]
> 
> should return commit _audit and versioned_object attributes for all
> Encounter compositions.
> 
> Ian
> 
> 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
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care  www.phcsg.org
> 
> 
> 
> 
> On 19 July 2011 06:50,   wrote:
>> Hi dear All
>> 
>> I confuse to make a AQL query using versioned_object or Version,
>> 
>> Does anyone know some example of using versioned_object and version?
>> 
>> 
>> 
>> Thanks in advance
>> 
>> 
>> 
>> Mahdi Asgari
>> 
>> 
>> 
>> Naji Research and Development
>> 
>> EHR Technical Manager
>> 
>> 
>> 
>> Gmail:mahdi.asgari at gmail.com
>> 
>> Y! Messenger: mahdiiran
>> 
>> ooVoo: mahdi.asgari
>> 
>> 
>> 
>> ___
>> 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 Digest, Vol 49, Issue 12

[Sam Heard]

Mahdi

The ID needs to be the archetypeID not the archetype-node-ID if it is the
root node of an archetype.

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of mahdi.asgari at gmail.com
> Sent: Saturday, 30 April 2011 6:02 PM
> To: openehr-technical at openehr.org
> Subject: RE: openEHR-technical Digest, Vol 49, Issue 12
> 
> Hi dear Ian
> 
> According to openEHR-technical Digest, Vol 49, Issue 12 you saied two
> bellow
> statement are correct (in scope of ADL 1.4):
> 
> 1-The archetype-node-id in a locatable constructed around an
> archetype
> in an archetypeslot is the archetype-node-id it gets from its own
> archetype
> (which is called in the slot).
> 2-The archetype-node-id in a locatable constructed around the
> archetype calling the archetypeslot is to be ignored.
> 
> I have a validation problem:
> If the archetype-node-id in a locatable constructed around an archetype
> in
> an archetypeslot is the archetype-node-id it gets from its own
> archetype,
> means at(child archetype node id) instead of at0001(slot node id)
> so how
> can I apply occurrence of slot? for example
> 
> Entry[at] matches {-- Encounter
> content matches {
> allow_archetype INSTRUCTION [at0001] occurrences matches
> {0..1}
> matches {
> include
> domain_concept matches {/instruction.v1/}
> }
> allow_archetype OBSERVATION [at0002] occurrences matches
> {1..1}
> matches {
> include
> domain_concept matches {/observation.v1/}
> }
> }
> }
> 
> the object may be something like this:
>  archetype_node_id="at">
> .
>  
>  archetype_node_id="at">
> .
>  
> 
> In the above example how I can apply occurrence for INSTRUCTION objects
> optional or just one occurrence and OBSERVATION only one occurrence
> must be
> appear.
> Or maybe we must bypass constraint defined on slots?
> What is the main constraint applied? Slot constraint or child archetype
> constraint?
> 
> Thanks in advance
> 
> 
> 
> -Original Message-
> From: openehr-technical-bounces at openehr.org
> [mailto:openehr-technical-bounces at openehr.org] On Behalf Of
> openehr-technical-request at openehr.org
> Sent: Monday, August 23, 2010 5:05 PM
> To: openehr-technical at openehr.org
> Subject: openEHR-technical Digest, Vol 49, Issue 12
> 
> Send openEHR-technical mailing list submissions to
>   openehr-technical at openehr.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> or, via email, send a message with subject or body 'help' to
>   openehr-technical-request at openehr.org
> 
> You can reach the person managing the list at
>   openehr-technical-owner at openehr.org
> 
> When replying, please edit your Subject line so it is more specific
> than
> "Re: Contents of openEHR-technical digest..."
> 
> 
> Today's Topics:
> 
>1. Re: ArchetypeNodeId of an archetypeslot (Ian McNicoll)
>2. Re: ArchetypeNodeId of an archetypeslot (Bert Verhees)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 23 Aug 2010 13:19:09 +0100
> From: Ian McNicoll 
> Subject: Re: ArchetypeNodeId of an archetypeslot
> To: For openEHR technical discussions 
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Bert,
> 
> I appreciate you will be currently using ADL1.4, but in essence, by
> aggregating archetypes as you suggest, you are creating a template. ADL
> 1.4
> does not define this aggregation/template behaviour, which is why I
> pointed
> you to the ADL1.5 specs, which cover both the templates and specialised
> archetypes. We, therefore do not have an official ADL1.4 answer to your
> question but your final statement is correct :
> 
> The archetype-node-id in a locatable constructed around an archetype in
> an
> archetypeslot is the archetype-node-id it gets from its own archetype
> (which
> is called in the slot).
> The archetype-node-id in a locatable constructed around the archetype
> calling the archetypeslot is to be ignored.
> 
> Also remember that there is no absolute requirement for a single slot
> to
> have an atnode name but Heather and I now pretty well always assign one
> routinely as it helps document the usage of the slot for downstream
> users.
> 
> 
> Ian
> 
> Dr Ian McNicoll
> office / fax  +44(0)141 560 4657
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
> ian at mcmi.co.uk
> 
> Clinical Analyst  Ocean Informatics
> Honorary Senior Research Associate, CHIME, University College London
> openEHR
> Archetype Editorial Group Member BCS Primary Health Care SG Group
> www.phcsg.org / BCS Health

occurrences and cardinality in ADL, XML, JSON

[Sam Heard]

Hi All

As ADL only states constraints there is no logical reason to include unbounded. 
So no constraint expressed  = RM max. This is likely to be one or unbounded.


Sent from my phone

On 11/11/2011, at 5:11 AM, Thomas Beale  
wrote:

> 
> In the current ADL 1.4-based XSDs used in openEHR, occurrences, cardinality 
> and existence are expressed as XML elements. We will want to improve this for 
> ADL 1.5 based XML. Now, we don't want to only take care of XML; we also need 
> to make it work for JSON, and (internally) for dADL - neither of the latter 
> have XML's 'attributes'. Many people have asked for more efficient ways of 
> serialising. Here are some ideas for ADL 1.5 XML, JSON etc.
> 
> ~~ first question: occurrences and cardinality  
> Occurrences and cardinality  are proper intervals in the AOM representation. 
> The most simplified object structure (JSON and dADL) for occurrences and 
> cardinality could look as follows (I use dADL & occurrences here):
> 
> occurrences = <
> lower = <2> -- Integer field
> upper = <10> -- Integer field
> >
> 
> but the upper limit is commonly unbounded, i.e. '*' in typical UML-like 
> syntax. We could do:
> 
> occurrences = <
> lower = <2> -- Integer field
> upper_bounded =  -- Boolean field
Sam: no need for this.
> >
> 
> meaning that 3 possible attributes could occur for an occurrences, but only 
> ever 2 at the same time. Or we could make everything into a string:
> 
> occurrences = <
> lower = <"2"> -- String field
> upper = <"*"> -- String field
> >
Sam: no need for this
> 
> The upside is that the 'upper' attribute now handles both bounded and 
> unbounded values. The downside is that the JSON / dADL parsers would have to 
> do a bit more work to generate the required Interval object - since 
> the 'upper' attribute now has to be treated as a little fragment of syntax 
> and checked before being turned into an Integer. 
> 
> If we were just doing JSON, dADL and other 'proper' OO syntaxes, the first 
> one would be the obvious one. But since we are also targetting XML, we have 
> to think whether it makes more sense to do:
> 
> occurrences_upper="10"> -- xsi:type=C_OBJECT
>CLUSTER
>  
> and
> 
> occurrences_unbounded="true"> -- xs:boolean has to support 0/1 and true/false
>CLUSTER
>  
> which is the analog of the first approach above, or it could be:
> 
> occurrences_upper="10">
>CLUSTER
>  
> and
> 
>
>CLUSTER
> 
> with both attributes defined in the XSD as xs:string. This means that like 
> for JSON/dADL, the XML standard parser only generates strings, and somehting 
> further has to be done to obtain a proper Interval object. 
> 
> My preference is still to go with the first way of doing things. Do others 
> agree with this? If so, it is what I will implement in the ADL 1.5 workbench. 
> 
> ~ second question:existence 
> Existence as an interval can be 0..0 (prohibited, commonly used in 
> templates), 0..1 (optional, typical in the RM) and 1..1 (used in templates 
> and sometimes in archetypes). Now, since archetypes and templates are 
> constraint structures, they can only further constrain the RM in ADL/AOM 1.5. 
> The only possibilities for this are actually "0..0" and "1..1", so we could 
> collapse existence onto a single Boolean for serialised representation (it 
> could also be a single Boolean in the AOM, but that would be a breaking 
> change, and since we already use Intervals for occurrences and cardinality, 
> it does not seem worth the trouble). 
> 
> Thus in JSON/dADL it could be:
> 
> some_attr = <
> existence = 
> >
> 
> In XML:
> 
> 
>
> 
> 
> Now, this is cheating a bit because we are making it look like there is an 
> AOM property 'existence' of type Boolean, but there isn't. Should it be named 
> something else to make this clear? I.e. a pseudo attribute that only exists 
> in serialised format but not in AOM internal format, e.g. 
> 'existence_constraint'? I would favour this. In my current implementation, 
> the serialised format actually has its own object model, and this would have 
> to be true for JSON as well. I think it also makes sense in XML - that there 
> will be a level of classes corresponding to the space-efficient serial form, 
> which are not the same as the internal AOM classes.
> 
> thoughts?

Agree, it could be 0 or 1
> 
> - 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: 

Questions about the necessity of ITEM_SINGLE

[Sam Heard]

Hi Eric,

The serialisation in XML Schema should provide the basis for transformation
I would have thought. If there is a standard transformation then we can
share data based on a previous reference model.

Is that sensible?

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Erik Sundvall
> Sent: Wednesday, 5 October 2011 6:58 PM
> To: For openEHR clinical discussions; For openEHR technical discussions
> Subject: Re: Questions about the necessity of ITEM_SINGLE
> 
> Hi!
> 
> Perhaps the following image with UML redesign useful as input for a
> 2.0 development fork:
> http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
> The accompanying mail describing it is at
> http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
> 
> I have right now submitted parts of that mail as a formal change
> request at:
> http://www.openehr.org/issues/browse/SPECPR-73
> Feel free to add all your own thoughts from this discussion to that
> issue.
> 
> The argument that there are systems with 1.X data is of course valid
> for refreshing 1.X one more time, but a 2.X version of the RM should
> not wait too long since we'd like to have as much as possible of
> future patient data to be in 2.X form.
> 
> Does anybody have an approximate number indicating how many patient
> records are now in 1.X systems? Do you believe those system owners
> with real patient data could be able to convert data to a 2.X based
> systems, I guess there aren't too many vendors involved...
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
> 
> P.s. There was no way of specifying in jira that it could relate to a
> 2.0 release
> 
> On Tue, Oct 4, 2011 at 10:32, Thomas Beale
>  wrote:
> > On 03/10/2011 15:23, pablo pazos wrote:
> >
> > Hi everyone,
> >
> > I've been studying how to simplify the ITEM_STRUCTURE model to
> enhance the
> > persistence performance of our Open EHR-Gen project
> > (http://code.google.com/p/open-ehr-gen-framework).
> >
> > Now I'm reaching a point in which I doubt about the necessity of
> ITEM_SINGLE
> > in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> > arguments and hear your comments about it.
> >
> > Semantic argument: As I understand ITEM_SINGLE, the semantics of this
> class
> > are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I
> mean
> > that: the semantics of ITEM_SINGLE is just a matter of cardinality
> (=1).
> >
> > Practical argument: in practice, an ITEM_SINGLE is like using an
> ELEMENT as
> > an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> > interface of each class can be the same, like: getItems(),
> setItems(), the
> > ITEM_SINGLE breaks that with getItem() and setItem().
> >
> > if you have a look at the RM specification for ITEM_STRUCTURE (p13-),
> you
> > will see that the interfaces are quite different across all the
> classes -
> > the ITEM_TABLE type has table-specific accessor functions, and the
> LIST type
> > has an interface specific to a list. But... see below...
> >
> >
> > Evolution argument: If I have an archetype with an ITEM_SINGLE, but
> the
> > concept modeled with this archetype needs to change adding more nodes
> to the
> > archetype, I need to change the ITEM_SINGLE to another
> ITEM_STRUCTURE, but
> > if the archetype is modeled with an ITEM_TREE, I can add any nodes
> without
> > changing the ITEM_STRUCTURE type. I think this way is more simple to
> create
> > new archetypes with backwards compatibility.
> >
> >
> > What do you think?
> >
> > this seems to be the conclusion of people creating archetypes as
> well. It
> > has turned out over the years that archetype modellers are far less
> able to
> > stick to any particular data structure than one might have thought. I
> don't
> > think the statically declared RM type is the main issue in archetype
> > authoring - it is the archetype paths that really matter... but if
> neither
> > were to change over time, that certainly makes things easier. The two
> data
> > types we thought would be used quite often were ITEM_LIST and
> ITEM_TABLE. It
> > appears that these types have been used pretty rarely, although that
> might
> > just reflect which parts of medicine have been modelled.
> >
> > Sam and no doubt others have proposed simplifications to the
> ITEM_STRUCTURE
> > part of the model, and I would have no problem with simplifying it.
> > However there are already openEHR operational systems in
> existence and a
> > lot of tools and archetypes, so we can't simply make breaking changes
> to the
> > release 1.x reference model - and - ITEM_STRUCTURE appears in a lot
> of
> > places in the model. I have not made a proper analysis, but a general
> > approach to simplifying things would probably involve adding an
> attribute to
> > ITEM_STRUCTURE to indicate which kind of logical structure it was
> mean

openEHR Archetypes Development

[Sam Heard]

Hi Laura

 

Thanks for the link. I am finding it very difficult to make head or tail of
the pages and what it all means.

The pages appear to have a very basic 13606 element at the top and then a
heap of references including self references.

 

Can you help at all?

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sato Laura (NHS
CONNECTING FOR HEALTH)
Sent: Friday, 7 October 2011 11:34 PM
To: For openEHR technical discussions
Subject: RE: openEHR Archetypes Development

 

In part in (a slow!) response to the discussion below, I'm pleased to invite
comments on the current draft detailed content models (based on 13606 and
using the SNOMED CT concept model) for Discharge Summary, now accessible at
https://svn.connectingforhealth.nhs.uk/svn/public/lra/PUB/discharge/content/
index.html.  (Apologies for the certificate warning that you'll be
confronted with at first.)

 

For some background info, this work is still relatively rough - it's an
interim draft release that shows our first attempt to publish a full suite
of detailed requirements, technical models and instance examples for record
content.  We're aware of a few inconsistencies and gaps in the end-to-end
flow, but I'd still welcome any comments you might have time to send us ...
I'm hoping that we'll release the next draft (based on comments received in
the next few weeks) in November.

 

Best wishes,

Laura

 



Laura Sato

Head, Logical Record Architecture

 

Department of Health Informatics Directorate

Technology Office, NHS Connecting for Health

 

email: laura.sato at nhs.net

mobile: (44) (0)7733 324 338

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Eunice Ab
Sent: 03 June 2011 12:18
To: For openEHR technical discussions
Subject: Re: openEHR Archetypes Development

 

Dear Laura, Ian

 

Many thanks for your emails. They have been so helpful .

 

Laura, I am going to take up the offer of contacting you to get to know more
about the 'central activities'. I will be in touch soon.

 

Ian, I totally agree that most of the work done on data standards is
currently been hidden away behind the N3 firewall or through trud. We need
more accessible mechanisms for this work expecially for those that actually
need to use these standards locally.

 

Hopefully this will be taken into consideration in current and future work.

 

Thanks again.

 

Best regards

 

Eunice

 

On 3 June 2011 10:44, Ian McNicoll 
wrote:

Thanks Laura,

That is very helpful clarification. It is unfortunate that much of the
interesting work being done in the English NHS is 'hidden away' either
with the TRUD mechanism or in the case of the Clinical Data Standards
work, behind the N3 firewall. I know steps are being taken to address
these issues but it does present a significant barrier for those
outside the NHS.

Regards,


Ian

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

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org  




On 3 June 2011 10:28, Sato Laura (NHS CONNECTING FOR HEALTH)

 wrote:
> Dear Eunice,
>
>
>
> For info, although NHS Data Standards & Products has worked with openEHR
> archetypes in the past, we are currently working on developing care record
> content models that use the EN/ISO 13606 reference model and ISO 21090
data
> types (both with a relationship to, but not exactly the same as, openEHR's
> technical infrastructure), alongside a modelling approach that seeks to
make
> as much use as possible of the SNOMED CT clinical concept hierarchy, as
well
> as re-usable ELEMENT models and terminology constraints.  Do please feel
> free to get in touch with me, if you'd like more information about current
> NHS 'central' activities in this area.
>
>
>
> We also continue communications with Thomas and Ian (and others) to
maintain
> links with the openEHR community, and hopefully will be able to provide a
> clearer picture of how NHS content and openEHR archetypes fit together in
> the coming months.
>
>
>
> Best regards,
>
> Laura
>
>
>
> 
>
> Laura Sato
>
> Head, Logical Record Architecture
>
>
>
> Department of Health Informatics Directorate
>
> Technology Office, NHS Connecting for Health
>
>
>
> email: laura.sato at nhs.net
>
> mobile: (44) (0)7733 324 338
>
>
>
>
>
>
>
>
>
> From: openehr-technical-bounces at openehr.org
> [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Eunice Ab
> Sent: 19 May 2011 18:22
> To: For openEHR technical discussions
> Subject: Re: openEHR Archetypes Devel

openEHR course in spanish

[Sam Heard]

Hi Pablo

This looks excellent. There is some repetition but it is clear that you are
providing an overview in the first classes and drilling down in later
classes. I would suggest that you might actually introduce some of the tools
a little earlier as people will have more fun if they can build or edit some
models.

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 18 October 2011 7:36 AM
To: openehr clinical; openehr technical; openehr implementers2
Subject: openEHR course in spanish

 

Hi,

 

I'm trying to impart a course on openEHR for spanish speakers audiences,
here is the agenda for the course:
http://informatica-medica.blogspot.com/2011/10/curso-de-openehr-en-espanol.h
tml

 

Please click on the "ENGLISH" link on the top-right corner to translate the
page.

 

This are my 2 cents in spreading openEHR in the latin-american medical
informatics communities.

 

It would be nice to have the feedback of the openEHR community on the topics
of the course. Any comments, sugestions, references, resources, etc, are
very welcome!

-- 
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: 

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Erik

 

Plans seem to take some promising directions even though that whitepaper
at...

http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentDa
ta/data/openEHR%20Foundation%20moving%20forward.pdf

...still needs some serious editing in order to better strengthen trust in
openEHRs future.

 

[Sam Heard] Getting the balance of top down governance and sponsorship and
bottom up participation and 'ownership' is difficult and we have worked hard
to get it right. This paper is seeking to set the scene and morph into one
or more clear statements of intent. 


1. First a procedural question:
Was that whitepaper formally ratified by the new board, or by the old board,
or is it's current state just a suggestion by Sam? 

[Sam Heard] The whitepaper was ratified by the participants in the planning
process, the current Board (Profs. Kalra, Ingram and myself) and the new
Transitional Board.

I know for sure that some people in the acknowledgements...

> Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale,
> Martin van der Meer and Tony Shannon for assisting in the planning.

...would likely object to part of it's current content.

[Sam Heard] It is obvious that there will be parts of the document that are
not considered ideal by all the participants in its development. These have
been thrashed out and we have presented the best first cut.

2. A second procedural question:
What is the mandate period of the transitional board? When will the
suggested new structure with an elected board start? That date seems to be
missing in the mail and in the document, but having an end date is very
likely important for building trust in any kind of stated interim governance
system (ask the people in the middle east and northern Africa...).

[Sam Heard] I for one am very happy to express a date for elections if
organisations embrace these arrangements. Clearly if there is no interest in
participating from industry or organisations then we would have to think
again. I suspect we will then move to election of the Board by Members but
it is our wish to provide a means of determining the governance for
openEHR's key sponsors. The aim is to balance the Members with governance
from the funders and sponsors. Some may prefer a democratic organisation top
to bottom; we do not think this will achieve the best results.

I am interested in the views of Members.

3. A document content change suggestion:
Remove the CC-BY-SA part in the licencing discussion (page 5) since it makes
the document authors and anybody ratifying it look incompetent. Saying that
original things are CC-BY and that derivative models should be CC-BY-SA is
just plain stupid. Then the originals are NOT CC-BY. It's just as silly as
saying that a piece of open source code is licenced under Apache II licence
but that any derivative code must be licenced under GPL... 

[Sam Heard] The point you are making I think refers to:

---

Clinical Models

Archetypes, Templates and Terminology subsets developed by the community

Creative Commons for organisational and individual use. CC-BY-(SA) The Share
Alike (SA) is specifically applied to derived archetypes and templates only.

---

[Sam Heard] The text may not be sufficiently clear but the intent is.  We
are drawing attention to the fact that the intent is that the SA part of the
license is only applied to derived archetypes and templates. That is, it is
a CC-BY-SA license with specific exclusion of all derivations except
archetypes and templates. This means that anyone creating a template from
archetypes cannot claim that they own it and no one else can use or copy it.
They can keep it secret. I apologise if this is not clear.

The thoughts behind the third point in the "Principles of licencing" are
understandable, but as stated over and over again, e.g. at...

http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Propos
al?focusedCommentId=13041696#comment-13041696 

...the SA part of CC-BY-SA won't help against copyright and patent abuse.
Only fighting possible upcoming bad patents in particular and bad patent
laws in general might save the openEHR community form patent abuse.

[Sam Heard] If this is true then the SA part of the license has no value. If
this is true then I have not heard this before.

 

A more practical way is to enforce good licencing (e.g. CC-BY) upon import
of archetypes and archetyped data in real systems and tools. That will at
the same time protect against anybody sneaking in badly licenced stuff that
is not derived from openEHR original archetypes (something that a CC-BY-SA
scheme never will be able to protect against.) 

[Sam Heard] The intent is not to stop the use of any archetypes whatsoever,
for any purpose. It is not policing. Rather , the intent is to ensure that
people cannot stop anyone using an archetype or template without any
recourse to action by others.

 

There are many other interesti

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Diego

[Sam Heard]  This would be a step forward and would allow for slim and fat
systems to offer the same basic calls.

> > My suggestion is for the this point
> "Begin an open source software project for tools, web-based if
> possible, to author archetypes, templates and terminology reference
> sets directly interacting with the Clinical Knowledge Manager and
> equivalent repository and review tools"
> 
> I agree with the first part (create web-based open source tools), but
> I think that the second part should be clarified. We should define a
> basic API to access repositories, to avoid doing ad-hoc
> implementations for each one of the possible repositories

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Pablo ? this is very helpful.

Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 6 September 2011 8:42 AM
To: openehr technical
Subject: RE: openEHR Transition: two procedural and one licensing question

 

Hi,

I think Diego's point is to change this "... directly interacting with the
Clinical Knowledge Manager and equivalent repository and review tools"to
something like "... to interact with any Clinical Knowledge Manager through
a standard API (to be defined)".


-- 
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: Mon, 5 Sep 2011 21:49:01 +0100
Subject: Re: openEHR Transition: two procedural and one licensing question
From: ian.mcnic...@oceaninformatics.com
To: openehr-technical at openehr.org

Hi Diego,

I understand from Sebastian that you have been exploring the current CKM web
services.  Do you think these might form the basis for an open repository
API or do you have any other comments or alternative suggestions? 

Ian

On Monday, 5 September 2011, Sam Heard 
wrote:
> Thanks Diego
>
> [Sam Heard]  This would be a step forward and would allow for slim and fat
> systems to offer the same basic calls.
>
>> > My suggestion is for the this point
>> "Begin an open source software project for tools, web-based if
>> possible, to author archetypes, templates and terminology reference
>> sets directly interacting with the Clinical Knowledge Manager and
>> equivalent repository and review tools"
>>
>> I agree with the first part (create web-based open source tools), but
>> I think that the second part should be clarified. We should define a
>> basic API to access repositories, to avoid doing ad-hoc
>> implementations for each one of the possible repositories
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

-- 
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
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org


___ 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/20110906/0d940784/attachment.html>

openEHR Transition Announcement (about regional/national openehr organizations)

[Sam Heard]

Hi Pablo

It needs to be added.

Thanks Sam

Sent from my phone

On 07/09/2011, at 1:38 AM, pablo pazos  wrote:

> Hi,
> 
> Not so long ago we have discussed about a governance and organization model 
> to the openEHR community, and we have talked about regional/national openEHR 
> communities 
> (http://www.openehr.org/wiki/display/oecom/Foundation+Organisational+Structure).
>  I can't find this mentioned in the whitepaper.
> 
> I think if we want to have a global impact on the ehr scene, we need to 
> support those communities also, and define ways to coordinate the work of the 
> community as a whole.
> 
> 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: Mon, 5 Sep 2011 02:00:45 +0100
> From: thomas.beale at oceaninformatics.com
> To: openehr-announce at openehr.org
> Subject: [openEHR-announce] openEHR Transition Announcement
> 
> 
> Dear All,
> 
> I am writing on behalf of the new Transitional Board of openEHR to share our 
> plans to take openEHR to a new level of operations; a new structure, business 
> model and governance. Our vision is the creation of a thriving community that 
> works collaboratively to benefit humanity through efficient and effective 
> electronic health records (EHRs) that support the highest quality health care 
> for the least effort.   
> Until now, the openEHR Foundation has functioned as an owner of intellectual 
> property, governed by University College London and Ocean Informatics, with 
> board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam 
> Heard (Ocean).
> 
> 
> With the support of the considerable community of Members and via engagement 
> of a new category of sponsoring organisational Member known as ?Associates? - 
> Companies, Universities and Governments - the Transitional Board proposes a 
> number of changes:
> 
> The openEHR Foundation becomes an operational non-profit organisation with 
> paid key staff and resources;
> The Board (of governance) of the Foundation is extended to up to 10 people 
> with a shift to election by the openEHR Associates;
> Members who participate are recognised by their peers, may take on 
> decision-making roles, and have the right to commit changes to the key 
> development assets of the Foundation.
> The Members will participate individually and, through qualification by peer 
> recognition, will control the development within the three Programmes that 
> are building the key assets: 
> The openEHR specifications of the logical health record and attendant 
> services as well as the methods for describing the content using archetypes 
> (Detailed Clinical Models) and templates; and
> The openEHR archetypes and templates to be used within systems and for 
> message content between systems to achieve interoperability; and
> The openEHR software projects, to provide open source development of tools to 
> support the uptake and use of the specifications and templates.
> A group of Members will be needed to bootstrap each of these programmes and 
> determine the working arrangements that are suitable to the products that 
> they are managing at the current stage of development.
> 
> The Associates will determine who governs the Foundation by nominating and 
> voting on new members of the Board. The Board will appoint key Operational 
> staff and will approve the leader of each of the Programmes. The Programme 
> Leaders will be appointed by Qualified Members working in that Programme, 
> subject to Board approval. We believe this will create the right balance 
> between the ?ground up? creation of openEHR through participation of Members 
> and ?top down? governance.
> 
> The first step is to share with you a white paper providing more detail on 
> the proposals and to ensure that the Members are reasonably satisfied that 
> this is the right direction to head. 
> Some key activities have been proceeding in the background and are reaching a 
> point of maturity. It has taken us some time to gather more clinical 
> champions in this endeavour and companies that can use and work with the 
> tools in their early stages of development. It has also taken quite some time 
> for Thomas Beale to work out how to provide a seamless pathway between 
> definition of archetypes, specialisation of archetypes to ensure development  
>scalability, to meet jurisdictional requirements, and templates that 
> allow tailoring for actual use in specific settings. The result is ADL/AOM 
> 1.5. He has, as usual, been totally committed to this work and it is probably 
> very importa

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Pablo and Shinji

Supporting localization both technical and operational needs to be included. 
The no language primacy principle is a real winner, different written forms of 
the same language is not covered as yet. 

How local groups run is another, clearly these can be national or context based.

Thanks for the input.

Cheers Sam

Sent from my phone

On 07/09/2011, at 2:38 AM, pablo pazos  wrote:

> Hi Shinji,
> 
> That's exactly what I tried to point in another mail to the lists: local and 
> regional openEHR organizations should be supported by openEHR and we need to 
> put it into the white paper.
> 
> -- 
> 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: Tue, 6 Sep 2011 19:13:45 +0300
> > Subject: Re: openEHR Transition: two procedural and one licensing question
> > From: skoba at moss.gr.jp
> > To: openehr-technical at openehr.org
> > 
> > Hi All,
> > 
> > I have been suffered by sever jet lag after long trip, while I have
> > been thinking about this new white
> > paper and our local activity. I could not find such localisation
> > activity in this white paper, but please
> > consider and mention about such local activity.
> > I would like to show these two proposals.
> > 1) Local activity support.
> > As a global standard, localisation to each country or area is
> > necessary. My three years experience
> > to implementation of the Ruby codes, archetypes and template, we need
> > lots of localisation efforts
> > for Japanese use. I think this experience may be available to localise
> > for other countries. East Asian
> > countries people is keen in openEHR development and their engagements
> > are promising for their
> > health care.
> > 
> > 2) Premature artefact repository
> > CKM provides us well-considered archetypes and templates. This is a
> > great knowledge resource
> > for mankind. However, to incubate archetype as a common concept takes
> > long time like vintage wine.
> > On the other hand, I need more agile movement for daily development. I
> > have developed about 50
> > archetypes and 6 templates. These artefacts are still premature to
> > evaluate on CKM, but I would
> > like to discuss about my artefacts on line with many people. Yes, it
> > will be a 99% junk repository,
> > but 1% diamond would be a precious for our community. As Major league
> > cannot exist without
> > minor leagues, I think CKM needs such minor artefacts groups.
> > I am preparing to share them on GitHub, because anyone can use
> > repository for each use by fork
> > and merge request is useful.
> > I think the licence of this repository would adopt CC-BY-SA, is this
> > OK, Erik and Ian?
> > 
> > Cheers,
> > Shinji KOBAYASHI(in Japan, a path of typhoon.)
> > 
> > 2011/9/6 Erik Sundvall :
> > > Thanks for replying Sam!
> > >
> > > Erik Wrote (to openEHR-technical at openehr.org):
> > >>> Was that whitepaper formally ratified by the new board, or by the old 
> > >>> board,
> > >>> or is it's current state just a suggestion by Sam?
> > >
> > > On Mon, Sep 5, 2011 at 17:58, Sam Heard  > > oceaninformatics.com> wrote:
> > >> [Sam Heard] The whitepaper was ratified by the participants in the 
> > >> planning
> > >> process, the current Board (Profs. Kalra, Ingram and myself) and the new
> > >> Transitional Board.
> > >
> > > This is a bit worrying for the period until a broader board can be
> > > elected. I was hoping that somebody within the new board would be
> > > interested enough and have time to take licensing issues and community
> > > feedback seriously, let's hope that the board does a bit more research
> > > and community dialogue before ratifying a new version of this
> > > whitepaper. Could somebody from the board please confirm that you'll
> > > take a serious look at this in the near future?
> > >
> > > Erik wrote:
> > >> What is the mandate period of the transitional board? When will the
> > >> suggested new structure with an elected board start?
> > >
> > > On Mon, Sep 5, 2011 at 17:58, Sam Heard  > > oceaninformatics.com> wrote:
> > >> [Sam Heard] I for one am very happy to express a date for elections if
> > >> organisations embrace these arrangements. Clearly if there is no 
> > >> i

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thank you Shinji, this is an excellent idea - to really put support for 
language and other localization at the heart. I would propose that one 
Organisation become an associate and manage local activites - which 
Organisation should be by a vote of local associates.

This prevents the need for a lot of administrative activity.

What do others think?

Cheers Sam

Sent from my phone

On 07/09/2011, at 10:15 PM, Shinji KOBAYASHI  wrote:

> Hi Sam and all
> 
> Thank you for comments about localisation.
> First of all, I emphasize LOCALISATION is not ISOLATION.
> Only to fork and arrange global resource for local usage is isolation.
> True localisation is to feed back such experience to enrich core
> implementation.
> I think endorsement program at page 4 of white book should include
> localisation as global promotion, and endorsement / promotion program
> should have a board like other specification / clinical modeling / software
> engineering.
> Because local activity management depends on its own domestic situation,
> local governance should be decided by local community. However, bad
> localisation disgrace all of our community and makes people unhappy in its 
> area.
> So I think local activity requirements are,
> * Keep contact with global community
> * Implement openEHR clinical models for domestic use.
> * Provide proper translation, specialised implementation for their domain.
> * Promote openEHR specification for their domain.(Web/mailing list)
> * Governance of local community as good status
> * Feed back localisation experience to global community.
> I also think two or three of these conditions are enough to be a local 
> activity.
> 
> These are my requests from Japan(probably from other local activities, too)
> * Permit to use openEHR name and logo for domestic promotion.
> * Publish local activity directory for whom need to contact with them
> on the openEHR.org web.
> * Disallow to use openEHR  name and logo whenf you think we are not
> worth to use.
> * Keep contact with local activities.
> 
> Cheers,
> Shinji KOBAYASHI
> 
> 2011/9/7 Sam Heard :
>> Hi Pablo and Shinji
>> Supporting localization both technical and operational needs to be included.

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Stef

The previous Board did not want to make an error and use too loose a licence 
given that there is no going back.

Our concern is that someone could specialize an archetype and claim copyright, 
or create a template and do the same. It is our intention at this stage to have 
a specific clause in the licence that limits it to derived archetypes and 
templates. At all discussions with industrial parties this has been acceptable, 
many see it as positive as the corollary of Eric's approach (which may be the 
best) is that there are heaps of archetypes out there that have openEHR 
attribution but are copyright to other parties.

Is it clear what I am saying. It is a conundrum - and needs careful appraisal 
before going to BY alone.

Cheers Sam

Sent from my phone

On 07/09/2011, at 10:38 PM, Stef Verlinden  wrote:

> 
> Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven:
> 
>> Do read that wikipage and follow the links there to the mail
>> discussions. What is it that you think is missing or unclear in the
>> arguments against SA?
> 
> 
> 
> That they're hidden in a lot of text form which one has to follow through 
> hyperlinks and read even more text.
> 
> You stated somewhere - correctly - that companies want to avoid risk, 
> similarly decision makers want to avoid reading through lengthy discussion 
> (from which they have to draw there own conclusions:-) )
> 
> 
> If I understand you correctly your main argument is that:
> 
> the share alike (SA) requirement will create a risk for lengthy juridical 
> procedures - in every country they operate - for companies  who include 
> openEHR archetypes or derivatives thereof in their systems. Since companies 
> avoid risk, they  will choose other solutions without an SA requirement.
> 
> The reason for this is that it's not clear what SA exactly means. For 
> instance in the context of building archetype-based GUI- stubs, forms etc. in 
> proprietary systems. As a consequence it could be possible that companies are 
> forced - unwillingly - to open up the source of their proprietary systems. It 
> will take years and many court cases, in different countries, to sort this 
> out. Until then (the large) companies will stay away from openEHR.
> 
> This problem can be avoided completely by dropping the SA requirement.
> 
> 
> So I guess the first question is: who has a solid argument against Erik's 
> argument.
> 
> The second question is: what are the exact benefits of the SA requirement and 
> are they worth the risk of companies not using openEHR at all (presuming 
> that's a real risk).
> 
> 
> Cheers,
> 
> Stef
> 
> 
> 
> ___
> 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: 

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Tim, 
It is tangled up with the CC-BY-SA question. Some one needs to have the 
copyright or there is a license agreement that is evoked as you enter the the 
archetype in the repository.

Our advice was that having copyright simplifies the world. Having said that the 
same archetypes now exist in other repositories with copyright assigned to the 
national provider, so it is already murky.

The real point is that interoperability depends on sharing archetypes, which 
need to be available for use without regard to others. 

By that, I also mean I can freely use ANY archetype or template out there if I 
need to.

Cheers Sam

Sent from my phone

On 08/09/2011, at 9:05 AM, Timothy Cook  wrote:

> Sam,
> 
> Just to be clear.  Is it yours and the boards intent that all
> archetypes and templates be marked as copyright openEHR Foundation?
> 
> Thanks.
> 
> On Wed, Sep 7, 2011 at 15:46, Sam Heard  
> wrote:
>> Thanks Stef
>> The previous Board did not want to make an error and use too loose a licence
>> given that there is no going back.
>> Our concern is that someone could specialize an archetype and claim
>> copyright, or create a template and do the same. It is our intention at this
>> stage to have a specific clause in the licence that limits it to derived
>> archetypes and templates. At all discussions with industrial parties this
>> has been acceptable, many see it as positive as the corollary of Eric's
>> approach (which may be the best) is that there are heaps of archetypes out
>> there that have openEHR attribution but are copyright to other parties.
>> 
>> Is it clear what I am saying. It is a conundrum - and needs careful
>> appraisal before going to BY alone.
>> Cheers Sam
>> Sent from my phone
>> On 07/09/2011, at 10:38 PM, Stef Verlinden  wrote:
>> 
>> 
>> Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven:
>> 
>> Do read that wikipage and follow the links there to the mail
>> discussions. What is it that you think is missing or unclear in the
>> arguments against SA?
>> 
>> That they're hidden in a lot of text form which one has to follow through
>> hyperlinks and read even more text.
>> You stated somewhere - correctly - that companies want to avoid risk,
>> similarly decision makers want to avoid reading through lengthy discussion
>> (from which they have to draw there own conclusions:-) )
>> 
>> If I understand you correctly your main argument is that:
>> the share alike (SA) requirement will create a risk for lengthy juridical
>> procedures - in every country they operate - for companies  who include
>> openEHR archetypes or derivatives thereof in their systems. Since companies
>> avoid risk, they  will choose other solutions without an SA requirement.
>> The reason for this is that it's not clear what SA exactly means. For
>> instance in the context of building archetype-based GUI- stubs, forms etc.
>> in proprietary systems. As a consequence it could be possible that companies
>> are forced - unwillingly - to open up the source of their proprietary
>> systems. It will take years and many court cases, in different countries, to
>> sort this out. Until then (the large) companies will stay away from openEHR.
>> This problem can be avoided completely by dropping the SA requirement.
>> 
>> So I guess the first question is: who has a solid argument against Erik's
>> argument.
>> The second question is: what are the exact benefits of the SA requirement
>> and are they worth the risk of companies not using openEHR at all (presuming
>> that's a real risk).
>> 
>> Cheers,
>> Stef
>> 
>> 
>> ___
>> 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
>> 
>> 
> 
> 
> 
> -- 
> 
> Timothy Cook, MSc
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> Skype ID == timothy.cook
> Academic.Edu Profile: http://uff.academia.edu/TimothyCook
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Tom

It is normal practice with CC to include clarifications and the whole
structure of the license is designed to do this.

Let's stay with the issue of how we stop someone copyrighting and charging
for a specialised archetype? Or a template that is fundamental to health
care (like an antenatal visit)?

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Thomas Beale
> Sent: Thursday, 8 September 2011 10:30 AM
> To: openehr-technical at openehr.org
> Subject: Re: openEHR Transition: two procedural and one licensing
> question
> 
> On 07/09/2011 21:46, Sam Heard wrote:
> > Thanks Stef
> >
> > The previous Board did not want to make an error and use too loose a
> > licence given that there is no going back.
> >
> > Our concern is that someone could specialize an archetype and claim
> > copyright, or create a template and do the same. It is our intention
> > at this stage to have a specific clause in the licence that limits it
> > to derived archetypes and templates.
> 
> I don't think actually changing the text of any accepted, well known
> license is a good idea at all - then it becomes something for which no
> legal analysis is available, and won't be trusted by anyone. Instead,
> openEHR should simply state which kinds of artefacts require which
> kinds
> of license (if any).
> 
> - thomas
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Well that may be true but government agencies and companies will want to know 
that no one has recourse to legal action if they use an archetype.

Cheers Sam

Sent from my phone

On 09/09/2011, at 8:21 AM, Timothy Cook  wrote:

> On Thu, Sep 8, 2011 at 16:54, Sam Heard  
> wrote:
>> Hi Tom
>> 
>> It is normal practice with CC to include clarifications and the whole
>> structure of the license is designed to do this.
>> 
>> Let's stay with the issue of how we stop someone copyrighting and charging
>> for a specialised archetype? Or a template that is fundamental to health
>> care (like an antenatal visit)?
> 
> Maybe that isn't such a bad thing.  They are only roping themselves
> into their own corner.
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: Web-based tools?

[Sam Heard]

Hi Ian

My interest is the pain we get as the tools get developed and tweaked as does 
ADL and multiple versions. 

Also, if we are to use Thomas' engine it should tip the balance a bit further 
as installing and updating numerous layers gets even more painful.

Finally, web tools are easier to access on multiple devices including mobile.

Cheers San

Sent from my phone

On 10/09/2011, at 1:10 AM, Ian McNicoll  
wrote:

> Hi all,
> 
> One of the suggestions in the White Paper which appears to have
> universal support is a move to support much more open-source tools
> development. Clearly some tooling must be web-based e.g repository
> management and associated formal and informal discussion e.g. CKM and
> any new community repository.
> 
> However, I am much less clear on why we might need web-based primary
> authoring tools for archetypes and templates. Diego, Pablo and Sam are
> all keen on this approach but I remain unconvinced that this is really
> a key requirement, given that archetype authoring is in essence a
> solitary activity much like any other code development. By all means
> build in much better integration with repositories and other
> mechanisms to allow joint working, but even with modern javascript
> libraries and Flex-style components, HTML-based tooling just feels
> like it adds a layer of development complexity and probably some
> usability-clunkiness which is not offset by the benefits.
> 
> Maybe I am just an old-timer but having waited for may years to get
> the kind of development environment that Visual Studio, Eclipse and
> equivalents bring, and that I think is equally required for archetype
> development, I am loathe for us to get slowed-down by insisting on a
> 'web-based'.
> 
> What do others think?
> 
> Ian
> 
> 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
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care  www.phcsg.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

EN/ISO 13606 & openEHR - harmonisation possibilities

[Sam Heard]

As Dipak has explained, the attribution in ISO is not available. I believe 
attribution is a distraction from the task - I have seen lots of slides from 
others used in this space and ideas transferred here and there. Let's 
appreciate all work and try and build on it efficiently.

Cheers Sam

Sent from my phone

On 10/09/2011, at 5:05 AM, Thomas Beale  
wrote:

> On 09/09/2011 19:04, David Moner wrote:
>> 
>> Thomas,
>> 
>> Could you please clarify this sentence?
>> 
>> I'm the main author of that document. As you said, it is a 45 pages 
>> document of which only two and a half are a summary description of ADL 
>> to understand the proposed archetypes. And only there we can see some 
>> examples of ADL structures (yes, openEHR ones) taken directly from 
>> EN13606-2, which is the norm referenced at the document, and not from 
>> the openEHR specifications.
>> 
>> I really think that your affirmation is misleading and unfair.
> 
> David,
> 
> sorry - you are right, there is not 'a lot' of copied material, only p 
> 11 & 12. But I do find it funny that there is no mention of openEHR, 
> because it means that readers of the document won't realise that they 
> should go to openEHR to see ongoing developments in the specification 
> and tools (I am not saying the only development in tools of course, but 
> since 13606-2 is a snapshot of an openEHR spec, it would make sense to 
> make this clear, one would have thought).
> 
> - thomas
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: Web-based tools?

[Sam Heard]

Hi Tom

 
My interest is the pain we get as the tools get developed and tweaked as
does ADL and multiple versions. 


well, changes to formalisms are different from changes to tools. All these
things are already or can be version managed, so this is just a question of
release management.

[Sam Heard] No, it is people from the installed base working on current
archetypes. It is always unclear when current users HAVE to upgrade to
continue working..the web means we can do this organically. The Foundation
is planning a move to ADL 1.5 and clearly this should be the environment
that the tools support. There will be tweeks to the specifications during
the early years.

 

 
Also, if we are to use Thomas' engine it should tip the balance a bit
further as installing and updating numerous layers gets even more painful.


Sam, I am not sure what you mean by this. 

[Sam Heard] Supporting services through DLLs, RPCs and other technologies is
difficult as it requires a local installation. The Brosphorus (Seref/Beale)
service will require further implementation locally. Just as we see that the
Eiffel library finds it difficult to keep up with the Mac except by going to
the BSD environment (let alone iOS and Android), we will see a lot of
locally supported applications move to web based tools when the GUI support
is sufficient.



 
Finally, web tools are easier to access on multiple devices including
mobile.


that's one advantage for sure. But we don't see any 'heavy' tools being used
over the web yet, e.g. Eclipse, Visual Studio.

[Sam Heard] These are for building the applications that we want - they will
build web-based tools as well. I agree that development environments are
likely to be local for some time - though GIThub and others provide a lot of
that support via the web now.

Cheers,. Sam

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/ce6767ab/attachment.html>

Tools for collaborative working

[Sam Heard]

Dear All

The Board is interested in using tools for collaborative online working and
keeping these coordinated. We already have Jira and Confluence from
Atlassian. These are working well as far as I am aware.

I would like to propose that we consider going to third parties for:

Source code repository
- Bitbucket from Atlassian (Mercurial)
  - ? other options

Agile development
- Pivot Tracker (I have applied for 4 accounts for free - openEHR
Specifications, openEHR Software, openEHR Clinical Models, openEHR
Localisation) Projects would then be created under each of these by the
Members if we chose to use this tool.
- ? other options

Please discuss these issues. I have asked a couple of the less technical
people to review Pivot Tracker to consider its role in tasks other than
software development.

We will obviously be guided totally by the lists on these matters - the
point being that we really want to use one tool for one purpose across
different programs if possible or appropriate. Even if the tool turns out
not to be the best one at times, the uniformity will be very important going
forward.

Cheers, Sam


Dr Sam Heard
Chief Executive Officer
Director, openEHR Foundation
Senior Visiting Research Fellow, University College London

214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808
21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 75 7549 7937 

Questions about the relationship between Instruction, workflow and Action

[Sam Heard]

Hi Pablo,

Comments in line

Sent from my phone

On 01/08/2012, at 15:39, pablo pazos  wrote:

> Hi Sam,
> 
> I'm reviving this thread :D 
> 
> I'm working on a project and we need to define a simple state machine, this 
> is the way I think it should be done and it would be very nice to have you 
> comments about this:

The idea is that the 'computational' state machine is defined in the RM - 
initial, active, etc. you are defining the clinically relevant steps, linked to 
this underlying state machine. These are archetyped.

> 
> The idea is to record physical activity recomended by a clinician.
> 
> There is one INSTRUCTION (the recommendation) with many ACTIVITIES (each one 
> a recommended sport or activity).
> We have 4 states: INITIAL, SCHEDULED, ACTIVE and COMPLETED.
> And there are 2 ACTIONS, one to record the scheduling of the activity and 
> other to record the initiation and end of the activity. (Let's say these are 
> SCHED_ACTION and INIT_END_ACTION).
> 
> When a recommendation is created (INSTRUCTION and ACITIVITIES), the current 
> state is INITIAL (that should be saved on the repository that you mentioned 
> in your email).

The action will be to 'prescribe' the exercise or plan it - something the 
clinician will understand. The state will be initial.

> 
> Now we need to model the state machine: INITIAL --(schedule)--> SCHEDULED 
> --(start)--> ACTIVE --(finish)--> COMPLETED.

The ACTION to schedule will have the state Scheduled, to undertake the exercise 
with state Active and then an Action to record completing the exercise with 
state Completed.

> So, we create a ISM_TRANSITION on the SCHED_ACTION with current_state = 
> INITIAL and careflow_step = schedule.

State = Scheduled

> And in the INIT_END_ACTION we have 2 ISM_TRANSITIONs with curr_state = 
> SHCEDULED and careflow_step = start,

The state is Active , the crr_state is the state after the transition.

> and the other, curr_state = ACTIVE and careflow_step = finish.

Completed

> 
> The third part should be to provide the entry point to execute that ISM, so 
> we set the SCHED_ACTION.archetypeId to each ACTIVITY.action_archetype_id, so 
> when the INSTRUCTION is on INITIAL, only a SCHED_ACTION could be executed.
> 
> And, on any ACTION execution, we update the repository with the action 
> executed and the new state (and we keep all the actions and transitions taken 
> so we can reproduce the process later).
> 

This is correctlinking with EHR path or WorkflowID - which allows linking 
other ENTRYs as well.

> 
> What do you think? That's the right way to do it?
> 

Hope that helps - Sistine might give a little more guidance.

Cheers Sam

> -- 
> 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: sam.heard at oceaninformatics.com
> To: openehr-technical at openehr.org
> Subject: RE: Questions about the relationship between Instruction,
> workflowand Action
> Date: Wed, 7 Dec 2011 13:09:31 +0930
> 
> Hi Pablo,
> 
>  
> 
> The design principles are that the Instruction should remain unaltered by 
> people basing actions on this instructions ? as the action and instructions 
> could be disconnected at any moment. For example, the instruction (medication 
> order) should not be changed by anyone just to give a medication etc.
> 
>  
> 
> So the state of the instruction is carried in the record of the action (if 
> appropriate). We have decided to name the pathway steps and attach a machine 
> readable state to that step. This makes it much easier for clinicians to 
> model and to see what is going on.
> 
>  
> 
> In our openEHR repository we maintain an instruction index ? that is a 
> pointer to all instructions and all actions that relate to that instruction ? 
> and the current state of the instruction.
> 
>  
> 
> You will see an archetype ACTION in the openEHR repository and the 
> careflow_steps are archetyped to provide a name and the current state matches 
> an openEHR code for state. This means that a careflow step being carried out 
> will set the state to a particular machine state.
> 
>  
> 
> Hope this helps.
> 
>  
> 
> Cheers, Sam
> 
> 
> 
> From: pazospablo at hotmail.com
> To: openehr-clinical at openehr.org; openehr-technical at openehr.org
> Subject: Questions about the relationship between Instruction, workflow and 
> Action
> Date: Sun, 4 Dec 2011 15:36:36 -0300
> 
> Hi everyone!
> 
>  
> 
> I'm trying to understand how to execute a state machine of a fully structured 
> INSTRUCTION, and I have some questions and thoughts to share with you...
> 
>  
> 
> The first issue is about archetyping an ACTION that execute and ACTIVITY of 
> an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the 
> ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both 
> attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS

HTML 5 Microdata

[Sam Heard]

Dear All

I am interested in how we might work from a template or data instance to 
HTML 5 microdata. There is an introduction here for people who are not 
familiar.

http://www.webmonkey.com/2010/09/microdata-html5s-best-kept-secret/

What is obvious is that standardisation of information at the 
"Microformat" leve will be useful for APIs that do very common things 
and being able to express these within an HTML 5 blob will be useful.

I think it might mean having a dictionary as part of CKM which respects 
the dependencies but provides key information sets for things like 
Allergies, Medications, Problems, Vaccinations, Weights, heights, blood 
pressures, temperatures etc.

Interested in what others think.

Cheers, Sam

-- 
    

*Dr Sam Heard*
/Chief Executive Officer/
Director, /open/EHR Foundation
Senior Visiting Research Fellow, University College London

214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808



21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 74 2641 9957

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/b268c397/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/b268c397/attachment.jpe>

Commiting ACTIONs for the same INSTRUCTION ACTIVITY

[Sam Heard]

Hi All

The openEHR specification is clear about the notion of update/versioning 
of a composition or creating a new event. The idea of a persistent 
composition is useful for information where new data ALWAYS makes 
previous data redundant not incorrect at the time (such as a medication 
list in a shared health record). This is useful for allergies and other 
lists which have to be maintained.

An event composition will relate to information at a particular time 
which may be collected again but does not replace the previous 
information. This is usually the case for most recordings. A new version 
of this composition will invalidate the previous version (as key data 
was missing or incorrect).

Cheers, Sam

On 10/08/2012 7:08 PM, Ian McNicoll wrote:
> How is the patient reporting back their exercise activity to the clinician?
>
> I think it is better to create a new Composition for each 'patient
> report' rather than re-versioning a single Composition. The question
> then is how and, how often, the patient sends a report.
>
> As an example, let's say the patient reports weekly. In that case I
> would generate a new event Composition for each weekly report.
>
> Perhaps you could use a CLUSTER archetype to represent both
> recommended exercise, and the patient reported outcome, to be used in
> both the INSTRUCTION/ACTIVITY and in the ACTIONs. Can you gove more
> information on some of the detail of the exercise recommendations and
> the patient reports.
>
> Ian
>
>
> On 9 August 2012 19:28, pablo pazos  wrote:
>> Hi Ian, thanks for the input.
>>
>> I'm trying to do it "by the book", obviously clinical input is essential to
>> model things :)
>>
>> What do you think about the ACTION to report patient activity?
>>
>> Should I create a new composition every time the patient report something?
>> or
>> Should I version the same composition on every exercise report for the same
>> exercise program?
>>
>>
>> At first I was thinking about having one ACTIVITY and versioning
>> COMPOSITIONs to represent states, but then ISM states came into play :D
>>
>>
>> In this scenario, I could keep exercise scheduling and activation states
>> just in the app, and commit a COMPOSITION only when the exercise is
>> finished, so I can interpret the COMPOSTION as a finished activity/exersice
>> on our openEHR repository (without putting an explicit state on the ACTION
>> archetype), and as you said, changing the state of the ACTIVITY as a much
>> higher level by a clinician.
>>
>> --
>> 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: Ian.McNicoll at oceaninformatics.com
>>> Date: Thu, 9 Aug 2012 18:45:56 +0100
>>> Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
>>> To: openehr-technical at lists.openehr.org
>>> Hi Pablo,
>>>
>>> Thanks for the example. It makes more sense now, although I have to
>>> say that it feels to me as if you are overloading the idea of
>>> ACTIVITY/ACTION in this scenario. My approach would have been to
>>> regard the whole exercise program as a single task modelled as an
>>> Activity, and just to capture the patient-reported progress as part of
>>> the ACTION archetype, and only change state at a much higher-level i.e
>>> when the whole program is scheduled, starts or stops.
>>>
>>> There is nothing technically wrong with what you are suggesting, of
>>> course.
>>>
>>> I would be interested in other's thoughts - not sure if this is more
>>> appropriate for the clinical list?
>>>
>>> Ian
>>>
>>>
>>>
>>> On 9 August 2012 18:28, pablo pazos  wrote:
 Yes! this is really clear and has been a great help.

 Thanks a lot.


 Just to give info that may help other in the future: in our case, the
 instruction is a recommendation to do some exercise, and we need to know
 if
 the activity (the exercise) is completed. We consider a completed
 activity
 to be one exercise instance, e.g. one walk in the park. But the
 recommendation is something like "walk 30 min/day for 2 weeks", so I
 think a
 good approach is to create one ACTIVITY for each day, and let the
 patient
 change the state of each day's ACTIVITY (scheduled, started, completed).

 In this case, if the day passes and the activity was never "active",
 we'll
 mark it as "expired".

 Of course, any comments about this scenario are very welcome.

 --
 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, 9 Aug 2012 18:07:31 +0100

 From: thomas.beale at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY

Triggering behaviour

[Sam Heard]

Hi Isaac

Just saw your post. The triggering rules could be based on the reference 
model alone but would be largely to do with access notification or the 
like - e.g. if the same user saves or reads more than 20 EHRs in an hour 
to stop the user access. All clinically oriented business rules need to 
be based on AQL and DO need to know what archetypes are involved - but 
not at the time of creating the system. These rules can be written when 
and as needed.

Cheers, Sam

On 14/08/2012 4:25 PM, Isaac Lamb wrote:
>
> Hi All,
>
> I have a question regarding triggering behaviour based on data 
> captured via archetypes / templates.
>
> In the openEHR Architecture Overview document, the following extract 
> seems to indicate this has been considered in the openEHR specification.
>
> "Clearly applications cannot always be totally generic (although many 
> data capture and viewing applications are); decision support, 
> administrative, scheduling and many other applications still require 
> custom  engineering. However, all such applications can now rely on an 
> archetype- and template driven computing platform."
>
> When developing an openEHR system, how can decision support and the 
> other actions mentioned above be implemented when there is no way to 
> know which archetypes / templates will be used in the final system?
>
> Kind Regards,
>
> Isaac Lamb
>
> Software Developer
>
> *Email*isaac.lamb at charmhealth.com.au 
> 
>
> Description: Description: Description: cid:image002.jpg at 01C8F3D1.27611F50
>
> Suite 13, 65 MacGregor Terrace Bardon QLD **
>
> *Telephone*+61 (0) 7 3512 5300 | *Fax* +61 (0) 7 3512 5399
>
> *Helpdesk*1300 736 320 | support at charmhealth.com.au 
> 
>
> *Web*www.charmhealth.com.au **
>
>
>
>   
>
>
> DISCLAIMER: This e-mail, together with any attachments, is 
> confidential and intended for the named
> recipient(s) only. If you are not the intended recipient or have 
> received this message in error, you are
> asked to immediately notify the sender and delete this message and any 
> copies of this message from
> your computer system network and destroy any printed copies of this 
> email. Any form of unauthorised
> disclosure, modification, distribution, publication or use of this 
> e-mail message is prohibited.
>
>
>
> Scanned by the Netbox from Netbox Blue 
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 168 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2105 bytes
Desc: not available
URL: 

What should AQL return in this case?

[Sam Heard]

Hi All

The work_flow_id of an entry provides a way to link any ENTRY with an 
INSTRUCTION. There are more complex workflow parameters possible within 
the ENTRY class that can be used if more complex issues arise.

Relating ENTRYs in a general way outside a particular application or 
repository is more difficult unless it follows the ACTION/INSTRUCTION 
model proposed in openEHR.

Just some ideas.

Cheers, Sam

On 20/08/2012 9:10 PM, Thomas Beale wrote:
>
> This is a good question. I wold summarise it as: how do I ensure an 
> AQL query picks up proximate rather than distant objects for a given 
> object?
>
> It depends on the data. If the only thing in the data that indicates 
> that INSTR Y1 is related to OBS X1 is temporal proximity, then you 
> would have to include something to do with time in the a WHERE clause. 
> Now, this might actually be ok - if you know a priori that a certain 
> pattern of Obs followed by Instr always corresponds to e.g. a 
> situation of 'lab result' followed by a new order (or whatever the 
> pattern that you are looking for), then this is safe to use.
>
> Normally such inferences would not be safe. So we need to think about 
> how the proximate Obs/instr pairs could be explicitly linked. In 
> openEHR/13606, this is done with LINK objects, so your query WHERE 
> clause could match Instructions that had a LINK pointing back to an 
> Obs with some kind of causal relation specified.
>
> Going one better means building some kind of active index in the 
> record, where DV_EHR_URIs are used to refer to pairs / groups of 
> Entries that are part of the same investigation, or whatever it might 
> be. Then to query, you would be querying that structure. There are 
> moves to standardise such structures in openEHR, but it's not there yet.
>
> - thomas
>
> On 20/08/2012 05:19, Seref Arikan wrote:
>> Greetings,
>> Here is the setting in which AQL is being used:
>> We are interested in outcomes of a particular clinical instruction  
>> in cases where a particular observation has been recorded.
>> We want to get an attribute of both the observation and the and the 
>> instruction from patient EHR. The patient's EHR has multiple 
>> observations and instructions, as shown in the following diagram (the 
>> dual line connections are from the partial graph representation 
>> domain, meaning a child contained somewhere) The diagram also 
>> contains the query and other details, which I'll discuss below
>>
>> Inline image 1
>>
>>
>> The problem here is that the observation and instruction tuple can be 
>> represented in 4 ways. (I hope the diagram represents why it is so) 
>> Should AQL implementation return all 4? Then the consumer of the 
>> result set would have to sort things out. This is similar to RDMS 
>> behaviour when a select statement is issued on two tables without any 
>> joins.
>> I'm inclined to accept this as the expected behaviour, but I'd like 
>> to hear what others think.
>>
>> (of course, adding some constraint that would enforce the instruction 
>> to have a creation time later than the observation would return only 
>> two tuples, but that is not the case I'm asking for)
>>
>> Best regards
>> Seref*
>> *
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 35089 bytes
Desc: not available
URL: 

Python / Django experience??

[Sam Heard]

Hi All

 

I want to ensure that the technical possibilities do not overwhelm the
clinical reality in this space. It is a very new space and, for
interoperability and sharing of applications, we need to align ideas for
shared data specifications as part of the process. It has been and remains
attractive to consider code repository support for this activity, but I
think a much less sophisticated approach that engages leaders in an
alignment process is most important.

 

The key decision in these early days is what to put in the parent archetype
and what to keep for localisation through specialisation or templates.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Friday, 3 February 2012 2:50 AM
To: openehr technical
Subject: RE: Python / Django experience??

 

Hi all,

 

What I've been thinking is to share the same interface/protocol to do simple
tasks on distributed CKMs like:

 

1.  Adding an artifact (archetype, template, termset, terminology
service, process definition, gui template, etc.), lets think only about
archetypes for now.
2.  Updating an archetype (with version management)
3.  Listing all the archetypes
4.  Listing all the archetypes for one RM type (i.e. composition, entry,
action, etc.)
5.  Listing all the archetypes that archetype_id match a regexp
6.  Listing all the archetypes that match some text (free text search)
7.  Retrieve archetype in ADL/XML/JSON/YAML by archetype_id

 

 

Ian, about the requirements you mention:


> Basic requirements
> 
> 1. Query across multiple repositories using multiple criteria, based
> on something similar to the CKM ontology.

 

For this I think something like DNS protocol will do the job
(http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a
distributed search by redirecting the query if some server doesn't have the
answer. So, if we have a service to register artifacts on CKM servers
(service 1. on the list above), with an "artifact registered notification
protocol", and another protocol for "CKM server discovery", we could
implement the distributed search.


> 2. Establish references to remote assets, almost certainly caching the
> referenced asset locally

 

This would be the a mix of "adding and artifact" and "artifact registered
notification protocol".


> 3. Establish subscriptions to remote assets, to enable change notification
etc
> 

And this would be included in the "CKM server discovery protocol", that
could defined like some services provided by the NDP protocol, using
messages like RA, NS, NA, ... to discover CKM servers to create a CKM
network over Internet:
http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%
20Volume%20I/ch02lev1sec5.html 
I think some of these services could be found also in the ICMP protocol:
http://www.networksorcery.com/enp/protocol/icmp.htm

 

 

Just to clarify my thoughts, I don't think we need a network protocol!!! I
think we could create our protocols to handle artifacts in a distributed way
reusing some ideas from those proven protocols that our machines run
everyday to connect to the Internet and access distributed resourses.

 

 

How this stuff could work in reality?

 

1.  We need a set of "root CKM servers", always online, that could
answer our queries or redirect to some another server that could answer
(like DNS).
2.  In those servers (could be only one, like openEHR.org CKM), other
servers could advertise themselves to form part of the CKM network, this
could be done like an ICMP or NDP router advertisement. Those servers could
download also a list of servers currently connected to the network, and
update the list anytime.
3.  The children servers could be not always online, so each entry on
the root server registry should have a lifetime, that when reached, the
entry is eliminated from the list (like in ICMP
http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could
trigger a notification to the other members of the network, to update their
server list.
4.  When an artifact is added to a server, it should notify other
servers in the network, so they could know what server has the original copy
of the artifact, and maybe they can make a copy of the artifact that sould
be read-only on those servers that cache a copy. The cached archetype could
have a lifetime, that when reached, a new copy of that archetype should be
downloaded from the original server, if the server is still online, or renew
the lifetime if the original server is offline.
5.  Then a query received by any CKM could be responded or redirected to
other server, and all servers in the network could keep up with all the
archetypes created worldwide.

 

 

I don't know if this is crazy talk or if it's seems reasonable to you.
Please let me know :D

 

 

Kind regards,

Pablo.

 

 

-- next part --
An HTML attachment was sc

Python / Django experience??

[Sam Heard]

Hi,

 

We started archetype development in the NHS using Subversion and it got in a
real mess very quickly. As Pablo says the version and dependencies are not
the same as in code.

 

I think we need to consider what are the tools that are needed now to make
openEHR more attractive to clinical application developers, and what are the
functions of those tools. Let's ensure that businesses can thrive working in
the openEHR environment and make sure we try and fill the gaps as the first
priority.

 

Cheers, Sam

 

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 8 February 2012 4:14 AM
To: openehr technical
Subject: RE: Python / Django experience??

 

Hi Erik and all,


> On Thu, Feb 2, 2012 at 18:19, pablo pazos  wrote:
> > I don't know if this is crazy talk or if it's seems reasonable to you.
Please let me know :D
> 
> Not crazy, but maybe overly complicated.
> 

Maybe I don't present the idea in the best way, but in the end is just some
services to advertise/discover artifact repositories/servers, services to do
distributed queries, and services for notifications (subscribe/notify). Some
of this ideas are in use out there for zillions since Internet born and
evoluted.


> Perhaps it would be a good idea to use a layered approach?
> 1. An existing distributed version control system (DVCS) like GIT (and
> an agreed directory structure and naming conventions within it) for
> storing versioning and distributing archetype source files etc.

About using some version control system (VCS), I don't think this is a good
solution because the semantics of "archetype version" are not the same
semantics as in "plain text versioning" (here changing one character will
create a new version of the artifact). With VCS you can handle
local/internal evolution of an archetype in development, but for a
global/public archetype versioning system, IMO this is not the right tool to
handle archetype versions (and other artifact versions).

 

I think we need to define the versioning system/semantics/context of an
artifact, and then implement this spec on design tools or in each artifact
repository. If I'm not mistaken, a discusion about this topic took place a
while ago and I don't know if there was consensus on the proposals.

 

Kind regards,

Pablo.

-- next part --
An HTML attachment was scrubbed...
URL: 

Does XMLSerializer (java) create archetype slots with too much extra information?

[Sam Heard]

Hi Diego

This was the result of some overzealous efforts in the past (designed to
make XML look verbose :-). The discussion has been about the fact that
Occurrences does not need an includelower/upper and unbounded is not
necessary as it can never be a constraint statement.

The expression is new to me...

Sam


> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Diego Bosc?
> Sent: Wednesday, 4 January 2012 1:18 AM
> To: For openEHR technical discussions
> Subject: Does XMLSerializer (java) create archetype slots with too much
> extra information?
> 
> This is a simple question: Why does a simple archetype slot like this
> (ADL)
> 
> allow_archetype ELEMENT[at0001] occurrences matches {0..*} matches {
> -- Archetype slot
> include
> archetype_id/value matches {/.*/}
> }
> 
> ends up like this?
> 
> 
> ELEMENT
> 
>   true
>   false
>   false
>   true
>   0
> 
> at0001
> 
>   
>   archetype_id/value matches
> {/.*/}
>   
> BOOLEAN
> 2007
> false
> 
>   STRING
>   archetype_id/value
>   CONSTANT
> 
> 
>   String
>   
> .*
>   
>   CONSTANT
> 
>   
> 
> 
> I'm not complaining about the ultra-verbose occurrences (surely can be
> improved, but there was already a discussion about this on this
> mailing list).
> I don't get the point of putting the 'expression' tags on this case.
> It's like putting the same thing twice.
> Is the 'operator' tag supposed to be understandable?
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR / FHIR data types cross analysis

[Sam Heard]

Thanks Tom for this useful work.

 

A couple of thoughts:

1)  It might be worth explaining the need for DV_BOOLEAN - and not just
use Boolean

2)  The separation of date and time is not usual in computing languages
at the moment and I would guess is a consideration - we certainly do not
model these separately but as a constraint

3)  The ability to have codes as units in quantity is an interesting
approach which has been around for a while in HL7 v2 where you are not
limited to SI units/UCUM but can have TAB for tablets etc.

 

You state: "The FHIR choice to represent units as a code or a string seems
unnecessarily complicated. A UCUM units string should be adequate. There is
an example with unit=mcg/L and code=ug. What can this mean?"

 

Nota sure how we could have a code for a unit that is UCUM/SI - this does
not make sense really - but having the ability to put in quantities that are
not SI Units does have some merit. Pulse is a good example - it is really a
frequency x/min but people often say bpm or beats per minute. The amount of
tobacco people use can be in cigarettes per day or oz/week or gm/day. At the
moment we have to divide these into different parts of the archetype.

 

That is not to say that it is right to put the counted thing as a unit and
not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for
medication and do cause some difficulty.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 30 January 2012 4:27 AM
To: Openehr-Technical
Subject: openEHR / FHIR data types cross analysis

 


I have started a gap analysis of the openEHR and FHIR data types
 , created by Grahame Grieve as part of the HL7 'fresh look'
activity. ANyone is welcome to add to the tables on this page - I am just
slowly working on it in the background.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

DV_DURATION as ranges

[Sam Heard]

Hi Tom and Diego,
The reference workbench only has an interval constraint on duration as it is
the logical constraint. If this is a point duration then it still expresses
a range. Not sure if this has changed over time.
Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Thomas Beale
> Sent: Tuesday, 31 January 2012 2:51 AM
> To: openehr-technical at openehr.org
> Subject: Re: DV_DURATION as ranges
> 
> 
> I thought I had replied to this, but must not have. Anyway, I don't
> understand why single point values are not used either, rather than
> point ranges (which seem somewhat pointless ;-)
> 
> - thomas
> 
> On 25/01/2012 22:56, Diego Bosc? wrote:
> > No comments about this one?
> >
> > 2012/1/13 Diego Bosc?:
> >> As Ian suggested I copy this issue from CKM to the technical list.
> >> I have seen that in some archetypes (e.g. Apgar or BloodPressure)
> >> that use DV_Duration restrictions (such as the width of the interval
> >> event in the blood pressure archetype or the famous offset in the
> >> apgar
> >> archetype) define them like this:
> >>
> >> offset existence matches {1..1} matches {
> >> DV_DURATION[at0040] occurrences matches
> >> {0..1} matches {  --
> >> value existence matches {1..1}
> matches {|PT10M|}
> >> }
> >> }
> >>
> >> As you can see, even if it is a single default value (10 minutes),
> >> they are defined as ranges. As durations allow the definition of
> >> default values (and they parse correctly) I think they should be
> >> changed to this:
> >>
> >>   offset existence matches {1..1} matches {
> >> DV_DURATION[at0040] occurrences matches
> >> {0..1} matches {  --
> >> value existence matches {1..1}
> matches {PT10M}
> >> }
> >> }
> >>
> >> As checking a concrete value is always easier than a range I would
> >> suggest to change them to that.
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Questions about the XSD-files.

[Sam Heard]

Hi Seref
Only one XSD set from openEHR. If we upgrade it has to be formal.
Cheers, Sam

On 27/11/2012 2:43 AM, Seref Arikan wrote:
> Greetings,
> Did I get this right? There are XSDs on openEHR web site. There are 
> also XSDs which are different than the first set, provided by LinkEHR.
> If these are XSDs of the published parts of the openEHR 
> specifications, such as RM or AOM, then there should only be one XSD 
> set, published by openEHR.
> If the XSDs belong to parts which are not part of the openEHR specs, 
> having more than one XSD theoretically would not hurt 
> interoperability, since they are not openEHR XSDs until they're 
> published by the foundation, but in practice, this would be a problem 
> waiting to emerge in the future.
> Am I missing something here? Multiple XSDs sounds like a big can of 
> worms to me.
>
> Best regards
> Seref
>
>
> On Mon, Nov 26, 2012 at 5:02 PM, Bert Verhees  > wrote:
>
> Thanks Athanasios and Diego,
>
> It is easier to download then to write it myself ;-)
>
> But still I wonder why the OpenEHR-community is not offering these.
>
> cheers
> Bert
>
>
>
>
> On 11/26/2012 05:51 PM, Diego Bosc? wrote:
>
> Hello Bert,
>
> We created a XML Schema for the demographics part some time
> ago. You
> can download it from here.
>
> 
> http://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd
>
> Regards
>
> 2012/11/26 Bert Verhees  >:
>
> Hi,
>
> I was studying the OpenEHR XSD files, I found they
> validate fine against
> Saxon-EE 1.0 and 1.1
>
> But I have a few points which are not clear to me.
>
> 1)
> In the Structure.xsd I find this line, I don't know why it
> is there.
> 
>
> I commented it out, and it still validates fine.
>
> 2)
> There were some more things in the same file.
> There were no element-declarations to the concrete
> classes, like ITEM_TREE,
> CLUSTER, and so on.
> I would expect them because there are also archetypes in
> CKM based on these
> classes/elements and can be instantiated in XML.
>
> I added them, and now I can generate example XML with
> these classes as root,
> which was not possible before.
>
> 3)
> It would be nice to have elements in the base-types XSD
> too. There is no
> need for it in the OpenEHR implementation, because they
> will never be
> root-element, but it is good to see their XML-structure
> isolated, for
> convenience.
> I will try that and see if they will be a problem.
>
> 4)
> And the last point is, I missed the Demographics.xsd,
> although these
> RM-classes are also archetypeable and can lead too to
> XML-instances.
>
> Thanks
> Bert Verhees
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR / FHIR data types cross analysis

[Sam Heard]

Hi

This is an interesting discussion. It seems that we might have hit the issue
of defining data types independent of a reference model. In a reference
model we do want to know that there are a limited set of types (formally
expressed) that can be used at any point.

I was influenced by the discussion at CIMI that demonstrated this.

So the sort of textural elements you have within the datatypes that allow
someone to say Autumn for datetime (HumanDate) are probably best dealt with
in models where that is appropriate and with a suitable set of
terminologies.

An uncertain datetime is better for processing than a text (soon after my
mother died). There is no doubt about the usefulness of the text, just that
it does not belong in a date field.

The FHIR may be suitable for messages at this point in time, if so, it is
easy to port information to this.

Let's keep this thread alive and get a little broader input. Thomas is
influenced by Eiffel, Grahame by XML. Most developers will probably sit
somewhere in between in terms of requirements for rigor.

Cheers, Sam


> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
> Sent: Sunday, 18 March 2012 11:50 PM
> To: For openEHR technical discussions
> Subject: Re: openEHR / FHIR data types cross analysis
> 
> >> I just wasn't thinking what I wrote this. In FHIR, a boolean data
> >> type, primitive, is a type that can be used in models an is exactly
> >> equivalent to DV_BOOLEAN.
> >
> > but isn't the problem that it doesn't inherit from some DATA_VALUE
> > parent type (Any in HL7 data types)? How can it be one of the
> possible
> > values in a location like ELEMENT.value which would be statically
> > typed to this parent type (as it is in 13606, HL7 RIM and openEHR)
> > unless it is a descendant of this type?
> 
> FHIR has no such restriction - elements must have a type of one or more
> of the defined types, either primitive or complex
> 
> >>> Well, this is the HL7 modelling mentality, trying to create a data
> >>> type class with all possible attributes, some of which can be
> >>> removed in some subclass.
> >>
> >> not at all. nothing is removed in FHIR. There are some data types
> >> where attributes in the superclass are constrained by the
> definitions
> >> in the subclass.
> >> You do the same.
> >
> > do we?
> 
> yes, check out DV_EHR_URI - this is exactly the same pattern for
> exactly the same reason
> 
> > does anyone use the Java.util calendar type? It's hopeless for dates
> > and times!
> 
> I use java.util.Date. don't know anything about calendar. but so what.
> 
> > I think it is mostly the latter - Date is usually used when time info
> > is really not of interest or expected.
> 
> why shouldn't the relationship between date and datetime be the same as
> that between DV_EHR_URI and DV_URI? I haven't defined that, but that
> would be the natural way to do it in FHIR.
> 
> > I want a spec that looks like an openEHR spec ;-) That's useful
> 
> I don't think I'll do exactly like (framemaker!), but others have asked
> for a formal computable statement of constraints.
> 
> >> Should I do anything about them, or are they just there because they
> >> were thinking of straight text? Do they think
> formatting/hyperlinking
> >> is important?
> >
> > that can be constrained in the archetype as well.
> 
> but it generally isn't - and can't be in the archetype builder.
> So I don't know what was intended.
> 
> >> DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates
> >> one of the mappings to being "defining".
> >
> > well 'defining_code' isn't a mapping; a mapping by definition is an
> > association between two things from two different models or
> > ontologies. A defining code is the code corresponding to the text
> > (description) in the value field.
> 
> really? Sounds like a clear difference until you start working at the
> instance level. Say I have a field in which I want to put the concept
> "Asthma". The Snomed-CT code for this is 195967001: Asthma. I didn't
> get his either by NLP, or by user input - it's configured as part of a
> process.
> 
> Now the interpretation of of DV_TEXT is text, possibly with a code. So
> when I'm going to represent that, I'll use DV_TEXT of "asthma" with a
> mapping to snomed code 195967001 in the mappings. The mapping type will
> be 
> hell, I don't know, does anyone use that, and what do they put in it?
> I don't know whether the Purpose_valid invariant means I need one or
> not (Group_id_term_mapping_purpose is not defined anywhere that I can
> find, for example), but I think not. Anyhow, my snomed code goes in a
> mapping. I can't imagine any normal implementer would think differently
> on this point.
> 
> But if I'm doing a DV_CODED_TEXT, then the snomed code goes on the
> defining_code instead of a mapping.
> 
> >> Does that mean that a DV_TEXT couldn't have a "defining" code
> >> 

openEHR / FHIR data types cross analysis

[Sam Heard]

Sorry about the XML slur :) Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
> Sent: Monday, 19 March 2012 8:16 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR / FHIR data types cross analysis
> 
> Hi Sam
> 
> Actually, this has come up in a couple of other places. The FHIR data
> types are defined for use within the FHIR framework. There's two very
> important parts of FHIR that influence the modeling of the data types:
> * the FHIR take on extensibility
> * the fact that all FHIR resources have a narrative section It's become
> clear to me that this will mean that the FHIR data types aren't
> suitable for use elsewhere
> 
> More generally, I don't think you can define a set of data types
> independently of a set of framework assumptions - and therefore data
> types are only independent of reference models if said reference models
> share the same framework assumptions.
> 
> But I'm quite offended by the notion that I'm influenced by XML.
> Bah. Might as well have said that I'm influenced by text.
> Actually, like Thomas, I prefer to work in a 3gl framework ;-)
> 
> Grahame
> 
> 
> On Mon, Mar 19, 2012 at 8:00 AM, Sam Heard
>  wrote:
> > Hi
> >
> > This is an interesting discussion. It seems that we might have hit
> the
> > issue of defining data types independent of a reference model. In a
> > reference model we do want to know that there are a limited set of
> > types (formally
> > expressed) that can be used at any point.
> >
> > I was influenced by the discussion at CIMI that demonstrated this.
> >
> > So the sort of textural elements you have within the datatypes that
> > allow someone to say Autumn for datetime (HumanDate) are probably
> best
> > dealt with in models where that is appropriate and with a suitable
> set
> > of terminologies.
> >
> > An uncertain datetime is better for processing than a text (soon
> after
> > my mother died). There is no doubt about the usefulness of the text,
> > just that it does not belong in a date field.
> >
> > The FHIR may be suitable for messages at this point in time, if so,
> it
> > is easy to port information to this.
> >
> > Let's keep this thread alive and get a little broader input. Thomas
> is
> > influenced by Eiffel, Grahame by XML. Most developers will probably
> > sit somewhere in between in terms of requirements for rigor.
> >
> > Cheers, Sam
> >
> >
> >> -Original Message-
> >> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> >> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
> >> Sent: Sunday, 18 March 2012 11:50 PM
> >> To: For openEHR technical discussions
> >> Subject: Re: openEHR / FHIR data types cross analysis
> >>
> >> >> I just wasn't thinking what I wrote this. In FHIR, a boolean data
> >> >> type, primitive, is a type that can be used in models an is
> >> >> exactly equivalent to DV_BOOLEAN.
> >> >
> >> > but isn't the problem that it doesn't inherit from some DATA_VALUE
> >> > parent type (Any in HL7 data types)? How can it be one of the
> >> possible
> >> > values in a location like ELEMENT.value which would be statically
> >> > typed to this parent type (as it is in 13606, HL7 RIM and openEHR)
> >> > unless it is a descendant of this type?
> >>
> >> FHIR has no such restriction - elements must have a type of one or
> >> more of the defined types, either primitive or complex
> >>
> >> >>> Well, this is the HL7 modelling mentality, trying to create a
> >> >>> data type class with all possible attributes, some of which can
> >> >>> be removed in some subclass.
> >> >>
> >> >> not at all. nothing is removed in FHIR. There are some data types
> >> >> where attributes in the superclass are constrained by the
> >> definitions
> >> >> in the subclass.
> >> >> You do the same.
> >> >
> >> > do we?
> >>
> >> yes, check out DV_EHR_URI - this is exactly the same pattern for
> >> exactly the same reason
> >>
> >> > does anyone use the Java.util calendar type? It's hopeless for
> >> > dates and times!
> >>
> >> I use java.util.Date. don't know anythin

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Sam Heard]

Hi Shinji

We could not get sponsorship for the conference, which is a shame. For that
reason it looks like that will not happen until we have Associates and some
core funding.

I would like to organise some Google handouts at different times each month
- probably 3/month suiting Asia, Europe/Africa and the Americas. Would
others be interested in meeting for a chat every month, with Video. We could
use GoToWebinar for some more formal gatherings.

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
> Sent: Friday, 2 March 2012 10:40 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012
> - POLL
> 
> Hi all,
> 
> Can I resume this topic?
> I am much looking forward to meeting this conference.
> I know there are many problems, but just to do it very great for us.
> 
> Regards,
> Shinji
> 
> 2012/1/13 Thomas Beale :
> > On 13/01/2012 08:14, Ian McNicoll wrote:
> >> I do like the idea but I would prefer that each conference has its
> >> own very clear identity, albeit that some sessions could be shared,
> >> along with venue etc. A couple of the MIE conferences have operated
> >> this way with local informatics conferences being co-hosted/located
> >> with the European event, with some joint sessions but otherwise a
> >> very clear individual agenda and focus.
> >>
> >
> > Right - that could be a solution.
> >
> > - thomas
> >
> > ___
> > 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 lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Sam Heard]

Hi Shinji

We could not get sponsorship for the conference, which is a shame. For that
reason it looks like that will not happen until we have Associates and some
core funding.

I would like to organise some Google handouts at different times each month
- probably 3/month suiting Asia, Europe/Africa and the Americas. Would
others be interested in meeting for a chat every month, with Video. We could
use GoToWebinar for some more formal gatherings.

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
> Sent: Friday, 2 March 2012 10:40 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012
> - POLL
> 
> Hi all,
> 
> Can I resume this topic?
> I am much looking forward to meeting this conference.
> I know there are many problems, but just to do it very great for us.
> 
> Regards,
> Shinji
> 
> 2012/1/13 Thomas Beale :
> > On 13/01/2012 08:14, Ian McNicoll wrote:
> >> I do like the idea but I would prefer that each conference has its
> >> own very clear identity, albeit that some sessions could be shared,
> >> along with venue etc. A couple of the MIE conferences have operated
> >> this way with local informatics conferences being co-hosted/located
> >> with the European event, with some joint sessions but otherwise a
> >> very clear individual agenda and focus.
> >>
> >
> > Right - that could be a solution.
> >
> > - thomas
> >
> > ___
> > 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 lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org

visualizing AQL result

[Sam Heard]

Leykun

The result of the query might be a table or some objects (as XML). The
display of these needs to use a script - which I believe is available in the
public domain. I will copy to Heath to ask about this.

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Leykun
Melkamu
Sent: Friday, 2 March 2012 9:31 AM
To: openehr-technical at openehr.org
Subject: visualizing AQL result

 

Hello!

 

I am a student and working my thesis on openEHR application can I get help
on how to visualize the result of my AQL queries. How can I use the
operational template and the c # code generated from oceans template
designer?  Thanks in advance for your help. 

 

Best regards,

 

Leykun 

-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR (local) terminologies

[Sam Heard]

Hi Diego
Rong has made this generally available - or it is in the download of the
archetype editor.
Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc?
> Sent: Thursday, 1 March 2012 8:39 PM
> To: For openEHR technical discussions
> Subject: openEHR (local) terminologies
> 
> I sent this email when I thought the migration process was over, but it
> wasn't. I am sending it again, sorry if someone receives two copies
> :)
> 
> Is there any place where openEHR local terminology files (e.g. the
> possible values from C_DV_QUANTITY.property or
> DV_CODED_TEXT.defining_code) can be viewed? (as code/description
> tables)
> 
> Regards
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org

openEHR (local) terminologies

[Sam Heard]

Hi Diego
Rong has made this generally available - or it is in the download of the
archetype editor.
Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc?
> Sent: Thursday, 1 March 2012 8:39 PM
> To: For openEHR technical discussions
> Subject: openEHR (local) terminologies
> 
> I sent this email when I thought the migration process was over, but it
> wasn't. I am sending it again, sorry if someone receives two copies
> :)
> 
> Is there any place where openEHR local terminology files (e.g. the
> possible values from C_DV_QUANTITY.property or
> DV_CODED_TEXT.defining_code) can be viewed? (as code/description
> tables)
> 
> Regards
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org

openEHR-technical Digest, Vol 67, Issue 34

[Sam Heard]

Hi Tim
HL7 Twittered about making things more openly available the other
daydoes anyone have the link?
Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Timothy Cook
> Sent: Thursday, 23 February 2012 4:44 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR-technical Digest, Vol 67, Issue 34
> 
> How can anyone say that HL7 is open in any fashion?  You are not free
> to distribute it outside of your organization except in small parts so
> that the specifications cannot reproduced.
> 
> See the paragraph immediately preceding the one previously quoted here:
> 
> "HL7 CORPORATE/ORGANIZATIONAL MEMBERS are authorized to:
> 
> reproduce and distribute Material on an internal basis solely for
> use within their organization;
> reproduce and distribute excerpts of Material (not entire domains
> or chapters) to any customers of a product or service implementing
> those Material, provided that the HL7 Access database may not be
> included, either in whole or in part, in any product intended for
> direct or indirect commercial resale;
> use excerpts of Material to create customized implementation
> guides; and
> use Material in the development of software applications and
> messaging systems for direct use or distribution without additional
> licensing fees."
> 
> There is NOTHING open about this, fee paid or not.
> 
> --Tim
> 
> On Mon, Feb 20, 2012 at 17:55, Thomas Beale
>  wrote:
> > On 20/02/2012 22:34, William Goossen wrote:
> >
> > Hi Heath, Thomas,
> >
> > My experience is that HL7 v3 is an open standard and OpenEHR is
> > proprietary (as owned by the OpenEHR foundation holding the
> > copyrights, albeit I understand that work is underway to sort that
> out).
> >
> >
> >
> > Correction: HL7 is open, although requires a small fee for use;
> > openEHR is an open and free specification. Neither are proprietary;
> > proprietary essentially means 'not openly published and usable'. That
> > does not apply to either HL7 or openEHR.
> >
> > - thomas
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> 
> 
> 
> --
> 
> Timothy Cook, MSc
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> Skype ID == timothy.cook
> Academic.Edu Profile: http://uff.academia.edu/TimothyCook
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR / FHIR data types cross analysis

[Sam Heard]

Sorry about the Eiffel slur J

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Monday, 19 March 2012 8:18 AM
To: openehr-technical at lists.openehr.org
Subject: Re: openEHR / FHIR data types cross analysis

 


Actually, Eiffel has nothing to do with it (I wrote my own date/time
libraries based on ISO 8601 semantics). What I am influenced by is what I
see in CKM and other repositories.

openEHR CKM



NEHTA CKM


On 18/03/2012 21:00, Sam Heard wrote: 

Hi
 
This is an interesting discussion. It seems that we might have hit the issue
of defining data types independent of a reference model. In a reference
model we do want to know that there are a limited set of types (formally
expressed) that can be used at any point.
 
I was influenced by the discussion at CIMI that demonstrated this.
 
So the sort of textural elements you have within the datatypes that allow
someone to say Autumn for datetime (HumanDate) are probably best dealt with
in models where that is appropriate and with a suitable set of
terminologies.
 
An uncertain datetime is better for processing than a text (soon after my
mother died). There is no doubt about the usefulness of the text, just that
it does not belong in a date field.
 
The FHIR may be suitable for messages at this point in time, if so, it is
easy to port information to this.
 
Let's keep this thread alive and get a little broader input. Thomas is
influenced by Eiffel, Grahame by XML. Most developers will probably sit
somewhere in between in terms of requirements for rigor.
 
Cheers, Sam
 
 
 
 
 
 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21360 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0002.png>
-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 19995 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0003.png>

Units, Quantities, etc

[Sam Heard]

Hi All,

I think the units database that we have as part of openEHR tooling allows
for the addition of equivalent and language dependent expressions, as well
as conversion where that is possible.

How about we make that available somewhere to get this going. It does mean
we are not beholden to others and can know when we have UCUM compatible
expressions (convert if necessary).

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale
> Sent: Wednesday, 21 March 2012 11:15 PM
> To: openehr-technical at lists.openehr.org
> Subject: Re: Units, Quantities, etc
> 
> On 21/03/2012 09:28, Grahame Grieve wrote:
> > But the question around can you trust the data is, can you recognize
> > properly when the units are ucum or not? For some reason I haven't
> put
> > my finger on, you are linking the knowing of this with the boundary
> of
> > the type. It's not clear to me why you're making that link.
> >
> > Grahame
> 
> 
> well... good question. So in other words: if there is a units field
> specifically for 'formal' units, is it UCUM only or not? I would have
> said it should be except for annoying problems like the one Heath
> mentioned - UCUM uses '*' for exponent instead of '^' which almost
> everyone else uses
> 
> We could use the same approach as an openEHR DV_PARSABLE, where the
> name of the syntax is stored as well, but this is IMO inviting a
> different kind of pain...
> 
> My answer would be: let's get UCUM doing everything we need (for the
> formal units field I mean, not the informal one); if we can't, we need
> a new UCUM.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org

Archetype authoring attribution

[Sam Heard]

Hi David

 

As the aim for all is interoperability of these things, I would hope that
the information would be two way. I would suggest getting the new experts to
comment on CKM and then derive a 13606 archetype (this is described in the
13606 standard). I would like that to be a future part of CKM but understand
this may seem a little too controlling.

 

If we start creating clinical content specifications in lots of places it
will not really assist medicine a great deal. We estimate that it is costing
health care dearly to do this again, again and again. Particularly when
providers are interested in quality and sharing information.

 

That said, I would attribute the work to openEHR, the original authors,
contributors and any new expert inputs. The license is to openEHR so I guess
it is openEHR that needs attributing if you want to stay with the legal
requirement. The SA does mean that you have to share the derived work under
a similar license, something that some have been worried about. I am
interested in your views on this.

 

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of David
Moner
Sent: Thursday, 22 March 2012 9:33 PM
To: OpenEHR clinical discussions; OpenEHR technical discussions
Subject: Archetype authoring attribution

 




Hello,

 

Back again with the licensing topic of archetypes, with a real use case.

 

We have been asked to help in creating a set of 13606 archetypes for breast
and prostate cancer. Although they will probably incorporate some new
requirements, the main source will be some of the openEHR archetypes
available at the CKM.

Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which
is the state of that discussion), the doubts are the following:

 

- Converting the archetype to a new reference model is considered as a
derivation? Or the openEHR archetype is considered just as a reference
material as could be any textbook or paper?

- The author of the new archetype has to be the one of the openEHR archetype
(Ian McNicoll btw) or the person who in fact creates the new RM-based
archetype?

 

The underlying question here that should be clarified is to define which is
the extension of the concept "derived work".

 

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: 

13606 revisited - list proposal

[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  
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. 




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 

Questions about ADL/AOM 1.5, archetype flattening and operational templates

[Sam Heard]

Hi All

There is no limit to the complexity we can all support - but you will 
lose the clinicians if the level of fragmentation and reuse gets beyond 
a certain point. One advantage of openEHR is that we have pushed the 
very common patterns (e.g. timing, distributed workflow) into the 
reference model.

I would recommend using examples from current models.

Cheers, Sam

On 4/05/2012 1:31 AM, Thomas Beale wrote:
>
> The example below I would say is taking things to extremes. Normally, 
> if you are going to create separate archetypes, they have distinct 
> semantics. Here you are trying to use one archetype for three 
> purposes, but to nevertheless retain the semantic distinctions inside 
> the parent archetype, rather than specifying them in the child 
> archetypes. So one has to ask the question: why bother with separate 
> archetypes here? If you really want to have this ELEMENT archetype for 
> some the purpose of reuse, then you can constraint ELEMENT.name to be 
> the coded term you want in each case i.e. 'systolic BP' etc.
>
> I have to admit I don't see much use in having such an ELEMENT 
> archetype, because it is not really saying anything much. Defining the 
> same thing inline seems to be clearer and easier.
>
> Do you have any more realistic examples?
>
> - thomas
>
> On 03/05/2012 09:18, Diego Bosc? wrote:
>> Ok, let me make an example so I can explain me better. I'm not saying
>> this is the way we should model this case, but just to show that the
>> use case is there.
>>
>> If we get blood pressure archetype and decide to represent systolic,
>> diastolic, and mean arterial pressure as slots to another archetype
>> (in this case pressure_measurement), you get something like this
>>
>> http://img717.imageshack.us/img717/6919/a4e77856c56c4c5499c5d1b.png
>>
>> this is the ADL code:
>>
>> definition
>>  ENTRY[at] occurrences matches {1..1} matches {  -- Blood Pressure
>>  items existence matches {0..1} cardinality matches {0..*; 
>> unordered} matches {
>>  CLUSTER[at0001] occurrences matches {0..*} matches {  -- Blood 
>> Pressure Measurement
>>  parts existence matches {0..1} cardinality matches {0..*; 
>> unordered; unique} matches {
>>  allow_archetype ELEMENT[at0003] occurrences matches 
>> {0..*} matches {  -- Systolic
>>  include
>>  archetype_id/value matches 
>> {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/}
>>  }
>>  allow_archetype ELEMENT[at0006] occurrences matches 
>> {0..*} matches {  -- Diastolic
>>  include
>>  archetype_id/value matches 
>> {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/}
>>  }
>>  allow_archetype ELEMENT[at0009] occurrences matches 
>> {0..*} matches {  -- Mean Arterial Pressure
>>  include
>>  archetype_id/value matches 
>> {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/}
>>  }
>>  }
>>  structure_type existence matches {1..1} matches {
>>  CS occurrences matches {1..1} matches {  --
>>  codeValue existence matches {0..1} matches 
>> {"STRC01"}
>>  codingSchemeName existence matches {0..1} matches 
>> {"CEN/TC251/EN13606-3:STRUCTURE_TYPE"}
>>  }
>>  }
>>  }
>>  }
>>  }
>>
>> ontology
>>  terminologies_available =<"SNOMED-CT", ...>
>>  term_definitions =<
>>  ["es"] =<
>>  items =<
>>  ["at"] =<
>>  text =<"Blood Pressure">
>>  description =<"Blood Pressure">
>>  >
>>  ["at0001"] =<
>>  text =<"Blood Pressure Measurement">
>>  description =<"a meassure of a BP">
>>  >
>>  ["at0003"] =<
>>  text =<"Systolic">
>>  description =<"Peak systemic arterial blood pressure - 
>> measured in systolic or contraction phase of the heart cycle.">
>>  >
>>  ["at0006"] =<
>>  text =<"Diastolic">
>>  description =<"Minimum systemic arterial blood pressure 
>> - measured in the diastolic or relaxation phase of the heart cycle.">
>>  >
>>  ["at0009"] =<
>>  text =<"Mean Arterial Pressure">
>>  description =<"The average arterial pressure that 
>> occurs over the entire course of the heart contraction and relaxation 
>> cycle.">
>>  >
>>  >
>>  >
>>  >
>>  constraint_definitions =<
>>  >
>>  term_binding =<
>>  ["SNOMED-CT"] =<
>>  items =<
>>  ["

Evolution of identifiers (a future/current problem?)

[Sam Heard]

Hi

A couple of key points:

1) We have to maintain a backwardly compatible revision process that 
allows all data from previous instances of the (same version of the) 
archetype to be compatible with the future revision (either of the 
specialisation or the parent). This is formally tested in CKM. This 
greatly simplifies the versioning and maintenance.

2) The inclusion of differential archetypes for specialisation in ADL 
1.5 allows revision of the parent without updating the specialised 
child. This takes away much of the maintenance associated with revision.

3) Versions are NOT backwardly compatible - so in the example the 
specialised archetype would be version 2. The issue is if the 
specialisation is versioned and not the parent. It will be necessary to 
use a different name in the current scheme. We are finding that using a 
different name for radically different archetypes is sometimes a better 
alternative to versioning as people may want to increment one in current 
use.

4) Thomas and others are proposing compatibility records in the data (as 
is used by CDA). The alternative is to have meaningless IDs that are 
reconciled using a source of truth (like CKM). This does require that 
all archetypes are registered in a CKM like environment that is formally 
part of the openEHR ecosystem. I think we will likely end up somewhere 
like that.

5) Having some pressure to limit the number of archetypes out there - 
encouraging alignment - in these early days is very helpful. After all, 
we are seeking interoperability and it does mean we have to put in the 
effort to get people using the same concepts.

Cheers, Sam

On 15/06/2012 12:05 AM, Thomas Beale wrote:
>
> It needs a bit of updating, but most of the answers are in this doc 
> .
>
> - thomas
>
> On 14/06/2012 10:30, Diego Bosc? wrote:
>> Hello all,
>>
>> I have been thinking a little about archetype specialization and 
>> versioning and how do those two relate. I don't know how it is being 
>> solved right now, but seems like a big issue for the future. Take the 
>> following scenario:
>>
>> We have an archetype (e.g. 'openEHR-EHR-Evaluation.problem.v1') and a 
>> specialization of that archetype (e.g. 
>> 'openEHR-EHR-Evaluation.problem-diagnosis.v1'). Now we generate a new 
>> version of the parent archetype (creating a 
>> 'openEHR-EHR-Evaluation.problem.v2').
>>
>> If we create a specialization of 'openEHR-EHR-Evaluation.problem.v2', 
>> what identifier should it have?
>> How can we distinguish which is the parent of archetype mentioned 
>> above ('openEHR-EHR-Evaluation.problem.v1' or 
>> 'openEHR-EHR-Evaluation.problem.v2') using only the identifier 
>> information? (I know that parent information is inside the archetype)
>> If both parent versions of the concept are valid and you generate new 
>> specializations from them, how is this handled?
>>
> *
>
> *
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Regarding the role of ITEM_STRUCTURE

[Sam Heard]

Hi Anthanasios

I think time has shown that this is probably an area of over engineering 
in openEHR. All archetypes are now ITEM_TREE and could be clusters.

If we think of these as providing constraint on an underlying cluster - 
ITEM_LIST is a cluster of ELEMENTs and ITEM_TABLE sets up a set of 
clusters to provide the Information structure of an addressable table.

There is a place for ITEM_LIST and ITEM_TABLE but the other issue is 
these constraints might be brought to bear at any point in an 
information hierarchy.

I have proposed in version 2 of the RM that we make these 
specialisations of CLUSTER as a constraint statement. That would ensure 
backward compatibility.

Cheers, Sam

On 16/06/2012 1:25 AM, Athanasios Anastasiou wrote:
> Hello everyone
>
> I am sending this email to clarify the role of ITEM_STRUCTURE in
> relation to other structures (such as HISTORY and EVENT) both from the
> point of view of EHR semantics as well as the computational view.
>
> My "problem" in one line is that i can't understand if ITEM_STRUCTURE
> are there to ensure that their content is interpreted properly
> semantically or they really "do what they mean" (i.e. they represent
> tables, lists, trees that have to be populated as such).
>
> A related question is also this one:
>
> Is it possible that a C_MULTIPLE_ATTRIBUTE constraint pointing to an
> ITEM_LIST will have upper_unbounded=True?
>
> If yes, then ITEM_LIST would have to be dynamically expanding (and this
> complicates things a little bit but...that's life)...If no, then the
> contents of ITEM_LIST can be considered static (yay!) and you only need
> to know that this is an ITEM_LIST for interpretation purposes (which of
> course is KEY when you come across an ITEM_TREE)
>
> This will help me in two points:
> a) Clarify the role of ITEM_STRUCTURE and use it properly in archetypes
> and templates
> b) Be able to assign widgets properly (and later read data off them)
> when constructing a GUI.
>
> A few more notes are available at the end of this message
>
> All the best
> Athanasios Anastasiou
>
>
>
> What i understand but would like to verify is that ITEM_STRUCTURE do
> what they say they do, i.e an ITEM_LIST represents a dynamic list
> (constrained by some C_MULTIPLE_ATTRIBUTE) and an ITEM_SINGLE
> representsjust one entry (constrained by some C_SINGLE_ATTRIBUTE).
>
> But i am a little bit confused for two reasons:
>
> a) by what is meant by HISTORY.
>
> HISTORY already implies "A list of events" with the type of the list
> being (point or interval)EVENT which could imply "A [single item or
> table] of ITEM_STRUCTURE" OR "A [list,tree] of ITEM_STRUCTURE"and
> this is where it gets confusing.
>
> Does that mean that all of the following are valid? (with respect to
> HISTORY)
>
> *) a dynamic list of events containing dynamic lists of item structure
> (the history.events can expand and so can the item structures held by
> events)
>
> *N1) a dynamic list of events containing static lists of item structure
> (events can expand, but each event is supposed to simply contain a list
> of items that is actually fixed in size).
>
> (dynamic and static expanded for the following lines as well)
> *) A list of trees
> *) a list of tables
> *) a list of single values (this is the most intuitive thingFor
> example, a time series represented as a history of point events of
> single_value...)
>
>
> b) by the explanation given in the specs
> With reference to (*N1) above:
> The example that is given in the spec for ITEM_LIST is that of "parts of
> an address". This is what leads me to believe that ITEM_LIST is not
> supposed to be a dynamic list but just something THAT IS TO BE
> INTERPRETED AS A LIST but from a computational point of view is just a
> list. I really do hope this makes sense. (I have gone through section 6
> in "data_structures.pdf" and that again points to ITEM_STRUCTURE being
> used for interpretation rather than "definition" :-/)
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
>
>

Regarding the role of ITEM_STRUCTURE

[Sam Heard]

Hi Diego

I think David Ingram has made a valuable contribution; these are 
empirical solutions to real problems in real systems. The reality of 
OBSERVATION is that it deals with point in times, intervals ( max, min 
etc) and analogue readings. These need to be handled consistently or we 
end up with combinatorial explosion - lab glucose in LOINC is over 200 
codes.

Satre said that "belief is confusing things with their names". We need 
to look at the classes and the utility provided. When we have a small 
number of archetypes there is no doubt we can manage these things with 
slots etc. But this requires massive alignment very early in the piece.

Cheers, Sam



On 21/06/2012 8:19 PM, Diego Bosc? wrote:
> Hi Thomas&  Ian,
>
> I see what you mean, and I agree that in its current form
> ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there
> are other cases where this is still valid (restrict the ENTRY class in
> its current form I would say that it has no sense either, but maybe
> CARE_ENTRY could be used in the same way). Maybe it is even useful for
> those archetypes which is difficult to tell if they are an Observation
> or an Evaluation :)
>
> 2012/6/21 Ian McNicoll:
>> Hi Thomas / Diego,
>>
>> As far as the published archetypes are concerned we will have thought
>> fairly carefully about if and when to constrain EVENT to Point or
>> Interval, and this is definitely something that should be applied at
>> template level in most cases but, as ever, we have to be careful not
>> to over-apply constraints when the downstream use cases are not wholly
>> clear.
>>
>> Ian
>>
>> On 21 June 2012 09:21, Thomas Beale  
>> wrote:
>>> On 20/06/2012 20:30, Diego Bosc? wrote:
>>>
>>> So you have to select the ITEM_STRUCTURE class but you don't have to
>>> select the EVENT class? (most CKM archetypes have now EVENT and not
>>> INTERVAL_EVENT or POINT_EVENT)
>>> I think it should be allowed/forbidden following only one criteria.
>>>
>>>
>>>
>>> in general, there is no harm not choosing a subtype if you are only
>>> constraining properties of the supertype. In the case of ITEM_STRUCTURE this
>>> doesn't make sense because it is an abstract type with no structure defined;
>>> anything you want to constrain will be in a particular subtype.
>>>
>>> In the case of EVENT however, you can sensibly constrain just EVENT
>>> properties, and if you don't force the subtype, you are saying - I don't
>>> care if this event happens to be a point event or an interval event, which
>>> is entirely reasonable. Although, I must admit I suspect that at least some
>>> of those CKM archetypes probably did really intend only a POINT_EVENT, so in
>>> some cases, the type constraint should be made.
>>>
>>> - 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
>>
>> 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
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

SMART platform and RDF

[Sam Heard]

Hi Kathrin

This is very exciting news and I look forward to catching up on this 
area. It has been attempted on a few occasions, I believe as the OWL 
tooling improves we are likely to see benefits.

Cheers, Sam

On 3/07/2012 8:29 PM, Kathrin Dentler wrote:
> Dear all,
>
> Here in Amsterdam we are working on expressing archetypes as OWL 
> graphs, and actually I think that it would be ideal to host them under 
> the openEHR domain in future.
>
> We transform archetypes from ADL to OWL, with the work of Catalina 
> Costa from Medical University of Graz (previously in Universidad de 
> Murcia) and Leonardo Lezcano from the Universidad de Alcal? as a 
> starting point. Please consult our paper [1] that has been accepted 
> for the KR4HC workshop for details. It is not yet camera ready, but it 
> gives an overview of some advantages of representing archetypes in OWL.
>
> Currently Alberto Maldonado from IBIME, Technical University of 
> Valencia, is doing a research visit in our group. He is working on 
> generating OWL data (individuals) that are compliant with the OWL 
> representation of archetypes from both legacy XML data and archetype 
> compliant XML EHR extracts. The idea is to have normalized clinical 
> data expressed in OWL in order to ease its reuse in clinical research 
> (mainly clinical trials) and quality measurement.
>
> Best regards,
> Kathrin Dentler
>
> [1] http://www.few.vu.nl/~kdr250/prohealth12kr4hc_archetypes_owl.pdf
>
>
>
> Op 03-07-12 10:19, Ian McNicoll schreef:
>> There is quite a bit of interest in the UK in adapting the US-based
>> SMART platform www.smartplatforms.org for UK use. One aspect of SMART
>> involves the definition of a fairly simple API which serves RDF graphs
>> of archetype like objects e.g Blood pressure, allergy. The SMART guys
>> are aware of openEHR and have been quite support of it in the CIMI
>> work, and I understand that they do not see the clinical content
>> definitions underpinning the APIs as core business.
>>
>> It seems to me that there is an interesting possibility of using
>> openEHR archetypes (probably templated) to define the clinical content
>> which is to be expressed as RDF graphs. This will give a much more
>> adaptable and extensible approach + better model governance etc.
>>
>> It seems to me that the key requirement is to be able to create a
>> run-time artefact, in the same way that we create Template data schema
>> but to output RDF rather than XSD. Is this correct and if so, does
>> anyone have any experience with this?
>>
>> The other interesting aspect is that because the SMART API returns
>> mostly ENTRY-level components, these need to be wrapped in some
>> COMPOSITION level metadata. Does it make sense that we actually return
>> very lean EHR Extracts?
>>
>> Ian
>>
>
>

HL7 ANY type

[Sam Heard]

HI Bert
Heath is away but he will share with you that we have been taking the 
same approach. LOINC codes or name values are the basis for our queries 
when there is no specific archetype. So we have the path to the values, 
but use the names of the elements for queries.
Cheers, Sam

On 10/07/2012 8:19 AM, Thomas Beale wrote:
> On 09/07/2012 22:41, Bert Verhees wrote:
>> Op 09-07-2012 17:15, Seref Arikan schreef:
>>> implementation, that would be a big set of data, which you'd have to 
>>> downcast in your own implementation and apply filters.. Would you 
>>> like to discuss your use case in more detail? 
>> Hi Seref,
>>
>> Thanks for your interest.
>>
>> The use case is about, that we need to write a set of archetypes 
>> which is usable as datastorage for a HL7 VMR-model in a 
>> decision-system. In this model, there is an ObservationResult with 
>> type ANY to hold the observation-value.
>> The only query-able solution we can find is to specialize the 
>> archetype to common situations. We have, for example an 
>> ObservationResult related to pregnancy, in a specialized archetype.
>> Depending on the kind of DataValue, there are other attributes.
>
> Hi Bert,
>
> well, the whole idea of archetypes is that you know what particular 
> data configurations are actually being created, out of the billions of 
> ones possible from the statically declared information model. With no 
> archetypes, then you just have the information model, and you can 
> query on that, but you have no idea what you are going to pick up 
> because you don't know what your data are. But nothing technically 
> prevents you from putting in paths that assume e.g. 
> ObservationResult.value is a PQ, i.e. .../value/units or whatever it 
> comes out to be.
>
>>
>> The customers/users, however are not happy with this. They wonder how 
>> it is be done in HL7, of they have the same problem. I don't know, 
>> does someone know?
>
> there's no problem here - it is how any information system works - if 
> there are no archetypes, you just end up querying on the static 
> information model and hope for the best.
>
>>
>> What would be a good solution, it would be good also if AQL had a 
>> solution to query the type of a datavalue, and than it would be 
>> possible to query the value, depending on the type, there would be 
>> another attribute to query.
>
> at the moment this would not generally be possible, because it would 
> rely on the concrete persisted form of the objects including their 
> data type (i.e. 'class name'). The openEHR RM doesn't mandate this, 
> although someone might add it to there private persistence solution. 
> If it were there e.g. if  you added an attribute to LOCATABLE like 
> rm_type: String and then query on that.
>
> Why not just use archetypes and templates? This achieves the same 
> result in a better way. Even if your archetypes are generic for 
> attributes like the above one, obviously some particular data type was 
> chosen at run time. You can include in your archetype all sensible 
> alternatives for the attribute in question, each with its own at-code. 
> Then when the data are stored, they will have the at-code of the 
> actual archetype node used, i.e. the TS or PQ node or whatever. That 
> means you can build an AQL query for exactly that data object.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
>
>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Sam Heard]

Hi Tom

I absolutely agree with your summary. Technically I think making use of 
obsolescence is the appropriate way to go in software. No competent 
vendor will put out an operating system, compiler or software that 
breaks existing tools without doing the work for them.

The point I am making is that there are now health records out there so 
we need to be absolutely clear that existing health records will work 
with changes. If we want to use upgrade scripts these need to be handled 
between releases so that the old and new work at the same time for a 
while and ensure we have planned obsolescence over a period of software 
cycles (say 3-5 years).

Cheers, Sam

On 6/09/2012 11:56 PM, Thomas Beale wrote:
>
> Personally I think the best way to look at this is as follows:
>
>   * specifications will evolve, and they may include breaking changes.
> As a community we should stick to the usual rules (semver.org)
> whereby we identify releases containing breaking changes with a
> new major version
>   * all releases should be published with the list of changes with
> respect to the previous release ('release notes') and a system
> impact statement as follows:
>   o impact of the changes on *existing software*, including tools
> and re-usable libraries
>   o impact of the changes on existing *archetypes and templates*
>   o impact of these changes on *existing data*, and if
> appropriate, migration / transformation algorithms for the
> data to convert to the new form
>   o impact of the changes on *existing queries*, and how they
> should be upgraded if appropriate
>
> Of course we will try our best to minimise such changes. But none of 
> us here are perfect, so we will never totally succeed at that. For the 
> last two items, there would preferably be software tools / scripts etc 
> available to do the work. Overall, the above should ensure existing 
> systems can be made to interoperate with newer systems. Obviously 
> since in openEHR we are somewhat obsessive about reference model 
> stability, we can hope that the impacts will not be great, and in fact 
> will be very acceptable in comparison to most changes in comparable 
> published standards or industry products.
>
> The implication is always there that someone starting an 
> implementation from scratch later on will build a better system. 
> That's life, and it's how the world makes progress. Someone with an 
> older system might have the annoyance of correcting existing queries 
> or whatever, but on the other hand, they will always be ahead in 
> database optimisation, application framework building and other 
> matters. That's life.
>
> I don't believe we can legislate on what organisations actually choose 
> to do with the specifications - in the end it will be up to them. Our 
> job is to make sure adopters can make /informed/ decisions. Our real 
> goal is to show how using the output of openEHR can actually lead to 
> better health outcomes for society.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

Commiting ACTIONs for the same INSTRUCTION ACTIVITY

[Sam Heard]

Hi Pablo,
You need to reversion the persistent composition without the medication in it. 
Ideally an action showing it has been ceased should be recorded in an event 
composition.
Cries that help?
Sam

Sent from my phone

On 12/09/2012, at 0:07, pablo pazos  wrote:

> Hi Sam,
> 
> What "redundant data" means in the context of persisten compositions?
> 
> I.e. if I need to remove a medication from the medication list because the 
> patient no longer takes that drug, as I see it the medication is invalid (not 
> redundant) at the present moment.
> 
> Please be as specific as you can, I really want to understand the difference. 
> Thanks a lot.
> 
> -- 
> 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: Tue, 14 Aug 2012 07:35:49 +0930
> > From: sam.heard at oceaninformatics.com
> > To: openehr-technical at lists.openehr.org
> > Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
> > 
> > Hi All
> > 
> > The openEHR specification is clear about the notion of update/versioning 
> > of a composition or creating a new event. The idea of a persistent 
> > composition is useful for information where new data ALWAYS makes 
> > previous data redundant not incorrect at the time (such as a medication 
> > list in a shared health record). This is useful for allergies and other 
> > lists which have to be maintained.
> > 
> > An event composition will relate to information at a particular time 
> > which may be collected again but does not replace the previous 
> > information. This is usually the case for most recordings. A new version 
> > of this composition will invalidate the previous version (as key data 
> > was missing or incorrect).
> > 
> > Cheers, Sam
> > 
> > On 10/08/2012 7:08 PM, Ian McNicoll wrote:
> > > How is the patient reporting back their exercise activity to the 
> > > clinician?
> > >
> > > I think it is better to create a new Composition for each 'patient
> > > report' rather than re-versioning a single Composition. The question
> > > then is how and, how often, the patient sends a report.
> > >
> > > As an example, let's say the patient reports weekly. In that case I
> > > would generate a new event Composition for each weekly report.
> > >
> > > Perhaps you could use a CLUSTER archetype to represent both
> > > recommended exercise, and the patient reported outcome, to be used in
> > > both the INSTRUCTION/ACTIVITY and in the ACTIONs. Can you gove more
> > > information on some of the detail of the exercise recommendations and
> > > the patient reports.
> > >
> > > Ian
> > >
> > >
> > > On 9 August 2012 19:28, pablo pazos  wrote:
> > >> Hi Ian, thanks for the input.
> > >>
> > >> I'm trying to do it "by the book", obviously clinical input is essential 
> > >> to
> > >> model things :)
> > >>
> > >> What do you think about the ACTION to report patient activity?
> > >>
> > >> Should I create a new composition every time the patient report 
> > >> something?
> > >> or
> > >> Should I version the same composition on every exercise report for the 
> > >> same
> > >> exercise program?
> > >>
> > >>
> > >> At first I was thinking about having one ACTIVITY and versioning
> > >> COMPOSITIONs to represent states, but then ISM states came into play :D
> > >>
> > >>
> > >> In this scenario, I could keep exercise scheduling and activation states
> > >> just in the app, and commit a COMPOSITION only when the exercise is
> > >> finished, so I can interpret the COMPOSTION as a finished 
> > >> activity/exersice
> > >> on our openEHR repository (without putting an explicit state on the 
> > >> ACTION
> > >> archetype), and as you said, changing the state of the ACTIVITY as a much
> > >> higher level by a clinician.
> > >>
> > >> --
> > >> 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: Ian.McNicoll at oceaninformatics.com
> > >>> Date: Thu, 9 Aug 2012 18:45:56 +0100
> > >>> Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
> > >>> To: openehr-technical at lists.openehr.org
> > >>> Hi Pablo,
> > >>>
> > >>> Thanks for the example. It makes more sense now, although I have to
> > >>> say that it feels to me as if you are overloading the idea of
> > >>> ACTIVITY/ACTION in this scenario. My approach would have been to
> > >>> regard the whole exercise program as a single task modelled as an
> > >>> Activity, and just to capture the patient-reported progress as part of
> > >>> the ACTION archetype, and only change state at a much higher-level i.e
> > >>> when the whole program is scheduled, starts or stops.
> > >>>
> > >>> There is nothing technically wrong with what you are suggesting, of
> > >>> course.
> > >>>
> > >>> I would be interested in other's thoughts - not s

Trying to understand the openEHR Information Model

[Sam Heard]

Smaller pieces, although scrolling would be cool.
Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: Randolph Neall<mailto:randy.ne...@veriquant.com>
Sent: ?18/?04/?2013 3:18 AM
To: For openEHR technical discussions<mailto:openehr-technical at 
lists.openehr.org>
Subject: Re: Trying to understand the openEHR Information Model

>The performance is perfectly adequate in all of these systems for the
kinds of queries used in point of care (e.g. typically sub 1-second), and
in some cases where ETL is implemented, the performance is also acceptable.
It's also true that quite a lot of effort and thinking has gone into
optimising AQL queries. There is always a query that can be written that
will take a long time to answer, but so far there is no overlap between
those type of queries and point of care latency requirements i.e. such
queries are always report-oriented, research queries or some other kind of
population query, where a (let's say) 5 second response is perfectly
acceptable.

That's excellent! Can you give any idea how long it takes to retrieve into
live memory and screen on a user's computer an entire EHR record of
"typical" size and complexity? Or does that not generally happen, with
records instead being fetched in smaller pieces?

Randy




On Wed, Apr 17, 2013 at 12:10 PM, Thomas Beale <
thomas.beale at oceaninformatics.com> wrote:

>
> I should probably point out that there are some dozens of openEHR
> operational 
> deployments<http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities>,
> all heavily using AQL for screen population, reporting and so on. The
> performance is perfectly adequate in all of these systems for the kinds of
> queries used in point of care (e.g. typically sub 1-second), and in some
> cases where ETL is implemented, the performance is also acceptable. It's
> also true that quite a lot of effort and thinking has gone into optimising
> AQL queries. There is always a query that can be written that will take a
> long time to answer, but so far there is no overlap between those type of
> queries and point of care latency requirements i.e. such queries are always
> report-oriented, research queries or some other kind of population query,
> where a (let's say) 5 second response is perfectly acceptable.
>
> There is probably about 3 years of experience of such systems now (there's
> more like 6 years experience of commercially deployed AQL) that show that
> the performance challenges of this kind of framework are satisfiable, and
> no longer a research question (they were once obviously!).
>
> The second order types of structures I mentioned below rely less on AQL,
> and more on smart commit type rules / triggers logic, which effectively
> enables pre-built query results to be maintained in a live system.
>
> We're somewhere on a road where we are already riding in motorised
> transport, but we don't really know if what we have today is a Fiat Punto
> or a Maserati. Hopefully it's the Fiat, because that leaves us a lot of fun
> and room to get to the Maserati (at which point we start looking at air
> travel;-).
>
> - thomas
>
>
> On 17/04/2013 15:58, Randolph Neall wrote:
>
>  Hi Seref,
>
>  >Hint: think about how you're going to get data out before thinking how
> you're supposed to keep it. There are lots of possibilities, but you need
> to anchor those with a single method of access. I suggest  a  brief look at
> Archetype Query Language (AQL)
>
>  That's the whole point, Seref--"how you're going to get the data out."
> And certainly AQL is one way to do that. My concern has to do with querying
> performance (deserialization as a prerequisite to record inspection, etc.)
> and the infrastructure resources necessary to support them. Thomas hints at
> possibly some big changes when he said, "There is an emerging set of
> 'second order' object definitions, that use the URI-based referencing
> approach in very sophisticate ways to represent things like care plans,
> medication histories and so on. I can't point to a spec right now, but they
> will start to appear." I don't know how radical that will prove to be. I'd
> assume they'd still occur within the AQL paradigm. But it does appear that
> openEHR itself is evolving on this point and perhaps for good reason.
>
>  Please don't interpret my remarks as any sort of disrespect for openEHR;
> I hope it has been apparent that my respect for the entire system has grown
> as I have learned more about it. Some really brilliant people, perhaps
> inc

Re: Trying to understand the openEHR Information Model

[Sam Heard]

Hi Randy


I guess it does so far at least. I guess there will only be a few back end 
openEHR servers in the future, one or two of which are likely to be open source.


The idea is that the query layer is further away from the implementation layer 
than is usual for a health care system. The way the openEHR data can be stored 
is still an experimental science.


Ocean has an AQL parser which then queries the openEHR repository and is now 
optimised in a number of ways. Some of these are independent of the storage 
mechanism entirely. 


Cheers, Sam



Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Consultant & Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
Senior Visiting Research Fellow, University College London



From: Randolph Neall
Sent: ?Saturday?, ?20? ?April? ?2013 ?12?:?37? ?AM
To: For openEHR technical discussions



Seref, to add to my questions:



> AQL is the most neglected, yet, probably one of the most important components 
> of an openEHR implementation.
 


Does this imply that each implementation of openEHR is sufficiently different 
from others as not to allow for easy sharing of such things as search or 
storage technologies? 




Randy




On Thu, Apr 18, 2013 at 6:09 AM, Thomas Beale  wrote:




On 17/04/2013 22:04, Randolph Neall wrote:



Thomas, somehow I'm not finding the AQL specification. It's probably right 
under my nose on your specification/release page. Also, do you have any 
references describing the AQL processor? Did you write that from scratch?? It 
would seem that the AQL processor would indeed function as a formidable DBMS in 
its own right, at least with regard to reads, capable of managing AND/OR logic 
trees and serving up flat "tables" of joined data structures like any RDBMS. 



Randy 




http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language

- thomas


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130420/0e9da195/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR-technical Digest, Vol 18, Issue 37

[Sam Heard]

Hi William

That road is seductive but assumes that SNOmed or the like covers the concept 
unambiguously. The fact is that the world experts on SNOMED spent weeks 
discussing what codes applied to the BP archetype nodes.and finally agreed 
with the ones I had proposed.

The fact is that the archetypes are often far less ambiguous than the terms in 
an ontology.

Modeling in openEHR will accelerate now we have a widening implementation base. 
The models won't be perfect or all encompassing but they will support high 
fidelity processes and sharing evolving data expressions.

Ontological based approaches may be suitable in 20 years, but will need to be 
based on the clinical models, not the other way around. Clinicians need to 
define what they want to record.

My 2p - Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: William Goossen<mailto:wgoos...@results4care.nl>
Sent: ?28/?08/?2013 6:16 PM
To: openehr-technical at lists.openehr.org<mailto:openehr-technical at 
lists.openehr.org>
Cc: openehr-technical at lists.openehr.org<mailto:openehr-technical at 
lists.openehr.org>
Subject: Re: openEHR-technical Digest, Vol 18, Issue 37

The General problem with the at codes is that each archetype has the same at 
codes. Hence it is not an ontology it refers to but is an internal 
micro-ontology only .

In the DCM approach each node SHALL have a minimum of one external code, 
preferable Snomed CT, which links the data element in the archetype to an 
external ontology, which importantly allows external maintenance and governance 
and facilitates the use in other archetypes or templates as defined in OpenEHR.

Vriendelijke groet,

Dr. William Goossen

Directeur Results 4 Care BV
+31654614458

Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at lists.openehr.org 
het volgende geschreven:

> Send openEHR-technical mailing list submissions to
>openehr-technical at lists.openehr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> or, via email, send a message with subject or body 'help' to
>openehr-technical-request at lists.openehr.org
>
> You can reach the person managing the list at
>openehr-technical-owner at lists.openehr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openEHR-technical digest..."
>
>
> Today's Topics:
>
>   1. Re: Polishing node identifier (at-codes) use cases.
>  (Gerard Freriks)
>
>
> --
>
> Message: 1
> Date: Wed, 28 Aug 2013 13:26:14 +0200
> From: Gerard Freriks 
> To: For openEHR technical discussions
>
> Subject: Re: Polishing node identifier (at-codes) use cases.
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
>
> David,
>
> Can I summarise it for my understanding as:
> - AT codes are pointers to an 'ontology'.
> - AT codes can be considered symbols that represent a particular concept
> - The 'ontology' provides a name that will be used to display the name of a 
> node (concept) in an archetype.
> - When a node is specialised the node name used will indicate a new concept 
> (its meaning has changed)
> - When the archetype is specialised ideally the new concept in the 
> specialisation is a subordinate concept.
> - When a Node is specialised the standard does not prescribe that the new 
> concept is a sub-set of the previous one.
> - The question is: is each Node (and the concept it represents) unique or not.
> - The question is: is it obligatory that each node in the archetype carries a 
> unique code  of the form AT .
>
> My answers to both questions are:
> - Each archetype node is  a unique concept that must have attached to it a 
> unique identifier.
> - Archetype editors must support this.
>
> And I would like to add:
> - When specialising each specialised concept must be a subset of its previous 
> one.
>
>
> Gerard Freriks
> +31 620347088
> gfrer at luna.nl
>
> On 28 aug. 2013, at 09:13, David Moner  wrote:
>
>>
>> I'll try to summarize the origin of the different views we have regarding 
>> this topic and maybe this can be also useful to see why this is not just a 
>> configuration problem of the tools.
>>
>> We can find the explanation of node identifiers in two places (I use the 
>> latest drafts, I think):
>> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, 
>> used to distinguish sibling nodes of the same type. [Pr

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Pablo

Sent from my iPad

On 06/02/2013, at 7:55 AM, "pablo pazos"  wrote:

> Hi Sam, reading more about this, it seems FEEDER_AUDIT_DETAILS is more for 
> copying stuff from non-openEHR systems,
> but from your words I tend to think it can be used also as an audit to copy 
> stuff from openEHR systems. In both cases,
> the use case for creating FEEDER_AUDIT_DETAILS might be when importing 
> records from legacy systems. Is that correct?

Yes...if you are importing complete compositions from another EHR system you do 
not need this as the Audit and contribution details capture all that is 
required.
> 
> In the other hand, I haven't still a clear idea of what is considered the 
> *same system* or *same domain* and
> what should be the criteria to set a limit for the commit use case. As I 
> stated on my previous email (maybe it's not so clear),
> one system could be considered inside or outside the same domain of the EHR 
> Server (where stuff sould be committed),
> so the AUDIT_DETAILS.system_id could vary depending just on what I consider 
> to be on the same domain or not.

The system ID in audit details is the one that is committing the new 
composition. Simple, straight forward.

> 
> BTW, I don't know if this is correct, but I consider importing or copying 
> records from another system a different use case
> than commiting compositions for record sharing. May be FEEDER_AUDIT_DETAILS 
> should be only used for copying/importing
> and AUDIT_DETAILS for committing. What do you think?

Yes, but if you look for sharing data between openEHR systems on the Wiki it 
will show how to preserve the information from the original commit.

Cheers Sam

> 
> 
> -- 
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> http://cabolabs.com
> 
> From: sam.heard at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
> Subject: RE: Questions about commit and AUDIT_DETAILS
> Date: Thu, 31 Jan 2013 10:24:27 +0930
> 
> Hi Pablo
> 
>  
> 
> One simple thing ? the FEEDER_AUDIT_DETAILS is there to let you record when 
> something in this composition came from somewhere else. The AUDIT_DETAILs are 
> what happened here. You do not need to record FEEDER_AUDIT but it can be 
> helpful. You can log it if you want but then it is not clear to others where 
> this came from.
> 
>  
> 
> You need more technical input on the rest.
> 
>  
> 
> Cheers, Sam
> 
>  
> 
> From: openEHR-technical [mailto:openehr-technical-bounces at 
> lists.openehr.org] On Behalf Of pablo pazos
> Sent: Thursday, 31 January 2013 10:03 AM
> To: openeh technical
> Subject: RE: Questions about commit and AUDIT_DETAILS
> 
>  
> 
> Hi guys, thanks fo your answers,
> 
> Now it is more clear for me: what openEHR defines is an inter-system audit, 
> and what I tried to do is to have an intra-system audit (between subsystems 
> of the same system).
> 
> There's only one confusion I need to clarify: isn't the FEEDER_AUDIT_DETAILS 
> designed to record information of the source for record copying between EHR 
> domains/environments? e.g. having FEEDER_AUDIT_DETAILS.system_id == system 
> where the composition was first committed. If so, why the 
> AUDIT_DETAILS.system_id is meant to record the same information? Or better 
> said, is there any difference between FEEDER_AUDIT_DETAILS.system_id and 
> AUDIT_DETAILS.system_id?
> 
> The problem I see is we could use the word "system" for many purposes, and 
> other words like "domain" or "environment" could descrive better what is 
> "inter" or "intra".
> In my case the EHR Server and the EMR apps are each one an independend 
> system, but together they also are a system. If the communication is intra or 
> inter system only depends of who controls each subsystem (EHR Server or the 
> EMR apps). In any case, I need to record an audit of the commit to the EHR 
> Server.
> 
> Consider this:
> 
> If there is a monolitic EMR App that has it's own composition repo (commits 
> data to itself), it could send a copy of the compositions to the EHR Server 
> to share the records with other systems.
> If the Org1 owns the EMR and the Org2 owns the EHR Server, then the system_id 
> == EMR, but if Org2 owns an EMR2 system that commits records to the EHR 
> Server, then for commits from EMR2 the system_id == Org2 (an environment or 
> domain id).
> Is this correct from the openEHR purpose for the AUDIT_DETAILS.system_id?
> 
> 
> About the question asked by Thomas, I don't think we need to record a "device 
> id". In my case a client (i.e. an EMR App) is also a Client/Server system (my 
> apps are all web apps). So, we have a communication architecture like this:
> 
> EHR Server (server) <=> EHR Server (client), EMR (server) <=> EMR (client)
> 
> EHR Server (server): server side of the EHR Server web app
> EHR Server (client): client side of the EHR Server, where admins manage stuff 
> using a web GUI (web browser, device)
> EMR (server): server side of the EMR, storage, logic, etc.
> EMR (client): client side of the EMR, where 

defaultValue/assumedValue in CPrimitive.

[Sam Heard]

Hi All

 

The reason we introduced the assumed value in the Observation.State was to
deal with the fact that many variables may be introduced in regard to the
state of the person when an observation is made - clothing, fasting,
post-challenge, at rest, on exertion, asleep, upright/sitting/lying etc.

 

Actually these 'state' variables are not recorded but are largely assumed to
be of a certain value. So we do not need to say that an ECG is at rest - but
we do need to say that it was an exercise ECG. The state variable for
exertion is assumed to be at rest unless stated. A blood pressure which is
stand alone is assumed to be sitting in most instances. The archetype allows
formal expression of what the relevant state variables are and what they are
assumed to be when they are missing. This is helpful for standardisation of
observations without massive data collection constraints.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ian McNicoll
Sent: Tuesday, 8 January 2013 12:57 AM
To: For openEHR technical discussions
Subject: Re: defaultValue/assumedValue in CPrimitive.

 

Hi Bert,

 

 

Assumed value: This is a statement in an archetype which asserts what should
happen if a value is missing. It can really only apply safely to an element
is Observation/State or in a Cluster archetype intended for use in  state.
Essentially this is a design-time statement of 'clinical knowledge' and
should not end up in data. Personally I don't use this very often as it can
be difficult to know when/how that knowledge can be safely applied. One
reasonable example is in OBSERVATION.body_weight.v1 where the 'State of
Clothing' has an assumed value of 'Lightly Dressed'.

 

 

Default value: Generally applied at template level as it will often differ
depending on the exact use-case. A default value does appear in  run-time
data.

 

As Thomas,says in his reply, Assumed value has rarely been used but it can
sometimes be helpful.

 

On 7 January 2013 13:52, Bert Verhees mailto:bert.verhees at rosa.nl> > wrote:

Please can some one short explain what the difference is between
assumedValue and defaultValue in CPrimitive?

Thanks
Bert

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or
g





 

-- 
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 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: 

csingleattribute and existence

[Sam Heard]

Hi Bert

 

I have been a little irritating about this in the past. The single attribute
could be determined by occurrences but I am not sure of the downstream
implications at this stage.

 

My interest has been in existence as a constraint. Clearly everything is
logically optional at any level if existence is to have any relevance.
Existence as a constraint is therefore binary - something is mandatory or
prohibited. I have proposed in XML that we have existence as a binary
statement 0 or 1.

 

The expression of existence is clearly a tertiary state - optional as well
as mandatory or prohibited - it is only as a constraint that it is binary.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Thomas Beale
Sent: Monday, 7 January 2013 9:57 PM
To: openehr-technical at lists.openehr.org
Subject: Re: csingleattribute and existence

 


Bert,

one very useful thing you can do is to identify guidelines for use of the
current specification. E.g. statements of the form

if existence is set on a single-valued attribute, and there is only one
child object, no occurrences should be set, since they can always be
inferred from the owning attribute's existence. 

and so on. These kind of statements I can add to the ADL 1.5 spec (which we
should treat as the usable spec these days).

thanks

- thomas

On 07/01/2013 11:21, Bert Verhees wrote:





But besides that, suppose you have a CSingleAttribute with REQUIRED set with
more CObjects as alternatives in it. 
All occurrences for the CObjects need then to be set to 0..1, every other
setting is erroneous. 
Occurrences 0..0 is useless, why define a CObject if it may never occur. 
Occurrences 1..1 is useless, why define alternative CObjects if the one
chosen is defined. 

Maybe the occurrences of CObjects should not be looked at when child of a
CSingleAttribute 


occurrences can be 1..1 if it is the only possibility. 


My statement was that it is useless, it can be possible but has no meaning.
Skipping the alternatives is more clear. 
And if there are no alternatives, setting the CSingleAttribute.existence to
REQUIRED does the same. 





occurrences can be 0..1 on two alternatives, with an additional rule that
says that either A or B must be there (thus satisfying the 1..1 in the
attribute itself) 

That is the only meaningful occurrence possible in the CObject. So if there
is only one meaningful, what is the point of making it configurable? 








- 
It is that I am looking further in the world then existing archetypes. 
We had the discussion about the tried enforcing top-down-structure of
archetypes and the consequences of this policy a few weeks ago. 


I'm not sure how this relates to the technical issue we are discussing
here...? 


It is because you advised me to use the existing OpenEHR archetypes and
Java-implementation. I indicated why I don't do that exclusively. 









I am also looking further than the existing Java-libraries, but that I will
soon announce more about this. 


I am not claiming that the current specification approach is perfect. But
the experience I know about elsewhere leads me to think it is pretty
workable; we don't seem to have any problems in most tools or libraries on
this issue. 

If there are aspects you are thinking about in some other kind of archetype,
please share it, that would help. 


No it is not perfect, and yes it is workable. My suggestions were partly
that I was not sure to understand the construct well, and partly to discuss
improvements. 

When I have other issues, I will gladly discuss them. 

Bert 

___ 
openEHR-technical mailing list 
openEHR-technical at lists.openehr.org
  
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or
g 

 

-- 




Thomas Beale
Chief Technology Officer, Ocean Informatics
 

Chair Architectural Review Board,   openEHR
Foundation 
Honorary Research Fellow, University College London
  
Chartered IT Professional Fellow, BCS, British Computer Society
  
Health IT blog   

 

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 

Problem with specialization using the Archetype Editor

[Sam Heard]

Hi
To specialise in the current AE, you open the parent and then
File->specialise.
Cheers, Sam

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Peter Gummer
Sent: Friday, 11 January 2013 3:04 PM
To: For openEHR technical discussions
Subject: Re: Problem with specialization using the Archetype Editor

pablo pazos wrote:

> I think it would be better if the AE copies the parents nodes into the
specialized archetype when the AE user clicks on "File > Specialize", of
course, only when the ADL version is 1.4.
> Manual copying is error prone. What do you think?


I'm not sure, but I think that when you upload a specialised archetype to
CKM it validates it against the parent. You can also use ADL Workbench to
validate it.

Nonetheless, that's a nice suggestion, Pablo. It would need to be a new menu
item, since "File | Specialise" already does something (i.e., it creates a
specialisation of the specialisation). Maybe "File | Update Specialisation"?

It would take a while to implement something like that, however, because
we'd have to make sure it handled everything properly. Even then, I'm sure
that corner cases would remain where the specialised archetypes got out of
step.

ADL 1.5 is the only real solution. I'd rather put that effort into moving to
ADL 1.5.

Peter


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or
g

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Bert

 

I am sure the technical people will respond but it is a good question.

 

The commit time is the time that the author committed it to the system. I
believe this is usually generated on the server to ensure accuracy. When
there is a system with considerable delay between the clinician saving to
the record and the record being stored in the EHR repository, I would use
the Finish Time of the event context for the clinical commit time and leave
the commit time to show when this information became visible as part of the
health record.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Bert Verhees
Sent: Wednesday, 23 January 2013 8:50 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Questions about commit and AUDIT_DETAILS

 

On 01/23/2013 06:11 AM, pablo pazos wrote:

The definition of AUDIT_DETAILS.system_id is: "Identity of the system where
the change was committed. Ideally this is a machine- and human-processable
identifier, but it may not be.".

Let's say I have a CLIENT where COMPOSITIONS are created, and a SERVER where
COMPOSITIONS are committed by the CLIENT.

I understood this as not technically committed (that is the database-server)
but conceptually committed, and that is the machine on which the client-user
is typing/clicking. The client-user gives order to commit a dataset.

This is different if there is an automatic feed of data, in that case, the
feeder-audit is used. 

regards
Bert Verhees

-- next part --
An HTML attachment was scrubbed...
URL: 

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Pablo

 

One simple thing ? the FEEDER_AUDIT_DETAILS is there to let you record when
something in this composition came from somewhere else. The AUDIT_DETAILs
are what happened here. You do not need to record FEEDER_AUDIT but it can be
helpful. You can log it if you want but then it is not clear to others where
this came from.

 

You need more technical input on the rest.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos
Sent: Thursday, 31 January 2013 10:03 AM
To: openeh technical
Subject: RE: Questions about commit and AUDIT_DETAILS

 

Hi guys, thanks fo your answers,

Now it is more clear for me: what openEHR defines is an inter-system audit,
and what I tried to do is to have an intra-system audit (between subsystems
of the same system).

There's only one confusion I need to clarify: isn't the FEEDER_AUDIT_DETAILS
designed to record information of the source for record copying between EHR
domains/environments? e.g. having FEEDER_AUDIT_DETAILS.system_id == system
where the composition was first committed. If so, why the
AUDIT_DETAILS.system_id is meant to record the same information? Or better
said, is there any difference between FEEDER_AUDIT_DETAILS.system_id and
AUDIT_DETAILS.system_id?

The problem I see is we could use the word "system" for many purposes, and
other words like "domain" or "environment" could descrive better what is
"inter" or "intra".
In my case the EHR Server and the EMR apps are each one an independend
system, but together they also are a system. If the communication is intra
or inter system only depends of who controls each subsystem (EHR Server or
the EMR apps). In any case, I need to record an audit of the commit to the
EHR Server.

Consider this:

*   If there is a monolitic EMR App that has it's own composition repo
(commits data to itself), it could send a copy of the compositions to the
EHR Server to share the records with other systems.
*   If the Org1 owns the EMR and the Org2 owns the EHR Server, then the
system_id == EMR, but if Org2 owns an EMR2 system that commits records to
the EHR Server, then for commits from EMR2 the system_id == Org2 (an
environment or domain id).
*   Is this correct from the openEHR purpose for the
AUDIT_DETAILS.system_id?



About the question asked by Thomas, I don't think we need to record a
"device id". In my case a client (i.e. an EMR App) is also a Client/Server
system (my apps are all web apps). So, we have a communication architecture
like this:

EHR Server (server) <=> EHR Server (client), EMR (server) <=> EMR (client)

*   EHR Server (server): server side of the EHR Server web app
*   EHR Server (client): client side of the EHR Server, where admins
manage stuff using a web GUI (web browser, device)
*   EMR (server): server side of the EMR, storage, logic, etc.
*   EMR (client): client side of the EMR, where end users inupt and
visualize data (web browser, device)
*   <=>: HTTP communication (the EHR Server (server) has communication
with the EMR (server) for commit and query)


I don't think the EMR (client) id (the device where the end user is
accessing the EMR(server) from a browser) it's needed for audit at the
application level (maybe it's needed as a low level audit for sys admins).
In my case I need the id of the EMR (server) because it commits stuff to the
EHR Server (server), it doesn't matter if the EMR is part of the same domain
of the EHR Server or not.
Also consider that both of those XXX (server) has fixed IPs, but the EMR
(client) could run from any device, using dynamic IPs, but what is really
needed is the id of the logged user instead of the device id.

In the case above, do you think openEHR audit structures should support the
record of the EMR (server) id when commiting stuff to the server or I should
create my own audit structures to record that information?

Thanks a lot!

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
http://cabolabs.com  

-- next part --
An HTML attachment was scrubbed...
URL: 

Re: Regarding the use of the Demographics Package...

[Sam Heard]

Hi Anthanasios - Heath has been doing something like that



Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Consultant & Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
Senior Visiting Research Fellow, University College London



From: Athanasios Anastasiou
Sent: ?Monday?, ?1? ?July? ?2013 ?9?:?00? ?PM
To: Openehr-Technical


Hello everyone

Would it be good practice to use the demographics package to describe
both the patients for which data are available in a system but also the
users of the system?

As far as the first part is concerned, the demographics package provides
a very good level of detail for describing the parties that could be
involved in healthcare provision for some event.

However, was / is there also the intention of using the same demographic
entities "data store" to perform authentication / access control too?

(I am thinking of:
a) A pre-condition for an operation to be carried out on the existence
of specific PERSON.roles or membership of a PERSON into some GROUP
(which is straightforward); and

b) Providing something like a ROLE(meaning="canLogin") with an
associated CAPABILITY.credentials Archetype that could be used to
perform authentication...Besides the trivial example of having a CLUSTER
with clear text username / password, there could be an Archetype with
just enough information to authenticate a user against an external
service (e.g. an LDAP directory) In this case, the Archetype would not
store username / passwords, just enough information required to connect
to the component that will be performing the authentication to retrieve
a simple yes/no answer at the time of logging in) )

Looking forward to hearing from you
Athanasios Anastasiou




This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130701/36dfd873/attachment.html>

TDS (and TDD) implementations?

[Sam Heard]

Hi
We designed the process to allow ant XML schema generated to be transformed to 
openEHR with a single transform.

I expect it may well be possible to do the reverse. At least it would be 
possible to get to a consistent flattened form.

The reason for the TDS is to validate data using XML tools.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: Daniel Karlsson<mailto:daniel.karls...@liu.se>
Sent: ?14/?06/?2013 5:12 PM
To: openehr-technical at lists.openehr.org<mailto:openehr-technical at 
lists.openehr.org>
Subject: Re: TDS (and TDD) implementations?

Hi Ian,

On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
> Hi Erik,
>
>
> The Ocean TDD->canonical transform is available at
>
>
> http://openehr.codeplex.com/SourceControl/latest#176376
>
>
>
> look for TDD_to_openEHR.xsl
>
>
> As far as I know a generic reverse transform is not possible.

How could that be? Is there something in the TDD format that is not in
the RM format? The intuition tells me that it should be easier going
from the rich RM format to the TDD format than in the opposite
direction. What are the specific issues that make a reverse
transformation problematic? Could anything be changed to make the
transformation possible?

/Daniel
>
>
> There are at least 3 or 4 companies using TDD as part of their CDR
> offering.
>
>
> It would be good to make this part of the managed standard and public
> spec .
>
>
> Ian
>
>
>
> On 30 May 2013 10:21, Erik Sundvall  wrote:
> Hi!
>
>
> Which projects and products out there support TDS (Template
> Data Schema)? And do they support conversion of TDDs (Template
> Data Documents) to standard "canonical" openEHR RM instances
> (in e.g. XML)? Is there any available XSLT, webservice or
> other thing that can convert bidirectionally between TDD and
> openEHR RM-based instances?
>
>
> What about a TDS specification? Is there any published or
>  work-in-progress document? If not is there any entity, group
> or person that could/should be sponsored or bribed to produce
> such a thing? :-) It seems to be on the
> roadmap http://www.openehr.org/programs/specification/roadmap and 
> described there anyway...
>
>
> I think TDS is an essential component in the toolbox in
> practical openEHR integration projects but without a public
> spec, it will be harder to take seriously and hard to make
> compatible implementations.
>
>
> (ExampleTDS-info for people not familiar with the
> approach: 
> http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf)
>
>
> Best regards,
> Erik Sundvall
> Tel: +46-72-524 54 55
> LiO: erik.sundvall at lio.se 
> http://www.lio.se/Verksamheter/IT-centrum/
> LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/
>
> ___
> 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 openEHR Foundation  www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care  www.phcsg.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/c0e3ea26/attachment-0001.html>

Guideline Definition Language (GDL) specifications and GDL-editor release announcement

[Sam Heard]

Congratulations Ring

Thanks for taking such a great leading position with openEHR, which only gets 
stronger with time.

We need to think about how to integrate this in the CKM space so the rules can 
be shared when appropriate.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: Rong Chen<mailto:rong.c...@cambio.se>
Sent: ?12/?03/?2013 1:28 AM
To: openEHR-technical at lists.openehr.org<mailto:openEHR-technical at 
lists.openehr.org>; openEHR-clinical at 
lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>; 
openehr-implementers at lists.openehr.org<mailto:openehr-implementers at 
lists.openehr.org>
Subject: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement

Dear all,

We are pleased to announce the immediate availability of the design 
specifications of Guideline Definition Language (GDL) and its reference 
implementation under open source software licenses. GDL is formal language 
designed to express and to share Clinical Decision Support rules across 
language and technical barriers by leveraging openEHR designs. CDS rules in GDL 
format is agnostic to natural languages, reference terminologies and rules 
engine languages.

There are considerable synergies in the development of clinical models and CDS 
rules. Semantically well-defined clinical models can provide reliable means of 
input and output of the rules. On the other hand, experiences from CDS rules 
development can lead to improvements of the clinical models as well as 
increased motivations to adopt structured and standardized clinical models. 
Reusing existing high-quality clinical models in the form of archetypes would 
hopefully increase the productivity in authoring and maintaining clinical rules.

Please note that GDL is still in development. We aim to submit the GDL 
specifications for review in openEHR in the near future. We look forward to the 
community's feedback to further improve the specifications.

Some important links from this release:

1.   GDL Specifications 
(v.90)<https://github.com/openEHR/gdl-tools/blob/master/cds/docs/specs/gdl-specs.pdf?raw=true>

2.   GDL Editor<http://sourceforge.net/projects/gdl-editor/>

3.   GDL sample 
files<https://github.com/openEHR/gdl-tools/tree/master/cds/cm/guides>

4.   GDL Reference Implementation 
Project<https://github.com/openEHR/gdl-tools/wiki>

Rong Chen
On behalf of the Informatics Team,
Cambio Healthcare Systems, Sweden


Rong Chen, MD, PhD
CMIO, Director of Health Informatics
+46 8 691 49 81

Cambio+ Healthcare Systems AB
Stockholm:
Ringv?gen 100. SE-118 60 Stockholm
Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99
Link?ping:
Brigadgatan 14. SE-587 58 Link?ping
Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99
Epost: info at cambio.se<mailto:info at cambio.se> | Hemsida:www.cambio.se

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/65a5a4de/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 146 bytes
Desc: image001.png
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/65a5a4de/attachment.png>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Guideline Definition Language (GDL) specifications and GDL-editor release announcement

[Sam Heard]

Hi Rong - noticed the Typo (Ring) - it seems I have trouble with names of 
people in Sweden!

Cheers, Sam 



Sent from Windows Mail


From: Rong Chen
Sent: ?12? ?March? ?2013 ?10?:?09? ?PM
To: For openEHR implementation discussions, For openEHR technical discussions, 
openEHR-clinical at lists.openehr.org
Subject: RE: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement




Hi Sam and all,

 

Thanks for the positive feedbacks so far. We really appreciate that.

 

Personally I am very fond of the idea to host GDL rules in CKM. CKM?s support 
of change management, distributed review, indexing and search, translation and 
release sets management (including archetypes/templates, rules and term 
refsets) will immediately benefit the development of rules.

 

Cheers,

Rong

 


Rong Chen, MD, PhD

CMIO, Director of Health Informatics

+46 8 691 49 81 

cid:image001.png at 01CE14CE.DC7B4E10 

Cambio+ Healthcare Systems AB 

Stockholm: 

Ringv?gen 100. SE-118 60 Stockholm 

Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99 

Link?ping: 

Brigadgatan 14. SE-587 58 Link?ping 

Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99 

Epost: info at cambio.se | Hemsida:www.cambio.se 

 



From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Sam Heard
Sent: 11 March 2013 22:04
To: For openEHR technical discussions; openEHR-clinical at lists.openehr.org; 
openehr-implementers at lists.openehr.org
Subject: RE: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement

 



Congratulations Ring

Thanks for taking such a great leading position with openEHR, which only gets 
stronger with time.

We need to think about how to integrate this in the CKM space so the rules can 
be shared when appropriate.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808






From: Rong Chen
Sent:  ?12/?03/?2013 1:28 AM
To: openEHR-technical at lists.openehr.org; openEHR-clinical at 
lists.openehr.org; openehr-implementers at lists.openehr.org
Subject:  Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement



Dear all,

 

We are pleased to announce the immediate availability of the design 
specifications of Guideline Definition Language (GDL) and its reference 
implementation under open source software licenses. GDL is formal language 
designed to express and to share Clinical Decision Support rules across 
language and technical barriers by leveraging openEHR designs. CDS rules in GDL 
format is agnostic to natural languages, reference terminologies and rules 
engine languages.

 

There are considerable synergies in the development of clinical models and CDS 
rules. Semantically well-defined clinical models can provide reliable means of 
input and output of the rules. On the other hand, experiences from CDS rules 
development can lead to improvements of the clinical models as well as 
increased motivations to adopt structured and standardized clinical models. 
Reusing existing high-quality clinical models in the form of archetypes would 
hopefully increase the productivity in authoring and maintaining clinical 
rules. 

 

Please note that GDL is still in development. We aim to submit the GDL 
specifications for review in openEHR in the near future. We look forward to the 
community?s feedback to further improve the specifications. 

 

Some important links from this release:

1.   GDL Specifications (v.90)

2.   GDL Editor

3.   GDL sample files 

4.   GDL Reference Implementation Project

 

Rong Chen

On behalf of the Informatics Team,
Cambio Healthcare Systems, Sweden

 

 

Rong Chen, MD, PhD

CMIO, Director of Health Informatics

+46 8 691 49 81 

cid:image001.png at 01CE14CE.DC7B4E10 

Cambio+ Healthcare Systems AB 

Stockholm: 

Ringv?gen 100. SE-118 60 Stockholm 

Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99 

Link?ping: 

Brigadgatan 14. SE-587 58 Link?ping 

Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99 

Epost: info at cambio.se | Hemsida:www.cambio.se
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/fc14fd1c/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 146 bytes
Desc: image001.png
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/fc14fd1c/attachment-0001.png>

MedInfo 2015 openEHR tutorials

[Sam Heard]

Hi Pablo

I wonder if Jusara could organise a submeeting in an academic/industry forum 
prior to MedInfo?

Cheers Sam

Sent from Windows Mail

From: pablo pazos
Sent: ?Saturday?, ?2? ?August? ?2014 ?9?:?06? ?AM
To: For openEHR clinical discussions, For openEHR technical discussions
Cc: For openEHR implementation discussions

Thanks for the info Heather!

I think we should do something similar to the previous workshops for devs, 
something simple to get newcomers to understand how to work with archetypes in 
software (parsing, processing, validating data, extracting paths, etc), and 
more specific topics for skilled openEHR devs (persistence options, REST APIs, 
querying, reporting, UI generation, ...).

I would love to see a hands-on tutorial in which we can program live and help 
newcomers to pass the first barrier in openEHR software development: lose the 
fear of archetypes.

Also I would like to know how we want to present this, should we submit the 
proposals individualy and then organize or should we coordinate and make one 
proposal with all the workshops/tutorials?

Thanks!

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com


From: heather.les...@oceaninformatics.com
To: openehr-technical at lists.openehr.org; openehr-clinical at 
lists.openehr.org
Subject: RE: MedInfo 2015 openEHR tutorials
Date: Fri, 1 Aug 2014 01:54:59 +
CC: openehr-implementers at lists.openehr.org


Hi Pablo,



We have kept info on Conferences in the wiki: 
http://www.openehr.org/wiki/display/resources/Conferences



See Medinfo 2013: 
http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen,+Denmark.
 2 half day sessions were held then - one clinical modelling focussed and the 
other technical



Regards



Heather



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Friday, 1 August 2014 12:14 AM
To: openeh technical; openEHR Clinical
Cc: openehr implementers
Subject: RE: MedInfo 2015 openEHR tutorials



Hi Shinji!



By chance, do you have the agendas of the previous openEHR developer's 
workshops?



It would be nice to see what has been done, do a little bit of introduction 
workshops for beginners and do some new cool stuff for skilled openEHR devs.



BTW, maybe a good place to coordinate and share info about ideas would be the 
openEHR wiki.



Thanks!

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com



From: skoba at moss.gr.jp
Date: Wed, 30 Jul 2014 10:25:16 +0900
Subject: Re: MedInfo 2015 openEHR tutorials
To: openehr-clinical at lists.openehr.org
CC: openehr-technical at lists.openehr.org; openehr-implementers at 
lists.openehr.org

Hi Pablo and all,

We had developers' workshop at Medinfo2007, 2010 and 2013, and I organized 
developers' workshop 2010, and 2013.

I think the combination of clinical workshop/tutorial half day and developers' 
workshop half day would be better.

I have to write up until the tutorial/workshop dead line, 15 Jan, 2015.

Shinji KOBAYASHI



2014-07-29 13:52 GMT+09:00 pablo pazos mailto:pazospablo at hotmail.com>>:

Hi all!



Since next MedInfo is in Brazil (near Uruguay) I'll be attending for sure. I 
also might present a paper or two and want to propose an openEHR related 
tutorial.



Is other people planning to present openEHR papers or tutorials? It would be 
great if we can coordinate tutorials (and topics) together so we can have our 
"openEHR day" at MedInfo.



What do you think?



We have 1 year to plan this, and that's not a lot of time!



I hope we can join forces and do something nice for the south american openEHR 
community. We are eager to learn from others that already have openEHR working 
in the real world, and learn from their success and failures.

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



___ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___ openEHR-clinical mai

MedInfo 2015 openEHR tutorials

[Sam Heard]

Hi Pablo

Great to hear from you and your plans for Medinfo 2015. I plan to come for the 
meeting and I am sure a lot of others do too. A group of openEHR implementers 
will be meeting in Istanbul before MIE on the Saturday afternoon (venue to be 
decided).

I would hope that there will be sufficient momentum in Brazil to have a high 
profile openEHR stream at Medinfo and take a key role in the conference.

Cheers, Sam

Sent from Windows Mail

From: Pablo Pazos
Sent: ?Tuesday?, ?29? ?July? ?2014 ?2?:?23? ?PM
To: For openEHR clinical discussions, For openEHR implementation 
discussions, For openEHR 
technical discussions

Hi all!

Since next MedInfo is in Brazil (near Uruguay) I'll be attending for sure. I 
also might present a paper or two and want to propose an openEHR related 
tutorial.

Is other people planning to present openEHR papers or tutorials? It would be 
great if we can coordinate tutorials (and topics) together so we can have our 
"openEHR day" at MedInfo.

What do you think?

We have 1 year to plan this, and that's not a lot of time!

I hope we can join forces and do something nice for the south american openEHR 
community. We are eager to learn from others that already have openEHR working 
in the real world, and learn from their success and failures.

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
-- next part --
An HTML attachment was scrubbed...
URL: 

Doctor specialty in the IM

[Sam Heard]

This sounds important to me. There are a number of issues that come to mind:

  1.
There a number of levels that doctors function (Australian label) - Resident 
(no specialty expertise), Registrar (training in this speciality) and 
Consultant (Qualified in this speciality).
  2.
Different countries use the labels differently - e.g. Resident = Registrar in 
Primary Care training in the US and Canada
  3.
Health Professionals moving between countries may function at one level (say 
consultant) in one country and another level in another country (say 
registrar). People may be acting as the consultant while someone is away...or 
head of department or whatever.
  4.
Doctors may state where they are working (Paediatrics) rather than the level 
(Registrar) - both are important

Cheers, Sam

Sent from Windows Mail

From: Heath Frankel
Sent: ?Friday?, ?7? ?November? ?2014 ?6?:?29? ?PM
To: For openEHR technical discussions
Cc: For openEHR technical discussions

Hi Pablo,
I too have this requirement but more specifically I need the speciality of the 
composer that he was performing at the time of writing the composition. 
Therefore option 2 is not viable as this may change over time and the clinician 
may have multiple specialities and they may not even be applicable to the one 
he was performing at the time of being the composer.

I am not keen on option 1 as you need to somehow correlate a participation with 
the composer and we have to replicate what is already specified in the composer 
just to specify the function.

Ideally a speciality attribute should be provided on the composer but that 
would be a RM change.

I think your other_context option is the best available option, but in the 
interest of alignment I would like to get agreement on this, perhaps by 
collaborating on a cluster archetype for author details to be used in the other 
context structure and make this available on CKM.

I actually have some other othercontext archetypes that maybe useful to others 
but unfortunately I don't understand the process on how a techie like me can 
contribute archetypes to CKM that I use in real project because I am not a 
"clinical" modeller.

Regards

Heath

On 7 Nov 2014, at 1:54 pm, "pablo pazos" mailto:pazospablo at hotmail.com>> wrote:

Thanks Thomas,

For this requirement I need to query documents by attending physician 
specialty, so in the 2nd option I'll need to query the demographic server to 
get the ids of the physicians with specialty X, then find the records for 
patient Y with composer contained in that list of physicians.

Of course this is a pretty naive implementation, in this case I would have 
indexes of compositions by specialty, something I can create when the 
composition is committed to the EHR server, then this kind of query will use 
those indexes to avoid the "manual" join between demographic and ehr models.

Yep, the 3rd will need archetyped other_context. Thinking out loud, this kind 
of solution can help on enabling this kind of query by specialty to be 
implemented as AQL, so there will be no need to add another service endpoint to 
the API (thinking of my implementation).

Thanks again!

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com


Date: Thu, 6 Nov 2014 16:08:01 +
From: thomas.beale at 
oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Doctor specialty in the IM


Hi Pablo,

the first is as good as any. Normally PARTICIPATION.function is intended to 
capture the function of the physician in the activity, which could be general 
or specific. It might not be the same as the specialty of the doc, especially 
if that specialsiation is not implicated in this activity.

It makes sense to do 2 if you are already using openEHR demographics, because 
then you can use PARTY_PROXY.external_ref to point to the PARTY in the provider 
DB, and that will have the specialty, and then the participation can be 
something more specific. E.g. a senior surgeon might be an 'assisting 
physician' at a difficult birth being managed by the primary Obstetrician of 
the patient.

I don't think you need to query the demographic DB, just refer to the object, 
unless you actually need to have the specialty in the EHR data.

Option 3 is probably only sensible if it is archetyped that way - otherwise 
noone will expect that info in the context object. But you need to look at how 
clinical people are using the context structure (i.e. look at some Composition 
archetypes) - maybe they are putting this sort of information in there.

- thomas

On 06/11/2014 15:50, pablo pazos wrote:
Hi, I have a small question: if I need to record the specialty of an attendi

How to model relationship between archetypes?

[Sam Heard]

Hi Li
Work flow is managed using instructions and actions. The order is an 
instruction, activities for each test if you like. Actions may include taking, 
sending the sample, receiving, reviewing, acting on the result. At some point 
the status of the Instruction is set to complete. This allows complex pathway 
steps.

Heather Leslie should be able to point you to the archetypes.

I think workflowID is used.

Cheers Sam

Sent from my Windows Phone

From: li wang
Sent: ?11/?09/?2014 6:36 PM
To: For openEHR technical discussions
Cc: For openEHR technical discussions
Subject: Re: How to model relationship between archetypes?

Sorry for not put myself clear.

My model is simple, an doctor requests a lab test and gets corresponding 
result, and the result are related to the request. For example, if the doctor 
orders two lab test requests, full-blood-count-request and 
liver-function-request, then there are two lab test results, 
full-blood-count-result and liver-function-result, and the 
full-blood-count-result is related to the full-blood-count-request, the 
liver-function-result is related to the liver-function-request. So that the 
corresponding result can be found from the request and vice versa.

Is that clear enough?

In programming language, a possible implementation I think may be that there 
are two classes, lab-test-request and lab-test-result, lab-test-result has an 
attribute stores id of lab-test-request instances to hold the relationship 
between these two classes.
Does use LINK in archetypes go the same way? The LINK attribute in archetype 
lab test result points to archetype lab test request, and in lab test result 
archetype instance the LINK attribute stores id of lab test request archetype 
instance? Is that right?

And how to use template to model the relationship between lab test request and 
lab test result?

Thanks a lot!

Kind regards,
Li Wang

On Sep 11, 2014, at 09:09 PM, Athanasios Anastasiou  wrote:

Hello Wang

 > 1. Does LINK require the linking attributes to be explicitly defined in
 > archetypes?
A LINK uses an EHR URI (page 77 in
http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf)
to define its end-points and that can be as detailed as needed. However,
the LINK's mission is not to relate fields (as if it were a foreign key
for example) but to relate concepts which are represented by archetypes.
The overview in Page 23 in that previous document I linked is a very
good starting point about LINKs.


 > For example, should one more LINK typed attribute be added
 > under links attribute in openEHR-EHR-OBSERVATION.lab_test.v1 target at
 > openEHR-EHR-INSTRUCTION.request-lab_test.v1?
It would really depend on what you are trying to do. My recommendation
would be to make sure that all information necessary for defining the
OBSERVATION stays with the OBSERVATION rather than linked to another
entity.

Is it possible for you to share a bit more information about what you
are trying to model?



 > 2. If I use a template with a SECTION node and put both
 > openEHR-EHR-INSTRUCTION.request-lab_test.v1 and
 > openEHR-EHR-OBSERVATION.lab_test.v1 under it using archetype slots, does
 > that means these two archetypes are implicitly related to each other?
If you do it in that way you would effectively be relating SOME
request-lab_test with SOME lab_test in the context described by that
specific template. Better specialise it all the way down to the specific
archetypes you want to use. That relation would be semantic, i.e. for a
process to occur (in the real world) it requires these two pieces of
data to be known / recorded.

 > For example, in openEHR-EHR-SECTION.soap.v1, is OBSERVATION[at0006] node
 > implicitly related to SECTION[at0007]?
They will be related because when it comes to querying for that piece of
data you would have to specify that you require all EHR's that contain
data structured according to that particular template and that
furthermore the OBSERVATION is (for example) 125 BPM.

 > And how to express one to many
 > relationship between these two in template?
Do you mean one section to many observations? It does not exactly work
like this.


The Reference Model is a palette of data structures and each one fits a
particular use (in the "real" world). If you have more than one
OBSERVATIONs associated with the same event, perhaps you need to express
this in a different way.

Which brings us back to an earlier question, what are you trying to model?


Hope this helps.

All the best
Athanasios Anastasiou









On 11/09/2014 13:41, li wang wrote:
   > Thanks a lot!
   >
   > LINK can solve my problems very well. But I still have some questions
   > between using LINK and templates.
   >
   > 1. Does LINK require the linking attrib

Problem with version and specialisation

[Sam Heard]

My take on this is that such archetypes need to be fairly inclusive and stable, 
using templates to constrain.

There is no guarantee that versions will remain compatible. As revisions are 
only extensions, this should work. Versioning (breaking change for existing 
data , needs to be limited to when there is real benefit as software will need 
to change.

Cheers Sam

Sent from my Windows Phone

From: jacky.lauchunkin at gmail.com
Sent: ?22/?09/?2014 10:47 AM
To: openehr-technical
Subject: Problem with version and specialisation

Dear All,
I met a problem when using specialisation and version.
For example, I have two archetypes, openEHR-DEMOGRAPHIC-PERSON.patient.v1 
and openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1. Archetype 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1 is specialised from 
openEHR-DEMOGRAPHIC-PERSON.patient.v1. Let's say the archetype 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1 have modified for several 
times and its current version is v3. And now 
openEHR-DEMOGRAPHIC-PERSON.patient.v1 has upgraded to version 2, 
openEHR-DEMOGRAPHIC-PERSON.patient.v2. Can I simply upgrade 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v3 to version 4 so that I can 
change its specilisation to openEHR-DEMOGRAPHIC-PERSON.patient.v2?


Best wishes!
Jacky.Lau
2014-09-19
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: New paper: Archetype-based data warehouse environment

[Sam Heard]

Congratulations David and to you wonderful colleagues.
Cheers, Sam

Sent from Windows Mail

From: David Moner
Sent: ?Friday?, ?19? ?June? ?2015 ?5?:?37? ?PM
To: For openEHR clinical 
discussions, For openEHR technical 
discussions

Dear all,

My colleagues Luis Marco-Ruiz, Jos? A. Maldonado, Nils Kolstrup, Johan G. 
Bellika and myself have just published a paper titled "Archetype-based data 
warehouse environment to enable the reuse of electronic health record data" in 
the International Journal of Medical Informatics. I think this work can be of 
interest for many of you.

Best regards,
David

Link: http://www.sciencedirect.com/science/article/pii/S1386505615300058

Abstract:

- Background. The reuse of data captured during health care delivery is 
essential to satisfy the demands of clinical research and clinical decision 
support systems. A main barrier for the reuse is the existence of legacy 
formats of data and the high granularity of it when stored in an electronic 
health record (EHR) system. Thus, we need mechanisms to standardize, aggregate, 
and query data concealed in the EHRs, to allow their reuse whenever they are 
needed.
- Objective. To create a data warehouse infrastructure using archetype-based 
technologies, standards and query languages to enable the interoperability 
needed for data reuse.
- Materials and methods. The work presented makes use of best of breed 
archetype-based data transformation and storage technologies to create a 
workflow for the modeling, extraction, transformation and load of EHR 
proprietary data into standardized data repositories. We converted legacy data 
and performed patient-centered aggregations via archetype-based 
transformations. Later, specific purpose aggregations were performed at a query 
level for particular use cases.
- Results. Laboratory test results of a population of 230,000 patients 
belonging to Troms and Finnmark counties in Norway requested between January 
2013 and November 2014 have been standardized. Test records normalization has 
been performed by defining transformation and aggregation functions between the 
laboratory records and an archetype. These mappings were used to automatically 
generate open EHR compliant data. These data were loaded into an 
archetype-based data warehouse. Once loaded, we defined indicators linked to 
the data in the warehouse to monitor test activity of Salmonella and Pertussis 
using the archetype query language.
- Discussion. Archetype-based standards and technologies can be used to create 
a data warehouse environment that enables data from EHR systems to be reused in 
clinical research and decision support systems. With this approach, existing 
EHR data becomes available in a standardized and interoperable format, thus 
opening a world of possibilities toward semantic or concept-based reuse, query 
and communication of clinical data.


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

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Adverse reaction archetype... just published

[Sam Heard]

Congratulations to all, a big topic and enabler.
Sam

Sent from my Windows Phone

From: Heather Leslie
Sent: ‎19/‎11/‎2015 7:02 PM
To: For openEHR clinical 
discussions; For openEHR 
implementation discussions; For 
openEHR technical discussions
Subject: Adverse reaction archetype... just published

Hi everyone,

Just a quick note to let you know that the Adverse Reaction archetype has been 
published.

The evolution of the archetype from its first iteration uploaded in July 2008 
and first ever review in July 2009 through to today has been fragmented and a 
bit ‘staccato’ with review contributions coming from the openEHR, NEHTA and 
Nasjonal IKT CKMs at various times through the process, culminating in 
publication in the international openEHR CKM. I expect that Norway is likely to 
follow suit very soon, others will utilise it at their own pace.

This published archetype is the result of activity in each of the openEHR, 
NEHTA and Nasjonal IKT CKMs:

  *   Activity:
 *   First review round 2009 (openEHR)
 *   5 Review rounds Nov 2010 to Jul 2011 (NEHTA)
 *   Further review round 2012 (openEHR)
 *   4 joint review rounds with FHIR community from Jul 2014-Nov 2015 
(openEHR)
 *   1 parallel review round by Nasjonal IKT in Norwegian language Jun-Sep 
2015 (Norway CKM)
  *   12 Review rounds completed in total, comprising
 *   91 individuals participated from 16 countries
 *   182 individual reviews
  *   0 face to face meetings! All work was done online, including Editorial 
facilitation of reviewer feedback.

And this is definitely our most complex archetype published to date. It is a 
ubiquitous concept, but implemented in many different ways and contexts, and 
the added requirement that flexible extensions will be required for aligned 
activities such as reporting to government or for clinical trial data.

It is anticipated that an aligned FHIR resource will be made available based on 
the common clinical content collaboration.

An absolutely phenomenal effort from everyone!

Now we move on to the Medication family of archetypes in the next few days – 
another extraordinarily complex modelling feat that is currently being 
coordinated by Ian McNicoll. If you would like to participate please adopt the 
archetypes you would like to review: 
http://www.openehr.org/ckm/#showProject_1013.30.27

Kind Regards

Heather

Dr Heather Leslie MBBS FRACGP FACHI
Consulting  Lead, Ocean Informatics
Clinical Programme Lead, openEHR Foundation
p: +61 418 966 670   skype: heatherleslie   twitter: @omowizard

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Scenarios for change type "deleted"

[Sam Heard]

Hi All

Ideas from a clinical perspective:

  1.  A patient or clinician may want to delete a composition from one instance 
of a health record. For example, a correspondence about a surgical operation 
(which is considered sensitive by a patient) might come to a mental health 
service and be added to their record at that site. The patient may ask for it 
to be removed as it is not relevant at that location.
  2.  A patient may want something deleted from their ‘virtual EHR’ or single 
logical record. This will be more difficult and should be deemed to be an error 
of some sort, or have expired from a medicolegal point of view. A label like ‘ 
personality disorder’ entered by an inexperienced nurse at an emergency clinic 
might be an example. Clearly propagating the update of the entire EHR will 
depend on the governance of each instance. We will have to have very clear 
rules for this to be automated and safe. It will, however, always be possible 
to return the record to the state it was at any given interaction.
  3.  A patient may want to delete (or recall) all propagated copies of a 
composition. This would appear to be reasonable, especially in an “opt out” 
situation like we have in Australia. This does not have the medicolegal issue 
that item 2 has as the record will be held in the ecosystem in which it was 
created. However, a trust system will still be required or very strong 
governance of who can propagate such a deletion.
Cheers, Sam

Sent from Mail for Windows 10


From: openEHR-technical  on behalf 
of Bert Verhees 
Sent: Sunday, November 5, 2017 3:15:09 PM
To: For openEHR technical discussions
Subject: Re: Scenarios for change type "deleted"


Here is the a description by royal organization of medical institutions of the 
Dutch law for saving medical data.
https://www.knmg.nl/advies-richtlijnen/artseninfolijn/praktijkdilemmas-1/praktijkdilemma/hoe-lang-moet-ik-medische-dossiers-van-patienten-bewaren.htm

It was years ago 10 years. It is now 15 years. Dutch law is always harmonised 
with European or UN law if there is such law on that level.

There are two considerations.
1) The medical institutions want an end point for their responsibilities to 
keep data access able.
2) Patients have the right to clean up their history.

The medical institution is not required to remove the data after 15 years but 
it has the right to do that. 10 years ago I wrote software to facilitate that 
for the largest GP software user group of the Netherlands.

After those 15 years a patient can demand totally removal of every trace at a 
medical institution.

So. This to close that part of the discussion.

I did not read yet Pablo 's long reply. I will certainly do that maybe later 
today. I am again travelling.

Best regards
Bert

Op zo 5 nov. 2017 00:26 schreef Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>>:
On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

On 15/10/2017 12:49, Pablo Pazos wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

well, a deletion is a deletion, logically. In a non-versioned system, the data 
object would literally disappear.

Logical deletions don't make data disappear, even if it's not under a versioned 
system.

In a versioned system, such as we have, the top version records the fact of 
deletion, which logically applies to the whole versioned object.

That sort of works on a lineal versioned system, the specs are not clear in 
terms of how to handle a deletion in a distributed versioned system.

I agree delete should be considered to affect the status of the whole versioned 
object, but on a branching scenario this is not so well defined or maybe can't 
be implemented at all (see below ***).

The issue I see with versioning for deletion is that amendments, modifications, 
etc. are defined at the same level of the deletions, and the other modification 
types apply to the latest version, not to the whole composition. Considering 
this: shouldn't delete be specified on it's own, separated from other change 
types?

I always had doubts about using a commit to delete something, and now I'm 
starting to understand why :)



This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

it could, if in system A (say in hospital A), the Composition is logically 
deleted but in system B (clinic B) a copy of that Composition (say medications 
list) is modified with a new version; then if this modified Versioned object is 
copied back to system A, system A will see a branched tree, which communicates 
the fact that hospital A thinks the inform

RE: Process to follow for coding using Terminology server

[Sam Heard]

Hi Dileep

There is also the Mappings attribute set which allows you to code but without 
changing the text to the definition in the terminology. You can then code 
something in a range of terminologies.

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: Wednesday, 20 December 2017 7:04 PM
To: For openEHR technical discussions 
Subject: Re: Process to follow for coding using Terminology server

 

Thanks Ian,

 

I tested and it works. Your detailed explanation was a great help. I am sure 
you will make a very good teacher👍. Though Pablo also said the same thing 
first, I did not fully get it.

 

 

regards





   


Dileep V S


Founder


HealtheLife Ventures LLP


m:

+91 9632888113


a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100


w:

  healthelife.in  e:   
dil...@healthelife.in

 

On Wed, Dec 20, 2017 at 2:03 PM, Ian McNicoll mailto:i...@freshehr.com> > wrote:

Hi Dileep,

 

As Pablo says, any DV_TEXT can be sub-classed as DV_CODED_TEXT.

 

How are you storing the composition data ,FLAT JSON?

 

If so you can save coded data for any DV_TEXT node as follows

 

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|code":
 "91936005",

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|value":
 "allergy to penicillin",

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|terminology":
 "SNOMED-CT",

 

 
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent":
 "non-coded text",

 

The fulll RAW JSON equivalent is

 

{

"@class": "ELEMENT",

"name": {

"@class": "DV_TEXT",

"value": "Causative agent"

},

"archetype_node_id": "at0002",

"value": {

"@class": "DV_CODED_TEXT",

"value": "allergy to penicillin",

"defining_code": {

"@class": "CODE_PHRASE",

"terminology_id": {

"@class": "TERMINOLOGY_ID",

"value": "SNOMED-CT"

},

"code_string": "91936005"

}

}

},

 

AQL to retreive is something like

 

  b_a/data[at0001]/items[at0002]/value/value as causative_agent_value,

b_a/data[at0001]/items[at0002]/value/defining_code/code_string as 
causative_agent_code,

b_a/data[at0001]/items[at0002]/value/defining_code/terminology_id/value as 
causative_agent_terminology,

 

Ian

 

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com  
twitter: @ianmcnicoll

 

  

 

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
 

Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

 

On 20 December 2017 at 05:41, Dileep V S mailto:dil...@healthelife.in> > wrote:

Hi,

 

We are in the process of adding a terminology server to code the composition 
date. However many of the nodes that can be coded are text fields (Eg. 
Symptom/sign name in Symptom/sign archetype that we have used in Complaints 
template). As we understand, the data type has to be changed to CODED-TEXT 
before we can store coded data.

 

What is the best practice to do this? Shall we go ahead and edit the 
archetypes, in which case our archetypes will no longer be same as the ones in 
CKM? Are there more robust mechanisms to achieve this without breaking 
compliance to CKM?

 

regards



   


Dileep V S


Founder


HealtheLife Ventures LLP


m:

+91 9632888113  


a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100


w:

  healthelife.in  e:   
dil...@healthelife.in

 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org 
 
http://lists.openehr.org/mailman

RE: Quantities of arbitrary units in openEHR

[Sam Heard]

Hi All

The 'property' editor is available with the archetype editor. Has anyone had
a look at adding the required type and then the whatever bit can be in all
the tools.

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Sebastian Garde
Sent: Thursday, 25 January 2018 7:33 PM
To: For openEHR technical discussions 
Subject: AW: Quantities of arbitrary units in openEHR

 


This sender failed our fraud detection checks and may not be who they appear
to be. Learn about spoofing  

Feedback  

Hi Silje,

 

I think this may 'just' be a modelling tooling issue, openEHR itself
supports this ok.

 

Speaking for CKM, if you upload an archetype with this to CKM, it should
validate the UCUM unit correctly for [arb'U]{whatever}.

However, [arb'u]{whatever} or similar is (very slightly) incorrect in my
understanding:

 

1.  Use the completely vertical ' not ' or similar (at least that is my
understanding).
2.  openEHR uses (implicitly I think, but it may be hidden somewhere in
the spec), the case-sensitive version of UCUM - therefore the U needs to be
upper case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

 

Regards

Sebastian

 

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
Im Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: openehr-technical@lists.openehr.org
 
Betreff: Re: Quantities of arbitrary units in openEHR

 

Hi Silje,

I don't understand how adding an 'Arbitrary' term to the openEHR terminology
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange
units just turn up in the String form you quoted for UCUM arbitrary units in
that field?

(BTW, to ask for a new terminology term, just create a new issue on the PR
tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it to
limit the actual units for property = pressure (say) to only pressure units.
I think we need to define such a service properly

- thomas

 

On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:

Hi all,

 

I'm working on representing medication strengths in archetypes at the
moment. Most medications are thankfully measured in SI units such as mg/ml
or mg/{dose unit}, but others use arbitrary units that are not derived from
any other physical dimensional units. Examples of these are standardized
quality units (SQ-U), focus forming units (FFU), European and American
pharmacopoeia units, anti factor Xa units, or international units (IU).
There are seemingly an unlimited number of these units, and they apparently
make up new ones as they go along (ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.

 

UCUM has a generic way of representing these, as "[arb'u]{whatever}"
(arbitrary unit, name of the unit), but openEHR doesn't seem to have a
property in its Quantity data type for them. Could it be a possibility to
add an "Arbitrary" property to the openEHR support terminology for unit
properties?

 

Also, is it ok to model Quantity elements with a property set but the units
left unconstrained? I've just started trying to add these units to an
archetype (as a concentration, so got around the property issue), and it's
just a never ending task. 

 

Kind regards,
Silje Ljosland Bakke

 

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web:   http://arketyper.no / Twitter:
 @arketyper_no

 





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or
g

 

-- 
Thomas Beale
Principal, Ars Semantica  
Consultant, ABD Team, Intermountain Healthcare
 
Management Board, Specifications Program Lead, openEHR Foundation
 
Chartered IT Professional Fellow, BCS, British Computer Society
 
Health IT blog   | Culture blog
  

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: The openEHR Asia summit succeeded.

[Sam Heard]

Congratulations Shinji

It is your commitment and continuity that has made such a difference. I hope to 
attend the next meeting.

Cheers, Sam



Sent from Mail for Windows 10




From: openEHR-clinical  on behalf 
of Shinji KOBAYASHI 
Sent: Monday, July 30, 2018 9:28:31 PM
To: For openEHR clinical discussions; For openEHR technical discussions; For 
openEHR implementation discussions
Subject: The openEHR Asia summit succeeded.

Dear openEHR colleagues,

We completed all the schedule for the first openEHR Asia summit, and
the second general assembly of Japan.
We also celebrated the new board member, Xudong Lu with many kampais.
Congratulations.
In Asia, openEHR activities are supported with ground roots, and
growing steadily.
Dr Ryan Bannez showed his beautiful EMR system based on Marand
EhrScape in Philippines, and 40 clinics adopted that.
Prof Xudong Lu showed 5 big projects plan in China.
I presented openEHR Japan activity and nation-wide EHR project in
Japan, that involving 75 hospitals.
The next openEHR Asia summit will be in China in the next year.

Best regards,
Shinji Kobayashi

___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Drug dispense entry class question

[Sam Heard]

Hi All



There is the interesting situation as to what constitutes a stop/start and an 
amend for medication. Generally, if it is the same generic substance people 
will want to see it as an amend. This means they do not have to go through all 
the warnings and search again in the database. This is probably of no 
consequence from a data point of view, apart from the fact that you do not want 
to be warned that a patient has previously been on this medication (happens in 
our system).



Cheers, Sam



Sent from Mail for Windows 10




From: openEHR-technical  on behalf 
of Thomas Beale 
Sent: Monday, August 13, 2018 9:07:18 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Drug dispense entry class question



On 11/08/2018 20:50, Karsten Hilbert wrote:
> On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote:
>
> I meant to say that some treatments will not end until the
> patient dies meaning that the COMPLETED state will never be
> reached if we take into account

certainly true in theory, and maybe in reality. But drug treatments
change and different variants may be tried over time - true even for
basics like insulin - so at least for some chronic medication
situations, it probably will be the case that one treatment finishes and
another starts, based on a (?slightly) different order, with this
repeating over time.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Sam Heard]

Hi Tom
If we are using the same archetype for the sender info and receiver data then I 
can see only two sensible options from a design perspective:
1) There are two slots...named receiver and sender.
2) the designer did not know what might be in here so the person filling the 
slot in the template or the data named them differently.

In many situations it will be critical to differentiated sender and receiver 
unambiguously so a cluster could be a sensible solution. Otherwise transfering 
the name of a slot to the name of the archetype in the slot?

Cheers Sam


 Original message 
From: Thomas Beale 
Date: 23/10/18 9:50 pm (GMT+10:00)
To: openehr-technical@lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same 
archetype


I'm becoming convinced that we need to make a technical change to allow the 
slot id be stored in the data, as suggested on the discussion thread already.

So my suggestion for modellers is: assume it will get solved, and do your 
modelling in the natural / preferred way (i.e. don't introduce hacks like extra 
CLUSTERs), and we'll work out an ADL-level solution.

It would help if you can add any detailed info to the description of the PR 
that Sebastian just created.

- thomas


On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:
Hi all! I hope the SEC will discuss and hopefully solve this issue in the 
upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there 
are some archetypes that are based on the (in my opinion fair) assumption that 
it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs 
apart. An example is “Communication capability” 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having 
to change the modelling to circumvent the technical issue, if possible. 😊

Regards,
Silje

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Christmas greetings from the CKM team

[Sam Heard]

Thank you for the great report Heather. It is such a big undertaking and you 
have made a wonderful start.
Cheers, Sam

From: openEHR-clinical  On Behalf 
Of Heather Leslie
Sent: Friday, 21 December 2018 7:25 PM
To: For openEHR clinical discussions 
Cc: For openEHR technical discussions ; 
For openEHR implementation discussions 
Subject: Christmas greetings from the CKM team

Hi everyone,

What a year it has been, and great to be able to reflect back on achievements 
and the gathering momentum.

Silje Ljosland Bakke and myself, as clinical program leads would like to thank 
everyone for their contributions and efforts over the year.

Some stats to provide some insight into the ‘state of the CKM’ and activity 
over the year:

  *   Archetypes
 *   443 archetypes available, distributed over 35 projects; and a further 
102 ungoverned ones evolving in incubators
 *   In projects: 322 are draft; 26 currently undergoing review; 79 are 
published for content
 *   In the past 12 months, 16  archetypes were published; 203 archetypes 
were modified; 66 were created and added to CKM as new models
 *   Archetypes for ECG report and alcohol consumption are just on the 
brink of publication – we can expect them to be published very early in the new 
year.
  *   Templates
 *   85 templates have been submitted, mostly as examples of modelling for 
specific scenarios; 77% are in ungoverned incubators
 *   None have been reviewed to final publication status
  *   Translations
 *   Over the years there have been many archetypes that have been 
translated – we currently have representations in 24 languages, the top five 
(obviously excluding English as the default language of CKM) being:

  *   Portuguese (Brazil) - 119 archetypes translated;
  *   Norwegian Bokmal with 110;
  *   Arabic (Syria) with 78
  *   Spanish (Argentina) 51
  *   Spanish (Spain) 42
Again, a huge amount of work by a very small number of volunteers and largely 
invisible and beneath the surface.

  *   CKM users
 *   As of today, 2106 registered users from 93 countries
 *   Top five countries, by number of registered users: Brasil; UK; USA; 
Australia; Sweden
 *   278 new registrants signed up this year, purely by word of mouth. 
Imagine if we did some marketing!
  *   Reviews:
 *   749 registrants have volunteered to participate in reviews
 *   This years:
*   80 unique reviewers participated this year, 75 completing at least 
1 content review and 5 reviewers participate only in translation reviews
*   23 archetypes completed at least one review round this
*   414 archetype reviews were submitted - 375 content reviews in 39 
review rounds; 34 Swedish translation reviews in 7 review rounds
  *   We have 35 projects; 18 public incubators; 15 private incubators
  *   44 archetypes are available on a ‘view only’ basis as they are ‘owned’ by 
other collaborating CKMs – 29 referenced from the UK Apperta CKM; and 5 from 
the Norway CKM

>From an operations point of view it has been really pleasing to see activity 
>increasing and new users actively engaging in reviews.

Silje and I particularly wish to thank all those who participated as Editors – 
the ongoing effort week by week, herding cats behind the scenes and teasing out 
the patterns that make each archetype implementable is easy to underestimate 
and should not be! And to Sebastian for crafting the CKM itself that powers 
this great collaborative effort.

We thank you all for your participation and encourage those who are not yet 
active to indicate your willingness by adopting archetypes that you’d like to 
participate in for review purposes. We value any and all input. There is no 
‘stupid’ answers as everyone views the content from their own professional 
perspective and unique domain knowledge.

By volunteering your comments we have collectively created an extraordinary 
international resource, with no equal – there is no body of work in the public 
domain that is so broad and deep, and so transparent and freely available. And 
all crowd sourced from volunteer participants. Please pat yourselves on the 
back for an extraordinary effort as a community!!

The year has not been without it’s dramas and disagreements, but I am 
continuously amazed at the respect and collegiality by which people collaborate 
in meetings, on openEHR clinical Slack channels and of course, in the archetype 
reviews. Unfortunately the Slack channels are only available by invite only, so 
if you would like to be included please email me directly - 
heather.les...@atomicainformatics.com
 - and I’ll add you in:

Some big topics have been ‘nailed’ this year – in particular the Medications 
family of archetype, which has constituted a massive amount of work by editors 
and reviewers. Others that have finally been published include the tricksy 
archetypes for: Contraindication; Pulse oximetry; Problem/Diagnosis qu

New Data Types draft + open questions

[Sam Heard]

Dear All

Some further information on my thoughts on these matters.

1. Rubrics

I believe that the textural entry in the record should be the only text that
is carried - not the individual rubrics - as not only is this unnecessary -
but it leads to the danger of use of the rubrics without access to the
terminology service from which they are derived. Remember, if the codes are
there then the rubrics are available if you have access to that terminology
service - and the final 'rubric' or post coordinated string is always
present.

2. Mode changing

Alan's idea of mode is important - some 'modifiers' change the meaning of
the term to something quite different. I suggest that such relationships
have to be in the archetypes - such as 'risk of' or 'family history of' amd
we have archetypes for these notions. The argument for this is that we need
more than these term associations anyway - family history in the future will
require the nature of the relationship and also if it was genetic or not.
Risk will require quantification and almost certainly some details of how it
has been calculated.

Fear of probably does not fall into this category - and should not be
available as a qualifier for this reason. I would suggest a specific place
holder in the problem archetype for this - remebering that agorophobia is a
precoordinated version of this anyway and we should be careful to ensure
that there is some consistency about this.

3. Negation - there are limited terms that have sensible negation - but
family history is an example where you may wish to say that there is no
family history of XXX on the maternal side - as this may be significant. For
this reason there is a negation placeholder in the family history archetype.
This may be required in a number of places.
Negation does not sit well at the term level - how would we describe the
situation above - 'Family history - maternal relatives - not(ovarian
cancer)'. This is not what we want to say - it should be 'not(Family
history - in maternal relatives - of ovarian cancer)' - something that is
only possible in the archetype structure.

Although it is tempting to consider the utility of palpable having
not-palpable as a negation - present and absent do not work so well - and
most polar extremes such as high pitched and low pitched are not negations
at all. What if someone records 'not(liver)'.

These are my initial contributions to this debate.

Cheers, Sam

Dr Sam Heard
The Good Electronic Health Record
Ocean Informatics, openEHR
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard at bigpond.com
www.gehr.org
www.openEHR.org
__


>
> A new proposed draft of the openEHR data types is available at
> http://www.deepthought.com.au/health/openEHR/data_types_1_5_2.pdf. This
> draft includes a major rewrite of the explanation of text types (plain
> text, coded text and friends). The model is not drastically different,
> apart from the addition of a new attribute in DV_TEXT called mappings.
> This is an important attribute, as explained in the text, and covers the
> semantics of classifying terms, equivalents (HL7 "translations"), and
> other scenarios where text (coded or otherwise) is mapped to other terms.
>
> OPEN QUESTIONs
>
> There are a few outstanding questions on the model, which terminology
> experts on this list might like to respond to.
>
> 1. The use of rubrics in TERM_REFERENCE and DV_CODED_TEXT.
> The "rubric" is the textual rendering corresponding to a code. We have
> put it in TERM_REFERENCE, which models exactly the 1:1 asscociation of a
> rubric and a code, and also in DV_CODED_TEXT, where it means the final
> text string generated by the terminology service, taking into account
> qualifiers. For almost all instances of DV_CODED_TEXT, there is only one
> TERM_REFERENCE anyway, so the two rubrics are duplicates. For those
> cases where post-coordination of a primary and one or more qualifiers is
> generated by the terminology service (e.g "lung, left"), the rubric of
> each TERM_REFERENCE will be the primary and the qualifier terms ("lung"
> and "left", respectively), while the rubric of the DV_CODED_TEXT the
> coordinated result ("lung, left").
>
> Sam Heard suggests that there is no reason to keep the rubrics of the
> TERM_REFERENCEs, since a) it is almost always a duplicated of the rubric
> of the DV_CODED_TEXT, and b) it will never be needed even in cases where
> qualifiers are used.
>
> Is there any reason to keep TERM_REFERENCE.rubric?
>
>
> 2. Mode-changing term flag
> We have not currently used a flag to indicate change of mode such as
> "risk of", "history of" etc. Our analysis

TBD's Datatypes

[Sam Heard]

Tom

TBD_2: The language translations should be new versions from my point of
view and should not be transmitted unless they are persistent transactions
and have become the primary data source. DV_CODED_TERM would not be
translated anyway if others agree with no rubrics in DV_CODED_TERM - so this
should enable translations to remain primary on each occasion.

TBD_3: DV_TEXT.Value needs to be unicode for languages that require
unicode - this is a certain requirement.

TBD_5: The idea of statistical reference was that a variety of normals could
be used. I am not sure how to proceed here except that normal ranges will
usually be given without indication of their statistical meaning.

TBD_6: I do not think that this is sensible as there are a huge variety and
they can be expressed in the text string as you have done in the TBD.
Ordinals are really the standard in urinalysis and the fact that a provider
might show the ranges of each ordinal in their product is not so important -
if we move to numeric then the data value can change to a range for example.

TBD_7: I am not sure where the property names come from - I thought it was
part of the ISO standard?? Otherwise, there is a very comprehensive list in
HL7 that I think has too many - but we could reference that??

TBD_8: OK but there are many others - numbers of Red blood cells per cL of
blood, pure ratios 1:128

TBD_9: Yes, how are we to do this - probably needs to be built in - Does the
Eiffel Library have one?

TBD_14 and 15: I think that we need to consider this. I would propose that
our URI is the best way to have a link and the idea of references is the way
to go. I am not sure that we need this - the 'In response to' probably
should be archetyped rather than be a link value - ?? ideas.

Cheers, Sam
________
Dr Sam Heard
The Good Electronic Health Record
Ocean Informatics, openEHR
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard at bigpond.com
www.gehr.org
www.openEHR.org
__


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Subject of care

[Sam Heard]

Dear all

I have been reviewing the subject of care - over family history. It is clear
that the following information is potentially useful:

1. The name of the person so you can refer to them as so-and-so

2. The relationship (father, mother) this might or might not include their
genetic relationship (adoptive) - at present I have this in the genetic
relationship boolean value of the family history problem. I think this is
the most appropriate as it is the only time when it is essential to know
it??

3. The ID of the person in the demographic server - allowing contact details
etc.

Can others think of other issues with identifying the subject of an entry in
the EHR - (not the ehr itself!) Times when this is likely are around the
birth of a child and for family history problems.

Cheers, Sam

Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
Hon. Senior Research Fellow, UCL, London

105 Rapid Creek Rd
Rapid Creek NT 0810

Ph: +61 417 838 808

sam.heard at bigpond.com

www.openEHR.org
www.HL7.org
__




Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
Hon. Senior Research Fellow, UCL, London

105 Rapid Creek Rd
Rapid Creek NT 0810

Ph: +61 417 838 808

sam.heard at bigpond.com

www.openEHR.org
www.HL7.org
__

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Subject of care

[Sam Heard]

Eric

We have fetus and donor as subjects of care also - sorry for omitting that.
Cheers, Sam

> -Original Message-
> From: Eric Browne [mailto:eric at montagesystems.com.au]
> Sent: Monday, 2 December 2002 8:48 AM
> To: Sam Heard
> Cc: Openehr-Technical
> Subject: Re: Subject of care
>
>
> Sam,
>
> I'm not sure if you are only considering familial links. If not,
> then organ donor/donee relationships might give rise to similar
> (and other) identification requirements.
>
> eric
>
> 
> Eric Browne  \  phone:  +61 8 8331 3022
> Montage Systems  \  web:http://www.montagesystems.com.au
> Level 1, 145 The Parade, \  email:  eric at montagesystems.com.au
> Norwood, SA 5067   Australia.
> --------
>
> On Mon, 2 Dec 2002, Sam Heard wrote:
>
> > Dear all
> >
> > I have been reviewing the subject of care - over family
> history. It is clear
> > that the following information is potentially useful:
> >
> > 1. The name of the person so you can refer to them as so-and-so
> >
> > 2. The relationship (father, mother) this might or might not
> include their
> > genetic relationship (adoptive) - at present I have this in the genetic
> > relationship boolean value of the family history problem. I
> think this is
> > the most appropriate as it is the only time when it is essential to know
> > it??
> >
> > 3. The ID of the person in the demographic server - allowing
> contact details
> > etc.
> >
> > Can others think of other issues with identifying the subject
> of an entry in
> > the EHR - (not the ehr itself!) Times when this is likely are around the
> > birth of a child and for family history problems.
> >
> > Cheers, Sam
> > 
> > Dr Sam Heard
> > Ocean Informatics, openEHR
> > Co-Chair, EHR-SIG, HL7
> > Chair EHR IT-14-2, Standards Australia
> > Hon. Senior Research Fellow, UCL, London
> >
> > 105 Rapid Creek Rd
> > Rapid Creek NT 0810
> >
> > Ph: +61 417 838 808
> >
> > sam.heard at bigpond.com
> >
> > www.openEHR.org
> > www.HL7.org
> > __
> >
> >
> >
> > 
> > Dr Sam Heard
> > Ocean Informatics, openEHR
> > Co-Chair, EHR-SIG, HL7
> > Chair EHR IT-14-2, Standards Australia
> > Hon. Senior Research Fellow, UCL, London
> >
> > 105 Rapid Creek Rd
> > Rapid Creek NT 0810
> >
> > Ph: +61 417 838 808
> >
> > sam.heard at bigpond.com
> >
> > www.openEHR.org
> > www.HL7.org
> > __
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
> >
>
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Subject of care

[Sam Heard]

Mario

This may be the case but our subject of care is quite specific - it is the
whole person to whom this information relates.

So information about the fetus or donor can be in the person's record. We
have family history problem - with a specific subject - that is, the
relative. I have modelled relatives to allow each to be adoptive with zero
genetic sharing if required.

It is true that paternity and adoption are not always disclosed - but we
have to go with the patient's belief and test where important.

Cheers, Sam

> -Original Message-
> From: Mario Cortolezzis [mailto:mcortolezzis at innovantis.com]
> Sent: Monday, 2 December 2002 10:03 PM
> To: Sam Heard
> Cc: openehr-technical at openehr.org
> Subject: Re: Subject of care
>
>
> Hi Sam,
>
> Is sometimes (from a specialist view) a specific System (liver or
> heart) not
> treated as a subject of care ? Example SIZE  related to
> the organ (or other subsystem of the body) rather than applied on
> the whole
> individual ?
>
> Cheers, Mario
>
> - Original Message -
> From: "Sam Heard" 
> To: "Eric Browne" 
> Cc: "Openehr-Technical" 
> Sent: Monday, December 02, 2002 3:09 AM
> Subject: RE: Subject of care
>
>
> > Eric
> >
> > We have fetus and donor as subjects of care also - sorry for omitting
> that.
> > Cheers, Sam
> >
> > > -Original Message-
> > > From: Eric Browne [mailto:eric at montagesystems.com.au]
> > > Sent: Monday, 2 December 2002 8:48 AM
> > > To: Sam Heard
> > > Cc: Openehr-Technical
> > > Subject: Re: Subject of care
> > >
> > >
> > > Sam,
> > >
> > > I'm not sure if you are only considering familial links. If not,
> > > then organ donor/donee relationships might give rise to similar
> > > (and other) identification requirements.
> > >
> > > eric
> > >
> > > 
> > > Eric Browne      \  phone:  +61 8 8331 3022
> > > Montage Systems  \  web:http://www.montagesystems.com.au
> > > Level 1, 145 The Parade, \  email:  eric at montagesystems.com.au
> > > Norwood, SA 5067   Australia.
> > > 
> > >
> > > On Mon, 2 Dec 2002, Sam Heard wrote:
> > >
> > > > Dear all
> > > >
> > > > I have been reviewing the subject of care - over family
> > > history. It is clear
> > > > that the following information is potentially useful:
> > > >
> > > > 1. The name of the person so you can refer to them as so-and-so
> > > >
> > > > 2. The relationship (father, mother) this might or might not
> > > include their
> > > > genetic relationship (adoptive) - at present I have this in the
> genetic
> > > > relationship boolean value of the family history problem. I
> > > think this is
> > > > the most appropriate as it is the only time when it is essential to
> know
> > > > it??
> > > >
> > > > 3. The ID of the person in the demographic server - allowing
> > > contact details
> > > > etc.
> > > >
> > > > Can others think of other issues with identifying the subject
> > > of an entry in
> > > > the EHR - (not the ehr itself!) Times when this is likely are around
> the
> > > > birth of a child and for family history problems.
> > > >
> > > > Cheers, Sam
> > > > 
> > > > Dr Sam Heard
> > > > Ocean Informatics, openEHR
> > > > Co-Chair, EHR-SIG, HL7
> > > > Chair EHR IT-14-2, Standards Australia
> > > > Hon. Senior Research Fellow, UCL, London
> > > >
> > > > 105 Rapid Creek Rd
> > > > Rapid Creek NT 0810
> > > >
> > > > Ph: +61 417 838 808
> > > >
> > > > sam.heard at bigpond.com
> > > >
> > > > www.openEHR.org
> > > > www.HL7.org
> > > > __
> > > >
> > > >
> > > >
> > > > 
> > > > Dr Sam Heard
> > > > Ocean Informatics, openEHR
> > > > Co-Chair, EHR-SIG, HL7
> > > > Chair EHR IT-14-2, Standards Australia
> > > > Hon. Senior Research Fellow, UCL, London
> > > >
> > > > 105 Rapid Creek Rd
> > > > Rapid Creek NT 0810
> > > >
> > > > Ph: +61 417 838 808
> > > >
> > > > sam.heard at bigpond.com
> > > >
> > > > www.openEHR.org
> > > > www.HL7.org
> > > > __
> > > >
> > > > -
> > > > If you have any questions about using this list,
> > > > please send a message to d.lloyd at openehr.org
> > > >
> > >
> > >
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Action specifications

[Sam Heard]

Aniket

Thanks for that.
Thanks for your thoughts.

> There are finite orders in the Medical Terminology
> which can be classifed according to the department and
> coded.
> Effort such as CPT(Common procedural terminology) can
> be extended and continued to encompass all such
> 'action specifications'.
> Thus the medical record can be structured broadly into
> a.Enquiry specifications(history)

We call these observations (as per Rector) - the subject is the source.

> b.Examination specifications(clinical examination)

We also call these observations - the clinician is the source.

It is quite difficult to separate these more conclusively - a patient may
say they are constipated and have not used their bowels for 5 days - in a
nursing home a care attendant might notice that the patient has not used
their bowels for 5 days. These are no different except in source and we have
found it helpful to use the same information component.

> c.Action specifications which can be further divided
> into
> 1.Clinical actions(Temparature,Pulse,Blood Pressure
> etc.)

As we are only concerned with the record - we can record these as
observations - but they can be the subject of an instruction. For these
types (having their own archetype) the specification is not so important -
but with medication and other complex instructions it becomes very helpful
to reuse the instruction data.

> 2.Laboratory actions(All lab orders)
These are instructions

> 3.Procedure actions(OT,Cath-lab)
These are often complex records - but for us at present are an observation
with the ability to accept an action specification.

> 4.Medication actions.
Administration is the same as procedure - but the medication order is an
instruction.


Cheers,


Sam


> Thus the terminology can be classified and coded.
> Based on the Clinical experiences the frequency of
> these 'Specifications'can be varied and we amy have a
> more or less structured Medical record.
> Furhtermore,based on the granularity of enquiry
> specifications we may be able to classify the results.
> CPGs can be incorporated in these.
> Comments
> ANIKET
>
> --- Sam Heard  wrote:
> >
> > Dear All
> >
> > In developing an ontology for health record
> > recordings - an archetype
> > ontology - I have come to the idea that there is a
> > great deal of utility in
> > the idea of an 'action specification'. This is the
> > part of an instruction
> > that says what to do - not when (or under what
> > conditions) to do it.
> >
> > Let me give you an example:
> >
> > A medication order is an instruction:
> >
> > medication=Amoxycillin: dose=250mg: route=IV:
> > frequency=three times daily
> >
> > The action specification is:
> >
> > medication=Amoxycillin: dose=250mg: route=IV
> >
> > The when part is:
> >
> > frequency=three times daily
> >
> > OR  A Pap test notification instruction might
> > consist of:
> >
> > Action is Pap Test & send specimen to laboratory
> > When is two years since last pap test OR 1/1/03
> >
> > The important thing is that the 'action
> > specification' can be reused in the
> > EHR as a record of what was done. So a medication
> > administration reuses the
> > action specification of a medication order - and has
> > a record of who
> > administered it - likewise for the Pap test.
> >
> > There may be no need to do this at the information
> > model level - perhaps
> > leave it to the application. But there are some
> > advantages - a consistent
> > description of what is to be done and what was done
> > using the same
> > structure - guaranteed transformation from an
> > instruction to recording an
> > action.
> >
> > Comments?
> >
> > Cheers, Sam
> > ________
> > Dr Sam Heard
> > Ocean Informatics, openEHR
> > Co-Chair, EHR-SIG, HL7
> > Chair EHR IT-14-2, Standards Australia
> > Hon. Senior Research Fellow, UCL, London
> >
> > 105 Rapid Creek Rd
> > Rapid Creek NT 0810
> >
> > Ph: +61 417 838 808
> >
> > sam.heard at bigpond.com
> >
> > www.openEHR.org
> > www.HL7.org
> > __
> >
> >
> >
> >
> >
> > 
> > Dr Sam Heard
> > Ocean Informatics, openEHR
> > Co-Chair, EHR-SIG, HL7
> > Chair EHR IT-14-2, Standards Australia
> > Hon. Senior Research Fellow, UCL, London
> >
> > 105 Rapid Creek Rd
> > Rapid Creek NT 0810
> >
> > Ph: +61 417 838 808
> >
> > sam.heard at bigpond.com
> >
> > www.openEHR.org
> > www.HL7.org
> > __
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Subject of care

[Sam Heard]

Tom

The names of child or grandmother should not be via demographic as this
would also have privacy issues.

Next of kin - has legal status and should be via demographics.

Sam

> -Original Message-
> From: Thomas Beale [mailto:thomas at deepthought.com.au]
> Sent: Tuesday, 3 December 2002 12:03 AM
> To: Sam Heard
> Cc: Openehr-Technical
> Subject: Re: Subject of care
>
>
>
>
> Sam Heard wrote:
>
> >Dear all
> >
> >I have been reviewing the subject of care - over family history.
> It is clear
> >that the following information is potentially useful:
> >
> >1. The name of the person so you can refer to them as so-and-so
> >
> but not in the EHR as such - in some places like Norway, it is not
> allowed to have patient name or some other kinds of identifying
> information in the EHR. So it has to be in the demographic server, ad
> referenced from the EHR by meaningless ids. On the screen this will of
> corse be invisible.
>
> - thomas beale
>
>
>
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Categorising EHR Content

[Sam Heard]

 the event "person X was made redundant from
> > > their employment today"
> > > may have significantly greater effect on X's future
> > > health ( or the
> > > health of a close friend/relative ), than "person X
> > > was diagnosed with
> > > mumps today". If this is the case, then surely such
> > > events should
> > > legitimately be recorded in an EHR?
> > >
> > > I have problems with lumping too many things under
> > > observations, without
> > > distinguishing between "state" and "changes to
> > > state". Consider the
> > > following:-
> > >
> > > A. The _observation_ "subject  weighs Y kilograms"
> > > is a state recording.
> > > B. The _observation_ "subject experienced severe
> > > pain in lower left abdomen"
> > >is an event recording. An event causes a change
> > > of state.
> > > C. The _action_specification_ "appendectomy" is a
> > > process recording. It
> > >similarly causes a change of state.
> > >
> > > In the above, openEHR places A and B in the
> > > observation category. But
> > > from a healthcare perspectve, B is closer to C, than
> > > to A.
> > >
> > > Someone looking back in time through an EHR might be
> > > looking for
> > > seminal events of a certain class.  Again, consider
> > > a person admitted
> > > to an Itensive Care Unit (ICU) with first degree
> > > burns. The current
> > > "Service-Action" view of the world emphasises the
> > > care provided at
> > > the ICU, thus de-emphasing the important
> > > change_of_state event, namely
> > > the burn event.  The "Service-Action" view of the
> > > world portrays the
> > > burn_event as an attribute (observation) of the
> > > emergency care act. Surely
> > > a more appropriate approach should be to consider
> > > the emergency care act
> > > as a consequence of the burn event. This would also
> > > allow for subsequent
> > > trauma counselling to be related to the same event,
> > > rather than to the
> > > ICU burns treatment _action_specification_.
> > > Consequently, I believe that
> > > openEHR should include an _event_ archetype.
> > >
> > > A similar argument can be mounted for representing
> > > risks in their own
> > > right, rather than mere observations. Unfortunately,
> > > today's risks are often
> > > tomorrow's virtues and vice versa. Yet, given
> > > today's medical knowledge,
> > > the _observation_ "Person X smokes 50 cigarettes per
> > > day" carries
> > > significant value beyond the care event for which
> > > the observation is
> > > being recorded. Consequently, I believe there are
> > > good grounds for
> > > establishing a _risk_ archetype.
> > >
> > 
> > > regards,
> > > eric
> > >
> > >
> > 
> > >
> > > On Wed, 4 Dec 2002, Sam Heard wrote:
> > >
> > > >
> > > > Aniket
> > > >
> > > > Thanks for that.
> > > > Thanks for your thoughts.
> > > >
> > > > > There are finite orders in the Medical
> > > Terminology
> > > > > which can be classifed according to the
> > > department and
> > > > > coded.
> > > > > Effort such as CPT(Common procedural
> > > terminology) can
> > > > > be extended and continued to encompass all such
> > > > > 'action specifications'.
> > > > > Thus the medical record can be structured
> > > broadly into
> > > > > a.Enquiry specifications(history)
> > > >
> > > > We call these observations (as per Rector) - the
> > > subject is the source.
> > > >
> > > > > b.Examination specifications(clinical
> > > examination)
> > > >
> > > > We also call these observations - the clinician is
> > > the source.
> > > >
> > > > It is quite difficult to separate these more
> > > conclusively - a patient may
> > > > say they are constipated and have not used their
> > > bowels for 5 days - in a
> > > > nursing home a care attendant might notice that
> > > the patient has not used
> > > > their bowels for 5 days. These are no different
> > > except in source and we have
> > > > found it helpful to use the same information
> > > component.
> > >
> > === message truncated ===
> >
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> >
>
>
>
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org