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 On 14 December 2012 07:49, Bert Verhees <bert.verhees at rosa.nl> wrote: > 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. > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
