openEHR artefact namespace identifiers

[Thomas Beale]

, as otherwise the formal identifier of an archetype
> will change if a locally developed archetype becomes promoted to
> international use, a relatively common occurrence.
>
> We would then need to record the current publisher so that the
> agency with current responsibility could be identified
> current_publisher = 
>
> Thoughts would be welcome as I think we need to start making these
> (or alternative) specifications formal to enable tooling and
> application support to go ahead.
>
> Ian
>
> Dr Ian McNicoll
> office +44 (0)1536 414994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
> <mailto:ian.mcnicoll at oceaninformatics.com>
>
> Clinical analyst, Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> <http://www.openehr.org/knowledge>
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care www.phcsg.org <http://www.phcsg.org>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org>
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
> -- 
> David Moner Cano
> Grupo de Inform?tica Biom?dica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es
>
> Universidad Polit?cnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
> Valencia ? 46022 (Espa?a)
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- 
Ocean Informatics   *Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>


*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/282c622c/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/282c622c/attachment.jpg>

openEHR artefact namespace identifiers

[Erik Sundvall]

Hi!

On Tue, Apr 5, 2011 at 17:51, Ian McNicoll
 wrote:
> artefact identification proposals
> at 
> http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf
...
> se.skl.epj::openEHR-EHR-EVALUATION.problem.v1

...Then discussions regarding UUIDs, OIDs etc followed in several messages

Is not the simplest thing to just use URIs [
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even
better allowing non-latin characters by using IRIs [
http://tools.ietf.org/html/rfc3987 ]?

Then organizations can choose if they want to base IDs on
domain-names, UUIDs, OIDs or whatever that fits in a URI (which might
be a URN, see list at http://www.iana.org/assignments/urn-namespaces/
). Some archetype authoring organizations may like names with
semantics, some may not, so why enforce any of the views.

Now since metadata is going to be well defined inside the file, the
need for semantics in identifiers or file names is gone so the main
thing left is that we want a _unique_ string. URIs are supposed to be
unique.

Some URI-examples:
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
urn:oid:1.3.6.1.2.1.27
urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1
http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1
http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3
urn:nbn:se:liu:diva-38012

I see no point in enforcing usage of OIDs as suggested in some responses.

The idea of not changing the ID if/when transferring responsibility of
an archetype between authorities sounds very reasonable if the content
is unchanged.

When I visited Brazil, I noticed that the MLHIM project's development
version was using UUIDs for the artifacts (CCDs) that correspond to
what is called archetypes in openEHR.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

openEHR artefact namespace identifiers

[michael.law...@csiro.au]

Note that in the SNOMED case, there are two identifiers in play: the concept 
identifier (which contains the namespace ID) and a module identifier. The idea 
is that ye namespace in the concept identifier will remain fixed and thus 
indicate the entity that originally introduced the concept, while the moduleId 
used associated with the defining entries in the release files changes to 
indicate the entity currently maintaining that concept.

michael

From: Ian McNicoll mailto:ian.mcnic...@oceaninformatics.com>>
Reply-To: For openEHR technical discussions mailto:openehr-technical at openehr.org>>
Date: Wed, 6 Apr 2011 01:51:05 +1000
To: For openEHR technical discussions mailto:openehr-technical at openehr.org>>
Subject: openEHR artefact namespace identifiers

Hi,

About a year ago Thomas published a draft of some detailed artefact 
identification proposals at 
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf

to help with the rapidly approaching scenario of having to cope with similarly 
named artefacts being published by different authorities. We are starting to 
see this scenario emerging  in real-world projects and whilst potential 
collisions can be managed informally for now, we will need a formal mechanism 
before long.

I would like to raise one aspect which I think might need re-thought on the 
basis of recent IHTSDO proposal for SNOMED covering the same ground.

In the pdf Thomas says

" When an archetype is moved from its original PO (e.g. a local health 
authority, or a specialist peak
body) to a more central authoring domain (e.g. a national library, openEHR.org) 
its namespace will be
changed to the new domain, as part of the review and handover process. The 
archetype's semantic
definition may or may not change. In order for tools to know that an archetype 
was not created new
locally, but was moved from another PO, an explicit reference statement can be 
made in the archetype
in the description section of an archetype as follows:"

id_history = 

Thoughts would be welcome as I think we need to start making these (or 
alternative) specifications formal to enable tooling and application support to 
go ahead.

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor 
www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org

openEHR artifact namespace identifiers

[Heath Frankel]

 an archetype will change
if a locally developed archetype becomes promoted to international use, a
relatively common occurrence.

 

We would then need to record the current publisher so that the agency with
current responsibility could be identified

current_publisher = <"se.skl.epj">

 

Thoughts would be welcome as I think we need to start making these (or
alternative) specifications formal to enable tooling and application support
to go ahead.

 

Ian

 

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org

-- next part --
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 10878 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/affd720a/attachment.dat>

openEHR artefact namespace identifiers

[Diego Boscá]

Also, some of the restrictions of the identifier name seem arbitrary,
like minimum number of characters or what characters can you put.

2011/4/6 David Moner :
> Hello,
> I like that approach regarding namespaces, it will be needed sooner than
> later.
> Related to archetype identifiers there is another problem still to be
> solved. How they deal with RM evolutions? ?Current openEHR RM release is
> 1.0.2 but it can change in the future. Nowhere at archetypes is said which
> RM version was used to define them. This information should go, at least, at
> the archetype header, but probably should also be represented at the
> archetype id. ?Otherwise we will not be able to?differentiate?between an
> archetype for one version of the RM and the same archetype (modified if it
> is the case) for a different one.
> David
>
>
> 2011/4/5 Ian McNicoll 
>>
>> Hi,
>> About a year ago Thomas published a draft of some detailed
>> artefact?identification?proposals
>> at?http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf
>> to help with the rapidly?approaching?scenario of having to cope with
>> similarly named artefacts being published by different authorities. We are
>> starting to see this scenario emerging ?in real-world projects and whilst
>> potential collisions can be managed informally for now, we will need a
>> formal mechanism before long.
>> I would like to raise one aspect which I think might need re-thought on
>> the basis of recent IHTSDO proposal for SNOMED covering the same ground.
>> In the pdf Thomas says
>> " When an archetype is moved from its original PO (e.g. a local health
>> authority, or a specialist peak
>> body) to a more central authoring domain (e.g. a national library,
>> openEHR.org) its namespace will be
>> changed to the new domain, as part of the review and handover process. The
>> archetype's semantic
>> definition may or may not change. In order for tools to know that an
>> archetype was not created new
>> locally, but was moved from another PO, an explicit reference statement
>> can be made in the archetype
>> in the description section of an archetype as follows:"
>> id_history = > The IHTSDO proposals cover ?the same scenario i.e a SNOMED code originally
>> authored in one namespace subsequently being managed in a new namespace. A
>> good example might be a SNOMED term which is originally used t a national
>> level but is then adopted internationally. They suggest that the term keeps
>> its original authored namespace, and it is the namespace of the managing
>> entity that changes, arguing that this is much less disruptive to systems
>> that are using the term concerned.
>> I think we should consider adopting the same approach for openEHR
>> archetypes, as otherwise the formal identifier of an archetype will change
>> if a locally developed archetype becomes promoted to international use, a
>> relatively common occurrence.
>> We would then need to record the current publisher so that the agency with
>> current responsibility could be identified
>> current_publisher = 
>> Thoughts would be welcome as I think we need to start making these (or
>> alternative) specifications formal to enable tooling and application support
>> to go ahead.
>> Ian
>> Dr Ian McNicoll
>> office +44 (0)1536 414994
>> fax +44 (0)1536 516317
>> mobile +44 (0)775 209 7859
>> skype ianmcnicoll
>> ian.mcnicoll at oceaninformatics.com
>>
>> Clinical analyst,?Ocean Informatics, UK
>> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
>> Honorary Senior Research Associate, CHIME, UCL
>> BCS Primary Health Care ?www.phcsg.org
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
>
> --
> David Moner Cano
> Grupo de Inform?tica Biom?dica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es
>
> Universidad Polit?cnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
> Valencia ? 46022 (Espa?a)
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>