Forcing client systems to write code that take a complete Canadian postal code and render it in a standardized way is certainly possible. Systems will still need to convey partial postal codes, erroneous postal codes and postal codes for non-Canadian addresses. So we can't impose this as a general constraint. Systems need to be able to expose the data they have. Where automated transformation to align with a standard is possible, we can demand that be done. However, we should *only* demand that be done if we believe that the benefit is worth the cost of imposing that code on all client systems. (Note that servers could easily transform the data on consumption if they wished.)
One of the questions we discussed on the Entity sub-stream is the formatting of the Canadian postal code.
What I've found so far is this - "Postal Code – Should be printed in uppercase and placed two spaces to the right of the Province or Territory, with one space between the first three and the last three characters. A hyphen should not be used (ex. of unacceptable format: T0L-1K0)." (www.canadapost.ca/tools/pg/manual/PGaddress-e.asp?ecid=murl10006450)
We decided not to overload the Address.postalCode component with the Regex extension but rather provide a textual description as above, which applies to Canadian postal codes only, allowing to provide other (e.g. US ZIP number).
Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.
Baseline Canadian FHIR Profiles - Entities Stream Calls
Print
Email
Twitter