Additional update: The Transport resource now exists (FMM 0).  Recommendation from FHIR-I workflow group: Task.location indicates the 'primary' location associated with the execution of the Task (if there is one).  For an appointment, the location is just one of a set of entities that can be 'booked'.  Task isn't being used in the same way.  For most resources where Location is used (e.g. Procedure, Encounter, MedicationDispense, etc.) Location is 0..1. If you're trying to define a Task seeking to represent a transfer from one location to another, those locations would need to be identified as separate Task.inputs because there'd be a need to differentiate them.  (Also, be aware that there's work underway for a 'Transport' resource and possibly a corresponding request that will better support transfers.) Proposed change: Clarify Task.location to have usage notes saying "This should only be specified when the Task to be/being performed happens or is expected to happen primarily within the bounds of a single Location.  Other locations (e.g. source, destination, etc.) would either be reflected on the 'basedOn' Request or be conveyed as distinct Task.input values."