openEHR artefact namespace identifiers
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 thomas.beale at oceaninformatics.com: 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 artifact namespace identifiers
Thomas, Your proposed changes to the archetype Identifiers and governance actually aligns with the same management and inferencing requirements as OIDs, the only benefit left is the readability, but even that is becoming hard to do with the additional namespaces and delimiters. In addition, having meaningful IDs and deriving meaning from IDs is counter to what good practice in terminology identifier management. If we choose a GUID (or any other standard UID) for the archetype ID, then I see no reason why the VersionedObjectId scheme cannot be used for managing versions of the archetype as long as it is properly administered. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 8 April 2011 1:11 AM To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers Oids probably are the one kind of id I would not propose for archetypes; the multi-axial id in current use + the proposed namespace id is equivalent to an Oid, just with some more constrained rules on what is on the axes, and readable values. The need for a highly managed id assignment system plus loss of readability and inferencing capability seems like a backward step to me. UUIDs seem a more obvious step. Note that UUIDs don't cope properly with namespaces nor versions, and there are already id systems that assign a UUID to the 'artefact' and a second UUID to the version, so that it can be inferred if two concrete artefact instances are really just versions of the same thing. Note that a UUID is massive overkill for a version id of something! But this just shows that simple assignment of UUIDs or Oids is no panacea - thomas On 06/04/2011 01:41, Heath Frankel wrote: Personally, I would like to propose the use of OIDs for controlled artefacts as it is an ISO standard and already used in health informatics for identifying such knowledge artefacts such as terminologies. I know OIDs are not liked due their length, unreadability and managed allocation, but to me it is a natural fit for this kind of artefact ID. Each publishing organisation can get an OID and manage the items that they produce, this can be done using a content management system automatically as is done by CKM. And to be honest, the new namespaced ID scheme is likely to be longer and requires management, and barely legible once we include the namespace and additional delimiters. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/13a45640/attachment.html
openEHR artifact namespace identifiers
Hello I have been working some time in DCM/archetype metadata. Dublin Core is suitable for that, however, there is an ISO norm (ISO 15699. Health informatics. Clinical knowledge resources. Metadata ) which is an extension of Dublin Core for Health informatics and it's even more suitable. They have even defined 'archetype' as one of the valid document types!. I would be interested in helping on metadata topic. When do we start? ;) 2011/4/8 Erik Sundvall erik.sundvall at liu.se: Hi! While we are discussing metadata and identifiers... Shouldn't the metadata/description part of an archetype/template be based on Dublin Core ( http://en.wikipedia.org/wiki/Dublin_Core ) instead of an openEHR specific approach? That might make librarians, search engines and other existing artifact storage/searc software feel more at home :-) Using Dublin Core does not take away the requirement of having identifiers though, since something has to go into the Dublin Core identifier field. There are several levels of Dublin Core and the ones with good structural requirements on the values may be useful. The idea of using Dublin Core for archetype/template-like-artifacts I got from Tim Cook et.al. in MLHIM. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ ?Tel: +46-13-286733 On Fri, Apr 8, 2011 at 10:57, Thomas Beale thomas.beale at oceaninformatics.com wrote: I will have a play around with some new meta-data additions to archetypes and put them on this list in the next day or so. Let's then think about what is needed in terms of different kinds of 'identifiers', both assigned and generated. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR artifact namespace identifiers
Hi Diego, Very interesting. Is any of the documentation available without paying a small fortune? 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 On 8 April 2011 12:20, Diego Bosc? yampeku at gmail.com wrote: Hello I have been working some time in DCM/archetype metadata. Dublin Core is suitable for that, however, there is an ISO norm (ISO 15699. Health informatics. Clinical knowledge resources. Metadata ) which is an extension of Dublin Core for Health informatics and it's even more suitable. They have even defined 'archetype' as one of the valid document types!. I would be interested in helping on metadata topic. When do we start? ;) 2011/4/8 Erik Sundvall erik.sundvall at liu.se: Hi! While we are discussing metadata and identifiers... Shouldn't the metadata/description part of an archetype/template be based on Dublin Core ( http://en.wikipedia.org/wiki/Dublin_Core ) instead of an openEHR specific approach? That might make librarians, search engines and other existing artifact storage/searc software feel more at home :-) Using Dublin Core does not take away the requirement of having identifiers though, since something has to go into the Dublin Core identifier field. There are several levels of Dublin Core and the ones with good structural requirements on the values may be useful. The idea of using Dublin Core for archetype/template-like-artifacts I got from Tim Cook et.al. in MLHIM. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Fri, Apr 8, 2011 at 10:57, Thomas Beale thomas.beale at oceaninformatics.com wrote: I will have a play around with some new meta-data additions to archetypes and put them on this list in the next day or so. Let's then think about what is needed in terms of different kinds of 'identifiers', both assigned and generated. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/59018744/attachment.html
openEHR artifact namespace identifiers
Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. -- 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 From: heath.frankel at oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: openEHR artifact namespace identifiers Date: Fri, 8 Apr 2011 10:10:09 +0930 Hi Erik, I was suggesting that we enforce OIDs, in fact my intent was similar to yours, to open up the choice of what is used and not enforce the specially designed ID scheme currently used that requires upgrading to support namespacing making it have the same issues as the standard UID schemes. I like the suggestion of URIs, although I also agree with Tom's later comment that within openEHR implementations we should try to limit the options of the URI schemes used. However, ADL and AOM shouldn't be restricted to this same set, to allow other implementation profiles for other reference models to make their own choices. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 6 April 2011 9:04 PM To: For openEHR technical discussions Subject: Re: openEHR artefact namespace identifiers Hi! On Tue, Apr 5, 2011 at 17:51, Ian McNicoll Ian.McNicoll at oceaninformatics.com 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-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/abd75895/attachment.html
openEHR artifact namespace identifiers
On 08/04/2011 14:28, pablo pazos wrote: Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs.* * if you have a look at the Architecture Overview spec http://www.openehr.org/releases/1.0.2/architecture/overview.pdf, this is documented in some detail (more is needed... next release ;-). When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this was almost the only thing he found significant - that we could point to any knowledge model node or data instance node with a proper URI. Of course you can stick an Oid inside a URI, but I am still very unconvinced about Oids. I don't like making things complex when they can be simple. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/d0679b1a/attachment.html
