This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Talk:FHIR Datatypes Page"
Jump to navigation
Jump to search
Chris white (talk | contribs) |
|||
| Line 3: | Line 3: | ||
Does FHIR data type for dates permit the designation of a specific calendar - for example to indicate that the date is based on the Hijri calendar as opposed to the Gregorian calender? | Does FHIR data type for dates permit the designation of a specific calendar - for example to indicate that the date is based on the Hijri calendar as opposed to the Gregorian calender? | ||
* not as part of the core spec, but presumably it would be fine as an extension. (Unless you can demonstrate it's a requirement for 80% of existing healthcare apps that track dates? :>) Abstract datatypes supports alternative calendars, though none of the ITSs do, so mapping would theoretically be ok. | * not as part of the core spec, but presumably it would be fine as an extension. (Unless you can demonstrate it's a requirement for 80% of existing healthcare apps that track dates? :>) Abstract datatypes supports alternative calendars, though none of the ITSs do, so mapping would theoretically be ok. | ||
| + | |||
| + | == Generic containers with enumeration for content == | ||
| + | |||
| + | There is some guidance on 'slicing' to bind a repeating element in container elements like Name and Address that have generic repeating parts. However, since there is also an enumeration that constrains the possible types of repeating elements, it would be simpler and a lot more understandable to express these as specific elements (e.g. Name would have child elements given, family, etc). Has this been discussed and discarded? | ||
Revision as of 18:21, 5 September 2012
Calendar Option for Dates - Gregorian, Hijri ...
Does FHIR data type for dates permit the designation of a specific calendar - for example to indicate that the date is based on the Hijri calendar as opposed to the Gregorian calender?
- not as part of the core spec, but presumably it would be fine as an extension. (Unless you can demonstrate it's a requirement for 80% of existing healthcare apps that track dates? :>) Abstract datatypes supports alternative calendars, though none of the ITSs do, so mapping would theoretically be ok.
Generic containers with enumeration for content
There is some guidance on 'slicing' to bind a repeating element in container elements like Name and Address that have generic repeating parts. However, since there is also an enumeration that constrains the possible types of repeating elements, it would be simpler and a lot more understandable to express these as specific elements (e.g. Name would have child elements given, family, etc). Has this been discussed and discarded?
