In the context of exposing a unique Identifier at Entry level e.g for
FHIR mapping, I wondered about concatenating the composiitonUid (inc.
version) with an Entry UID. i.e Versioning (as now) is handled at
composition/contribution level.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0
On 16/12/2016 02:37, Bjørn Næss wrote:
If you add UID on ENTRY level and you want to use that for some
referencing/look up functionality:
How do you handle versioning of Compositions and its content? Is it a new
entry UID for each version ?
same UID across versions. There is a way to identi
I believe that ISO 13606 renewal has proposed uuid to be made optional, but
they are still there
El 18/12/2016 23:23, "Heath Frankel"
escribió:
> I think it should be a strong recommendation rather than mandatory
> considering it is currently optional and the need for backward
> compatibility.
>
nical@lists.openehr.org
Emne: Re: Could the specs group consider making uid mandatory?
right. Good argument from evidence for the UID. Want to create a PR with these
notes?
Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by parsing.
- thomas
On 19/12/2016 09:22, Heath Frankel wro
I completely agree with this argument from Heath :
I think it should be a strong recommendation rather than mandatory
considering it is currently optional and the need for backward
compatibility.
Op ma 19 dec. 2016 07:07 schreef Thomas Beale :
I knew that :)
On 19/12/2016 14:17, Grahame Grieve
I knew that :)
On 19/12/2016 14:17, Grahame Grieve wrote:
Not sure about mixing URIs with UIDs... OTOH, usually easy to
detect by parsing.
there's a URI format for UIDS: urn:uuid:{lowercase}
That's the best to handle mixing them
Grahame
>
> Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by
> parsing.
>
there's a URI format for UIDS: urn:uuid:{lowercase}
That's the best to handle mixing them
Grahame
> - thomas
>
> On 19/12/2016 09:22, Heath Frankel wrote:
>
> I think it should be a strong recommendation ra
right. Good argument from evidence for the UID. Want to create a PR with
these notes?
Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by
parsing.
- thomas
On 19/12/2016 09:22, Heath Frankel wrote:
I think it should be a strong recommendation rather than mandatory
con
I think it should be a strong recommendation rather than mandatory considering
it is currently optional and the need for backward compatibility.
I also think it maybe difficult to apply consistently in some cases such as
feeder data. There are cases in CDA profiles where there are mandatory IDs a
I also think that would be a good idea, since ENTRY = clinical
statement. We could make it an openEHR rule.
- thomas
On 14/12/2016 00:24, Ian McNicoll wrote:
There may be some advantages in routine application of uid at ENTRY level.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44
ig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA
Mobil +47 93 43 29 10
-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På
vegne av Pieter Bos
Sendt: tirsdag 13. desember 2016 14.42
Til: For openEHR technical discussions
Emne: Re: Could the
That sounds reasonable. I wonder how many existing systems already do this…
Regards,
Pieter Bos
Nedap Healthcare
On 13/12/16 14:24, "openEHR-technical on behalf of Ian McNicoll"
wrote:
There may be some advantages in routine application of uid at ENTRY level.
Ian
Dr Ian McNi
There may be some advantages in routine application of uid at ENTRY level.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical
On 13/12/2016 23:46, Seref Arikan wrote:
My preferred scenario would be to have an identifier on every node
indeed. Not having that, I could live with identifiers for at least
some types, such as entry subtypes and a few more. If it cannot be
UID, so be it.
What is the meaning of overhead h
This looks like it. Thanks.
On Tue, Dec 13, 2016 at 12:51 PM, Thomas Beale
wrote:
> https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-
> 91?filter=allopenissues
>
>
> On 13/12/2016 23:01, Boštjan Lah wrote:
>
>> On 13 Dec 2016, at 12:36, Thomas Beale wrote:
>>>
>>>
>>>
>>> On 13/12/20
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-91?filter=allopenissues
On 13/12/2016 23:01, Boštjan Lah wrote:
On 13 Dec 2016, at 12:36, Thomas Beale wrote:
On 13/12/2016 22:27, Pieter Bos wrote:
Generally the top-level structures will have a UID, and the other nodes can be
r
My preferred scenario would be to have an identifier on every node indeed.
Not having that, I could live with identifiers for at least some types,
such as entry subtypes and a few more. If it cannot be UID, so be it.
What is the meaning of overhead here? Processing time? Memory/disk space?
Accordi
> On 13 Dec 2016, at 12:36, Thomas Beale wrote:
>
>
>
> On 13/12/2016 22:27, Pieter Bos wrote:
>> Generally the top-level structures will have a UID, and the other nodes can
>> be reached with a path from there. So a UID plus path combination should
>> make all features possible. It’s alread
On 13/12/2016 22:27, Pieter Bos wrote:
Generally the top-level structures will have a UID, and the other nodes can be
reached with a path from there. So a UID plus path combination should make all
features possible. It’s already recommended to set the uid on those top-level
structures.
Sett
technical discussions
Subject: Could the specs group consider making uid mandatory?
Greetings,
Apologies if I missed a discussion about this, but as per
http://www.openehr.org/releases/RM/latest/docs/common/common.html#_unique_node_identification
"LOCATABLE descendants may have a uid, contain
Greetings,
Apologies if I missed a discussion about this, but as per
http://www.openehr.org/releases/RM/latest/docs/common/common.html#_unique_node_identification
"LOCATABLE descendants may have a *uid*, containing a GUID"
The optional/recommended nature of uid makes it impossible to implement
21 matches
Mail list logo
