I would not see that as a reason to make them different concepts - it’s the same data structurally and terminolologically, but via different devices. The DV_QUANTITY data types take care of accuracy in a detailed way, and it would be easy to determine if runtime blood glucose data samples came from a device with e.g. a +/- 5% error, as well as lab devices with much higher accuracy. It is also easy to discount or include recordings by comparisons with the device types. It would be the same archetype, but querying could remove less accurate measurements. In any case there are normal numerical methods for combining measurements of different accuracy. What might be interesting is if the device archetypes included some kind of ‘accuracy category’ or similar, so you could query across all data, looking for data of only ‘lab accuracy’ and ignoring ‘consumer device accuracy’ observations. - thomas beale
Hi Bert,
noone is forced to use any particular archetypes - it's always an open choice. If everyone goes their own way, the result will be local siloes of semantically computable data (which is an improvement over the current computability level), but essentially non-interoperable data outside each area of use.
I think organisations will take into account the costs and benefits of non-interoperability, and make choices they way. Wide-ranging interoperability may only make sense for a small number of core types of data. We'll see how that pans out over time.
The openEHR.org repository is not dictating anything to anyone, it's just providing a set of self-consistent archetypes that should be useful. Most of those archetypes will be from national programmes over time. Anyone can take part in the modelling. It seems to me to be a pretty free ecosystem.
Also, when ADL 1.5 is deployed more widely, there will be more possibilities for mix and match modelling, due to better differential archetype and template representation.
- thomas
oh no, please not 
The current design assumes that the namespace will be the reverse internet domain name of the organisation. That means that the 'registrar' of those ids is already taken care of in the DNS domain registration system. The reverse order is a common approach to ensure correct sorting and also sensible directory creation for some programming languages that use this method to create package directories.
So far I don't know of any reason not to do this.
- thomas
Hi Stefan,
We can support them, but Uids and domain names are far more usable. Oids can't be read by humans, and require online tools for resolution. I have never seen a convincing argument for their use. if you want to identify an organisation, there is a domain name, that's pretty much guaranteed these days, and all the rules are known. The ids are computable and human readable. Perfect.
If you want to identify an artefact or concept, Uids or some shorter code like Snomed ids work fine Uids can be generated and require no central infrastructure.
Obviously we would not prevent people putting Oids that they obtain into sensible places in openEHR (Oids are of course part of the id package), but I still really struggle to see their actual value. I certainly would not want to make any part of openEHR actually dependent upon them.
- thomas
Hi all, I just one to share a view on the subject.
This discussion remembers me of the terminology problem: there’s a lot of discussion of how we name a thing, but not all names work for every use, so we’ll end up with many names for the same thing, and that’s my idea. The problem is not THE name, the problem is how to define an identification process that can be implemented on tools that take two artifacts named differently and know that both represent the same concept.
My experience is:
For a development environment: I NEED archetypes on my file system with names that I can understand, I can give several reasons for that but I’m sure everyone understands this requirement.
For a shared environment like the CKM: I think human names and OID/URI/… should be supported. This is in the middle of a development environment and a production one. To support id X-referencing, both naming schemes should appear in the archetype header, but the name of the ADL file could be one or the other. In fact, I hope we can support I18N for the name too, so “openEHR-EHR-OBSERVATION.blood_pressure.v1” and “openEHR-EHR-OBSERVATION.presion_arterial.v1” can be identified as the same concept, but I can work with the latter at spanish-speaker environments. Obviously, archertype search and loading should be based not only on ADL file names, but on the content of the header, in fact software should support archetype indexes to do search and loading, and not rely ONLY on filesystem operations which is a not-so-reliable approach at big/serious systems.
For an implementation environment: OID/URI/… should be the main identification/naming standard because archetypes will be used by systems not by people. And if people shoud access archertypes in these kind of environment, the access will be using some kind of tool, not directly.
Hi Thomas, my problem is that archetypeID-clashes will occur if archetypes with the same ID's but different from content exist. This is because the Locatable is connected with an archetypeID according to the specs, and which is easy to lose its uniqueness, because it has obvious terms.
The problem is in my opinion, and recognized by others, that this is restrictive.
This problem is easy to resolve by giving them unique ID's.
If the same archetypeID's are easy possible, than this will be restrictive, because if an archetype is inside the eco-system, it is difficult to write another archetype on the same concept.
It even can happen in a large eco-system (like a regional health-eco-system which is in the Netherlands very common) that someone writes an archetype, with an already existing ID. So the current situation is restrictive and worse, it can easily come to erroneous situations.
It is also very hard to extend an ecosystem because, there can be more archetypes active in the extension-area, which have the same ID.
So this is restrictive too. I believe this is a similar situation as Koray Atalag experienced.
The concept and other content-parameters can be properties of an archetype, it is not necessary to put them in the archetypeID.
Compare with the WWW, every URL (ID) is unique, but title, keywords, other parameters are properties of the document, which have nothing to do with the URL (ID) of the document. This URL (ID) is nowadays more and more a meaningless database-entity, sometimes even build from different parts, all also with meaningless URL's (ID's).
So on the WWW it is possible to have more documents with the same concept, and still clashes are not possible. As long as you know the URL (ID) you can find your document.
Google, the largest database in the world, works this way.
Some time ago, I had a thread on this list, (or the technical list) about the filename which is the same as the archetypeID. You said, that this is not necessary, the filename can be anything. The ID is what is inside the archetype.
This is already an improvement (although I don't know one archetype-editor which supports another filename then the ID).
The next improvement should be that a Locatable should be able to point to an unique ID, and that ID, cannot be according to the specs of the archetypeID, which says that the concept and other things should be part of the ID and causes obvious terms to be used.
Regarding to interoperability, I think querying will never be possible in a same way. That is an utopia. (The better is the enemy of the good (is a Dutch saying))
Having content fixed to the archetypeID, because of interoperability is about the same as forcing products to have the same database-structure. Then you can exchange SQL (instead of AQL).
I don't think that is wise to aim that goal, because it will never happen.
And on the other hand, if you have all archetypes with a unique ID, you can safely inter-operate, because, then you are sure, it is the same archetype to which the Locatable points.
Better is, (if you are not sure that archetypeID's are uniquely pointing to the same content) to follow a way of message-definitions, and every systembuilder will have to take care that he is able to conform to the definitions.
We do that all the time, and we are able to communicate with all kind of systems.
Also regarding to decision support, partners are developing special HL7 messages to feed a HL7 decision support system, the name of that I forgot.
It will never get better than this, in my opinion, only if you aim for rigorous restrictions.
best regards
Bert
Hi Pablo,
The filename you store your archetype in, that can be anything, that is your decision.
The Locatable does not point to the filename, but to the ID.
A possible solution would be to have an extension on your workstation-filesystem which reads the archetype-properties together with the filenames.
That kind of extensions are in Windows available for images (displaying parts of the EXIF information, and even previews). Many professional gr
Also there are extensions for CVS, SVN and GIT, to show the status of a file. I think this kind of extensions are also possible for Apple and Linux.
You can even make money with writing such an extension (plugin).
Also external applications, for example the ADL-workbench-alike could help.
But I see that you recognize the problem, and I see you favor for the IOD-solution. I have read from others which favor for namespaces combined with the obvious concepts. I don't see the one fighting the other, they can coexist.
The first thought is that because the ID should be meaningless, and if people put meaning in it in a safe way, there should be no problem.
But I think the namespace solution is dangerous, because in large organizations, like universities, people can write archetypes inside the same namespace and clashes are still possible.
In my perception, the OID-solution would be the best, because that is the only way you really can be sure that every ID is unique. This is also worldwide recognized. And concepts, RM-name, that kind of things should be properties.
regards
Bert
that’s actually easy to do - you rename things in a template. In an ADL 1.5 template, it uses the same mechanism as the at-codes in archetypes, so you get full translation etc. I see no reason not to do this - it just requires ‘blood_pressure’ to be treated as a concept id whose full definition is ‘systemic arterial blood pressure measurement’, and which has synonyms like ‘presion_arterial’, ‘pression_arterial’, etc. - thomas
UIDs are good for identifying an artefact, no matter what other characteristics (including name, purpose etc) may change - so they are good for tracking in lifecycle and version management. Although, they don't track versions themselves - you need a multi-part id for that, which typically involves a UID and a version tree id.
UIDs are a lot easier to manage than Oids - globally unique but not requiring any central authority or infrastructure.
- thomas
the reason, I already explained, is that it still is restrictive, but less then now.
In large organizations like regional healthcare ICT eco-systems or universities people cannot use obvious names for their concepts because the concept is part of the archetypeId
That is a restriction.
It is also dangerous because organizations may not have (they do not have currently) an archetypeId registration, so double Id's, clashes can occur and put the safety of patients on risc.
Bert
you are right Thomas, I confused Oids and Uids. But my arguments do relate to UIDs, sorry for that.
Bert
Dear Ian,
OIDs are a requirement in some legislations, including the Austrian EHR space.
Can you please explain why they "become a nightmare"? I am sure they can, but I would like to hear your exact view.I understand the OID is not the only "name" of the archetype, just one of the unique means of identification. On top of that you can of course keep any naming / file / structuring / keywording / etc measures in place as you need them, so that you can find your way on the PC and elsewhere.
Hi Stefan,
We can support them, but Uids and domain names are far more usable. Oids can't be read by humans, and require online tools for resolution. I have never seen a convincing argument for their use. if you want to identify an organisation, there is a domain name, that's pretty much guaranteed these days, and all the rules are known. The ids are computable and human readable. Perfect.
They don't need to be read, it are the proporties which are read and give meaning.
Your passport number is not readable to but serves unique identification.
I understand that you find my arguments not convincible, but I haven't read why. Maybe that is still to come.
I give you a short reason, name-clashes are unevitable because of the use of obvious terms.
This can make a dataset unusable because you cannot be sure against which archetype it is validated.
In another email, I explained this with examples.
If you want to identify an artefact or concept, Uids or some shorter code like Snomed ids work fine Uids can be generated and require no central infrastructure.
Obviously we would not prevent people putting Oids that they obtain into sensible places in openEHR (Oids are of course part of the id package), but I still really struggle to see their actual value. I certainly would not want to make any part of openEHR actually dependent upon them.
Why don't you want that?
In every informatic-study you will be teached not to use meaningful IDs.
Why do archetypeIds differ from that?
It is not the Id that should give the archetype purpose, but the concept does. So, why mix to things which have different purpose.
I have not read a convincible argument why archetypeIds should be humanity readable.
Thanks
Bert
which is what we expect to do with namespacing, based on reverse internet domains. Using reverse internet domain names means we don’t have to invent a system for assigning the namespace ids, all we need to do is solve the technical problem of including namespace ids in the overall id. In the future, we should have ‘identifying properties’ that make up the multiaxial id, i.e. instead of the string openEHR-EHR-OBSERVATION.bp_measurement.v1 being a single property in the AOM ARCHETYPE class, it would be broken into pieces, and then this kind of id can be generated functionally. Other variants, including with the full version id can also be generated e.g. openEHR-EHR-OBSERVATION.bp_measurement.v1.3.16 (and in the future both of these will have namespaces). The only true ‘id’ field in that case will be the UID field. I think in the ADL representation of an archetype we would still use the multi-axial id at the top, because it is very convenient, but in XML and dADL, JSON, etc it would appear in pieces. And of course in AOM. Then it is just a question of tools using the different kind of ids - either the generated form, or the UID - to manage the archetypes. For example, CKM should use UIDs to track archetypes so that even the RM class could be changed (maybe someone decided it should be an ACTION instead of an OBSERVATION). And so on. We are not there yet, but those are the proposals I would have, and I have based most of the thinking on what others have said about improving the way the ids work (for example, the UPV guys have been asking for a long time to make the multi-part ids generated, and they are right, we are just slow in making it happen But I will get out a new version of the ADL 1.5 draft that includes these changes. Anyone is welcome to come up with a better idea in terms of namespacing of course - we just want something that works well. The only thing I see as really difficult to justify is getting embroiled in Oids. If we think Oids that are managed by other orgs need to be attached to openEHR artefacts, no problem, but we don’t want to make it so that tools like CKM (or any equivalent) rely on Oids to work - that will just paralyse them. assuming we have namespacing, I don’t think it is restrictive, it is just a problem that the assignment of new ids, and the ability to search existing ids is not yet an online service. I would propose that it is a simple separate service that just performs those functions, and needs to exist for each domain (i.e. archetype namespace, e.g. nl.nictiz or whatever). yep, see above that’s correct - I don’t know of any tool that makes any assumptions about file names or directories for some years now. The AWB for example fast-parses the archetypes no matter where they are or what they are called and figures out the ids and inheritance structure. I don’t believe any other tools make any assumptions about filename or directory. I think you will find that although the editor tools by default save the archetype in a file that is the same as its multi-axial id, this is not needed. You should be able to create a file called ‘blue_cheese.adl’ and the AE will read and save to that. some of this is already in the last two proposal docs (note these are not all up to date, so ignore the bits that are obviously wrong). But I don’t think meaningful multi-axial ids are a problem- like I said before, an id is just a string of characters. If it is made into a mnemonic, it is 100x more useful to software developers. It is only in perfect systems that the underlying nature of ids doesn’t matter. actually it’s already happening in production in at least 3 countries. We don’t make any assumption at all about the physical structure of the DB, about SQL converted form of AQL, or even that the converted form of AQL will include SQL at all - in some modern databases, SQL is gone. Physical database structures are way of strangling interoperability actually, because you need total freedom to choose what you want and also change it, to manage local requirements of scalability and performance. Delinking this from AQL is absolutely fundamental to success, and particular, of enabling a decision support industry to flourish. As i say, this is already routine today, so if you are having problems with AQL, we should discuss it - they have already been solved in other implementations. Ithink this is a different problem. I would expect to support the use of both UIDs and/or multi-axial ids in data, depending on the scope of sharing and so on. Converting between multi-axial and UID form will be easy in the future. In some systems, it might be the case that only UIDs are used, but that implies that noone ever needs to look at the data itself, or at EHR Extracts, or to visualise data at some debugging level. I have never seen any system like that ever. So in summary, I believe that what is needed is a service for helpinng to assign, check, compare ids etc, as well as namespacing, and UIDs, and interconvertability between these. - thomas
Using namespaces is a better idea then the current situation, I agree with that, but it is not the perfect solution, as I explained several times why. That is not my problem. You can put as much properties as you think is useful in an archetype. You can name the filename as you want (we, in our ecosystem, don’t use files to store archetypes) My problem is that the OpenEHR datasets depend on archetypes and they express this dependency by the property Archetype-ID in the Locatable-class. If errors (like clashes) occur in this relationship, even if there is no error but you have reasons to doubt, the datasets become unusable. The part I want to change is: to have in the specs to give the Locatable a unique relationship to its connected archetype, and resolving this by a UID (UUID, GUID, whatever) to identify the archetype seems evident. In XML the namespaces are in URL’s, they do not need to have a concept in this URL. It becomes less restrictive that is true, because there are more authorities, you can always find an authority which does not deny you a specific concept-name. Because, you can go to another which allows you that conceptname, or even organize your own namespace. And in that way the ID’s (in spite of being meaningful) can still remain unique, worldwide. But it is cumbersome. But as I said, it is better then the current. That is how the worldwide web started, I remember you could buy books with URL’s in it, like a phonebook. And people (also I) were busy typing URL’s from that book. I still have such a book as curiosity: The Internet Yellow Pages (Google in hardcopy) But now, nobody ever remember URL’s or reads them. It is all done by machines, and the URL’s often aren’t anymore readable. Even domainnames could not prevent them from becoming unreadable. With archetypes the same will happen. People are going to search for archetypes, conceptnames will become a very important search argument. Because this is, you should never allow a technical reason (like there is now) to deny conceptnames to people. Like in the worldwide web, the concept should not be in the URL, but somewhere else. You are right, files are only a form of transport for archetypes. I remember (but I never use archetype-editors anymore) that most of them connected the ID with the filename. Now you come to this, a generic reference-model for cheese would be nice. I am happy to read that there are many perfect systems in the world. For example, GUIDs in the Windows-registry are considered unique. GUIDs/UUIDs are used a lot as identifier, because they are “guaranteed” unique. In the systems I write, I use them a lot. Collisions are very unlikely. The chance of having two archetypes with the same UUID is smaller then the chance of finding human-like live somewhere in the galaxy. System-builders sometimes don’t want to use UUID’s because they want to put information in ID’s. Reason can be obscurity (hidden information). Another reason to put information in ID’s is to make them humanly readable. Like a car license-plate or flight-number, it is designed to be humanly readable. For example, the company-name is represented in the flight-number. But if everything else about that flight or car, which is machine-processable is in GUID/UUID or barcode or serial number, even the representation ID is connected to a GUID/UUID, serial number or barcode (which always is the case in larger systems), no-one cares. And as with archetypes, they are meant to be machine-processable, to give meaning to datasets and need for that a unique identifier which connects the dataset, without error or doubt to that archetype, as a license plate needs to be connected to a car. It was just an example to explain that having a rigid concept-with-archetypeID-connection from interoperabilty-point-of-view is the same as demanding from vendors to use a specific dataset-definition, where now, only is demanded that they need to interact conform to message-definitions. I am not sure what you mean to say, but if you mean to say, that decision support should rely on a specific message/dataset-definition, instead of relying on specific internal datastructures, then I agree. In the HL7-eco-system they favor this situation to as they express in their (nomen est omen) Virtual Medical Record-definition. It is not hard to write support for this because it is created with the thought of fitting on many-systems-situations. The problem with AQL is connected to the problem with the archetype-ID, and the fact that you cannot trust that if a dataset has a specific archetypeID, that the same archetype is meant as you have in your possession. Especially when there are only small changes this is dangerous, because the error can come unnoticed. OK, my question will then be, the only question which is important: Where to, do you connect the definition of a dataset (archetypeID in a Locatable)? To some humanly readable ID, or to a considered unique ID? Thanks again for your time. As said, I think I have made my point very clear and to avoid that I become a personal factor in this discussion I will leave the activities on this to others for some time. best regards Bert
Hi Thomas, in my first paragraph I was refering to the archetype name containing the archetypeID and how the name of the ADL file and the current archetypID should not be depending on the concept, e.g. supporting L10N on the concept name axis of the multi axial archetypeID (blood_pressure, presion_arterial, …) and this to be supported by tools.
The process I mention is an algorithm that could be implemented on tools that allows to detect that 2 archetypes represent the same concept independentyle of the multi axial id, maybe assigning another unique ID that is neutral to the concept e.g. OID/UID/URI/…
Sorry if I was not clear about this 
Kind regards,
Pablo.
well one idea we had in the past was that a Snomed code in an openEHR extension would be bound to the at0000 code of every archetype. Then the concept part of the name could be derived from that, in every local language. I don’t know if we need to go that far. I think a separately managed archetype ontology might be simpler, The main value of the multi-axial id is that it can be used in data. It doesn’t have to be used in data. A UID-based id can be used in data. sure - that’s a given - we just have not done it yet. - thomas
Bert,
I think you are over-stating the problem. When we formalise an ADL 1.5 definition of identifiers, which includes UIDs, it will be possible for any archetype developer to self-assign a UID, and guarantee no collisions. The concept id within the multi-axial id will need controlled assignment within the domain, but that's just the same as for Snomed codes and Oids. So I can't see how it is any more restrictive than any other identification system in use today. The concept id part of the multi-axial id is only problematic when it is completely uncontrolled and when there is no domain system - which is today's situation. We should see this as about to change...
Anyway, I'll post a new draft of the identification proposal on the wiki (i.e. as a wiki page) and everyone can play with it.
- thomas
Hi Thomas, in my posts I am referring to the current Reference Model which defines what an Archetype-ID is, and how a Locatable (dataset) refers to which archetype it is validated/defined, namely by the Archetype-ID as defined in the same Reference Model.
If you say that this dependency will change when ADL 1.5 will be introduced, then the problem is probably solved.
I understand in that case that the introduction of ADL 1.5 will bring a change in the Reference Model with it.
Please correct me if I misunderstand.
thanks
Bert