Hi
If there is an issue with Template Designer you can always report it at
https://oceanehr.atlassian.net/servicedesk/customer/portal/5
Please note that there are some differences in your attached archetype and the
latest version from CKM which may explain why it is failing (e.g. the details
Von: openEHR-technical Im Auftrag
von Thomas Beale
Gesendet: Dienstag, 18. Dezember 2018 18:39
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version
The example below
Bakke, Silje Ljosland wrote:
Hi,
Sebastian Garde and I had a brainstorm a while ago about how to handle
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be
noted explicitly (whether becaus
So that we don’t forget, I have created
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages
for both.
The more interesting question to me is whether this is optional and only added
when really needed or
n if you are using it to store the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]
Regards
El vie., 19 oct. 2018 a las 10:57, Sebastian Garde
(mailto:sebastian.ga...@oc
-CLUSTER.service_request_information.v1::at0141]
Regards
El vie., 19 oct. 2018 a las 10:57, Sebastian Garde
(mailto:sebastian.ga...@oceaninformatics.com>>)
escribió:
Hi all,
We have encountered an interesting issue with how to construct unique paths for
slots when there is more than one slot on the same
translations = <
["de"] = <
language = <[ISO_639-1::de]>
author = <
["organisation"] = <"University of Heidelberg,
Central Queensland U
Hi Heather,
Purely technically, I think the answer is "false" - since assumed values are an
available independent of their context (e.g. data or state).
But for all practical modelling I think the answer is "true" - assumed_value
should really be used for protocol/state, but not data.
As for
I agree with Seref’s intention of keeping it clean and clear and most
importantly of course consistent.
In this particular case, I think the REFERS idea is worth pursuing…to me this
sounds pretty fundamental and should be supported without the need for defining
an extension/function (in
While I agree with the SPEC-95 rationale (once you have a unit, you should be
able to know what its property is), it is still convenient to have the property
for constraining.
Otherwise you don't have a way to say in an archetype: I don't care about the
exact unit here, but please let it be a
:
On 25-01-18 11:03, Sebastian Garde wrote:
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
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
Hi,
There are unnecessary existence constraints in the archetype, e.g.
value existence matches {0..1}
While I don’t think that this is technically wrong, this constraint is
superfluous as it doesn’t constrain anything.
This may be what Template Designer is having problems with…just try to
Dear all,
We have just updated the openEHR Clinical Knowledge Manager.
This CKM release adds a new Dashboard for new or not logged-in users. It also
completely revamps the current Dashboards for logged-in users, editors and
clinical knowledge administrators. In addition, we have finetuned many
My personal opinion on this:
·ICARM needs to resolved - either it is ok to constrain any functional
property or it is not.
If ok, then this info (not error) can be removed completely. If not ok, ICARM
would be VCARMs as well (as it used to be until the discussion started). ICARM
/
Hi Pablo,
ICARM: This is the "softer" form of VCARM - i.e. it is just a piece of
information that while there is no corresponding attribute in the model, there
is a functional property that is commonly constrained. Typical examples are
offset and is_integral. These are frequently constrained.
My congratulations too, Pieter!
To add to Thomas, a perfectly redundant wheel-reinvention based on the specs
also validates the specs nicely and highlights potential
problems/inaccuracies/underspecified things in the underlying specs as we have
seen previously with the various 1.4
Yes, unfortunately. I have even implemented a Validation Check named VUI for
this in CKM after these discussion, so that this is not forgotten, because I
too think it is important to get this right...
This check is available for each archetype (or for all archetypes from
Reports/Validation
Hi Silje,
If I read
http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_types/data_types.html#_dv_ordinal_class
correctly, it seems to imply that the minimum you do is to give the text the
same value as the ordinal value: "...which may be strings made from + symbols,
or other
reason such as that Duration is not (usually) an
inbuilt datatype)
Cheers
Sebastian
From: pazospa...@hotmail.com [mailto:pazospa...@hotmail.com]
Sent: Donnerstag, 17. März 2016 04:03
To: Sebastian Garde <sebastian.ga...@oceaninformatics.com>;
openehr-technical@lists.openehr.org
Subje
hnical discussions
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
To make things worse, in the XML Schema DV_DURATION contains an
Iso8601Duration, which in the end is an string with a regex
2016-03-15 16:43 GMT+01:00 Sebastian Garde
<seb
; tml#_dv_duration_class
> That's what template designer does.
>
> Best regards,
> Bostjan
>
> On 15 Mar 2016, at 13:35, Sebastian Garde
> <sebastian.ga...@oceaninformatics.com> wrote:
>
> Dear all,
>
> There are a differences in how the Template Designer a
Dear all,
There are a differences in how the Template Designer and how CKM construct the
XML for a DV_Duration:
Take this snippet (from http://openehr.org/ckm/#showArchetype_1013.1.123_XML )
DV_DURATION
true
We have been through this a long time ago I think, with Koray having the exact
question and opinion I had.
The downside if you don't allow this kind of constraint(!) on functional
attributes in archetypes, here you cannot constrain the other two (real)
attributes when modelling an archetype
...or if it is for an archetype, you can raise a Change Request directly for
that archetype on CKM, e.g. for the Patient name archetype here:
http://openehr.org/ckm/#showArchetype_1013.1.477_CHANGEREQUESTS
Regards
Sebastian
From: openEHR-technical
implement such a function?
Hi Dmitry,
I’m not sure if this helps, but if you already have a local directory of ADL
archetypes then you can run the Ocean Archetype Editor in batch-processing mode
from the command line to export them as XML.
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform
10/2015 11:20, "Sebastian Garde"
<sebastian.ga...@oceaninformatics.com
<mailto:sebastian.ga...@oceaninformatics.com>> escribió:
Hi Heather,
Instead of removing the incorrect UCUM unit and the old modelling
patterns completely, would it be possible to mark these
Thanks Bert and all,
To me it was quite enlightening and pleasurable to see so many people
chip in and defend openEHR in the last 24 hours or so.
It couldn't have been clearer to me what you, Silje, Stef, Ian, Thomas,
Koray, Pablo and Seref have said.
Sebastian
On 04.09.2015 08:48, Bert
Hi Dave and all,
This is the Java XML Serialiser generating XML from ADL on the fly in
the CKM.
The archetype editor is doing it "your" way as well, and I would assume
this is correct.
I am a bit surprised this is happening, because I am pretty sure we
looked in depth at any the
. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics
Skype: gardeseb
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
openEHR-technical mailing list
openEHR-technical
/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
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI
Hi Pablo,
Looks like a bug to me.
You can submit bug reports for CKM via CKM's help menu
(or directly at
https://oceanehr.atlassian.net/rest/collectors/1.0/template/form/fa48ed8d?os_authType=none
)
Regards
Sebastian
On 14.07.2015 09:01, pablo pazos wrote:
Sometimes the translator email
On 18/11/2014 12:50, David Moner wrote:
Hi,
I was not aware of this addition. It is clear that having these UIDs
it will be simpler to check if the archetype has changed, as you say.
But is it also the intention of these UIDs to be used to fill the
archetype_id attributes in the RM
are
actually used for (namely to describe data).
Sebastian
Code24
On 10/1/2014 5:44 PM, Sebastian Garde wrote:
Hi Sebastian,
I realise you are physically not too far away from me in Germany and
we even share the same name, so I hope you won't shoot the messenger
here, but I have to say
Hi Thomas and all,
On 01.10.2014 14:07, Thomas Beale wrote:
On 01/10/2014 11:23, Ian McNicoll wrote:
In that sense v0.0.0 and v1.0.0-unstable are identical in terms of
their ?stability? and lack of commitment to the versioning rules.
I don't think this is true. Firstly, the standard first
are interested in feedback from the
community on whether V0 should be implemented in CKM and other openEHR
tools, although in practice V1- will do an identical job in terms of version
number governance.
Regards,
Ian McNicoll
Heather Leslie
Sebastian Garde
Thomas Beale
an identical job in terms of version
number governance.
Regards,
Ian McNicoll
Heather Leslie
Sebastian Garde
Thomas Beale
___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr
On 01.10.2014 14:57, Thomas Beale wrote:
On 01/10/2014 13:31, Sebastian Garde wrote:
It seems to me a no-brainer that we should support v0, because it's
the clearest possible sign I can think of, that everyone already
recognises, that indicates an artefact to be in early
chaotic
, Thomas Beale wrote:
On 01/10/2014 13:31, Sebastian Garde wrote:
It seems to me a no-brainer that we should support v0, because it's
the clearest possible sign I can think of, that everyone already
recognises, that indicates an artefact to be in early
chaotic/uncontrolled development. So v0
V0 should be implemented in CKM and other
openEHR
tools, although in practice V1- will do an identical job in terms of
version
number governance.
Regards,
Ian McNicoll
Heather Leslie
Sebastian Garde
Thomas Beale
___
openEHR-technical mailing
panel and select Change Requests.
Check out all the details at
http://www.openehr.org/wiki/display/healthmod/CKM+Change+Requests
The release notes for this release can be found at
http://www.openehr.org/wiki/display/healthmod/CKM+Release+1.3.0
Regards
Sebastian
--
*Dr. Sebastian Garde*
/Dr. sc
On 18.02.2014 14:56, Bert Verhees wrote:
For example, in the OpenEHR, the idea was that CKM would serve the
world with archetypes, and there would be no need of a strong
archetypeId-system, because, all archetypes ever to be taken seriously
were in CKM.
Now it is recognized that this is
On 18.02.2014 16:48, Bert Verhees wrote:
On 02/18/2014 03:52 PM, Sebastian Garde wrote:
On 18.02.2014 14:56, Bert Verhees wrote:
For example, in the OpenEHR, the idea was that CKM would serve the
world with archetypes, and there would be no need of a strong
archetypeId-system, because
repository or 'framework'. Much as we might
want there only ever to be one for the world, this was clearly only
ever going to be possible in the very long term, and quite impossible
for some concepts.
Ian
On 18 February 2014 16:05, Sebastian Garde
sebastian.garde at oceaninformatics.com wrote
Dear all,
We have updated the Clinical Knowledge Manager (
http://www.openehr.org/ckm ) today.
Among others, this new release adds reviewing for templates based on its
operational template (OPT).
Some aspects of how archetypes and templates are being displayed and of
the user interface in
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
-- next part --
An HTML attachment
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130513/0144a4ba
Editor: Under Tools/Options set the URL for shared
repository to http://openehr.org/ckm/services/ArchetypeFinderBean?wsdl
Regards
Sebastian
On 08.03.2013 09:36, Shinji KOBAYASHI wrote:
I confirmed, the web services working, too.
2013/3/8 Sebastian Garde sebastian.garde at oceaninformatics.com
/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
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
2013/3/7 Sebastian Garde sebastian.garde at oceaninformatics.com:
Hi Shinji,
No, they are certainly not obsolete.
This was just a curly bracket that moved one up accidentally.
I have fixed this locally and will be deploy asap.
Cheers
Sebastian
On 07.03.2013 13:36, Shinji KOBAYASHI wrote
These 4 webservices should work now as expected (using the /ckm url).
Sebastian
On 07.03.2013 15:58, Sebastian Garde wrote:
Hi Shinji,
I don't think anything has changed there (once it works again).
Regards
Sebastian
On 07.03.2013 14:43, Shinji KOBAYASHI wrote:
Hi Sebastian,
Thank you
-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130105
).
Thank you for the suggestion!
Cheers
Sebastian
On 27.07.2012 09:00, Sebastian Garde wrote:
Pablo,
you can just click on any of the other buttons after you logged in and
the rest of the buttons will appear as well
Sebastian
On 27.07.2012 03:33, pablo pazos wrote:
Hi,
When I'm seeing
/
Twitter: http://twitter.com/ppazos
___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Dr. Sebastian Garde
Dr. sc. hum., Dipl.-Inform. Med, FACHI
Senior Developer
Ocean Informatics
Skype: gardeseb
___ openEHR-technical mailing
list
://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Senior Developer
Ocean Informatics
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments
Hi Diego,
The issue has been resolved.
Cheers
Sebastian
On 02.04.2012 10:16, Sebastian Garde wrote:
Hi Diego,
thanks, yes, we are working on it.
It is simply the licence file that has expired.
Regards
Sebastian
On 02.04.2012 10:09, Diego Bosc? wrote:
Seems that there is some problem
case for this.
Sebastian
On 28.03.2012 19:16, Thomas Beale wrote:
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
The XML generator had a comment not sure if needed next to the
any_allowed related code.
So I have removed this now.
A corrected version is deployed to the openEHR ckm.
Regards
Sebastian
On 29.03.2012 08:49, Sebastian Garde wrote:
Sounds like the Java XML generator needs to be corrected
Hi Pablo,
sure, the easiest is probably to go to the Share with Colleague Tab
for that archetype.
You'll find a) the direct URL to this archetype which you can copy or
share using AddToAny and b) use the form to send it directly.
For details like referring to a specific revision of the
://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med
On 18.01.2012 12:45, Ian McNicoll wrote:
Hi Jostein,
Sebastian can confirm this but I understand that CKM uses an open
Freemind viewer browser component.
Essentially yes, it is the Freemind Flash Browser.
The source files for Freemind is a fairly simple XML as you can see when
you download
Dear all,
We have released a new version of CKM - up and running at
openehr.org/knowledge
The 1.1.5 release of CKM is a release that contains some major new
functionality and some minor usability changes and bugfixes.
Most prominently, it features the newly developed review functionality
for
The more I think about it, the more I think we should go with the pure
String option, because:
* it is the shortest form
* it is the most human readable form
* the same approach can be used for all three of occurrences /
cardinality / existence, even though we know it is
Yes - and if you want to go one further, ITEM_LIST is nothing more than
a special case of ITEM_TREE as well.
Modelling this explicitly hasn't been extremely useful I believe,
especially if weighed against your evolution argument.
Sebastian
Am 04.10.2011 01:42, schrieb Heather Leslie:
I model
I agree with you Thomas,
Whether these tools are open source or just free as in beer (for
openEHR) - doesn't matter too much...for me it is far more important
that the tool does its job.
If there are open source tools that really do the job - finevery
fine indeed, but if not, I for one, do
Am 16.09.2011 16:27, schrieb pablo pazos:
Nabble is great for mailing lists. http://www.nabble.com/ (one thing
that bothers me is the 40KB limit of the openEHR lists emails)
The 40kB limit is indeed a bit on the low side.
But it would not be so bad if the mailing list would immediately reject
The real problem though is not the actual size of the limit , but the
manual interaction that is required and the time delay until rejection.
If the list could be changed to automatic rejection this would solve the
problem .
Sebastian
Am 16.09.2011 19:21, schrieb Thomas Beale:
The 40kb limit
to the XSDs
temporarily or better wait for you to modify the serialiser and try to
re-download the archetypes from the CKM?
All the best
Athanasios Anastasiou
On 06/09/2011 09:53, Sebastian Garde wrote:
Hi
CKM is using the XML serialiser of the openEHR Java Reference
implementation
Hi
CKM is using the XML serialiser of the openEHR Java Reference
implementation.
It seems that the serialiser applies a different order to some elements
than required by the schema.
Not sure if these were turned around in the xsd at some stage maybe?
While I don't really understand why these
temporarily or better wait for you to modify the serialiser and try to
re-download the archetypes from the CKM?
All the best
Athanasios Anastasiou
On 06/09/2011 09:53, Sebastian Garde wrote:
Hi
CKM is using the XML serialiser of the openEHR Java Reference
implementation.
It seems
2011 10:53, Sebastian Garde
sebastian.garde at oceaninformatics.com wrote:
Hi
CKM is using the XML serialiser of the openEHR Java Reference
implementation.
It seems that the serialiser applies a different order to some elements
than required by the schema.
Not sure if these were turned
Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101216/d73ec7cf/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/f7ae9687/attachment.html
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101015/ff29af66/attachment.html
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100810/aed44411/attachment.html
Peter Gummer wrote:
Sebastian Garde wrote:
Not sure if this change would has an impact on the canonical MD5
hash generated by the Archetype Editor - ideally it would be the
same for an archetype with or without the concept clause?
I doubt it, Sebastian. Any small changes
Hi Thomas,
That makes a lot of sense in my opinion.
Don't think it will be a major problem, at least in the Java space this
particular change in ADL 1.5 is not worrying me as there are others that
are a lot more fundamental.
Not sure if this change would has an impact on the canonical MD5 hash
Hi Thomas,
A few concerns that come to my mind - I am not so sure that
removing/changing this rule is a good thing:
* It puts an additional burden on tools to support both ways of
creating a specialised node wither with or without specialised at
code.
* It puts an additional
Sebastian
Leonardo Moretti wrote:
I'm using the jars found on
http://www.openehr.org/wiki/display/projects/Java+Project+Download
Is there a new release of these jars? Where can I download it?
Thanks
leo
Sebastian Garde-2 wrote:
Leo,
In that case, you are probably using an older version
compliant with the standard..
Regards
leo
Sebastian Garde-2 wrote:
Hi Leonardo,
CKM is using the Java XML Serialiser to generate the XML presentation,
so it is no surprise you are seeing the same effect there.
I would see the Schemas as the source of truth.
If it is a sequence
Hi Leonardo,
CKM is using the Java XML Serialiser to generate the XML presentation,
so it is no surprise you are seeing the same effect there.
I would see the Schemas as the source of truth.
If it is a sequence in the schema then I believe that the order cannot
simply be changed in the XML.
Hi Thomas,
do you know if there is a formal way of how RefSets (=the resulting
Snomed CT codes etc.) and the RefSet query (=the query on Snomed CT to
get to the RefSet) are expressed and shared?
Similar to what is described here but based on RefSets:
for
openEHR templates, say.
eric
On 2010-05-06, at 5:48 PM, Sebastian Garde wrote:
Hi Thomas,
do you know if there is a formal way of how RefSets (=the
resulting Snomed CT codes etc.) and the RefSet query (=the query
on Snomed CT to get to the RefSet
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org
Mikael Nystr?m wrote:
I agree that we have to wait and see how much problems we will get. That was
also my reason to reply to Sebastian's e-mail which told that there is no
problem to add terminology bindings after the archetypes are finalized.
However, I didn't refer to theoretical worst
, and is believed to be clean.
http://www.dit.ie
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Hi Koray,
did you have a look at Mendeley http://www.mendeley.com/ ?
I haven't checked it out yet in detail yet, but it looks promising.
They have sufficient clout to make it happen (they are the skype people)
Some of the papers unfortunately cannot be made available on the openEHR
website due
/openEHR+Templates+and+Specialised+Archetypes
Sebastian
Diego Bosc? wrote:
So is there a final template schema/specification? Last thing I know
is that both Ocean and Zilics had their own schema for templates
2010/1/20 Sebastian Garde sebastian.garde at oceaninformatics.com
Best regards
Sebastian
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr
/listinfo/openehr-technical
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4628 (20091122) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean
Hi,
I think a couple of things could be changed to make CKM more
search-friendly, but I also think we have to look carefully what we want
and where:
* The idea behind linking comments/discussions directly to an
archetype and not just using a mailing list or the like is that we
Grahame Grieve wrote:
hi
Two of the demographics archetypes are open for review : postal address
and person name. I appear to be the only one who has commented on
either, but the system seems to have lost my review of the person name
archetype?
Hi Grahame,
I can see your reviews of both
just drop me an email and let me know, so we can coordinate and make
sure there is not duplication. Once you have translated an archetype
it needs to be uploaded to CKM by an Editor - so currently that role
resides with Ian McNicoll, Sebastian Garde or myself. So send it as
an email
/mailman/listinfo/openehr-technical
--
Ocean Informatics
Dr Sebastian Garde
Senior Developer
Ocean Informatics
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman
1 - 100 of 122 matches
Mail list logo
