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