On 14/08/2012 18:46, pablo pazos wrote:
Hi Thomas,
Just thinking...
Why not make node ID mandatory for all nodes?
Since this will be handled by tools, I don't see the point of having
to worry about if the node has an id or not: the tool just put some
node ID on each node and us as
On 08/08/2012 22:03, pablo pazos wrote:
Hi,
Just a small related question: can I continue executing ACTIONs for an
ACTIVITY that has already be completed? or do I need to create
another ACTIVITY with the same information in order to have another
execution workflow?
e.g. is this valid?
On 09/08/2012 17:44, pablo pazos wrote:
Hi Thomas,
I agree with that, but I think we are talking about different
scenarios. I understand we can have various ACTIONs for active
states (and reschedule or suspend/resume transitions).
My question is: if an ACTIVITY is completed (or aborted or
On 07/08/2012 04:43, pablo pazos wrote:
Hi all,
I've a simple question about commiting ACTIONs.
We have this scenario: one ACTIVITY should be executed by two
different ACTIONS (i.e. we have 2 ACTION archetypes).
When commiting anything to a openEHR repository, it sould be enclosed
by a
On 01/08/2012 17:16, Seref Arikan wrote:
Greeetings,
Looking at the current documentation for AQL, it is not clear to me if
a CONTAINS constraint should apply to all children of an RM type, or
to root level children only.
So if I use a statement such as EHR e CONTAINS COMPOSITION c .
On 19/07/2012 20:46, Diego Bosc? wrote:
I think she is referring to something like if patient is male then
obstetrics field should be null, and those are created as invariants
*
*
My understanding as well. ADL 1.5 will make this possible e.g., with a
rule in the archetype like:
Some interesting statements in what appears to be the first CEN TC251
'newsletter' (available here
http://www.ehealth-interop.nen.nl/publicaties/5092details=true) [my
emphasis]:
Electronic Health Records come of age: 13606
The first ever EHR architecture was standardised in CEN TC251
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
On 03/07/2012 09:50, Seref Arikan wrote:
Which I assume will be represented via XSD again, if multiple
technologies are to do the same thing in the same way.
*
*
actually, OPTs are not XSDs, they are an XML instance object
serialisation of the AOM XSD. I.e. all OPTs obey the one XSD. I must
the 'component' as 'user interface'
thanks
- thomas
On 28/06/2012 22:10, Timothy Cook wrote:
On Thu, Jun 28, 2012 at 12:55 PM, Thomas Beale
thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com wrote:
There is a new beta of the ADL Workbench available here
There is a new beta of the ADL Workbench available here
http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html;
release notes here
http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/release_notes.html.
This will be the final release
Hi Athanasios,
On 27/06/2012 17:33, Athanasios Anastasiou wrote:
Dear all
I am coming back to an earlier question
(http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007100.html)
because i am reaching the point where i am performing validation and i
really
Have a look at the following extract from the ordinal test archetype
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/c_domain_types/openehr-test_pkg-SOME_TYPE.ordinals.v1.adls:
SOME_TYPE[at] matches {-- root item
standard_ordinal_attr matches
A few weeks ago some of us had a look at the openEHR terminology, and
identified some of the problems on this wiki page
http://www.openehr.org/wiki/display/spec/openEHR+Terminology. One of
the (obvious) conclusions was that the Archetype Editor 'terminology'
needs to be its own thing, since
On 24/06/2012 15:22, Bert Verhees wrote:
I understand the problem that is solved with the plugin types. But I
must admit, it took quite some while.
You write that the LinkEHR cannot use the plugin types because it
follows the EN13606-2 specification, but that seems to me as a formal
Bert,
yes, you are right. It's not required, and the ADL Workbench and Ocean
Template Designer don't care about the file name. It's a straightforward
matter for all tools to remove this restriction (it means running a
micro-parser across all the files to read the first line or few lines,
so
On 24/06/2012 13:21, Bert Verhees wrote:
Thanks, David for your answer.
Excuse me my bit confusing email from yestrday, I was in a hurry
preparing a meal for guests, and at the same time working.
This not about bugs but mostly about features as designed
Although there are formal reasons
On 21/06/2012 19:07, Gerard Freriks wrote:
So to summarise, it came down to finding categories on which /health
information data structures /- i.e. information models - could be
based that would work reliably for most if not all of medicine. Now,
having used these categories for some
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
On 21/06/2012 11:49, 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
On 21/06/2012 12:08, Thomas Beale wrote:
On 21/06/2012 11:49, 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
of diabetes mellitus and insulin care plan for glucose
management are crystal clear.
I don't doubt that something better is possible in the future, but I
think for now some finer adjustments on the current ontology and data
structures will be of most practical help.
- thomas beale
On 21/06
On 21/06/2012 17:08, Thomas Beale wrote:
Now consider the diagnosis archetype (an instance of the 'opinion' aka
'description' type)... it contains the main 'proposition' - i.e. the
identified index condition, diabetes or whatever - and a bunch of
times / dates / durations / other
See openEHR 2.x RM candidates A-3 and A4 here
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model.
On 20/06/2012 11:50, Sam Heard wrote:
Hi Anthanasios
I think time has shown that this is probably an area of over
engineering in openEHR. All
On 08/05/2012 03:59, Shinji KOBAYASHI wrote:
Hi Thomas Beale,
Our, Ruby implementation repository has already moved on GitHub for
our convenience
last year for our convenience.
I was wondering if we could move our repository under
github://openehr/ruby-impl-openhr.
It would
On 06/05/2012 13:28, pablo pazos wrote:
Hi Peter, thanks for the pointer.
I think this is only ADL related and only 1.5. My idea is to include
ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets.
Maybe we can took some samples from there, but I believe this new repo
has a
yes, we will obviously migrate over to Github in the coming months. I
have a slight concern about how to avoid chaos, and I do think we need
to think carefully about how we organise Git projects/subprojects in
general. The openEHR terminology is not large (at all), but looks like
it will
On 02/05/2012 16:19, pablo pazos wrote:
Hi Thomas,
This example is very helpful, thanks.
About Diego's questions and your answers on other emails, as I
understand I have to merge/resolve the ontology section too, so all
needed codes are there without ambiguity.
Is the
Hi Pablo,
when archetypes are flattened, their ids replace the at-codes at the
root points. This example shows the flattened version of the EHR_EXTRACT
template test archetype. You can see the archetype ids, also a remaining
open slot. It's not a proper OPT, so the top root node does not yet
On 02/05/2012 09:21, Diego Bosc? wrote:
Is the at from the solved slot lost? Is not possible to redefine
the text or description and change it from the at of the included
slot?
I think it would be useful to have it somehow
*
*
the information is still in the archetype - the
On 02/05/2012 10:55, Diego Bosc? wrote:
Also, are the at from the resolved template changed in any way?
I see EXTRACT_CHAPTER with [at0002] and ELEMENT with [at0002.1], which
I think it may be changing specialization semantics
these two codes don't happen to be related - the at0002 is from
, it was not possible to include all of them to this cycles
investigation.
On 12/04/2012 17:44, Thomas Beale wrote:
On 12/04/2012 17:20, Athanasios Anastasiou wrote:
BTW, these lexical rules are historical, and will be obsoleted one
day -
I more or less had to construct them after 100s
The post with
subject = empty; sender = Greg Caulton
is dangerous, DO NOT FOLLOW THE LINK; DELETE FROM YOUR INBOX
Note that Greg is a normal subscriber, and has undoubtedly been the
victim of a virus.
- thomas beale
track?
All the best
Athanasios Anastasiou
On 10/04/2012 19:50, Thomas Beale wrote:
Hi Athanasios,
see the ADL 1.5 spec
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf
section 5.3.9.3 for the rules.
- thomas
On 10/04/2012 17:11
On 12/04/2012 15:47, Athanasios Anastasiou wrote:
It's eiffel, so easy to read ;-)
I am not familiar with Eiffel so let's just say i am glad you have
included that comment in the beginning of the function :-D
back to Pascal / Algol class then ;-)
That last (pseudocode) ELSE is to
On 12/04/2012 17:20, Athanasios Anastasiou wrote:
BTW, these lexical rules are historical, and will be obsoleted one day -
I more or less had to construct them after 100s of archetypes that
actually assume these rules had been built! You will see further down in
the ADL 1.5 text an indication
.
Looking forward to hearing from you
Athanasios Anastasiou
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics *Thomas
On 04/04/2012 13:29, Diego Bosc? wrote:
Yes, but what I mean is this
DV_ORDINAL [at0006] matches {
value matches {|2|}
symbol matches {
DV_CODED_TEXT matches {
value matches {???} --
value
I guess that's a reasonable statement. It depends on what part of your
infrastructure is responsible for ensuring that the data respect the RM,
but I get your point. In which case follow Ian's advice...
- thomas
On 04/04/2012 15:35, Diego Bosc? wrote:
yeah, but you are fixing everything
I have posted an openEHR 2.x flavoured model I created for early CIMI
use here
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+-+CIMI+version+1,
as I am on the RM committee in CIMI, and they wanted something ASAP. I
have not had time to discuss this model with anyone, and it should
.
It would be interesting to know how well the XMI files perform in other
tools.
I am using these UML files to generate some openEHR 2.x candidate models
as well, so XMI files for these will also appear at some point. These
latter files are likely to be the ones of interest to the CIMI forum.
- thomas
On 31/03/2012 18:01, Seref Arikan wrote:
Hi Tom,
have you seen my previous comments on the wiki regarding XMI and EMF?
*
*
yes... I just have not figured out what to do about it...
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
together some new test archetypes, including some
new 13606 ones, also test archetypes based on InterMountain Health
Clinical Element Models. I will announce these shortly when a bit more
work is done.
- thomas beale
**
-- next part --
An HTML attachment was scrubbed...
URL
On 28/03/2012 03:01, pablo pazos wrote:
Consider this ER scenario: a BP value could be recorded each 30 or
so, and the system could be used 1. for many patients, 2. by many
users, 3. on the same machine.
this is most likely a 1-event-per-Observation scenario. I realise it is
not always
On 28/03/2012 16:44, Sebastian Garde wrote:
On 28.03.2012 14:47, Athanasios Anastasiou wrote:
Hello everyone
I keep getting an error when parsing this ecg archetype (expressed as
XML) and i was wondering if this could be because the archetype was
uploaded to the CKM when the CKM used a
On 27/03/2012 10:41, Grahame Grieve wrote:
hi Ian
It meets perfectly the requirements I was aware of at the time, but now I have
a more perfect (ahh, less imperfect) knowledge. If I have a series of
observations,
I may provide some interpretation of them, that becomes the observation.
This
On 27/03/2012 10:42, Ian McNicoll wrote:
Hi Thomas,
I definitely agree here. While I think there is huge merit in having
some kind of simplified single Event OBSERVATION, there is absolutely
a need to handle the increasing numbers of device mediated multiple
event observations.
As a
On 27/03/2012 11:46, Grahame Grieve wrote:
One issue I have is that the event series imposes the same data at each
point, - can you give an example?
umm. getting hazy now. There's one challenge (synacthen?) where you
measure the hormone regularly, and keep track of the state of the patient
by
On 27/03/2012 13:12, Grahame Grieve wrote:
Some, actually most, of the issues you mentioned in the context of the NEHTA
work are familiar, and I think apply to many implementation situations.
Thomas and I have been discussing some possible solutions.
1. The ability to expose parts of the RM
, Thomas Bealethomas.beale at oceaninformatics.com
wrote:
On 21/03/2012 09:41, Thomas Beale wrote:
I have put up some more up-to-date UML resources for the current (1.0.2)
release of openEHR on this wiki page. For the moment I have done two
diagrams (RM and Data types) which should help people
a version with integrated changes - this
change, plus the simplification of ITEM_STRUCTURE etc.
- thomas
On 22/03/2012 13:56, David Moner wrote:
2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Instead, I think we should re-invigorate
.
- thomas
On 26/03/2012 13:41, Thomas Beale wrote:
David,
This
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.2ModifyCLUSTERtohavelocalvalue
is what I would realistically propose
On 23/03/2012 12:09, Heath Frankel wrote:
I know every developer can do it better than the next but any
developer can do it better than a tool.
How true. That statement should be on the wall of every UML tool
vendor's office!
- thomas
Indeed we had something like this in Release 0.95 of openEHR
http://www.openehr.org/releases/0.95/roadmap.html - see from the old
spec
http://www.openehr.org/releases/0.95/architecture/rm/data_structures_im.pdf.
This HISTORY model worked badly for multi-valued data.
However, if we are
On 26/03/2012 19:49, pablo pazos wrote:
Hi Thomas,
A while ago, we gave this issue a big thought when designing the
EHRGen framework.
Periodic event records are needed when recording certain studies and
when monitoring a patient, but this can be recorded as single point
events, and
On 22/03/2012 12:03, David Moner wrote:
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
On 23/03/2012 08:07, David Moner wrote:
There is no doubt about the attributions and original references that
must accompany the new archetypes (by the way, maybe in this sense the
archetype metadata could be improved. Diego Bosc? has been working on
this topic for his PhD).
I would be
or a HISTORYCOMPOSITION?
Thanks a lot for sharing,
Kind regards,
Pablo.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics *Thomas
On 22/03/2012 09:34, Seref Arikan wrote:
Hi Pablo,
I do not want to have a discussion about how to implement specs. That
was not my point. Let me try to be more direct:
Generics causes problems during implementation of openEHR if Java or
XML is involved. Java + XML has a huge user base.
On 22/03/2012 13:56, David Moner wrote:
2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Instead, I think we should re-invigorate the Java Implementation
Technology Spec, that Rong wrote originally some years ago
-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
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
On 22/03/2012 14:04, Seref Arikan wrote:
I have workarounds for the generics problems in Java, and I would be
more than hapy to contribute them to any doc. I did not know about
Rong's document.
I think I have made my point, whether or not it is a good one is a
different issue, but I don't
On 19/03/2012 03:01, pablo pazos wrote:
Hi Thomas, we are here:
http://www.openehr.org/shared-resources/usage/nonprofit.html
*
*
I knew that...!
-- next part --
An HTML attachment was scrubbed...
URL:
I have put up some more up-to-date UML resources for the current (1.0.2)
release of openEHR on this wiki page
http://www.openehr.org/wiki/display/spec/openEHR+1.0.2+UML+resources.
For the moment I have done two diagrams (RM and Data types) which should
help people a) understand openEHR at a
On 21/03/2012 09:41, Thomas Beale wrote:
I have put up some more up-to-date UML resources for the current
(1.0.2) release of openEHR on this wiki page
http://www.openehr.org/wiki/display/spec/openEHR+1.0.2+UML+resources. For
the moment I have done two diagrams (RM and Data types) which
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
On 18/03/2012 21:45, Grahame Grieve wrote:
ok, so you say it should be computable, but then allow a fixed unit of one,
and some other code as well. And this in a subclass of Quantity, so you
could always use it or encounter it in place of quantity. So if that's the
case, why not simply make it
On 18/03/2012 21:51, Heath Frankel wrote:
Hi Thomas,
I had an issue recently were I was receiving HL7 V2 Lab messages with
units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was
used in the archetype constraint for an RBC element. I translated the
HL7 unit into the archetype
On 18/03/2012 22:21, Stef Verlinden wrote:
Verstuurd vanaf mijn iPhone
Op 18 mrt. 2012 om 15:15 heeft Thomas Bealethomas.beale at
oceaninformatics.com het volgende geschreven:
I still think Quantities should be computable as such - if we don't know how
many mcg of substance 3 puffs is,
On 18/03/2012 17:45, pablo pazos wrote:
Hi Thomas,
Armando Prieto and Juan Escalante are students from Venezuela, they
took our Open EHRGen framework and improve it to create an EMR for the
SOS Telemedicine for Venezuela project.
They can give you more information about the project
On 19/03/2012 02:15, Grahame Grieve wrote:
for me, conversion between different units that are comparable. You
should ask Tom what else he thinks it yields up. I'd be interested.
Grahame
*
*
well any mathematical operation working on quantities - e.g. averages,
max, min, variance,
On 17/03/2012 22:18, Grahame Grieve wrote:
Couple of quick reactions - you need to talk to clinical modellers to get a
better response (maybe post on clinical list)...
um, maybe. but most are representational questions, not questions of
meaning, I think.
* DV_BOOLEAN - maps a to a coded
As Grahame mentioned on an earlier post, the question of units is
thorny. Although we technical people would like to mandate UCUM or some
other well-designed computable syntax, on its own, it won't work. There
seem to be two reasons for this:
* it doesn't take care of the need for a
On 18/03/2012 12:49, Grahame Grieve wrote:
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
On 18/03/2012 12:57, Grahame Grieve wrote:
Are discrete units only encountered in administrative directives? Do
you prohibit people from making observations or measurements that
include discrete units such as puffs, tablets, patches, vials, strips etc?
I don't think so; a physician could
The academic projects
http://www.openehr.org/shared-resources/usage/academic.html page on
the website lists currently known projects. I am sure that there are
more today. Please let us know if you have a project, and the details of
it, we will post it on this page.
- thomas beale
On 11/03/2012 09:43, Thomas Beale wrote:
Well, this is the HL7 modelling mentality, trying to create a data
type or class with all possible attributes, some of which can be
removed in some subclass. This is bad modelling, we should not be
doing it. I'm talking about interfaces here
Couple of quick reactions - you need to talk to clinical modellers to
get a better response (maybe post on clinical list)...
On 10/03/2012 19:34, Grahame Grieve wrote:
HI
I have responded to the comments in the wiki.
Generally, the FHIR data types are not purely for computation; they
yep, it's me, I forgot to set anything up. For the moment I am sole
member and admin. We might need a little bit of planning about how to
use the openEHR space I think - I am just thinking of how to make sure
we have a fairly comprehensible (to outsiders) Github presence, while of
course
For those interested, the jointly-sponsored HL7/OMG event
Interconnected Health 2012 program has just been announced. See you
in Chicago on April 2-4!
http://www.interconnected-health.org/program.htm
Please cross-post as you deem appropriate.
- Ken
Ken Rubin
Chief Architect, Federal
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,
Fred,
On 18/02/2012 00:26, fred trotter wrote:
Thomas,
This is quit usable critique and I will certainly draw
from it in future revisions of the work.
You make the argument that OpenEHR is primarily for interoperability,
and I can accept that fundamental argument. It is
Fred,
that's pretty much it. We can disagree whether we should solve the
sem-interop problem now (us; harder, longer) or later (you; get more
going faster), but that's not a real debate - in some places our view
makes more sense, in others yours is the practical sensible approach.
Our main
- a claim which Thomas Beale denies.
Those less likely to believe that we would make outragous resume
claims are quite correct. After much debate late in the book, David
and I decided to go exclusively with the term EHR, rather than EMR. We
believe (and we argue in the book) that the industry
On 17/02/2012 14:50, Randolph Neall wrote:
Other models I didn't try yet are Object Oriented DBs and Document
Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option,
fast for store highly hierarchical structures, but you need to write
some ugly queries if you want your data back
get a feel for the diversity (or unanimity), we might be able to
make some quick progress toward a proper openEHR EHR service.
- thomas beale
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr
On 05/02/2012 07:53, Shinji KOBAYASHI wrote:
Hi Seref,
This is the demo site for AQBE dynamic query generation.
http://wako3.u-aizu.ac.jp:8080/aqbe/
It is wonderful.
Regards,
Shinji
very nicely done! And fun.
- thomas
On 05/02/2012 07:53, Shinji KOBAYASHI wrote:
Hi Seref,
This is the demo site for AQBE dynamic query generation.
http://wako3.u-aizu.ac.jp:8080/aqbe/
It is wonderful.
One quick piece of feedback - any free-text field probably should not
just have = / != operators but a matching operator
On 31/01/2012 16:43, pablo pazos wrote:
Hi Thomas, I've added a proposal to the page on the wiki
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model
I'm also thinking about the ENTRY model, to lift up the
data/description attributes from all entry
On 01/02/2012 07:25, Erik Sundvall wrote:
On Tue, Jan 31, 2012 at 14:42, Thomas Beale
thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com wrote:
Erik,
which file do you mean here? Where is this alias?
Oh, never mind, it was just a sidetrack, focus
On 31/01/2012 11:15, Erik Sundvall wrote:
Hi!
Ok, if implementation experience says it is better to have separate
sections for human readable annotations and machine-targeted program
directives then I guess that is a good approach. Are there any tools
that support this now?
well not
On 31/01/2012 00:16, Heath Frankel wrote:
Hi Thomas,
I think you're going too far with this controlled key and syntax
approach. The important thing at this point is we get a structure
that we can start using to get more experience with. Although my
proposal was a simple property value
On 31/01/2012 13:12, Erik Sundvall wrote:
Hi!
On Tue, Jan 31, 2012 at 13:44, Thomas Beale
thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com wrote:
If going for an RDF-like URI based approach for program
directives or implementation_directives
it work properly with respect to localisation.
thoughts?
- thomas beale
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/cf7139a9/attachment.html
Now you need to join the java list
http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java ;-)
On 30/01/2012 14:43, M?rcio Costa wrote:
Hello guys,
after reading the majority of the docs, i tryed to write a very simple
app that:
1. Parse a ADL file to AOM
2. Try to build a Imput
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?yampeku
On 30/01/2012 20:56, Sam Heard wrote:
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
The openEHR RM, like 13606, CDA and most other such models has a generic
structure part for building trees of
Hi Erik,
your examples are:
annotations =
[/data/items[at0003.7]/items[at0010]] =
items =
[GUI-show-if] = $smoker -- Other annotation name examples:
GUI-hide-if ...
[some other annotation] = whatever
...with RDF-like annotations, some additional examples (and a wildly
On 25/01/2012 22:45, David Moner wrote:
2012/1/25 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Maybe another way of understanding this flag is as 'this node can
be skipped without loss of meaning'. I would be very interested
On 25/01/2012 23:03, David Moner wrote:
Following this new sense for it, I think that the implications for a
GUI or visual representation would depend on a decision of the
implementers. If the screen space is reduced, they could opt for just
showing the clinically relevant data and leave
701 - 800 of 1686 matches
Mail list logo
