<[ISO_639-1::ru]>
author = <
["name"] = <"Nina Alexandrova">
["organisation"] = <"Dostoevsky Media Services">
["email"] = <"nina at translation.dms.ru"<mailto:nina at
translation.dms.ru>>
["accreditation"] = <"Russian Translator id 892230-3A">
>
other_contributors = <"Marcus Barakovmailto:marcus at medicaltranslation.co.uk>>", "Irina
Pavlovamailto:irina at emias.ru>>", "Iliana Markova
<mailto:iliana.markova at gorodskaya.ru>">
>
>
or do we need more?
- thomas
On 17/03/2015 14:38, Bakke, Silje Ljosland wrote:
The way I see it the whole translation author block should ideally be
repeatable, including separate elements for name, organisation, email and
accreditation, which would of course require the accreditation element to ble
moved inside the author block (why isn't it there in the first place?).
Regards,
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/01232100/attachment-0001.html>
anslator id
> 00400595">*
>>
>
> author = <
> ["name"] = <"Bonnie Tyler">
> ["email"] = <"*_bonnie at medicaltranslation.co.uk_*"
> <mailto:freddy at medicaltranslation.co.uk>>
> [""] = <"">
> *["accreditation"] = <"Whatevs">*
>>
>
> author = <
> ["name"] = <"*Yannick Guillou* ">
> ["email"] = <"*_yg at francaistrad.fr_*
> <mailto:freddy at medicaltranslation.co.uk>">
> [""] = <"aabb">
>>
> *other_contributors = <mailto:jules at nautilus.fr>**>**?, ?Victor Hugo <mailto:vic at hunchback.net>**>**?>*
> >
> >
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/6565b8fa/attachment.html>
In fact, we spent some time not so much ago checking that archetypes
created with LinkEHR could be uploaded into the CKM without problems
;)
2015-03-17 15:49 GMT+01:00 Ian McNicoll :
> LinkEhr supports the demographic archetypes.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +4
s.ru">
*["accreditation"] = <"Russian Translator id 892230-3A">*
>
* other_contributors = <"Marcus
Barakov", **"Irina
Pavlova", "Iliana Markova ">*
>
>
or do we n
yper_no>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/4e106604/attachment.html>
atlassian.net/browse/SPECPR-24
This issue highlights some potential problems as well, but doesn't have a clear
solution yet.
I believe it should be considered at the same time.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/piper
_
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/13937018/attachment.html>
Med, FACHI/
Ocean Informatics
Skype: gardeseb
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft.
http://www.avast.com
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/e60d0fc6/attachment.html>
I'm not an UCUM expert, but that's what I believe it should be. Anything
with curlies seems to be equivalent to 1, so {1}=1.
There is some more information under ?29:
http://unitsofmeasure.org/ucum.html#section-Derived-Unit-Atoms
and there is a UCUM tracker issue:
http://unitsofmeasure.org/trac/ti
True, UCUM is an obscure standard :D
2015-03-17 12:02 GMT+01:00 David Moner :
> That's true Daniel, to be completely compliant with UCUM it seems the unit
> should be defined as 1 and not as an empty string.
>
> http://unitsofmeasure.org/ucum.html#section-Examples-for-some-Non-Units.
>
> 2015-03-1
> >
> > > ___
> > > openEHR-clinical mailing list
> > > openEHR-clinical at lists.openehr.org
> > >
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> >
> > ___
> > openEHR-clinical mailing list
> > openEHR-clinical at lists.openehr.org
> >
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/7b3bc50a/attachment.html>
So it would be stored as {1}? (as they are supposed to be UCUM). Empty
units doesn't feel like valid UCUM units either.
2015-03-17 11:55 GMT+01:00 Daniel Karlsson :
> Hi,
> what about the unit 1 (uno) for dimensionless quantities?
> http://goldbook.iupac.org/D01742.html
>
> /Daniel
>
>
> On tis, 2
Hi,
what about the unit 1 (uno) for dimensionless quantities?
http://goldbook.iupac.org/D01742.html
/Daniel
On tis, 2015-03-17 at 11:43 +0100, Diego Bosc? wrote:
> Qualified Real is a property from the domain type, not the type
> itself, I thought the idea was to get rid of domain types in the
>
Qualified Real is a property from the domain type, not the type
itself, I thought the idea was to get rid of domain types in the
future.
2015-03-17 11:23 GMT+01:00 Ian McNicoll :
> Hi David,
>
> Qualified Real is the current preferred option (for me anyway). I think we
> have flagged up in the spe
www.linkedin.com/in/davidmoner
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/7bf08812/attachment-0001.html>
lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
*Dr. 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.
http://www.avast.com
<mailto:openEHR-clinical at
lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/abd5a64a/attachment.html>
slations/bindings
These requirements are becoming a high priority in CKM development
- Peter
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/1b0a7b57/attachment-0001.html>
46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/e0d4004e/attachment.html>
ensionless quantities.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/f8dde57d/attachment-0001.html>
safe to rely on setting an empty unit to
> represent just a Real number
yes, I agree.
Release 1.0.3 is coming soon ;-)
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments
cker
> https://openehr.atlassian.net/browse/SPECPR-24
> This issue highlights some potential problems as well, but doesn't
> have a clear solution yet.
>
> I believe it should be considered at the same time.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/0a0092b0/attachment.html>
his to ADL/AOM 2, will it be enough for the
future?
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/1289c0a5/attachment.html>
ar as the
> DV_COUNT, but representing a real number and not an integer? Something
> equivalent to the REAL data type in ISO 21090
>
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/3ca94cd1/attachment.html>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
------ next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/4c02ba64/attachment-0001.html>
25 matches
Mail list logo