# Usage of Blood glucose archetype for self-monitoring **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2012-12-05 15:32 UTC **Views:** 29 **Replies:** 52 **URL:** https://discourse.openehr.org/t/usage-of-blood-glucose-archetype-for-self-monitoring/13831 --- ## Post #1 by @Hans_Demski1 Hello, i am involved in a project that supports diabetics in self\-monitoring their health status by collecting observations of daily living \(http://www.empower-fp7.eu/about/collecting-observations-of-daily-living/). We are currently defining the knowledge models by using the archetype methodology\. I think the archetypes for Body weight, Blood pressure and Medication action can be reused without problems for the purpuse of self\-monitoring by the patient\. As far as Blood glucose is concerned I am not sure if the labtest archetype \(openEHR\-EHR\-OBSERVATION\.lab\_test\-blood\_glucose\.v1\) is appropriate for self\-monitoring as it was defined as a labtest originally\. In contrast to the labtest that is performed on serum of the blood, the patient measures blood glucose by using hand\-held meter using test strips and capillary blood\. Therefore I doubt that the two measurement methods are comparable\. Moreover the whole Protocol section of the existing Blood glucose archetype is dedicated to labtests and not applicable to the self\-measurement\. I would like to hear your opinion if the existing Blood glucose "labtest" archetype should be used for collecting measurements done by the diabetic himself, or if you suggest to introduce a new archetype for Blood glucose self\-measurements\. Thank you for any hints and comments\. Hans Demski Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt \(GmbH\) Ingolstädter Landstr\. 1 85764 Neuherberg www\.helmholtz\-muenchen\.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme\-Bothe Geschäftsführer: Prof\. Dr\. Günther Wess und Dr\. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt\-IdNr: DE 129521671 --- ## Post #2 by @andres_gamboa Hi, I agree with that. Indeed the test aren´t comparable. This creates the necessity of re-defining the concept of Blood glucose. I suggest to create an archetype such " blood glucose monitoring", that includes the different technics for glucose blood measurement , as "serum glucose measurement" mainly known as "Glycemia", Home blood glucose monitoring (with glucometer) and Glycosylated hemoglobine, or something like that. Andres Gamboa M.D, Msc Biomedical Engineering --- ## Post #3 by @system Hi I would be interested in Ian McNicoll's point of view. Personally, I do not find the measurement of blood glucose different for home monitoring as long as it is clear that this is the method. Self or carer entry of data, a device suitable for near patient testing - these could be at a clinic or done by a nurse or doctor. I would use the blood glucose measurement for all measurements of this as I think it is the same thing. Others? Cheers, Sam --- ## Post #4 by @andres_gamboa Hi Again! Well first i would like to say that this kind of discussions are very enriching for me since I can learn so much, from all of you. I´m young and very curios and with lot of things to learn. Don´t want to seem like I´m arrogant. Regarding to EHR there are still lot of issues not resolved yet and one of the main problems resides in the difficulty of consensus in clinical concepts when one is trying to model the medical knowledge. I think that despite the possible controversy about the concepts (clinically speaking), what it is important in my personal opinion (And I would like to add that Im not an expert in the area, just very interested in this matter) is that the concept represented in the archetype must be clear enough to allow an accurate assessment. Since glucometers are biosensors they could have error, that depends of the device used to measure (and there are several) and sometimes they must be calibrated and so forth in order to make this measure more accurate and close to labtest results (gold standard). So comparing its results with labtest results can be misleading. That´s why in a previous email I suggested to treat them as different concepts. Now I suggest that maybe this matter should be discussed by clinicians that work in diabetes and reasearchers, and reviewed by engineers in order to find the most convienent solution, and in some way to standarize the concept. There´s a lot of people dealing with the same issue in diabetes. I think this link could be useful http://care.diabetesjournals.org/content/26/suppl_1/s106.long There you can find the recomendations of the American Diabetes Association for blood glucose monitoring. Lot of regards Andrés --- ## Post #5 by @system There's a spectrum, from lab test done in the lab - sometimes on capillary (neonates!) , through to ward tests managed by the lab, through outpatient tests somewhat administered by the lab, through to outright home testing, maybe somewhat mediated by some commercial lab service in the background (even if just a manufacturer) The important thing is whether the existing archetype allows the correct attribution, and allows the right kind of loinc codes for the method (or something else). Perhaps some judicious redefinitions to excise the "labness"? Grahame --- ## Post #6 by @system Hi all, Hans and I had a discussion about this topic before he posted this and my (and also Heather's) initial feeling was that it would be a shame if we require two different archetypes for one concept. To me, the concept seems to be the same, even if measurement differs and with it the margin of error. I suggest that the margin of error is not suitable as a differentiator of two concepts. If a different margin of error requires different archetypes, the same, at least in principle, would be required for lab tests in different labs with different machines etc (even if maybe the margin is not as wide) or for Blood pressures measured by different methods. That said, it may well be that the lab test archetype needs some changes to accomodate the different methods (in a similar way as we differentiate the method for measuring a BP, e.g. palpation and auscultation in the archetype). (At the very least the use and misuse needs to be clarified). The RM has a "provider" attribute which may already be sufficient to differentiate the two cases. If this problem turns out to be applicable to many other concepts as well, a more generic approach to document details about a lab-test with the ability to link the real concept may be required - maybe terminology can help here or slots. Whatever we do, I think we need to be guided by the "One archetype per concept"-principle! If archetypes need to be changed to be able to very clearly differentiate, search and filter by the one or the other type of measurement that is of course fair enough. Cheers Sebastian --- ## Post #7 by @ian.mcnicoll Hi Hans, Andrés, Very interesting question\. We faced this issue when modelling for a paediatric hospital and after some discussion decided to use the standard lab\_test\-glucose archetype but considered adding a Method element to protocol, to carry 'Test strip \- visual; Test strip \- automated; Laboratory analyser' as internal coded tests\. It is certainly clear that we may need to identify the methodology, and according to the guidance paper that Andres provided, we many also need to specify whether this is a whole\-blood or plasma / plasma\-calibrated measurement\. My own feeling is that we should try to incorporate these within the same archetype\. The general archetyping philosophy is try to try to model the clinical record and not the device or methodology\. @Hans \- I agree that there is a fair bit of lab\-related overhead in protocol but this would just be templated out, so that would not debar use of the archetype for this purpose\. I look forward to hearing other opinions\. I willtry ot get some opinions from clinicians and other lab/diagnostics experts --- ## Post #8 by @system Sorry to break in on a detail, but I think it is important\. I changed the title\. Who is "we"? Is that the same as "they"? I think so\. I don't think that such a restriction does right to the complexity of health care\-organization around the world, different cultures around the world, different business models, different users, different levels of education\. It is also my daily experience, people, companies do not let themselves restrict, they write archetypes whenever they want, and find for interoperability a message\-format, like in the Netherlands, we have well defined HL7 messages\. And this is only the Netherlands and western Europe\. If in such a small piece of Earth, there is already dissatisfaction about, rebellion against, ignoring of this restriction, how will this be if other countries want to use the OpenEHR concept? I think it will not work\. I think OpenEHR then will isolate itself, because that is not what many people want\. And also, regarding to multi\-level modeling, there is no modeling at all, because the community does not allow the users to design\. The leading community \("we"\) wants the users to use their archetypes, not write their own\. What is then the difference with a classical software company where a product and data\-structure is received, and requests for change from the customers, are impossible, or bring up many dollar signs in the eyes of the vendor\. I don't think the customer wants to know how a product is designed, if that is of no consequence for him/her\. Why the customers, if they would agree with this, would ever need an archetype editor is not clear to me\. It is the flexibility, and independence, no vendor\-dictatorship, which are important reasons people in my environment use OpenEHR\. It works different in my environment, where maybe ten different software projects are using an OpenEHR kernel, people get inspired by the archetypes from CKM, the experience of the writers helps them, but they don't let themselves control by the philosophy of restriction behind\. I think, that "we/they" will lose the concept of a single\-managed archetype repository\. The kernel\-concept allow the use of other archetypes and write own archetypes, and that is what people will do\. When "we/they" recognize this, than "we/they" can take measures to guide this process, because if it will not be guided, automatically, "we/they" get out of control\. That would be a pity, wouldn't it? Have a nice day Bert Verhees --- ## Post #9 by @system Hi Bert, Thanks for chipping in and giving me the opportunity to clarify and extend: The one archetype per concept principle applies on different levels for me. We were talking about the "international" openEHR archetypes at present, so what I really mean here is that *within one consistent eco-system* of archetypes there should only be one archetype per concept. This one consistent eco-system can be anything from the "international" space via national and regional initiatives or your own system. E.g. nationally, like Nehta, you may want to enable semantic interoperability between various national solutions. That's great. What is also great is that the knowledge gained by Nehta developing / adapting the international archetypes used as a starting point, can be fed back into the international space. What "we" certainly aim for is that the "international" archetypes are more than a good starting point, namely that they are of such high quality and so comprehensive that you *want* to use them. Initially, you'll need to make some changes for sure, but the more feedback is incorporated into the international archetypes over time, the better they get (I hope) and over time I believe the requirement for changes diminishes. There is no clear-cut top-down or bottom-up approach to get there, it is a rather messy inside-out long-term process based on opportunities that arise. I don't see a way around that. As you say, "we" [whatever "we" means] cannot nor want to restrict you or anybody else developing their own archetypes from scratch. If your eco-system is the system you develop and your business doesn't require you to look beyond your one system, then I would say that you don't need to worry. Take the international archetypes as a starting point (or not), develop whatever you need and be happy with it. By all means even use a completely different modelling philosophy that uses ten different archetypes per concept if that is easier. You say "It is the flexibility, and independence, no vendor-dictatorship, which are important reasons people in my environment use OpenEHR. " Absolutely! But one thing: interoperability is on a different level then in comparison to systems that are based on the same set of archetypes, e.g. for decision support based on it, etc. Regards Sebastian --- ## Post #10 by @system Now, what is needed is a definition for the word "concept". Because there is a lot of difference between a low education approach of some measurement at home and a complex measurement in the hospital, and even inside the hospital there can be differences, measurements done at the bed, measurements done in a lab. Archetypes must reflect the need of datastructure at a detailed level that is needed in a specific situation. So the concept blood-pressure is not fine grained enough, it must, for example, also indicate, blood-pressure measured by a home-user. Or you end up with archetypes full of optional structures: If done at home, skip 80% of the archetype. One of the arguments for Open Source is the Chinese saying: Let thousand flowers bloom. You can only learn from others if you give freedom to others. (Chinese people themselve could learn from their sayings :) And in this perspective, CKM is very good, because a lot of knowledge come together, and the archetypes are very helpful for the people I work with, as examples. I don't write archetypes, but I see a lot of archetypes, and I see people starting to write them for the first time, and I always point to CKM to help them. But there is a problem with the archetype-ID concept. People very fast write ID's with obvious names. I always teach them to add their company-name, or projectname in the conceptname part, so there is some uniqueness in the names, but of course, this is no guarantee. But I don't think we can solve this problem now. I just mention it. Very true, but I don't see that work, only at a local level, where you feed a decision support system with the use of known archetype-paths inside that location. I am afraid, that is the daily reality, and I tend to think that it is unavoidable. But of course, this is only a personal opinion. But if I am right, then it would be good to do something with the Archetype-ID specification, to guarantee better uniqueness. Best regards Bert Verhees --- ## Post #11 by @system Thanks Bert The tension between sharing data and having a simple system do what you want it to do quickly has been a massive headache for the industry. Massive systems are configured wherever they are implemented - large meetings, ongoing discussions and the result is that it does something like that group wanted but may be not for long. The alternative is to do this in a cooperative space and let the clinicians drive that process. The international aspects of the standardisation become clear but are not initially overwhelming. The blood glucose reading is a classic example. We could have a lot of different approaches - but actually we want to compare blood glucose measurements and the method and sample are of minimal concern. They may be of major concern if the reading is abnormal or within a very narrow range (when the method and measurer might be very important). Clinicians may agree that near patient testing and laboratory analysis will come closer together rather than further apart as miniaturisation becomes the norm. I just saw a company providing something that will measure a heap of variables through the skin...not sure on the accuracy but I sense the investment provided means that it is likely to be good. You did raise the issue of archetype IDs which remains an issue. We can control these in CKM instances but not outside, so we will have to be careful about this going forward. I would suggest that we configure the archetype editor to deal with local archetype names using a suitable additional name part. We have talked about this a great deal and the difficulty with specialisation is the main issue. We may move to meaningless IDs (? within SNOMED). There is a proposal to record compliance with multiple archetypes to deal with specialisation. It does need to cater for local specialisation that never gets to the central archetype store. Cheers, Sam --- ## Post #12 by @system > The alternative is to do this in a cooperative space and let the clinicians drive that process\. The international aspects of the standardisation become clear but are not initially overwhelming\. I agree, and just for that reason, it does not look right to me to restrict clinicians to give their own vision on a specific concept, because then they may be forced to use a name which is already in use, and this is, of course, not permitted\. > You did raise the issue of archetype IDs which remains an issue\. We can control these in CKM instances but not outside, so we will have to be careful about this going forward\. I would suggest that we configure the archetype editor to deal with local archetype names using a suitable additional name part\. > > We have talked about this a great deal and the difficulty with specialisation is the main issue\. We may move to meaningless IDs \(? within SNOMED\)\. There is a proposal to record compliance with multiple archetypes to deal with specialisation\. It does need to cater for local specialisation that never gets to the central archetype store\. And also, clinicians have no way to find out if a name is already in use, somewhere on the world, maybe even inside the same hospital\. It is the classical problem of using meaningful identifiers\. It is impossible to guarantee the uniqueness of an archetypeID, and clashes will be inevitable\. The argument of restricted eco\-systems in data\-exchange is a way around, but restrictive\. To avoid unnecessary restriction of information\-exchange is one of the goals of OpenEHR\. To avoid restriction on knowledge exchange should also be one of the goals\. Meaningful archetypeID's are an obstacle in the context of these goals\. A solution would be that in stead of CKM as an archetype\-repository, CKM would be a name\-server for archetypeID's and concepts, and eventually, if people would want their archetype to be published and discuss it, it remains possible\. In that way, clashes are not likely, and the restrictions which come from the current situation are resolved\. This is just a quick idea which probably needs improvement\. Best regards Bert Verhees --- ## Post #13 by @system Bert, Namespacing archetype ids is another possible solution if you want to maintain meaningful archetype ids\. \(This requires some thinking as to when/if a namespace changes when the "controlling" organisation changes \- e\.g\. if you offer to hand over an archetype of yours to the international space \- especially if is in use by yourself\.\) Sebastian --- ## Post #14 by @system > Bert, > > Namespacing archetype ids is another possible solution if you want to maintain meaningful archetype ids\. > \(This requires some thinking as to when/if a namespace changes when the "controlling" organisation changes \- e\.g\. if you offer to hand over an archetype of yours to the international space \- especially if is in use by yourself\.\) As far as I can see, this looks to me a very good solution\. But there must be a controlling organization which registers the names\. Bert --- ## Post #15 by @system And we are back to OIDs? Jussara Rötzsch Md, MSc Director, OpenEHR Foundation Owner, Giant Global Graph ehealth Solutions [](http://www.giantglobalgraph.com.br) --- ## Post #16 by @Koray_Atalag I'd strongly recommend we implement the namespace approach ASAP\. I've recently did some modelling by reusing a mix of Nehta and openEHR archetypes \- and had to manually rename archetypes with same name but slightly different content\. Very confusing and un\-maintainable\. Cheers, \-koray --- ## Post #17 by @system > I'd strongly recommend we implement the namespace approach ASAP\. I think so too, and to get it started, only the archetype\-ID specifications need to be changed, and the ADL\-parsers, perhaps, to be modified\. The next step must be a name\-registration, and the kernel\-specs need to be changed, so that, before accepting an archetype as valid, it checks at the name\-registration if it is registered\. The registration involves good design, f\.e\. it must be able to check if a poster is allowed to use the a specific namespace\. I am glad my concerns are shared and I leave further thinking to the OpenEHR community\. As soon as possible, I will register my namespace rosa\.nl :\-\) Thanks Bert --- ## Post #18 by @Stefan_Sauermann OIDs!!!! Yes!!! We need them!! Please! Greetings from Vienna, --- ## Post #19 by @ian.mcnicoll OIDS are a possibility but I think reverse\_urls are easier to manage and understand for human beings\. Archetypes end up as physical files on people's systems and OID's become nightmare in these circumstances\. So something like org\.openEHR::openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1\.adl Have a look at this presentation for some of the ideas floating about\. I have this a priority to present this formally to the community\. http://www.openehr.org/wiki/download/attachments/38895631/Clinical+Knowledge+Governance.pdf?version=1&modificationDate=1350405129538 Ian --- ## Post #20 by @Stefan_Sauermann 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\. Greetings from Vienna Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #21 by @Tim_Cook2 --- ## Post #22 by @thomas.beale 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 --- ## Post #23 by @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 --- ## Post #24 by @thomas.beale oh no, please not ;-) --- ## Post #25 by @thomas.beale 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 --- ## Post #26 by @thomas.beale 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 --- ## Post #27 by @pablo 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. --- ## Post #28 by @system 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 --- ## Post #29 by @system 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 --- ## Post #30 by @thomas.beale 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 --- ## Post #31 by @thomas.beale 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 --- ## Post #32 by @system 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 --- ## Post #33 by @system you are right Thomas, I confused Oids and Uids\. But my arguments do relate to UIDs, sorry for that\. Bert --- ## Post #34 by @system >> 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 --- ## Post #35 by @thomas.beale 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 --- ## Post #36 by @system 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 --- ## Post #37 by @pablo 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. --- ## Post #38 by @thomas.beale 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 --- ## Post #39 by @thomas.beale 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 --- ## Post #40 by @system 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 --- ## Post #41 by @Stefan_Sauermann Dear Tom: You write OIDS: "I have never seen a convincing argument for their use\." In the case of the Austrian EHR \(www\.elga\.gv\.at\) OIDs are used to enforce authenticy as part of the "forensic" issues\. Everything \(organisations, codelists, guidelines, numbering systems, single patient IDs, really every entity that appears in the Austrian EHR\) is tracable via its OID\. As you correctly say, an online tool is therefore necessary\. In Austria this has gone operative last year and here it is: https://www.gesundheit.gv.at/OID_Frontend/ It has a tree view \(among others\) and enables everybody to trace every entity back to the origin\. The use of OIDs does not dictate that the OID of every entity is actually registered in the central OID server\. The OID server keeps track of the root OIDs\. Organisations put leaves to the tree as needed in many cases\. The agreement in Austria was that full\-scale identification of "everything in the EHR" is indeed a core requirement\. This is satisfied by OIDs in Austria\. Hope this helps, greetings, Stefan --- ## Post #42 by @system Hi\! I think we had interesting ID\-discussions some time ago on the openEHR technical list, the thread was titled "openEHR artifact namespace identifiers", see: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/date.html Regarding choise of OID/GUID/URL etc\. the message\.\.\. http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005947.html \.\.\.mentions how they all are covered by URIs and IRIs some examples were: 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 \(Parts of that thread contained other interesting things like tracking versions of an identified object changed by many organisations using the VersionedObjectId scheme, mentioned by Heath\. But diving into that on the clinical list is probably not the best idea\. Instead we should continue those things in the technical thread\.\) Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 P\.s\. Bert I sometimes find your reasoning a bit hard to follow, so I hope you can help me with the following: \- Would namespacing solve most issues you are worried about, if the namespace was included in the idenitifying "property Archetype\-ID in the Locatable\-class"? \(I think this is the intention of ID\-mechanisms in ADL/AOM 1\.5 is that correct Tom?\) \- Bert are you also saying that some organisations are too big and unorganized to handle ID\-assignments within internal sub\-namespaces \(e\.g\. based on reversed internet sub domains\) so that you are worried about the risk of having ID\-clashes within the same namespace? I guess that could be true, but I doubt that OIDs or UUIDs would be any more fool\-proof in that case\. Stupidity could wreck stuff internally for any organisation \- OID\-rules could be violated by people \- GUID generation algorithms could be faulty \(and even produce ID\-clashes across organisation borders\)\. I guess intra\-organizational archetype repositories will need to curate and quality assure a bit when they put things into their catalogues, and one thing they may need to check is the ID\-assignments made by contributing organisations\. --- ## Post #43 by @system Op 11\-12\-2012 21:59, Erik Sundvall schreef: > Bert I sometimes find your reasoning a bit hard to follow, so I hope > you can help me with the following: Sorry for that, but it is because it is, for me, not all well thought through, while discussing the thoughts come\. > \- Would namespacing solve most issues you are worried about, if the > namespace was included in the idenitifying "property Archetype\-ID in > the Locatable\-class"? \(I think this is the intention of ID\-mechanisms > in ADL/AOM 1\.5 is that correct Tom?\) Using namespaces improves the situation a lot\. The chance of name\-collisions reduces a lot, but not disappear\. This is a serious problem How can you ever find a medication if it is stored in a path that you do not have in your archetype, because it was stored with a slightly different archetype, but the same name? This is what can happen\. A patient is taking a drug, which a health\-care professional cannot know\. Of course, this is only an example\. I am indeed worried about larger and badly organized institutions, like regional health services, which sometimes serve more then 100\.000 people, and have dozens of professionals\. A hobbying GP can create a local disaster by illegally using a name\. But there are more, hospitals with specialist\-kingdoms inside, universities where students come and go, software\-companies working for more customers in different healthcare branches, etc\. I already explained following a few days ago, but I don't blame you if you missed it in my badly structured texts\. I think that there must be a registry, and that archetypes should have unique numeric ID's\. I don't know which numeric structure\. In the specs of the kernel must be added that the kernel checks the ID of an archetype in this registry before using it to store data\. When the idea is not known, the kernel should not use that archetype\. If the kernel does not do that, it is not a good kernel for trusting in a changing ecosystem, its data can never be trusted, only in a very restricted environment\. There must be some way to check if the archetype with a specific ID is the same\. Maybe a checksum on the definition\-part? Or another way? This registry only need to store a few items, so it will not be a large database \(there will not be billions of archetype\-IDs, and even if there were, that still is not much\), costs will be low, maybe even free, run by hospitals or universities or Google or IBM, maybe it can be distributed and mirrored\. There can be internal in hospital mirrors for fast access\. But this is rather technical, I am sure there are people who know how to do this\. The fact that the kernel has then numeric \(unreadable\) ID's has some other implications on the software\-specs\. For example, now the archetypeID is part of AQL\-statements and templates\. This is because they have concepts incorporated in their name\. The new style archetypes will need some new properties, concept must be a property of the archetype, not a part of the ID\. In that way it will still be possible to wildcard or reg\-expr on concepts\. Reference\-Model\-information should be property too\. I have not thought it all through, it are discussion\-contributions, I write\. Thanks for asking Bert Verhees --- ## Post #44 by @thomas.beale I looked back through the thread - maybe I am just not seeing your explanation - but anyway, is it because you think there can be URI clashes? We are only talking about having a controlled id space within a namespace where the latter is based on internet domain - this is a pretty good guarantee that the organisation has been identified. So then it is just a question of managing the multi-axial id within that space, which should be easy (although we don't do it properly today). I'm not clear why you are talking about file names - they are not important in any tools using archetypes, to my knowledge. CKM doesn't use files at all. yes, that's the current spec. As I said elsewhere, there is a proposal (for some years now) to improve this, and to enable the use of the full multi-axial id (generated) and also Uids or Oids or whatever. So I don't think that in the future, there will be any problem. You will of course have difficulty to see what the archetypes are when inspecting data, so that's the downside. see above. But using a concept is also not a problem - it's just an id. The only problem is managing the assignment of ids, which doesn't occur today, but should. We had originally thought of doing this in a Snomed namespace, but now I am less sure that that is the right approach. there may be some confusion here. I am not advocating URLs. A domain name is not the same as a URL. I think we must be talking about different things; what kind of organisation domain names have become non-meaningful? well they won't search in general with the short concept name, they will use keywords and ontology-based search terms which will enable the search. CKM and other tools already do this. So the 'blood_pressure_measurement' string is of limited importance in searching. It's main importance is for enabling direct quick understanding of what an archetype is about in tools and in data, and in education. well actually concept names are part of well-design URLs all the time. That's the whole idea actually of a well designed reliable URL, to be based on a reliable concept, not a system directory or location. For example, the URL is reliable because it has nothing to do with physical location - it's based purely on the concept 'releases/1.0.2', the concept of the 'architecure' part of the specs, and the concept of what the target document is about. - thomas --- ## Post #45 by @system >> Hi 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\. > > I looked back through the thread \- maybe I am just not seeing your explanation \- but anyway, is it because you think there can be URI clashes? We are only talking about having a controlled id space within a namespace where the latter is based on internet domain \- this is a pretty good guarantee that the organisation has been identified\. So then it is just a question of managing the multi\-axial id within that space, which should be easy \(although we don't do it properly today\)\. You make the system depending on the quality of organizations\. I really did explain it several times\. Please read my latest reply to Eric Sundval, Tuesday, it was, I think\. It must be in the archive\. >>> 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\. >> >> 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\) > > I'm not clear why you are talking about file names \- they are not important in any tools using archetypes, to my knowledge\. CKM doesn't use files at all\. Since you and I several times stated that that is not important, you and I should not need to discuss this\. I believe this was a reply to Pablo who wanted descriptive filenames\. I told him he does not need to worry about that\. This will remain possible, also when archetype\-Id's are meaningless\. >> My problem is that the OpenEHR datasets depend on archetypes and they express this dependency by the property Archetype\-ID in the Locatable\-class\. > > yes, that's the current spec\. As I said elsewhere, there is a proposal \(for some years now\) to improve this, and to enable the use of the full multi\-axial id \(generated\) and also Uids or Oids or whatever\. So I don't think that in the future, there will be any problem\. You will of course have difficulty to see what the archetypes are when inspecting data, so that's the downside\. OK, this is the good news I was hoping for\. Do you know why this proposal never is discussed in the mailinglists and why it takes years to implement it in the specs? It is not only OpenEhr that is suffering from this weakness, also En13606 is\. Why isn't this brought under attention while it was under ISO, 2008, or since then? It is a weakness which can make datasets useless, especially in a message\-structure, when data leave their safe eco\-system\. The key feature, semantic interoperability is at risc, because, when receiving a data\-set, how can you be sure if it does refer to the same archetype you have in your house? There is no way, no digital signing, no checksum, no centrally enforced registry, nothing\. Even asking the archetype from the organization which sent the dataset, which is cumbersome, it still is no guarantee\. And that, while there are more solutions possible to resolve this\. I think this is critical\. Don't you? I did a proposal in the same email, I referred to, to Eric, above\. Only an idea to handle this\. You can easily find it in the mailinglists\-archive\. I am sorry that I don't have it at hand at this moment\. But of course there are more ways, and maybe better ways, to solve this\. >> 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\. > > see above\. But using a concept is also not a problem \- it's just an id\. The only problem is managing the assignment of ids, which doesn't occur today, but should\. We had originally thought of doing this in a Snomed namespace, but now I am less sure that that is the right approach\. I think that is conceptually wrong\. A concept is not just an ID\. It is an obvious term to describe something about the archetype, which can be used in AQL or templates, also with wildcards or reg\-expr\. Because it is an obvious term, it can easily happen that people, independent from each other, write different archetypes with the same concept\. If this is in the ID, then you have a problem\. Namespaces give some room, but still no guarantee\. We must do better then this\. It is possible to do better then this\. >>> 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\)\. >> >> 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\) > > there may be some confusion here\. I am not advocating URLs\. A domain name is not the same as a URL\. I know, but namespaces can have the same effect\. It is not a coincidence that often URL's are used to indicate namespaces in XML\. I was using this as a metafore \(is that an English word? I need more time to get used to the single tasking IPad\.\) >> 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\. > > I think we must be talking about different things; what kind of organisation domain names have become non\-meaningful? Thomas, you are replying to an example I gave over a week ago\. I don't have that email here, and I don't recall the exact context\. I remember it was just an example\. Sorry for that\. >> With archetypes the same will happen\. People are going to search for archetypes, conceptnames will become a very important search argument\. > > well they won't search in general with the short concept name, they will use keywords and ontology\-based search terms which will enable the search\. CKM and other tools already do this\. So the 'blood\_pressure\_measurement' string is of limited importance in searching\. It's main importance is for enabling direct quick understanding of what an archetype is about in tools and in data, and in education\. Possible, I don't know what other people do, I searched often for concepts\. But if concepts are unimportant, it would be better to skip them\. Never let unimportant information get in your way\. >> 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\. > > well actually concept names are part of well\-design URLs all the time\. That's the whole idea actually of a well designed reliable URL, to be based on a reliable concept, not a system directory or location\. Very many urls are meaningless\. See Youtube for example\. Google has no problem with that\. Bert\. --- ## Post #46 by @system Let me summarize my emails from last weeks\. In my opinion there are more choices to proceed: 1\- The currently situation which has no namespace and no unique archetypeIds\. You can never trust an archetypeID\. You always need to validate a dataset, and if it does not validate against the archetype with that Id in your system, the received dataset is useless\. No interoperability\. For a message\-standard this is fatal\. There is quite some urgency to repair this\. Which brings us to the following solutions, maybe there are more solutions, but these come to my mind\. 2\- Working with namespaces which brings the responsibily of the system being well maintained and trustworthy to the namespace\-owner\. 3\- Making it safe by design, so that even bad namespace\-owners cannot break the system\. To do this, you need a central registry outside the eco\-system, and some way of digitally signing\. Solution 2 can also work with digitally signing, which makes their archetypes also trustworthy but without a central registration, there can be a problem\. You will need the digitally signature to be in the dataset, to compare it with the signature of the archetype which is in your system\. What do you do when it does not fit? Throw away the dataset and start a discussion with the organization which sent it? And as long as this discussion is not finish, hold up communications with that organization? This brings us to situation 3, which handels all occuring situations best\. Regards Bert Verhees\. --- ## Post #47 by @thomas.beale Erik thanks for this, let's keep it in mind\. I am going to republish the id proposal as a wiki page, and others can then mess around with it directly, and fix / replace the original ideas with better ones\. I'll try to get this done in a few days\. I'll put some of the below in, because it is obviously sensible\. The second point of your p\.s\. was what I was also trying to say\. I think in the end Bert was criticising the current state of the specification, not what it obviously has to move to\. Anyway, let's move the debate on to a live copy of a spec for this stuff, and fix it\. Then we will have a solid proposal for the formal process\. \- thomas [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #48 by @system For my concerns, I completely agree with this initiative. Thanks Bert --- ## Post #49 by @ian.mcnicoll Hi Bert, Nice summary\. I think we are all agreed on your first point, and that this now needs urgent attention\. I have been speaking to THomas about how to add some sort of namespacing and more detailed versioning metadata to ADL 1\.4 archetypes to let us address some of these type of issues in the openEHR CKM in advance of the formal ADL1\.5 specifications\. I think some form of namespacing whether uri, oid or SNOMED type identifier is essential\. Ultimately whichever of these is adopted, the owner of the namespace is responsible for preventing identifier clashes within their namespace\. It will always be possible for people to subvert the system by accident or design unless we add\-in digital signing but that introduces its own burden of compliance, particularly in the authoring space where archetype creation and development needs to be very agile\. Option 3 clearly has merits but I am anxious that trying to enforce a top\-down registry for every potential developer will be hard and complex to maintain\. One idea I have toyed with is the concept of an openEHR Knowledge Federation, Basically a very light touch registry of 'official' openEHR namespaces and maintained list of URLs to the actual repositories concerned\. Essentially a sort of DNS\. This would need a little bit of funding and governance\. It would need clear rules of engagement and perhaps digital singing might be a requirement for Federation membership\. However I would not make Federation membership compulsory\. If people just want to tinker in the space they should be able to develop non\-namespaced archetypes\. In summary, I think option 3 is the gold\-standard' and that we should probably aim for some sort of central namespace registry but I think it needs to be light touch, easily governable and not mandatory\. It is up to consumers to decide if they trust non\-Federation namespaced archetypes\. Ian --- ## Post #50 by @ian.mcnicoll I have just re\-read Erik's PS in his email and I think we are basically in agreement\. I would prefer a to see a system where each namespace is essentially self\-governing with respect to unique identification and versioning \(which is an even bigger problem\)\. If they want to play in the wider community "The openEHR Knowledge Federation" they have to abide by a stricter set of rules, and of course, can be kicked out if they do not manage their identification and versioning governance safely\. We need to make this safe but we also need to keep it light\-touch and agile and avoid a cumbersome top\-down mechanism Ian --- ## Post #51 by @system Hi Ian, I agree with the light\-touch approach, I was also thinking about it\. I have some thoughts for a solution: Because a dataset has an archetypeID to indicate to which archetype\-content it must be able to validate\. The archetype\-content should be digitally signed, this makes it safe to exchange datasets, because both parties can be sure they are using the same archetype content and not only the same archetypeID\. This digitally signature should be a property of every dataset which is exchanged, so it should be a required property of the Locatable\-class \(if the archetypeID in this class is used\)\. The validation\-routines must be able to calculate the signature, so the parser\-routines also needs modification\. I don't know \(cannot oversee\) if this must be part of the ADL\-grammar\. The digitally signature should be added with the the archetype content itself, but it should not be a part of it\. I think this is the easiest way to maintain the digital signatures\. Than a central registry may not be necessary, because parties are able to check their archetypes against the digital signature, and see if the archetype has been changed since it is in possession of that party\. Solved will be that when an error occurs, it will be able to proof who is responsible for using this erroneous situation\. Possible it is enough to sign the definition\-character\-contents, excluding comments, trailing/leading spaces and new\-lines\. To do so, there will be only one end of line, that is after the closing curly brace of the definition\. I don't know if the ontology section should be signed with the definition\-section\. Maybe it should be signed separately for each language\. To make it easy for developers, they could during the developing process work with dummy\-signatures, which need to be defined\. The production\-kernel, however, should never allow dummy signatures in datasets\. It this is done, we can allow any archetypeID\-structure, because it is not the archetypeID internally which should be leading, but the archetype\-content\. As Thomas wrote yesterday, the concept is not important, we must discuss if it still should be inside the archetype\. But other things must sure be a part of the archetype \(but not the archetype ID, that is up to the designer\)\. These are the Reference Model \(and version\), and keywords\. If we agree on the concept is important also, this should be a property of the archetype, but this needs discussion\. I always used the concept to have a quick impression about what the archetype is about, but maybe I must change this habit\. I don't think that the RM\-class is needed in the archetype properties, because, that is where the definition starts with\. --- ## Post #52 by @thomas.beale > > You make the system depending on the quality of organizations\. I really did explain it several times\. Please read my latest reply to Eric Sundval, Tuesday, it was, I think\. It must be in the archive\. I think there is no other alternative, at least for now\. > My problem is that the OpenEHR datasets depend on archetypes and they express this dependency by the property Archetype\-ID in the Locatable\-class\. >> yes, that's the current spec\. As I said elsewhere, there is a proposal \(for some years now\) to improve this, and to enable the use of the full multi\-axial id \(generated\) and also Uids or Oids or whatever\. So I don't think that in the future, there will be any problem\. You will of course have difficulty to see what the archetypes are when inspecting data, so that's the downside\. > > OK, this is the good news I was hoping for\. > > Do you know why this proposal never is discussed in the mailinglists and why it takes years to implement it in the specs? well I think it has taken time for vendors \(including you, and others\!\) to get implementations together and working, to get a better feel for what the right approach is\. I could generate a theoretical proposal \(well, in fact I did ;\-\) but I am happy that we never implemented it directly; the last 3 years' experience across real implementations has generated knowledge about how to proceed properly\. Now I think a proposal that we all put together will really work \- we can do this work pretty quickly\. > It is not only OpenEhr that is suffering from this weakness, also En13606 is\. Why isn't this brought under attention while it was under ISO, 2008, or since then? well ISO just isn't connected to implementers in any meaningful way\. That's an argument for another day, but essentially the whole model of how standards are done in ISO needs to change, at least IT standards\. Stephen Kay has ideas on this\. I think the best we can do with respect to ISO today is to provide quality proposals from openEHR for the revision of 13606 \- stuff that works, like a better EHR Extract etc\. > It is a weakness which can make datasets useless, especially in a message\-structure, when data leave their safe eco\-system\. I wouldn't say 'useless', but you are right \- there are risks that should not be there\. So just like all the official standards, then ;\-\) We need to do better of course, and starting in 2013, we can start work on the specs again, and it really will require the implementers to step in and contribute ideas\. > The key feature, semantic interoperability is at risc, because, when receiving a data\-set, how can you be sure if it does refer to the same archetype you have in your house? There is no way, no digital signing, no checksum, no centrally enforced registry, nothing\. > Even asking the archetype from the organization which sent the dataset, which is cumbersome, it still is no guarantee\. various implementers have already hit this problem and solved it in local ways \- which is a bad outcome\. We need to rectify that\. We are nearly set up for doing more work on the specs and software \- it's taking time to do some practical things \- new website, move everything to Github, and define new governance\. I share the frustration, but we are getting there\. > And that, while there are more solutions possible to resolve this\. > > I think this is critical\. Don't you? > > I did a proposal in the same email, I referred to, to Eric, above\. Only an idea to handle this\. You can easily find it in the mailinglists\-archive\. I am sorry that I don't have it at hand at this moment\. > > But of course there are more ways, and maybe better ways, to solve this\. just make sure you are ready to contribute these idea when we start working on the proposals\! \- thomas --- ## Post #53 by @system I guess, this will be announced, when the time comes Bert --- **Canonical:** https://discourse.openehr.org/t/usage-of-blood-glucose-archetype-for-self-monitoring/13831 **Original content:** https://discourse.openehr.org/t/usage-of-blood-glucose-archetype-for-self-monitoring/13831