Datatypes R2 Issue 77

Introduction

The existing definition of assigningAuthorityName is tautological and doesn't actually indicate what "assigning authority" actually is. There are two possible interpretations:

1. The name of the legal organization responsible for issuing the identifier. This will usually be associated in some way with the II.root, but not always and the specific relationship isn't necessarily clear.

2. The name associated directly with the 'namespace' represented by the OID root. Essentially this would be a displayName that would function in a manner similar to CD.codeSystemName in that it could be displayed to users in place of the OID, while the OID would be used for system processing.

? backward compatible.

Discussion

--Lmckenzi 10:27, 30 April 2007 (CDT): If the use represents #1, then there may still be a use-case for #2. At a minimum, people need to know which use is appropriate.

Well there is a 3rd option: delete it alltogether. I feel that it is unsafe to send these things (incl. assigningAuthorityName, codeSystemName, and even CD.displayName), because implementers are tempted to rely on these names for processing. Even displaying to the end-user is not safe, because you display one thing and the code/oid may mean something else (with no way to check!). But that said definitely the answer to this specific item should be #2, but I like to discuss #3 also (drop it because it's unsafe.) It would be a mistake to do #1. Gschadow 06:12, 1 May 2007 (CDT)

Would you argue for removing codeSystemName as well? I think it would be a mistake to remove this field. It would be a negative ballot magnet too. Although I think that the intent of the definition is #1, I am happy to change the definition to #2. --GrahameGrieve 06:36, 1 May 2007 (CDT)

I would indeed argue for getting rid of codeSystemName. The problem is it is unsafe. Also, it is optional anyway (meaning when you really need it it's not going to be there). I know it would cause panic, but I think that life with it is worth than without. I fully expect to loose that argument. Gschadow 06:50, 1 May 2007 (CDT)

I agree it's unsafe if users try to use it for processing. However, if users are stubborn enough, they can send length-delimited data inside Act.text. In other words, some users can and will do whatever they feel like. That doesn't mean we shouldn't support genuine use-cases. I think that having a user-friendly, non-standardized, fully free-text name of the namespace or code system represented by an OID is useful. (And it's more useful for namespace than for codesystem, given that few people will have an excuse to not go to HL7 to look up the name for a code system in our registry, whereas the majority of identifiers will be private ids that will never show up in our registry and having a descriptive label for them could be useful. I certainly believe we need to be clear (using bold-face, capital MUST NOTs, exclaimation marks, etc. :>) that the property must not be used for processing purposes. In the end, some small percentage will do so anyhow, but that same small percentage would probably add an extension element or adapt a convention of putting the print name in brackets on the end of the root or something equally insane if it wasn't there, so we're not buying a lot by removing the element.

If the answer is #2, then the name is a little unfortunate. We certainly need to clarify the description. I'd suggest something along the following:

This is a human-readable name for the namespace represented for the OID or GUID communicated in root. It is a descriptive name for the actual namespace. e.g. "California, U.S. Driver's License Number, 1970-". It does NOT refer to the organization which issued the identifier (e.g. California Dept. of Motor Vehicles). It is intended for use as a human readable label when an identifier must be displayed to a human user where an OID would not be meaningful. In general, it should only be used when an extension is present, allowing for a display such as "California, U.S. Driver's License Number, 1970-: 123456789". There are absolutely no guidelines for the contents of this text other than it should be completely descriptive of the namespace. E.g. "Driver's License" or even "California Driver's License" would not be ideal. However, formatting, capitalization, whitepace, language, etc. are completely up to the sender. Applications MUST NEVER attempt to perform any decision-making, matching, filtering or other processing based on this property. It is for display only. All decision logic MUST be based solely on the root and extension properties.

Given this interpretation of the existing property, I don't think we need 'type' in the ISO datatypes. There's nothing you should be doing with type that you can't do with assigningAuthority(namespace)Name. Given that we're making it a string, anyone who tries to treat it as a code is nuts. If the use-case is a label for users, then we've already got that. My suspicion is that the 3 aspects supported by openEHR are simple migrations of the v2 concepts, and we know we don't want to go there. Lets just support a use-case that's reasonable and makes sense and make clear in the spec what the use-case is. If someone in ISO complains that they still need type, they need to explain what the use-case is, at which point we can judge it on its merits. Adding the existing field with bad codes and no explanation of usage, particularly given that its use will be prohibited in HL7, seems like a silly idea. (Not good form to sabatoge other standards . . . :>) --Lmckenzi 12:01, 1 May 2007 (CDT)

I don't mind Lloyd's definition. I think it's a lot more useful piece of information than assigningAuthorityName - but it's something different, so we should rename the property. Ironically, this would mean that it map to something different in ISO ;-). I am discussing this in the ISO context too now. But the ISO issues are secondary to R2 issues here; what should the R2 definition and name be? I vote for Lloyds definition above with the name namespaceName.--GrahameGrieve 12:43, 14 May 2007 (CDT)

Links

Back to Data Types R2 issues