On 11/11/2011 7:19 PM, Erik Sundvall wrote:
When a value (e.g. upper bound) may be either a number or a symbol (*
or infinity) most recieveing software will need to have logic
separating the cases anyway, no matter how they are serialized.
So then I wonder how much harder it would be to
On 11/11/2011 11:50 PM, Thomas Beale wrote:
occurrences: 1..*
well that's my opinion as well, and XML-ers always react badly! The
'proper' parser code for dealing with this form, used in the ADL parser
is (from the .y file):
Well I consider myself an XML-er and I don't see massive problems
On 12/11/2011 1:16 AM, Ian McNicoll wrote:
Apart from the size issue, readability is a particular problem because
of the verbosity of the current XML schema.
I'm not convinced that human readability should matter too much
(especially seeing ADL is meant to be the human readable format
- if we
On 11/11/2011 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
WHat are the rules for establishing new URNs?
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml
and RFC 3406
I think a well designed IHTSDO urn specification could be useful.
urn:ihtsdo:SCT-AU:20100131+:refset:135394005
etc
This doesn't help out with other terminology sets
I'm confused as to whether the intention here was really URI, URL or
URN?
My understanding was that the use of DV_URI for term binding in archetypes was
more in the vein of global identification of resources (more URN)
rather than actually telling the software how to get to the resource
(ala
Just to clarify some more, my contention is that you cannot
look inside a arbitrary URI to pick out values without
looking at the formal 'scheme' dependent spec.
So in the case of a 'http' URI, we can read the spec and know
what the bits mean - _for the purposes of fetching data
from web servers
- we need some way to define/specify what is the canonical form of a
URI/URN, we must agree in a terminology of names (of terminologies :D) and
subsets.
? - Snomed is the same as SNOMED? or ICD10 is the same as ICD 10 or CIE 10
(CIE = ICD in spanish)?
- we cannot rely of one tool
How about we just point the notifications at the implementers list then? Or
do people think we need a new list? (The HL7 experience of 40 + lists makes
me allergic to more lists ;-)
I am with you on the dangers of too many lists - but I think there should be a
difference between lists that
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
Yes - that's fine. I was thinking you wanted to represent
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
I know that these aren't used much at the moment,
but section 3.2 of the ADL draft is wrong
because it suggests that
\u
\u
are both acceptable quotation forms for unicode
character points. However, I think that the long
form () must have a capital U
to distinguish it. It is
4.5.1.2 still using ISO/IEC 10646 escape
sequences in the example string but these have
now been removed from ADL strings (the text
refers to the ISO 10646 as well)
Andrew
[Heath Frankel]
I understand your point here but if we cannot have some kind of schema
migration mechanism we will need a new schema per release, which is
something that I don't think anyone wants.
Yes - I don't want that either. I bring it up because if we are allowing
minor schema changes
The question is, what do we do when we do have a data breaking schema
change, like potentially in r1.1? I suggest that we just go with
http://schemas.openehr.org/v1.1 and we can assume the old
http://schemas.openehr.org/v1 meant r1.0.x. It wasn't expected to have such
a substantial schema
Actually the namespace decision including its current format was made in
conjunction with other openEHR members including yourself and Rong as far as
I remember.
Yes, sorry - wasn't trying to blame anyone :) I meant that the final
decision as to what actually went into the schemas was
done by
ok - this approach more or less replicates the release id approach
already in use, but converts it to a URL.
Except, this is a change that occurs in all xml _instances_, not just
the schema files. So every reference model document in every
system in existence now has to handle two different
CRs in this release have necessitated some very small (non-data
affecting) changes in the schema BaseTypes.xsd (impact statement of
Release 1.0.2 at
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/release_notes_1.0.2.htm
; published Release 1.0.1 schemas
The grammar (pasted in the spec) for the use_node
slot refers to object_path which is not actually
defined in the path grammar. Furthermore, I can't
actually tell from the spec whether use_node
is restricted to absolute paths, or whether it can
also accept relative paths.
archetype_internal_ref:
I have a vague recollection of discussing this before,
but I can't for the life of me work out what the
list_open field in AOM C_STRING class is
for. It is described as being for when a
constraint is non-exhaustive but I don't know what
this means in practical terms. I also can't
work out how the
Actually the use case is as follows:
We can call it the MD2 use case! :)
This may not seem idealistic but this the reality of what existing systems
do and existing users are used to. If openEHR is to be taken up by existing
system vendors and accepted by their users, we must support this
as they should remain purely about the semantics. There are others that
don't agree with me. The hide on form function in the Template designer
was partly to meet requirements for documentation of the templates for some
groups using this technology. I am not sure if the hide_in_ui parameter
This is another example of the approach to be as specific as possible. The
exclude statement can be used to exclude specific archetypes and the Include
ALL in this case means that all others are allowed. If the Exclude ALL
statement is added to an archetype, it means ONLY those specifically
Due to the limit of attachments per page I suggest the opposite approach,
upload to a conference specific page an then link to it from other index
pages. Obviously we will need another page for papers not related to a
conference, such as publications. I would also expect in future that we
MIE 2008 page to the openEHR website, in which we post papers and
presentations of sessions relating to openEHR. I am not sre at all of
what this list is, so if there are people on this list who could point
out authors presentations it would be helpful.
Actually, is it possible to have a
Note that that means that you would almost certainly have to specify
collapse that no values could ever start or end with a space or
contain more than one contiguous space.
This is what is specified in the openehr schema for most of the elements
you are talking about.
For instance, all types
Duration of 0 makes much more sense to me as a duration value of an
instantaneous event.
Well, I certainly agree that an instantaneous event cannot be an
interval event. However, there is some confusion in (my mind at least)
using the various DV_DURATIONS in History. But the biggest
I should note that in the next generation of archetypes and tooling,
archetype 'source' files for specialised archetypes will be
'differential' in nature - i.e. valid ADL, but containing only added and
changed items from the parent, just as for subclasses in an
object-oriented programming
All inputs are welcomed. I will distributing the draft PARs to the PHD
group today with the plan being to submit the PARs to the IEEE NESCOM
for review and approval at their next meeting. Also, all are encouraged
to join Continua. The membership structure is a relatively low barrier,
with
I was not sure what cadence is...
Cadence is the RPM for the bike wheels. Other measures of
these devices are pedal torque, speed and power (some primary
measures, some computed)
http://www.saris.com/c-11-power-meters.aspx
GPS is clearly location and could be
plotted in an observation
But the purpose then would not be to collect data for healthcare
purposes - i.e. this post is about the use of open EHR standards and
technologies for to answer a scientific question?
Well, this is dilemna I guess - it's data about a person, created
from a physical activity - but it's not a
I have come across an interesting opportunity to do some openehr
modeling in a sports science context. However, whilst half of
the data is medical (heart rate etc), the other half is
raw physical data (GPS location, cadence etc) related to in
this case a bike..
So I would have one large history
make archetypes quite brittle. i.e. when the archetype definition
is loaded into the clinical system I either have to consult the
URL straight away and store the resulting codes, or else delay
the binding and risk having the terminology codes for my
ADL disappear in the future?
why would
The point of the demonstration was that you could make snomed easier for
clinicians to use by creating these subsets ie medication route. These
subsets to be useful would need to be defined at a jurisdictional level or
higher so that everyone can use the same one. This allows for a change in
On 03/01/07, Gavin Brelstaff gjb at crs4.it wrote:
http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf
An interesting paper. I'm not sure Rahil or Alan are on this list??
Perhaps they should be cc'ed in on any discussion. Many of
the points about the difficulties of doing archetype
Mattias,
the usage of xsi:type is solely because object hierarchies are being
used in the AOM. Using xsi:type allows serializers to know the type
they are getting before having to parse it in.. however, even without
xsi:type, your serialization would still not be correct for the xsd
given (i.e.
I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in
the AOM (since I know the AOM very much in detail), but it's not in the XML
schema specification. I have not followed the AOM, because I thought I was
only supposed to look at the schema.
The AOM is at fault in this
I agree, that it's not OO style, but why isn't it implementable in XML? XML
isn't OO, it's just a way of storing structured information, and the guys
building the XML parsers to create the AOM objects again can probably deal
with that.
The use of complexType with extensions in XSD follows the
go back to your example, why didn't you use xsi:type in some places, for
example:
description
original_author
item ...
Is you used it here it would be:
description xsi:type=RESOURCE_DESCRIPTION
original_author xsi:type=hashTableStringString
item
EN13606 EHRcom is the result of an European/Australian consensus process and
can not be equated with OpenEHR.
EN13606 can be used to map to legacy systems and interact with OpenEHR
conformant systems.
So 13606 EHRcom is very much a go-between format - something that
can be used to transfer
both are optional.
thanks Grahame,
I thought they had to be optional (given the ED datatype recursively
refers to itself it would be hard to implement if they were
mandatory!).. am I misreading the UML diagram notation
or are the diagrams not up to date?
It uses notation like
thumbnail: ED[1]
This is not sensible to have in an archetype - otherwise it would not be
there! It is a requirement for templates in use.
I don't understand why it is not sensible to have in an archetype?
Couldn't it be useful to say that for this particular observation
we want to explicitly disallow the
I think that the right place to say for this usage of this archetype I want
to explicitly exclude something is in the template. The archetype should
be a representation of a concept that can be used for all conceivable
requirements of that concept and then constrained in the template.
I
One of Andrew's issues I don't think matters too much - the quoting of
; this is because amp; is used to quote the '' character. However, I
agree that using a more uniform '\'-based quoting approach will be
clearer, and make for easier parser construction. So let's say that we
will go for the
For the case where an attribute is constrained to '0'
existence i.e.
state existence matches {0} .
what should follow as the rest of the attribute
constraint? Technically, the rest of the definition
is superfluous as we have already stated that the
attribute must not exist, but the
'matches'
a schema for the VERSION and related classes, enabling VERSIONs to be
represented as XML inside EHR Extracts (the Extract specification itself
will be published soon)
a schema for the Archetype Object Model (AOM) This work has been done by Dr
Sam Heard at Ocean Informatics.
Would it be
- just have a couple of basic \ rules, and avoid quoted unicode
altogether, on the basis that we can use real unicode files (which we
already can in the next generation of the tools)
fine by me.
- use the ISO rules, that the spec currently indicates, i.e. or
#x
I think this would
The HISTORY IM has a definition for a period which
is meant to represent the time between contained
events. However, in the case where this
period is filled in, the spec makes no restriction on the
EVENT.time field - i.e. what is the meaning of
a HISTORY object with a period set, but yet which
From the ADL spec
4.4.6 Constraints on Dates, Times and Durations
Dates, times, date/times and durations may all be constrained
in three ways: using a list of values, using intervals,
and using patterns
However, the C_DATE, C_TIME etc classes for the AOM
only have a 'range' slot and not a 'list'
I am having trouble with the exact definition of the
string literal..
From the spec
--
3.5.1.2 String Data
All strings are enclosed in double quotes, as follows:
this is a string
Quoting and line extension is done using the backslash character, as
50 matches
Mail list logo
