Extending the Term Mapping Purpose set

Yes, thx I can see now that these are documented as an invariant. However, I’m not sure these are all being ‘correctly’ observed by different CDRs.

All of the suggestions I have made relax the invariant rules and we could just remove those invariant rules but I would like to introduce HL7 type binding strengths, and although it is messier to document, I think properly these are documented against the original attributes not against the terminology, as there are places where a single codeset is used in more than one place, and there is at least a possibility that the bindings might doffer for those attributes.

Our assumption that is required came from the invariant defined for the TERM_MAPPING class

Not sure if is documented, but as a programmer/implementer for me is ‘assumed’. I guess others are also see it the same way, hence they try to extend the terminology xml with new codes…

Just for my information is the ‘required’ status for the existing term-bindings actually documented anywhere or was it just assumed?

The discussion about binding strength is good and relevant, but I see it as a different topic/issue. Perhaps is better that focus on “fixing” the codes now as they are now ‘required’, having in mind that they might become ‘preferred’ in the near future

I suggest we add ‘interoperability’, and ‘other’ or similar for generic fallbacks. Then to complete the list I would consider also ‘automated data mining', 'billing' and 'legacy conversion’ as they are all mentioned in the RM specs for quite a while now.

About the code number, please don’t use or don’t rely on 672, as we cannot guaranty this is not used for something else. Instead, wait and help decide if above list is good, then I can issue very soon new codes and publish them in latest spec.