xxxRequest

Name / Flags / Card. / Type / W5 / Description & Constraints / Definition / Usage
identifier / S / 0..* / Identifier / id / Business identifier for request/order
definition / S / 0..* / Reference() / Protocol or definition followed by this request
basedOn / S / 0..* / Reference() / Plan/proposal/order fulfilled by this request
replaces / S / 0..* / Reference() / Request takes the place of referenced completed or terminated requests
requisition / S / 0..1 / Identifier / Composite request this is part of
status / !S / 1..1 / Code / status / entered-in-error | draft | active |suspended | completed[l1]
category / !S / 1..1 / CodeableConcept / class / proposal | plan | orig. order | encoded +[L2]
code / S / 0..1 / CodeableConcept[L3] / what / What’s being requested/ordered
subject / S / 1..1[L4] / Reference(Patient | Group? | ??) / who.focus / Individual the service is ordered for
context / S / 0..1 / Reference(Encounter | EpisodeOfCare) / context / Encounter or Episode during which request was created
occurrence[x] / S / 0..1 / dateTime| Period| Schedule? / when.planned / When service should occur
authored / S / 0..1 / dateTime / when.recorded / When the request transitioned to being actionable
requester / S / 0..1 / Reference(Device | Patient | Practitioner | RelatedPerson[L5]| Organization?) / who.author / Who/what is requesting service[L6]
performerType[L7] / S / 0..1 / CodeableConcept / who.performer / Desired type of performer for service
performer[L8] / S / 0..1 / Reference(Practitioner | Organization | Patient | Device | RelatedPerson) / who.performer / Desired performer for service
reason[x] / S / 0..1 / CodeableConcept | Reference(??) / why / Why is service necessary?
supportingInfo / 0..* / Reference(Any) / Additional information to be used in fulfilling request
note / 0..* / Annotation / Comments made about the service request
relevantHistory / 0..* / Reference(Provenance) / Key events in the history of the request / This may not include provenances for all versions of the request – only those deemed “relevant” or important.
This SHALL NOT include the Provenance associated with this current version of the resource. (If that provenance is deemed to be a “relevant” change, it will need to be added as part of a later update. Until then, it can be queried directly as the Provenance that points to this version using _revinclude
All Provenances should have some historical version of this Request as their subject.

[l1]These are the only statuses that should be supported. Statuses relating to requested/received/rejected/accepted/in-progress/failed are handled by Task, not by the request resource

[L2]Proposal, plan, original order should be present for all. Different resources may have others (e.g. reflex order for lab, MAR for pharmacy, etc.)

[L3]Could also be a reference to Medication|Substance|Device being requested (and name might change if you’re doing that)

[L4]Can be 0..1 for “bulk” orders (e.g. bulk supplies), though may want those to be a distinct resource. May need to revisit this if we include definition

[L5]While not all of these are appropriate for orders, most are appropriate for plans/proposals

[L6]Add an implementation note that this not the dispatcher, but rather who is authorizing

[L7]Need to make clear that this can be role, but not participation type. I.e. doesn’t describe the task, describes the capacity. Examples “compounding pharmacy” or “psychiatrist” or “internal referral”

[L8]Define a common extension structure that allows listing multiple alternative sets of type/performer with preference. Extension would be used in place of core elements. Make clear that the extension is for alternative performers (or) , not multiple performers (and).