Re: Archetype publication question - implications for implementers

Hi All Taking this part of the change, I do not see any reason not to add a unit (really symbol change only) and mark the old one as deprecated. The data is unchanged and there is no risk to processing whatsoever. The location change is a little more complicated and seems to be due to moving

RE: Archetype publication question - implications for implementers

I'm curious of how this obsolete flag would be supported in a implementation agnostic view. How it is different of having several implementation guides for different MU levels, an epSOS implementation guide (which changed the CDA reference model itself), or even better, FHIR resources with same id

RE: Archetype publication question - implications for implementers

Hi Heather, Although I agree with the idea of obsolete concepts, I wonder if it is necessary in this case of Tilt. Why can’t we just add the additional units as allowed options leaving the existing degrees symbol but in the element description indicate that this is obsolete and the correct units

RE: Archetype publication question - implications for implementers

Hi All, It has been an interesting conversation. Many thanks for everyone’s input. However, I think we do have a reasonable potential solution. It was Sebastian’s suggestion about governing at an intra-archetype level that has caught my attention - marking an existing data element as outdated,

RE: Archetype publication question - implications for implementers

Hi Ian, I should probably clarify that the versioning mechanism in SNOMED CT is more than a technical thing. The versioning mechanism also includes guidelines about how to handle the changes in the receiving system. However, the guidelines are distributes in a form that is machine (and human) r

Re: Archetype publication question - implications for implementers

Hi Vebjørn, I hope I did not give the impression that I was in any way suggesting that the Norwegian clinical reviewers were being obscure or unreasonable and causing problems, or that tilt is not used in some applications. The review team have done exactly what we ask of them - to point out issue

SV: Archetype publication question - implications for implementers

Hi all, As long as someone in the world performs medical research, our knowledge about medicine will increase and change. This imply that changes in our information models and ontologies due to new knowledge (and pervious errors) are something constant and something every implementer needs to p

SV: Archetype publication question - implications for implementers

Hi I've not been involved in the revision of the Norwegian Blood pressure archetype, so I do not posess any ownership of the changes proposed. They can be looked upon as minor, but still they have arised after a review. I know personally several of the reviewers, and can assure they are very co

Re: Archetype publication question - implications for implementers

Dear all, I agree with Ian that any change at international level should be market driven. From an experience of someone who works with standardization for years and who already led the adoption of standards in Brazil's extensive market, it is worth remembering that standards must reflect a con

Re: Archetype publication question - implications for implementers

Hi all, This is IMO, a very important issue for the openEHR community and many thanks to Heather for providing such a clear exposition of the issues and choices, faced by any community building products and tools based on open-source distribution and governance principles. As such, I do not think