Recently, Grahame posted a request on his blog requesting feedback on how FHIR represents extensions (http://www.healthintersections.com.au/?p=2467). Currently, all extensions appear under <extension> tags. This makes the wire format hard to read, particularly when there are nested extensions. The worst-case scenario involves using the Basic resource to create a new profile built entirely of extensions, resulting in definitions and instances with deeply nested <extension> tags and lacking of readable names, falling short of FHIR’s goal of “a human-readable wire format for ease of use by developers.”

The original design reason for representing extensions in this way was to enable one master XSD to validate any FHIR XML instance. Validation with the master XSD, however, is not very effective because it only incorporates the base resource definition, and does not validate extensions or check constraints specified by profiles, such as cardinality restrictions, data type restrictions, or fixed values. Since profiles will generally be in use, an instance would ideally be validated based on the profiled resource. Thus, having a single, master XSD might not be a totally compelling reason for the current representation of extensions. Moreover, a number of implementers have chosen to implement JSON only, and then the reasoning shifts dramatically.

In his post, Grahame presents four alternative representations, but dismisses them for various reasons, ultimately expressing his preference for the current syntax. His reasoning seems sound based on the alternatives he considers, but before abandoning the discussion, it might make sense to take a step back and reconsider the requirements, before passing judgment. So here goes:

• The representation MUST support distributed extensibility, whereby multiple parties create different extensions with the same names. HL7 should not put limits on who can create extensions, and given that openness, naming collisions may occur and should be planned for.
• The representation MUST distinguish modifying extensions from normal extensions. The receiver must be able to tell if an unknown extension is a modifying extension (one that may change the meaning of the resource), without reaching out over the internet to find the definition.
• The representation MUST allow the receiver to determine the identity of each extension, by providing a unique URI identifying the extension, or by linking to a structure definition that contains the URI for the extension.
• The representation MUST allow parsing the URI, the value, and the data type of an extension, without needing to reach out over the internet to find the definition of the extension.
• The representation MUST be able to express conformance to multiple profiles, allowing validation by linking to the structure definition(s) that define the extensions and additional constraints defined by profiles.
• The representation MUST be easily readable, even when there are multiple nested extensions.
• The representation SHOULD leverage existing standards, avoid abusing existing standards, and avoid creating a new standard if a similar one already exists.
• The representation SHOULD leverage existing standards for schema validation, such as XSD and schematron.
• The representation SHOULD treat extensions and core elements in the same way, rather than requiring a different type of processing logic for extensions.

Do you agree with these requirements? Stating the requirements provides a rational basis for evaluating proposed representations for extensions. In the next post, I will take a look at the current representation, and each of Grahame’s proposals, in terms of these requirements.