FHIR Datatypes Page

Given the size of the data types page, this page is just an index of open issues by data type.

Index

• FHIR Schedule

Datatype Profiles

At the moment, we allow profiling of resources, but not of datatypes. Grahame's concerned that allowing it introduces unnecessary complexity and is a step towards v3 insanity. Though he has introduced pseudo-profiles in Quantity via the "Restrictions" tab. (NOTE: For those reading the specification and not using the spreadsheets, this is referring to the Distance, Count, Duration, and Money restrictions.)

Lloyd's arguments for allowing profiling of datatypes:

• Profiles are re-usable structures defining constraints. There's nothing about that that makes them specific to resources. They could easily handle datatypes too
• In v3, we introduced datatype flavors because of the desire by people to have common constraints on types they could reference elsewhere
• We already sort of do this on Quantity - why create a special mechanism
• When jurisdictions create extensions for use in types, they're going to want profiles that enforce the use of those extensions and they're not going to want to redefine the constraints over and over again
• Places where such constraints are likely to be relevant/useful:
  • name (variations for registry and "simple" names, adding in realm extensions)
  • address (same as above)
  • attachment (restricting mime types, requiring/prohibiting by-reference)
  • Quantity (restricting unit to particular types, constraining status)

Grahame's arguments why allowing profiles on datatypes are a bad idea:

• I don't think that the re-usable data type constraints across multiple resources are going to turn up that often. (mostly demographics, a few resources)
• We've said that you profile resources, not a finer granularity - they are the level of re-use
• one of the reasons for data type flavors was that you couldn't profile the data types using the v3 methodology. FHIR has no such issue. Profile the contents of the resource how you want, all the way down to the primitives.
• given this, I don't see the need, and especially not before we have implementation driven need for it.

Lloyd's responses:

• It's a question of re-use and ensuring consistency. You don't want to have to maintain the same constraints in 30 different profiles. Resources are units of re-use. But so are datatypes. Why allow profiling of one but not the other. And it's not true you couldn't profile the datatypes - you could put constraint statements where-ever you wanted. Which is essentially how you profile types in FHIR too. Datatype flavors allow you to define those constraints once and reference them by name.
• I was hoping you'd identify the complexity/cost you feel is associated with allowing profiles on types

Grahame:

• well, if it's 30 times, then ok, but I suspect it won't be. Let's see use cases

Victor Chai:

• We should get rid of profiling or constraints. Instead of constraining the super data type, we should use extension mechanism. The current way of constraining super data type will lead to problems for implementation when we generate Java object from FHIR XML Schema, all these constraints will be lost. In the below example, Duration.java and Count.java will be the same as Quantity.java, whatever constraints we place on Count data type has no effect on the generated java class, whereas if we use OO extension mechanism, then the additional extended stuff will be reflected in the generated class.

@XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "Duration") public class Duration extends Quantity {

}

XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "Count") public class Count extends Quantity {

}

Lloyd:

• Not sure how we can use extensions. We're not adding anything. Simply tightening what can be sent via existing properties. Can you expand on how you'd envision extensions being used for something like Duration?

Victor Chai:

• Since FHIR resource is used for exchange format only, it should be as simple as possible without the sophisticated UML modeling constraints. The goal is that any developer can simply take the XML schema, and then generate the corresponding application object either .NET or Java, and then start developing. Secondly reason is that FHIR is tightly defined XML schema for 80% of the use cases, so if we follow this principle, we should not embed constraints in the data type or even at resource level, as those constraints will be not be retained at the generated application level objects, if those constraints will be 'lost' at generated application objects, then it does not serve the purpose for constraining in the first place.

I created the sample UML diagram to represent the Quantity and constrained data types to illustrate how we can use extension mechanism to model the data types in simpler way.

Lloyd: The challenge is that anyone may want to create constrained (and extended) versions of data types in different situations. The Netherlands will create a version of the PersonName type that includes voervogesal (sp?). Others will want to constrain a measurement to weight or pressure or something in the context of a particular profile. So applications will have to deal with constraints regardless (on datatypes and on resources). As well, the set of constraints defined by FHIR don't cover all use-cases, just a few special cases. The full capabilities of the base datatype will be needed for all the quantities not covered by the restrictions.

Comments

• The word "human" in HumanId and HumanName is used differently. In HumanId, it's an id, "as used by humans", in HumanName is "the name for a human". I.e. this suggests you can use a "humanId" to identify passports and dogs, but "humanname" can only be used to name humans.
• LM: We don't have any naming guidelines at the moment. Do you have a suggestion that would be clearer?