Pablo,
you may have already done this, but please make sure there is an issue
on the issue tracker http://www.openehr.org/issues/browse/SPECPR/ to
capture this. If you include various email responses in the
'description' section that will help.
I actually think that the 'system' should refer
On 05/09/2014 18:39, pablo pazos wrote:
I found an issue mentioning the system_id but I don't know if it's
related with this thread (don't understand 100% the change
description), also it says that is closed:
http://www.openehr.org/issues/browse/SPEC-165
Pablo,
I would suggest just to
Heath,
this is correct, you were not wrong for 10 y ;-)
We don't record the name or type or id of the application, and I am not
sure even now if that would be of any use. I can't see that it would be.
The system_id is for exactly the purpose that Heath as explained here.
- thomas
On
Hi Pablo,
the original idea is that it is an id more like emr1.my_domain.uy -
i.e. an actual host domain, so if the data are copied or moved
elsewhere, the receiver knows the original EMR system that the data were
created on.
- thomas
On 20/08/2014 17:25, pablo pazos wrote:
Hi,
I'm
Tim,
thanks. It's up - see here
http://www.openehr.org/downloads/ADLworkbench/installation_notes#linux.
- thomas
On 08/08/2014 16:55, Timothy W. Cook wrote:
If you are attempting to run the ADL Workbench on 64 bit systems with
MultiArch support you will need to setup support for the 32 bit
Hi Pablo
Ocean does work on the TD, but also intends to open source it. The only
barrier to this is that some code has to be removed that connects to
internal Ocean tools, also we need to check on any non-open source libs
that might have been used. We are being slower on this than we should,
On 17/05/2014 10:44, Timothy W. Cook wrote:
Exactly. One of the options when you start a Hangout is to enable
live recording to YouTube. You can then go back and edit it if you
wish. Otherwise it is streamed and recorded on YouTube. You fill in
the metadata and enable publication. That
need.
- thomas
On 16/05/2014 09:28, Bert Verhees wrote:
On 16-05-14 03:55, pablo pazos wrote:
I mentioned the phases, several times, in my previous messages :)
Maybe Thomas can break that up into more phases.
On 16-05-14 09:16, Thomas Beale wrote:
I think Pablo has summarised some useful
me
know on this list or privately.
I am continually trying to improve the usability of these pages, so
feedback from all users is extremely valuable. Please either leave
comments on specific pages, or post on the lists.
thanks
- thomas beale
-- next part --
An HTML
On 16/05/2014 19:10, Timothy W. Cook wrote:
On Fri, May 16, 2014 at 2:23 PM, Thomas Beale
thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com wrote:
On 16/05/2014 12:35, Timothy W. Cook wrote:
Tom gave a good intro to ADL 1.5 on the webinar Tuesday
There is a new page here
http://www.openehr.org/wiki/display/spec/ADL+1.5+templates+as+single+artefacts
that describes a proposal for ADL 1.5 single file templates. Note that
other useful rsources are on the ADL/AOM 1.5 parent page
Athanasios,
I have been re-organising the resource pages somewhat - I have put your
information below on the ADL parser resources page
http://www.openehr.org/wiki/display/spec/ADL+1.5+parser+resources -
feel free to rewrite keep up to date.
- thomas
-- next part --
An
On 03/04/2014 09:21, Athanasios Anastasiou wrote:
POINTS OF NOTICE REGARDING ADL 1.5:
1) Are there any ADL 1.5-specific files available out there for testing
purposes?
Hopefully the starting point for all resources is now here
On 02/04/2014 15:13, Gerard Freriks wrote:
imo
1- Slots need to 'point at' archetypes by Name of the Archetype and
NOT the file name. Plus something else ...
Gerard,
this has always been the case. I hope no-one is implementing anything to
do with filenames!
2- All Nodes in any archetype
I've put up a new page on this here
http://www.openehr.org/wiki/display/spec/ADL+1.5+parser+resources.
Please note that there are a few legacy rules that you don't need to
care about if you are doing pure 1.5. We'll make a pure version of these
parser grammars at some point. The ones at this
On 17/03/2014 16:31, ANASTASIOU A. wrote:
Hello Thomas
Thank you for the quick response. I guess i am going to have to go
through the yacc style files and get the definitions...it's been
sometime since i last used that family of tools. I am primarily
interested in ADL 1.5, for the new way of
On 12/03/2014 20:13, pablo pazos wrote:
https://raw.github.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/index.html
This URL will work:
http://htmlpreview.github.io/?https://github.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/index.html
I'll put
For intrest - some real world archetypes are posted here
http://www.openehr.org/wiki/display/spec/ADL+1.5.1+Example+Archetypes.
Also a link to the newly upgraded ADL regression test archetypes, for
the masochists here :)
- thomas
-- next part --
An HTML attachment was
On 16/02/2014 09:24, Bert Verhees wrote:
I have read the PPT from Thomas which is linked in
http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern
just to clarify, this PPT was created by the CIMI - it's based on the
CIMI model, not the openEHR reference model. I have
Hi Pablo,
I don't personally particularly agree with this approach either. There
are two other approaches that could be used: the COMPOSITION / SECTION /
multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an
earlier suggestion of Ian's and mine). I am going to build these models
For those of you following CIMI, there is now a dedicated CIMI space
http://www.openehr.org/wiki/display/CIMI/CIMI+Home on the openEHR
wiki. This page
http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern
summarises some recent developments on the question of 'panels
On 27/01/2014 14:01, Ian McNicoll wrote:
Hi Thomas,
Looking good. I think we do need to think of adding 'version_id to
each Translation to help developers know which original language
version/revision has been used to create the translation. This was
something that Bert mentioned.
I hadn't
On 15/01/2014 09:09, Diego Bosc? wrote:
I agree that sometimes regular expressions can be tricky, and surely
they don't look pretty on its current form. However, but they have an
advantage: They are formal and easily evaluated in any language. The
problem I see with this approach is that
I have created a wiki page
http://www.openehr.org/wiki/display/spec/ADL+1.5+-+where+to+define+value+sets
to describe a possibly radical idea about how we define value sets (like
body position etc) in archetypes.
all feedback welcome.
- thomas
-- next part --
An HTML
On 14/01/2014 10:52, Daniel Karlsson wrote:
Thomas and All,
[Sent to CIMI-list as well... Sorry for cross-posting]
From what I can see the
difference, apart from syntax, from the current AOM is that value sets
are named objects by themselves. This would actually solve the problem
of
On 14/01/2014 11:07, Diego Bosc? wrote:
I like the idea, we were already exploring something similar to this
for intra-archetype semantic relationships.
I have two questions/suggestions:
-once the vs is intoduced, do we still need to specify it as
local. Wouldn't be always be local
The ADL and AOM specification documents have now been upgraded to
reflect recent developments. They new include the new identification
system, plus terminology URIs, as well as other simplifications and
cleaning up. These changes are all implemented in the forthcoming ADL
workbench.
See
On 22/11/2013 09:44, Thomas Beale wrote:
Something IMPORTANT I have said before, and completely forgot due to
other distractions:
'should' have said before!
There is a proposal (it's on the SPECPR issue tracker somewhere) to
add a property to the LOCATABLE class called (say) sibling_id
On 22/11/2013 10:18, Bert Verhees wrote:
On 11/22/2013 10:44 AM, Thomas Beale wrote:
as ADL short hand for
cluster[@archetype_node_id='at0009']/items[@archetype_node_id='at0008',
@sibling_id='2']
I am not sure about this, sibling_id is the array-index, when I
understand. What happens
I spent a bit of time trawling back through that last discussion on
C_OBJECT.node_id (the property that carries at-codes) and whether it
should be mandatory or optional, and also whether empty is valid.
Currently it is mandatory, and can't be empty.
We need to make the spec work for 2
On 20/11/2013 11:28, Diego Bosc? wrote:
It is right in XPath, maybe is less intuitive, but I would say these
are even less intuitive and still work
/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items/value[3]/value=Balkenende
On 21/11/2013 18:35, Leo Simons wrote:
(: from all the items, take the first one, then take all the ones with
node id at0009 :)
/*[1][@archetype_node_id=at0009]
(: from all the items, take the first one iff it has node id at0009 :)
/*[@archetype_node_id=at0009 and
For reference, in terms of 'real XML' here is an example of a coded term:
items xsi:type=ELEMENT
archetype_node_id=at0001
name
valueEpisodicity/value
/name
value
On 20/11/2013 07:29, Bert Verhees wrote:
Hi all,
Thank you very much for your response.
First I want to respond to this one. Because there is also an XML issue.
It is not that I want to be unfriendly, but, this also needs to be
discusses.
I assume, the OpenEHR-XSD's are inspiration for
On 19/11/2013 20:08, Bert Verhees wrote:
Hi Alessandro,
I think you propose this?
/items[at0008,1]/value/value = Mark
/items[at0009,2]/value/value = Rutte
Either this or Bert's original (if it's legal Xpath) is correct,
assuming the data look something like (I just added the outer
one is supposed to be right?
2013/10/29 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Just to re-iterate, the 'narrative' property is meant to carry the
piece of text that would appear on a medication or with a
medication
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology Officer*
+44 7792
On 25/09/2013 23:20, Bert Verhees wrote:
Op 25-9-2013 22:47, Thomas Beale schreef:
On 25/09/2013 00:53, Bert Verhees wrote:
sure - if you have a separate property to store the archetype id,
it is empty in 95% of all object instances, and also you need a
class invariant to prevent it being
On 25/09/2013 00:53, Bert Verhees wrote:
sure - if you have a separate property to store the archetype id, it
is empty in 95% of all object instances, and also you need a class
invariant to prevent it being filled at the same time as the
archetype_node_id (at-code) property.
I must
On 23/09/2013 11:57, Diego Bosc? wrote:
How does this 'unknown' value relate to the discussions we already had
regarding the need of having all at codes present in the ontology?
it's a fake node id value I use in the ADL workbench compiler, just to
guarantee the non-void non-empty
On 24/09/2013 00:10, Bert Verhees wrote:
For that reason I believe specifications should very carefully
specify things. I'll give a very simple example. The openEHR
specifications routinely specify which properties of a class are
mandatory, optional, and which String fields have to be
On 20/09/2013 12:01, Diego Bosc? wrote:
By the way, I just found out that archetype_node_id from locatable
class from the reference model (common_im document, page 22) is
obligatory (!!!).
The meaning of the attribute is as follows:
Design-time archetype id of this node taken from its
On 10/09/2013 09:38, Bj?rn N?ss wrote:
Hi all.
We are discussing some details with the INSTRUCTION STATE MACINE. I
will go directly to my two questions:
1
The state machine define transition from all not-terminated states to
a terminated state. Except from POSTPONED state. There is no
On 02/09/2013 07:19, David Moner wrote:
2013/8/30 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
You are probably right. I think for the moment I would like to get
ADL/AOM 1.5 completed (more or less) with the current assumptions
On 02/09/2013 08:49, David Moner wrote:
2013/9/2 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Well, LinkEHR is a real implementation in use by several
organizations, and we think these identifiers are needed both
technically
On 02/09/2013 13:55, Bert Verhees wrote:
I have received a few archetypes created with the LinkEHR editor.
In there is a dateTime pattern like this:
time existence matches {1..1} matches {-??-??T??:??:??}
it shouldn't be a legal pattern - at least year has to be specified. if
you really
On 30/08/2013 22:02, pablo pazos wrote:
Wow, that's nice. Thanks Thomas.
I'll propose the change to the Java Ref Impl project on GitHub (the
one I'm using).
You can see the code in C_COMPLEX_OBJECT
On 30/08/2013 17:42, William Goossen wrote:
Semantic interoperability is absolutely compromised when for the same
clinical concept variants of archetypes are created.
If justified for internal system development , the moment exchange with
another system requires harmonizing on datapoint to
On 31/08/2013 08:00, William Goossen wrote:
Dear Bert,
I mean any kind of archetype, but in particular different archetypes for the
same concept, eg blood pressure.
Thy can have internally the same atXxxx code for different nodes.
as a general thing they don't although it's not formally
On 29/08/2013 20:53, Bert Verhees wrote:
I think, it has to also some connection with the idea of one world
wide archetype-repository. But we found out in discussion, this will
never happen. So now, in the new ADL-standard, 1.5, there will be room
for namespace. Archetypes will not be
On 30/08/2013 14:23, pablo pazos wrote:
Hi all,
Maybe this is OT but is related. I remembered a problem I had some
time ago working with algorithms that traverses the archetype structure.
For CObjects without nodeID, the path of the CObject is equal to the
path of it's parent CAttribute,
be that we can make
ADL/AOM work in a way that accommodates different 'modes' of operation.
- thomas
On 30/08/2013 07:27, David Moner wrote:
2013/8/29 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
well the idea here has always been
On 29/08/2013 07:00, Bert Verhees wrote:
My two cents,
A nodeID only has to be unique inside an archetype, because an
archetype with a specific archetypeId is considered unique.
The path to a data-item contains the nodeId and the archetypeID, and
together they form a unique combinations.
On 29/08/2013 01:06, Diego Bosc? wrote:
don't forget the organization responsible for that archetype ;D
For those who may not realise, Diego is referring (I assume) to the ADL
1.5 namespaced archetype identifiers, which would give paths of the form:
On 29/08/2013 07:39, Bert Verhees wrote:
On 08/29/2013 08:33 AM, Thomas Beale wrote:
On 29/08/2013 01:06, Diego Bosc? wrote:
don't forget the organization responsible for that archetype ;D
For those who may not realise, Diego is referring (I assume) to the
ADL 1.5 namespaced archetype
On 29/08/2013 08:30, David Moner wrote:
2013/8/28 Gerard Freriks gfrer at luna.nl mailto:gfrer at luna.nl
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
Bert,
all these tools are free, built and maintained by their originators at
their own cost. So you might be sending yourself the chocolates...
- thomas
On 28/08/2013 08: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
On 28/08/2013 10:07, David Moner wrote:
No, currently all at codes are also found at the ontology in
LinkEHR, even if they are empty, to be compatible with the VATDF2
check, although we would like to avoid it :-)
In my opinion we talk of two different levels of meaning. One is the
On 27/08/2013 18:20, Diego Bosc? wrote:
Thinking a little about node identifiers I have thought some
problematic use cases.
First, this is the current 'rule' in the wiki
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633) for
when node identifiers are really needed. I copy the
On 27/08/2013 18:20, Diego Bosc? wrote:
The problem with this rules come with the (explicit or implicit)
specialization of single attributes. take this example:
ELEMENT[at0009] occurrences matches {0..1} matches { -- Position
value existence matches
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology Officer*
+44 7792 403 613Specification Program, /open/EHR
http
On 27/08/2013 21:27, Diego Bosc? wrote:
I don't think archetype ontology would be more complicated at all.
There are currently archetypes with different set of properties in
each at code and tools can handle it well (if I remember correctly,
NEHTA archetypes have extra properties). I'm pretty
Treating units etc as keywords is a pretty dirty way to implement dADL
(now ODIN) parsing! The property names in a C_DV_QUANTITY (or
C_DV_ORDINAL) structure shouldn't be keywords, they are just property
names, and should be collected and either compared to the RM or (what I
do) converted
For those interested in ADL/AOM 1.5, I made a post in my blog
http://wolandscat.net/2013/08/21/adlaom-1-5-major-progress-update/
giving a progress update. It's getting simpler, more powerful, and more
generic.
- thomas beale
-- next part --
An HTML attachment
On 22/08/2013 07:15, Bert Verhees wrote:
On 08/22/2013 01:13 AM, Thomas Beale wrote:
For those interested in ADL/AOM 1.5, I made a post in my blog
http://wolandscat.net/2013/08/21/adlaom-1-5-major-progress-update/
giving a progress update. It's getting simpler, more powerful, and
more
On 22/08/2013 10:07, Bert Verhees wrote:
On 08/22/2013 10:48 AM, Thomas Beale wrote:
The specification is technically no longer backward compatible,
primarily because the special C_DV_ORDINAL and C_DV_QUANTITY syntaxes
are no longer supported - in fact the whole openEHR Archetype profile
for those at MedInfo, or wanting to follow, tweets with
#openehratmedinfo will be tracked on the main website starting sometime
today.
- thomas beale
On 13/08/2013 16:23, pablo pazos wrote:
Hi Thomas, thanks for the input, is great to understand the rationale
behind ACTIVITY.timing.
Right now I've more questions than proposals :)
...The RM says that ACTIVITY.timing should always be present, and i
believe it should be, otherwise
On 14/08/2013 11:18, Karsten Hilbert wrote:
On Wed, Aug 14, 2013 at 08:11:50AM +0100, Thomas Beale wrote:
There is no assumption in ACTIVITY.time that the activity is
repeated. In the GTS syntax, you can just as easily express a one-off
event at a certain time as you can a repeated event
!
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology Officer*
+44 7792 403 613Specification Program
Hi Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE
precisely because there seemed to be no accepted standard for
representing this information. I think there is still no single accepted
standard, but I think that possible standards are better understood.
One
-technical_lists.openehr.org
--
Thomas Beale
Chief Technology Officer Ocean Informatics
of Auckland
Private Bag 92019 Auckland 1142, New Zealand
Email: k.atalag at nihi.auckland.ac.nzmailto:k.atalag at
nihi.auckland.ac.nz | Web:
www.nihi.auckland.ac.nzhttp://www.nihi.auckland.ac.nz/
Skype: atalagk Mob: 021 02412096 DDI: +64 9 923 7199
--
Thomas Beale
Chief Technology
of Auckland
Private Bag 92019 Auckland 1142, New Zealand
Email: k.atalag at nihi.auckland.ac.nzmailto:k.atalag at
nihi.auckland.ac.nz | Web:
www.nihi.auckland.ac.nzhttp://www.nihi.auckland.ac.nz/
Skype: atalagk Mob: 021 02412096 DDI: +64 9 923 7199
--
Thomas Beale
Chief Technology
at nihi.auckland.ac.nzmailto:k.atalag at
nihi.auckland.ac.nz | Web:
www.nihi.auckland.ac.nzhttp://www.nihi.auckland.ac.nz/
Skype: atalagk Mob: 021 02412096 DDI: +64 9 923 7199
--
Thomas Beale
Chief Technology Officer Ocean Informatics
Rong Chen and myself attended the recent e-health summit day
http://www.omg.org/news/meetings/tc/berlin-13/special-events/Health_Community_Summit.htm
at the Berlin OMG meeting. I made a few notes about it
http://wolandscat.net/2013/06/20/omg-e-health-platform-summit-berlin-2013/
on my blog,
A major update of the Identification System for Knowledge Artefacts
draft specification is available here
http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts.
This update (0.7.0) includes:
* major updates to text
* rewritten grammar
* rewritten
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology Officer*
+44 7792 403 613
On 14/06/2013 08:56, Gerard Freriks wrote:
Hi,
While we are at it.
-1-
Why do we need a TDD?
Isn't a Template just a Composition archetype with Sections archetypes
and ENTRY archetypes and Cluster archetypes and Element archetypes
plus data types.
that's what a template is; but a TDD
On 14/06/2013 10:09, Daniel Karlsson wrote:
To write generic transformations is not trivial, I expect.
If possible at all.
I do not agree. I believe this is what every implementer necessarily has
to do, to provide a two-way transformation between a canonical form and
any serialization and/or
On 14/06/2013 10:54, Gerard Freriks wrote:
Templates are mostly EHR-EXtracts with Compositions inside.
I imagine that is probabaly true in 13606-land. It's so far uncommon in
openEHR, but should be used more, and I think will become common with
the growing use of the openEHR EHR Extract
On 14/06/2013 12:12, Gerard Freriks wrote:
Dear Thomas,
Why do we (CIMI) need a TDD?
Isn't a TDD a transformation that is used during the implementation of
a Template.
I have to admit I was surprised to see all this talk of TDD-like things
in CIMI. TDS/TDD is more than just a
On 14/06/2013 12:31, Daniel Karlsson wrote:
Gerard, Ian, Thomas, thanks for all answers.
On Fri, 2013-06-14 at 11:17 +0100, Thomas Beale wrote:
Such a standard TDS/TDD would have made the Swedish 2009-10 quality
registry project significantly easier and a lot of the criticism towards
On 14/06/2013 12:19, Diego Bosc? wrote:
Well, in ADL specialization allows extension
From here
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADLAOM1.5-SpecialisationSemantics)
extensions, i.e. object constraints added to a container attribute
with respect to the
On 14/06/2013 10:38, Ian McNicoll wrote:
Hi Daniel,
I should have been more precise. I still don't see how it would be
possible to create a single generic Canonical XML - TDD transform.
actually it would not even be all that hard. It is just a case of doing
a data-level transform that
Some of you may be interested to note that a new OMG RfP 'Archetype
Modelling Language (AML)' will be under discussion at the June OMG
meeting http://hssp.wikispaces.com/event-2013-06-OMG-Berlin.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
.
term_bindings =
[AccidentSiteTerms] =
items =
[at0073]= [AccidentSiteTerms::V::V - Vei, gate, fortau, gang- ,
sykkelvei]
[at0074] = [AccidentSiteTerms::T::T - Other transport area**]
Ian
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology
On 06/05/2013 10:47, Diego Bosc? wrote:
In fact, 'license' could be translated, but translating 'copyright'
makes less sense
Clearly we are not in the business of creating translations of things
like the CC licenses ourselves, which is the license of archetypes (at
least openEHR ones). We
On 03/05/2013 11:28, Diego Bosc? wrote:
By the way, we should use the momentum to also revamp the available
metadata. A few ideas:
- Move 'copyright' from language specific information to general
metadata (It's not being really translated at the moment).
- Move 'references' from
On 02/05/2013 08:36, David Moner wrote:
Hi,
Exactly, that was one of the original ideas, at least add that RM
version information at the archetype header. As you say, that only
indicates the version used to create the archetype and not the
compatibility with other versions of the RM
On 01/05/2013 10:28, Bert Verhees wrote:
Let me explain my problems and what I wish and what I think about
doing about that, and than what my problem is with the BMM-solution
-
I have a problem with both archetype-editors, I explained a few times
on this list why.
Both change
On 01/05/2013 14:48, pablo pazos wrote:
Hi Thomas, having a small spec would be great, thanks!
BTW, does anyone use XML representation of UML diagrams to process
class models?
wait time = 5 days
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
On 30/04/2013 23:45, Bert Verhees wrote:
Michael van der Zel at Results4Care put together a great little
plug-in for Enterprise Architect
Stupid product, EA, cannot be used in an environment based on
international standards, but is even when used on Mac of Linux
depending on Internet
On 30/04/2013 16:33, David Moner wrote:
Hello all,
We have just implemented the support of Basic Meta Model files (BMM)
in LinkEHR Editor as a format to import new reference models into the
tool.
First of all, I think that it is necessary to clarify some erroneous
ideas or
On 30/04/2013 18:30, Diego Bosc? wrote:
I think Thomas created it from scratch. There is a page on the wiki
discussing it
(http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR),
but we studied mostly to the bmm files included on the archetype
workbench in
On 29/04/2013 09:01, Mikael Nystr?m wrote:
Hi Tom,
Is the intention that the new data type TERMINOLOGY_CODE also can
contain a post-coordinated code so it, for example, can contain a
expression in SNOMED CT compositional grammar? (See
www.snomed.org/tig?t=rfg_expression_scg
On 26/04/2013 04:17, Shinji KOBAYASHI wrote:
Hi Thomas Beale,
At first, I am much sorry about lacking links.
http://www.rugson.org/pdf/PSRCPattaya2012.pdf
In this presentation, serialisation formats were compared with
features and metrics, such as size and (de)serialise performance
://www.drdobbs.com/web-development/after-xml-json-then-what/240151851),
and I think ODIN could have its place in the wider world.
- thomas beale
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments
On 25/04/2013 10:20, Erik Sundvall wrote:
Very interesting thoughts Tom!
My initial impression of the proposal is very positive. If I
understand things correctly this will enable shorter and more
readable serializations not only in ADL but also in other formalisms.
If we consider ADL
501 - 600 of 1686 matches
Mail list logo
