instead… Continue reading →"> Attributes Versus Elements in FHIR XML - Firely - LLM Cache

Attributes Versus Elements in FHIR XML - Firely

Some of you have asked me why, since our latest (0.7) Fhir Xml format, we use attributes to contain most of the “primitive” values, instead of the somewhat more common elements. E.g. for birthdate we now use:

<birthDate value="1972-11-30"/>

instead of:

<birthDate>1972-11-30</birthDate>

The reason is simple: extensions. Since any element in Fhir can be extended, there’s no such thing as a true “primitive” element. We might extend birthDate, so we could also include the original text as input by the user:

<birthDate value="2013-03-22">
    <extension>
        <url value="http://dontuse.example.org/profile/@narrative#originalText" />
        <valueString value="sometime next week" />
    </extension>
</birthDate>

If we wouldn’t have put the actual value in an attribute, we would end up with mixed content for birthDate:

<birthDate>
    2013-03-22
    <extension>
        <url value="http://hl7.org/fhir/profile/@narrative#originalText" />
        <valueCode value="sometime next week" />
    </extension>
</birthDate>

Handling mixed content is a pain for most of us, so we choose to use the “value” attribute over allowing mixed content.

Whether this really is out of line with current Xml authoring style is unclear: discussions on this subject on stackoverflow show a wide range of opinions, some even prefer to always put primitive values in attributes. It is however, clearly more painful for those using JSON, where any member is now expanded to a complex object:

"birthDate": {"value": "1973-05-31"}

instead of the more natural

"birthDate": "1973-05-31"

By Ewout Kramer

Ewout Kramer is one of the initiators of HL7 FHIR and a long-standing expert in healthcare information standards. With a background in computer science and decades of experience in healthcare IT, Ewout has played a key role in shaping how health information is exchanged and understood across systems. After early work with earlier generations of messaging standards, he collaborated with international leaders to design and document FHIR, a modern standard that has since become central to healthcare interoperability worldwide. As Firely's CTO, Ewout helps translate standards into practical solutions by embedding FHIR into real-world products and tools. Through consulting, coaching, and product development, he supports teams and organizations in adopting modern interoperability approaches that improve healthcare data exchange at scale.