Jan 2015 Ballot Comment #75

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • Modeling & Methodology
    • Datatypes
    • 1.14.0.14
    • Hide

      There are many phone numbers captured in a variety of places that don't conform to the URI syntax and for which there is no need for this - they're intended for use by humans, not machines. ?Will define a standard extension to convey a machine-friendly (i.e. URI) form for those that need it. ?(And the base form can be constrained by profile if you really need it to be)

      2015-01-19 MnM Q2?Jeff/Mike 15-0-1

      Show
      There are many phone numbers captured in a variety of places that don't conform to the URI syntax and for which there is no need for this - they're intended for use by humans, not machines. ?Will define a standard extension to convey a machine-friendly (i.e. URI) form for those that need it. ?(And the base form can be constrained by profile if you really need it to be) 2015-01-19 MnM Q2?Jeff/Mike 15-0-1
    • Enhancement
    • Compatible, substantive
    • DSTU1 [deprecated]

      Existing Wording
      If capturing a phone, fax or similar contact point, the value should be a properly formatted telephone number according to ITU-T E.123. However, this is frequently not possible due to legacy data and/or recording methods.

      Comments
      I believe that it would be better to use the URI format from IETF RFC 3966 (no spaces).

      From RFC 3966:
      However, even though ITU-T E.123 [E.123] recommends the use of space
      characters as visual separators in printed telephone numbers, "tel"
      URIs MUST NOT use spaces in visual separators to avoid excessive escaping.

      Grahame's Comments
      no. many implementers cannot conform to this in CDA - and it's about more than just spaces. And it brings no value to end users, to strip comments out. This can be applied as a rule in a profile if desired

            Assignee:
            Unassigned
            Reporter:
            dloewenstein
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: