Data Types R3 issues

Content on this page has been migrated to https://confluence.hl7.org/display/MnM/Data+Types+R3+Issues

This is the register of known data types issues for release 3.

These proposals have been categorized 2012-05-14 in terms of what will be considered as part of the next data types release

Proposed in-scope

• Update IETF RFC number under Language data type (BASIC) from RFC 3066 to RFC 5646 (or the latest RFC number) (Wendy Huang)
  • Alternatively we can reference BCP which is the dynamic identifier associated however there are caution guidance from IETF regarding this: However, referencing BCP 47 and then assuming that all the codes map to ISO 639 is problematic; BCP 47 allows a far richer code space than the isolated use of ISO 639; in particular, it allows use of associated country and script codes, so that, for instance, the Azeri language as written in Azerbajan using the Arabic script has a different code (az-AZ-Arab, I think) from the Azeri language as written in Russia using the Cyrillic script (az-RU-Cyrl). You might want to think hard about whether you want to reference BCP 47 at all if your desire is to disallow these qualifiers.
• Turn II.scope into a mandatory attribute Rene spronk
  • In MnM we discussed this and there are issues about making something mandatory that may be populated unsafely (Lloyd).
  • In general anything mandatory is a nuisance for implementers and may be populated quickly, dirty and/or unsafely. As such Lloyds argument applies to all mandatory model elements. Given the importance of II.scope to determine object equivalence there are IMHO sufficient reasons to consider turning this into a mandatory attribute. It's a tradeoff between the chances of unsafe use, and having to deal with a heap of implementation issues that we're facing without II.scope being present. (Rene)
  • Solution to this may involve adding an "Unknown" code to provide a safe value for implementers who really don't know what to populate.
• Add note to integrity Check about it's utility with digital signatures (Grahame)
• Add ability to flag lists as unsorted. (Lloyd)
  • A list nominally has a sort order. And sometimes the model is constrained to require the data to be a list. However, on occasion the order won't actually be known. This is sort of declaring a null flavor about the list. I.e. It's not a fully valid list, but you've still got some useful data to transmit.
• PIVL is unable to express that an interval starts at a time relative to another event. You can specify a particular starting date, or not starting date. But that's not often what you want, specially in DEF mood - start taking this tablet 3 times a day 2 days after some other event happens (the "after some other event" is not PIVLs business, but the days bit is - in particular, if you need to include the initial offset inside a GTS to operate with some other GTS fragment) (Grahame, for Cecil)
• We don't allow multi-dimensional collections (e.g. lists of lists of lists). There are some observation types where this would be extremely useful. At the moment, we need to separate observations for each occurrence, and that's exceptionally inefficient (Lloyd)
• Make it explicitly obvious that relative URLs are allowed in CDA documents for URL types. (Lloyd)
• Add "Toll Free" as a TelecommunicationUseCode (Lloyd)
• Add a property to the CD datatype as "valueSetDefinition" with a datatype of ED intended to contain the CTS 2 (or possibly other) definition of the value set. Needed to convey survey definitions, complex criterion triggers, etc. Common use-case is in Clinical Study Design (Lloyd)
• It should be possible to declare the character set for the ED datatype if the data is base64-encoded inside the "data" element. Otherwise it becomes impossible to have one instance reference content from other character sets. (Keith, as per blog post: http://feedproxy.google.com/~r/MotorcycleGuy/~3/bF5Amxi2zQM/hex-upon-all-your-charsets.html)
• TermID - need to capture the identifier for the Term (display name) seen by the user, rather than just the identifier of the concept. (Add to CD)
• document that ucum is case sensitive
• Under 6.10 Interval (IVL), it says "...the TS type should be used.". It should say "...the URG type should be used".

Defer

• Collapse Abstract and ISO 21090 into a single specification partitioned according to SAIF (Grahame)
  • Ideally we should have representations at Conceptual, Logical and Physical. We've never done Conceptual before.
  • Rationale: This isn't a datatypes issue, it's a tooling issue
• Allow address parts to nest. Makes it possible to send fully encoded address parts and receiver can parse the levels they know/care about and ignore further encoding. Could theoretically be relevant to names too, though less important there. (Lloyd)

Withdrawn

• Add 'conformance' into datatype properties (Lloyd)
  • introducing idea of "conformance" (required, optional, not permitted) into the datatype properties. E.g. "You are conformant if you ignore displayName, but not if you ignore code"
  • Encompasses issues deferred by Datatypes R2 Issue 103
  • Rationale: Handled in FHIR, not needed in abstract
• Introduce idea of "implementation" or "closed community" constraints on datatypes (Lloyd) (but initiated by Grahame)
  • implementers to be able to do things like constrain out the root when it's known. I.e. "non-worst case interoperability".
  • Rationale: Handled in FHIR, not needed in abstract
• Fix problems with cardinality in collections, likely by treating cardinality as an "argument" to the collection (Lloyd)
  • If you have a DSET<II>, cardinality of the attribute is still really 0..1, but the DSET may have a constraint that says number of items must be 2..5. Could be handled as DSET(II,2,5). Would require changes on the model sides too
  • Rationale: Theoretical, would require tooling changes, handled properly in FHIR
• Provide specific guidance about how to declare constraints on mixin attributes in a UML type declaration. I.e. How do you say that expressions are or are not allowed in a QTY datatype for a particular attribute in a UML model? (Lloyd)
  • Rationale: This isn't a datatypes issue, it's a methodology issue, it doesn't apply to FHIR (which allows datatype choices) and would require a tooling.
• Get schemas to enforce datatype flavors, use of mix-ins, etc. Possibly use Schematron w/ schema-aware X-paths? (Lloyd)
  • Rationale: This isn't a datatypes issue, it's a tooling issue