openEHR artefact namespace identifiers

[Diego Boscá]

That we are very cautious about reference model version changes
doesn't mean that any other organization does the same.
Look at HL7 v2 & v3 for example ;)

2011/4/8 Thomas Beale :
> On 07/04/2011 12:07, David Moner wrote:
>> Dear Thomas,
>>
>> I agree with your general approach, but you miss two important things.
>>
>> 1. If openEHR spreads, you cannot expect that all implementations will
>> be always up-to-date. That means that just upgrading the version
>> number of the archetype will not be enough for a system to
>> automatically differentiate the right version for the RM version they
>> have implemented. If we just say "Ok, but since that information will
>> be at the archetype header we don't need it at the identifier", we can
>> also say the same for the concept, the RM class, the RM and the
>> organisation. At the end, we will find that we don't need a semantic
>> id, as Erik said, and that a UUID, OID or whatever is enough for
>> identifying archetypes.
>
> I have no problem with a UUID or similar, but I don't think they are
> that useful on their own, and they require more tooling support. If you
> want to make inferences about what RM class, and what clinical concept
> a given archetype is about, and you only have a UUID, you need to know
> what / where to lookup. You also have to be able to have rules somewhere
> to know when to assign a new UUID, when to treat two different UUIDs as
> referring to archetypes that are actually revisions (i.e both compatible
> with the same data), when to treat them as versions (not compatible with
> the same data). We could potentially make the RM class name and concept
> id just new fields in the description. The thing you lose (and maybe it
> is worth losing) is that by creating a tuple of a particular subset of
> meta-data items, viz: publishing organisation + RM issuer + RM class
> name + archetype concept id + archetype version id, this happens to be
> the unique key in archetype space (a new revision or new translation on
> the other hand is obviously a new artefact, but it is not semantically a
> new archetype). To achieve the equivalent with a UUID -based id system
> means smarter software and either centralised id management (ISO oids)
> or some distributed id system, possibly like DNS. At the moment we can
> process the archetype id and directly know the relationship between two
> archetypes. I think going down the UUID road will require more agreement
> on tools and governance infrastructure.
>
>>
>> 2. Archetypes are not only for openEHR. We must always have in mind
>> that other reference models can be used with their own life-cycle that
>> could be not so fine-grained as in openEHR. For example, we are now
>> creating HL7 CDA R2 archetypes but during this year it is expected CDA
>> R3 to be approved. How will we differentiate archetypes of R2 from
>> archetypes of R3? Once again, R2 will still be used for many years and
>> updating the version number isn't enough.
>
> I don't know what R3 looks like, but if it is a different reference
> model, then the ids would be something like
>
> hl7-cda3-Entry.diagnosis.v1
>
> If CDA r3 on the other hand is a clean extension / superset of CDAr2,
> then the 'reference model' is really just 'cda', and there is no simple
> relationship between particular archetypes and particular releases of
> the CDA model.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

openEHR artefact namespace identifiers

[David Moner]

>
> > 2. Archetypes are not only for openEHR. We must always have in mind
> > that other reference models can be used with their own life-cycle that
> > could be not so fine-grained as in openEHR. For example, we are now
> > creating HL7 CDA R2 archetypes but during this year it is expected CDA
> > R3 to be approved. How will we differentiate archetypes of R2 from
> > archetypes of R3? Once again, R2 will still be used for many years and
> > updating the version number isn't enough.
>
> I don't know what R3 looks like, but if it is a different reference
> model, then the ids would be something like
>
> hl7-cda3-Entry.diagnosis.v1
>
> If CDA r3 on the other hand is a clean extension / superset of CDAr2,
> then the 'reference model' is really just 'cda', and there is no simple
> relationship between particular archetypes and particular releases of
> the CDA model.
>
> - thomas
>
>
So, at the end you are putting the RM version somewhere at the identifier...
 :-)

(btw, I don't know which will be the changes at R3)

David

-- 
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)
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artefact namespace identifiers

[Thomas Beale]

On 07/04/2011 16:40, David Moner wrote:
>
>
> So, at the end you are putting the RM version somewhere at the 
> identifier...  :-)
>
> (btw, I don't know which will be the changes at R3)

no - I am just using 'r2', 'r3' as parts of a name. I.e. 'CDAr2' and 
'CDAr3' may be two different names just like 'Marco' and 'Pierro', ... 
or like 'ICD9' and 'ICD10'. Here I am assuming that HL7 will allow 
anything to happen in CDAr3, including radical changes. If that is not 
the case, and CDAr3 is really just a clean extension of r2, then the RM 
we are talking about is just 'CDA', and any given archetype may or may 
not work with any particular minor or major release of it.

- thomas

*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artefact namespace identifiers

[Thomas Beale]

On 06/04/2011 12:34, Erik Sundvall wrote:
>
> Now since metadata is going to be well defined inside the file, the

it is not well enough defined yet, but it could be. We would need to do 
some work on that to define the exact rules.

> 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

There are two ways to see this. We could say that, assuming archetypes 
become quite widespread in IT in general, that anything should be 
allowed, just make it a URI formatted id. However, for major domains 
like health, I don't know if this helps, I think we need better 
standards than that. It would be a bit like saying to SNOMED national 
release centres: go make your own concept ids, you don't need to follow 
IHTSDO rules, only a meta-rule that says: don't take an id that has 
already been used.

I think that the URI/IRI/etc argument is a different dimension from the 
content of the ID. URIs et al are about technical accessibility within a 
notionally online info-fabric. But specific communities are still going 
to want to control their spaces- e.g. I don't think we will see ISBNs 
die out any time soon.

- thomas

openEHR artefact namespace identifiers

[Thomas Beale]

On 07/04/2011 12:07, David Moner wrote:
> Dear Thomas,
>
> I agree with your general approach, but you miss two important things.
>
> 1. If openEHR spreads, you cannot expect that all implementations will 
> be always up-to-date. That means that just upgrading the version 
> number of the archetype will not be enough for a system to 
> automatically differentiate the right version for the RM version they 
> have implemented. If we just say "Ok, but since that information will 
> be at the archetype header we don't need it at the identifier", we can 
> also say the same for the concept, the RM class, the RM and the 
> organisation. At the end, we will find that we don't need a semantic 
> id, as Erik said, and that a UUID, OID or whatever is enough for 
> identifying archetypes.

I have no problem with a UUID or similar, but I don't think they are 
that useful on their own, and they require more tooling support. If you 
want to make inferences about what RM class, and what clinical concept  
a given archetype is about, and you only have a UUID, you need to know 
what / where to lookup. You also have to be able to have rules somewhere 
to know when to assign a new UUID, when to treat two different UUIDs as 
referring to archetypes that are actually revisions (i.e both compatible 
with the same data), when to treat them as versions (not compatible with 
the same data). We could potentially make the RM class name and concept 
id just new fields in the description. The thing you lose (and maybe it 
is worth losing) is that by creating a tuple of a particular subset of 
meta-data items, viz: publishing organisation + RM issuer + RM class 
name + archetype concept id + archetype version id, this happens to be 
the unique key in archetype space (a new revision or new translation on 
the other hand is obviously a new artefact, but it is not semantically a 
new archetype). To achieve the equivalent with a UUID -based id system 
means smarter software and either centralised id management (ISO oids) 
or some distributed id system, possibly like DNS. At the moment we can 
process the archetype id and directly know the relationship between two 
archetypes. I think going down the UUID road will require more agreement 
on tools and governance infrastructure.

>
> 2. Archetypes are not only for openEHR. We must always have in mind 
> that other reference models can be used with their own life-cycle that 
> could be not so fine-grained as in openEHR. For example, we are now 
> creating HL7 CDA R2 archetypes but during this year it is expected CDA 
> R3 to be approved. How will we differentiate archetypes of R2 from 
> archetypes of R3? Once again, R2 will still be used for many years and 
> updating the version number isn't enough.

I don't know what R3 looks like, but if it is a different reference 
model, then the ids would be something like

hl7-cda3-Entry.diagnosis.v1

If CDA r3 on the other hand is a clean extension / superset of CDAr2, 
then the 'reference model' is really just 'cda', and there is no simple 
relationship between particular archetypes and particular releases of 
the CDA model.

- thomas

openEHR artefact namespace identifiers

[David Moner]

Dear Thomas,

I agree with your general approach, but you miss two important things.

1. If openEHR spreads, you cannot expect that all implementations will be
always up-to-date. That means that just upgrading the version number of the
archetype will not be enough for a system to automatically differentiate the
right version for the RM version they have implemented. If we just say "Ok,
but since that information will be at the archetype header we don't need it
at the identifier", we can also say the same for the concept, the RM class,
the RM and the organisation. At the end, we will find that we don't need a
semantic id, as Erik said, and that a UUID, OID or whatever is enough for
identifying archetypes.

2. Archetypes are not only for openEHR. We must always have in mind that
other reference models can be used with their own life-cycle that could be
not so fine-grained as in openEHR. For example, we are now creating HL7 CDA
R2 archetypes but during this year it is expected CDA R3 to be approved. How
will we differentiate archetypes of R2 from archetypes of R3? Once again, R2
will still be used for many years and updating the version number isn't
enough.

Finally, I also agree that is not the same to talk about "RM version of an
archetype" than to talk about "archetype validity regarding a RM", but one
should not exclude the other.

David



2011/4/7 Thomas Beale 

>  On 05/04/2011 19:16, David Moner wrote:
>
> 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.
>
>
> It should go in the archetype, that is for sure - but it should be
> understood only as 'the RM version used when this archetype was authored /
> quality assured etc' - rather than 'the RM version for which this archetype
> is valid'. The reason is easy to understand: for some particular archetype,
> authored at RM 1.0.2 let's say, it may be valid for many RM revisions after
> that, even RM 2.x, and not only that, it might be perfectly valid for prior
> revisions e.g. 1.0, 1.0.1, even 0.95 - it can depend a lot on what parts of
> the RM the archetype happens to use. This is the reason I argued against
> including the RM version in the archetype id, because it doesn't tell us
> anything about validity. (We had a long discussion about this on the
> technical list last year or 2009 I forget which).
>
> Now.. if the RM changes, let's say to 2.0.0, then we might assume that
> there are one or two breaking changes, and that a few archetypes could
> break. The only way I can see to deal with this is:
>
>- we stick with the rule that minor RM change numbers never break
>archetypes (or indeed existing data), i..e 1.0.1 -> 1.0.2 -> 1.0.3 etc is
>guaranteed safe
>- we say that a major RM version change, i.e. 2.x, 3.x etc that
>includes breaking changes there has to be a validity test run on all
>archetypes.
> - any that don't pass, i.e. are compromised by the change need to be
>   marked in some way, maybe a header field with the meaning 'valid up to 
> RM
>   release xxx' or so.
>   - such archetypes would themselves then have to be versioned
>   (.v1 => .v2)
>
> It should be remembered that we can undertake many innovations and 'fixes'
> that don't break anything on the RM, and therefore don't require a major
> release. So openEHR 2.x, 3.x etc are likely to be extremely rare events.
>
> - thomas
>
>
>
>
> --
>   [image: Ocean Informatics]  *Thomas Beale
> Chief Technology Officer, Ocean Informatics
> *
>
> Chair Architectural Review Board, *open*EHR 
> Foundation
> Honorary Research Fellow, University College 
> London
> Chartered IT Professional Fellow, BCS, British Computer 
> Society
> Health IT blog 
> *
> *
>
> ___
> 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)
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artefact namespace identifiers

[pablo pazos]

Hi!

I like the Erik's idea of having a global and unique URI to reference each 
archetype (also for templates). This will help to build a global archetype 
server, and the domain of the URI can act as the namespace of the archetype. 
And, if those domains really exist (like openehr.org), an archetype URI can be 
equal to real working URL :D, so we can request any archetype directly from the 
server via HTTP requests.

And it'll be great to build automated archetype tests to check the validity of 
an archetype against a version of the RM, as Thomas said. It'll be great to 
have this functionality integrated with the archetype editor.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



Date: Wed, 6 Apr 2011 23:11:42 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: openEHR artefact namespace identifiers



  



  
  
On 05/04/2011 19:16, David Moner wrote:
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.



It should go in the archetype, that is for sure - but it should be
understood only as 'the RM version used when this archetype was
authored / quality assured etc' - rather than 'the RM version for
which this archetype is valid'. The reason is easy to understand:
for some particular archetype, authored at RM 1.0.2 let's say, it
may be valid for many RM revisions after that, even RM 2.x, and not
only that, it might be perfectly valid for prior revisions e.g. 1.0,
1.0.1, even 0.95 - it can depend a lot on what parts of the RM the
archetype happens to use. This is the reason I argued against
including the RM version in the archetype id, because it doesn't
tell us anything about validity. (We had a long discussion about
this on the technical list last year or 2009 I forget which).



Now.. if the RM changes, let's say to 2.0.0, then we might assume
that there are one or two breaking changes, and that a few
archetypes could break. The only way I can see to deal with this is:


  we stick with the rule that minor RM change numbers never
break archetypes (or indeed existing data), i..e 1.0.1 ->
1.0.2 -> 1.0.3 etc is guaranteed safe
  we say that a major RM version change, i.e. 2.x, 3.x etc that
includes breaking changes there has to be a validity test run on
all archetypes. 

  
  
any that don't pass, i.e. are compromised by the change need
  to be marked in some way, maybe a header field with the
  meaning 'valid up to RM release xxx' or so.
such archetypes would themselves then have to be versioned
  (.v1 => .v2)
  

It should be remembered that we can undertake many innovations and
'fixes' that don't break anything on the RM, and therefore don't
require a major release. So openEHR 2.x, 3.x etc are likely to be
extremely rare events.



- thomas






  

  
  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

openEHR artefact namespace identifiers

[Thomas Beale]

On 05/04/2011 19:16, David Moner wrote:
> 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.

It should go in the archetype, that is for sure - but it should be 
understood only as 'the RM version used when this archetype was authored 
/ quality assured etc' - rather than 'the RM version for which this 
archetype is valid'. The reason is easy to understand: for some 
particular archetype, authored at RM 1.0.2 let's say, it may be valid 
for many RM revisions after that, even RM 2.x, and not only that, it 
might be perfectly valid for prior revisions e.g. 1.0, 1.0.1, even 0.95 
- it can depend a lot on what parts of the RM the archetype happens to 
use. This is the reason I argued against including the RM version in the 
archetype id, because it doesn't tell us anything about validity. (We 
had a long discussion about this on the technical list last year or 2009 
I forget which).

Now.. if the RM changes, let's say to 2.0.0, then we might assume that 
there are one or two breaking changes, and that a few archetypes could 
break. The only way I can see to deal with this is:

* we stick with the rule that minor RM change numbers never break
  archetypes (or indeed existing data), i..e 1.0.1 -> 1.0.2 -> 1.0.3
  etc is guaranteed safe
* we say that a major RM version change, i.e. 2.x, 3.x etc that
  includes breaking changes there has to be a validity test run on
  all archetypes.
  o any that don't pass, i.e. are compromised by the change need
to be marked in some way, maybe a header field with the
meaning 'valid up to RM release xxx' or so.
  o such archetypes would themselves then have to be versioned
(.v1 => .v2)

It should be remembered that we can undertake many innovations and 
'fixes' that don't break anything on the RM, and therefore don't require 
a major release. So openEHR 2.x, 3.x etc are likely to be extremely rare 
events.

- thomas


>
> 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 

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<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 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
>
>

openEHR artefact namespace identifiers

[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)
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artefact namespace identifiers

[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 = 

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 --
An HTML attachment was scrubbed...
URL: