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.)

My 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:

• [Grahame fill in here]