US Core Implementation Guide
9.0.0-ballot - STU 9 Ballot United States of America flag

US Core Implementation Guide, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 9.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/US-Core/ and changes regularly. See the Directory of published versions

Resource Profile: US Core PMO ServiceRequest Profile

Official URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-pmo-servicerequest Version: 9.0.0-ballot
Standards status: Trial-use Maturity Level: 3 Computable Name: USCorePMOServiceRequestProfile
Other Identifiers: OID:2.16.840.1.113883.4.642.40.2.42.70

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

The US Core PMO ServiceRequest Profile inherits from the FHIR ServiceRequest resource; refer to it for scope and usage definitions. This profile represents an order based on a PMO document and references the US Core ADI DocumentReference Profile to communicate the contents of the PMO document, such as POLST, MOLST, or other state-specific forms. PMO documents follow the patient across care settings and are typically stored as scanned images in EMRs/EHRs. Together, these two profiles satisfy the USCDI's PMO Order Data Element's intent to represent orders based on an individual's PMO. The US Core PMO ServiceRequest Profile establishes minimum expectations for recording, searching, and fetching PMO-related ServiceRequest information, specifying core elements, extensions, vocabularies, and value sets that SHALL be present to promote interoperability.

The decision to add the US Core PMO Service Request Profile and to meet the USCDI's PMO Order Data Element definition sparked a healthy debate on whether ServiceRequest is necessary for actionable orders or if DocumentReference is sufficient for PMO portability and patient access.

The rationale for adding ServiceRequest to represent the USCDI PMO Order includes:

  1. Enhancing Patient Access and Care: ServiceRequest enables actionable orders; without it, patient access and care goals are not fully met.
  2. Tracking PMO Implementation A derivative order via ServiceRequest is necessary to demonstrate that the PMO has followed the patient.

The concerns include:

  1. Incomplete Representation: A ServiceRequest reflects only part of a PMO order and may not fully capture the PMO's scope.
  2. Scope Creep Beyond USCDI: Concerns that it goes beyond USCDI requirements by including derivative orders.
  3. Unnecessary Complexity: ServiceRequest could add unnecessary complexity without clear justification.
  4. Sufficiency of Current Design: The current DocumentReference-based design already meets PMO requirements for USCDI

We request feedback on the clinical utility of this profile and its implications for certification

.

Example Usage Scenarios:

The following are example usage scenarios for this profile:

  • Query for a specific procedure
  • Query for a category of service request

Mandatory and Must Support Data Elements

The following data elements must always be present (Mandatory definition) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Views below provides the formal summary, definitions, and terminology requirements.

Each Service Request Must Have:

  1. a status
  2. an intent code indicating whether the request is a proposal, plan, or order.
  3. a code or plain text representation defining what is being requested*
  4. a patient

Each Service Request Must Support:

  1. a category
  2. plain text representation of what is being requested*
  3. a code or plain text representation of additional order details*
  4. the encounter in which the request was created
  5. when the requested service should happen
  6. when the request was made
  7. the requester*
  8. the code for the test, procedure, or service to be performed
  9. a reason or indication for referral or consultation

*see guidance below

Profile Specific Implementation Guidance

This section provides detailed implementation guidance for the US Core Profile to support implementation and certification.

  • This profile is intended for use when documenting derived medical orders after reviewing a patient's Portable Medical Order (PMO) — such as POLST, MOLST, or other state-specific forms. It is scoped to facility-based care environments where actionable orders are implemented, including hospitals, skilled nursing facilities, long-term care, and outpatient procedure centers (e.g., surgery centers, dialysis facilities).
    • This profile is not intended for routine ambulatory or office-based practice settings, where PMOs may be reviewed, but new standing orders are not typically derived.
  • Although the ServiceRequest.code is bound to US Core Procedure Codes, a broadly defined value set that accommodates many healthcare domains, it has several additional bindings based on the PMO categories found in ServiceRequest.category. The additional bindings are displayed in ServiceRequest.code's Description and Constrain column in the formal definition below.
  • Often, plain text is used instead of codes to define what is being requested/ordered and for additional order details.
  • *The profile element ServiceRequest.requester communicates the individual level provenance author data corresponding to the U.S. Core Data for Interoperability (USCDI) Provenance Author Data Elements.

Usages:

You can also check for usages in the FHIR IG Statistics

Changes since version 8.0.0:

  • New Content

    • Formal Views of Profile Content

    Description of Profiles, Differentials, Snapshots and how the different presentations work.

    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest C 0..* ServiceRequest A request for a service to be performed
    Constraints: prr-1
    ... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
    ... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
    ... status ?!SΣ 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    Binding: RequestStatus (required): The status of a service order.
    ... intent ?!SΣ 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    Binding: RequestIntent (required): The kind of service request.
    ... Slices for category SΣ 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    Binding: ServiceRequestCategoryCodes (example): Classification of the requested service.
    .... category:us-core-pmo SΣ 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... doNotPerform ?!Σ 0..1 boolean True if service/procedure should not be performed
    ... code SΣ 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... text SΣ 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail SΣC 0..* CodeableConcept Additional order information
    Binding: ServiceRequestOrderDetailsCodes (example): Codified order entry details which are based on order context.
    .... text SΣ 0..1 string Plain text representation to capture additional PMO order details.
    ... subject SΣ 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter SΣ 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] SΣ 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... authoredOn SΣ 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester SΣ 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... reasonCode SΣ 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference SΣ 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.

    doco Documentation for this format

    Terminology Bindings

    Path Status Usage ValueSet Version Source
    ServiceRequest.status Base required RequestStatus 📍4.0.1 FHIR Std.
    ServiceRequest.intent Base required RequestIntent 📍4.0.1 FHIR Std.
    ServiceRequest.category Base example Service Request Category Codes 📍4.0.1 FHIR Std.
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.orderDetail Base example Service Request Order Details Codes 📍4.0.1 FHIR Std.
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG

    Constraints

    Id Grade Path(s) Description Expression
    dom-2 error ServiceRequest If the resource is contained in another resource, it SHALL NOT contain nested Resources contained.contained.empty()
    dom-3 error ServiceRequest If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
    dom-4 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
    dom-5 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a security label contained.meta.security.empty()
    dom-6 best practice ServiceRequest A resource should have narrative for robust management text.`div`.exists()
    ele-1 error **ALL** elements All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
    ext-1 error **ALL** extensions Must have either extensions or value[x], not both extension.exists() != value.exists()
    prr-1 error ServiceRequest orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()

    This structure is derived from ServiceRequest

    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest 0..* ServiceRequest A request for a service to be performed
    ... status S 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    ... intent S 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    ... Slices for category S 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    .... category:us-core-pmo S 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... code S 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... text S 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail S 0..* CodeableConcept Additional order information
    .... text S 0..1 string Plain text representation to capture additional PMO order details.
    ... subject S 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter S 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] S 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... authoredOn S 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester S 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... reasonCode S 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference S 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.

    doco Documentation for this format

    Terminology Bindings (Differential)

    Path Status Usage ValueSet Version Source
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG
    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest C 0..* ServiceRequest A request for a service to be performed
    Constraints: prr-1
    ... id Σ 0..1 id Logical id of this artifact
    ... meta Σ 0..1 Meta Metadata about the resource
    ... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
    ... language 0..1 code Language of the resource content
    Binding: CommonLanguages (preferred): A human language.
    Additional BindingsPurpose
    AllLanguages Max Binding
    ... text 0..1 Narrative Text summary of the resource, for human interpretation
    This profile does not constrain the narrative in regard to content, language, or traceability to data elements
    ... contained 0..* Resource Contained, inline Resources
    ... extension 0..* Extension Additional content defined by implementations
    ... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
    ... identifier Σ 0..* Identifier Identifiers assigned to this order
    ... instantiatesCanonical Σ 0..* canonical(ActivityDefinition | PlanDefinition) Instantiates FHIR protocol or definition
    ... instantiatesUri Σ 0..* uri Instantiates external protocol or definition
    ... basedOn Σ 0..* Reference(CarePlan | ServiceRequest | MedicationRequest) What request fulfills
    ... replaces Σ 0..* Reference(ServiceRequest) What request replaces
    ... requisition Σ 0..1 Identifier Composite Request ID
    ... status ?!SΣ 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    Binding: RequestStatus (required): The status of a service order.
    ... intent ?!SΣ 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    Binding: RequestIntent (required): The kind of service request.
    ... Slices for category SΣ 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    Binding: ServiceRequestCategoryCodes (example): Classification of the requested service.
    .... category:us-core-pmo SΣ 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... priority Σ 0..1 code routine | urgent | asap | stat
    Binding: RequestPriority (required): Identifies the level of importance to be assigned to actioning the request.
    ... doNotPerform ?!Σ 0..1 boolean True if service/procedure should not be performed
    ... code SΣ 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... id 0..1 string Unique id for inter-element referencing
    .... extension 0..* Extension Additional content defined by implementations
    Slice: Unordered, Open by value:url
    .... coding Σ 0..* Coding Code defined by a terminology system
    .... text SΣ 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail SΣC 0..* CodeableConcept Additional order information
    Binding: ServiceRequestOrderDetailsCodes (example): Codified order entry details which are based on order context.
    .... id 0..1 string Unique id for inter-element referencing
    .... extension 0..* Extension Additional content defined by implementations
    Slice: Unordered, Open by value:url
    .... coding Σ 0..* Coding Code defined by a terminology system
    .... text SΣ 0..1 string Plain text representation to capture additional PMO order details.
    ... quantity[x] Σ 0..1 Service amount
    .... quantityQuantity Quantity
    .... quantityRatio Ratio
    .... quantityRange Range
    ... subject SΣ 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter SΣ 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] SΣ 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... asNeeded[x] Σ 0..1 Preconditions for service
    Binding: SNOMEDCTMedicationAsNeededReasonCodes (example): A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.
    .... asNeededBoolean boolean
    .... asNeededCodeableConcept CodeableConcept
    ... authoredOn SΣ 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester SΣ 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... performerType Σ 0..1 CodeableConcept Performer role
    Binding: ParticipantRoles (example): Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.
    ... performer Σ 0..* Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) Requested performer
    ... locationCode Σ 0..* CodeableConcept Requested location
    Binding: ServiceDeliveryLocationRoleType (example): A location type where services are delivered.
    ... locationReference Σ 0..* Reference(Location) Requested location
    ... reasonCode SΣ 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference SΣ 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.
    ... insurance 0..* Reference(Coverage | ClaimResponse) Associated insurance coverage
    ... supportingInfo 0..* Reference(Resource) Additional clinical information
    ... specimen Σ 0..* Reference(Specimen) Procedure Samples
    ... bodySite Σ 0..* CodeableConcept Location on Body
    Binding: SNOMEDCTBodyStructures (example): Codes describing anatomical locations. May include laterality.
    ... note 0..* Annotation Comments
    ... patientInstruction Σ 0..1 string Patient or consumer-oriented instructions
    ... relevantHistory 0..* Reference(Provenance) Request provenance

    doco Documentation for this format

    Terminology Bindings

    Path Status Usage ValueSet Version Source
    ServiceRequest.language Base preferred Common Languages 📍4.0.1 FHIR Std.
    ServiceRequest.status Base required RequestStatus 📍4.0.1 FHIR Std.
    ServiceRequest.intent Base required RequestIntent 📍4.0.1 FHIR Std.
    ServiceRequest.category Base example Service Request Category Codes 📍4.0.1 FHIR Std.
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.priority Base required Request priority 📍4.0.1 FHIR Std.
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.orderDetail Base example Service Request Order Details Codes 📍4.0.1 FHIR Std.
    ServiceRequest.asNeeded[x] Base example SNOMED CT Medication As Needed Reason Codes 📍4.0.1 FHIR Std.
    ServiceRequest.performerType Base example Participant Roles 📍4.0.1 FHIR Std.
    ServiceRequest.locationCode Base example ServiceDeliveryLocationRoleType 📦3.0.0 THO v6.5
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG
    ServiceRequest.bodySite Base example SNOMED CT Body Structures 📍4.0.1 FHIR Std.

    Constraints

    Id Grade Path(s) Description Expression
    dom-2 error ServiceRequest If the resource is contained in another resource, it SHALL NOT contain nested Resources contained.contained.empty()
    dom-3 error ServiceRequest If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
    dom-4 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
    dom-5 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a security label contained.meta.security.empty()
    dom-6 best practice ServiceRequest A resource should have narrative for robust management text.`div`.exists()
    ele-1 error **ALL** elements All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
    ext-1 error **ALL** extensions Must have either extensions or value[x], not both extension.exists() != value.exists()
    prr-1 error ServiceRequest orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()

    This structure is derived from ServiceRequest

    Summary

    Mandatory: 1 element
    Must-Support: 15 elements

    Structures

    This structure refers to these other structures:

    Slices

    This structure defines the following Slices:

    • The element 1 is sliced based on the value of ServiceRequest.category

    Maturity: 3

    Key Elements View

    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest C 0..* ServiceRequest A request for a service to be performed
    Constraints: prr-1
    ... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
    ... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
    ... status ?!SΣ 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    Binding: RequestStatus (required): The status of a service order.
    ... intent ?!SΣ 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    Binding: RequestIntent (required): The kind of service request.
    ... Slices for category SΣ 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    Binding: ServiceRequestCategoryCodes (example): Classification of the requested service.
    .... category:us-core-pmo SΣ 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... doNotPerform ?!Σ 0..1 boolean True if service/procedure should not be performed
    ... code SΣ 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... text SΣ 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail SΣC 0..* CodeableConcept Additional order information
    Binding: ServiceRequestOrderDetailsCodes (example): Codified order entry details which are based on order context.
    .... text SΣ 0..1 string Plain text representation to capture additional PMO order details.
    ... subject SΣ 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter SΣ 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] SΣ 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... authoredOn SΣ 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester SΣ 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... reasonCode SΣ 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference SΣ 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.

    doco Documentation for this format

    Terminology Bindings

    Path Status Usage ValueSet Version Source
    ServiceRequest.status Base required RequestStatus 📍4.0.1 FHIR Std.
    ServiceRequest.intent Base required RequestIntent 📍4.0.1 FHIR Std.
    ServiceRequest.category Base example Service Request Category Codes 📍4.0.1 FHIR Std.
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.orderDetail Base example Service Request Order Details Codes 📍4.0.1 FHIR Std.
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG

    Constraints

    Id Grade Path(s) Description Expression
    dom-2 error ServiceRequest If the resource is contained in another resource, it SHALL NOT contain nested Resources contained.contained.empty()
    dom-3 error ServiceRequest If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
    dom-4 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
    dom-5 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a security label contained.meta.security.empty()
    dom-6 best practice ServiceRequest A resource should have narrative for robust management text.`div`.exists()
    ele-1 error **ALL** elements All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
    ext-1 error **ALL** extensions Must have either extensions or value[x], not both extension.exists() != value.exists()
    prr-1 error ServiceRequest orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()

    Differential View

    This structure is derived from ServiceRequest

    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest 0..* ServiceRequest A request for a service to be performed
    ... status S 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    ... intent S 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    ... Slices for category S 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    .... category:us-core-pmo S 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... code S 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... text S 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail S 0..* CodeableConcept Additional order information
    .... text S 0..1 string Plain text representation to capture additional PMO order details.
    ... subject S 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter S 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] S 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... authoredOn S 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester S 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... reasonCode S 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference S 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.

    doco Documentation for this format

    Terminology Bindings (Differential)

    Path Status Usage ValueSet Version Source
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG

    Snapshot View

    NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
    .. ServiceRequest C 0..* ServiceRequest A request for a service to be performed
    Constraints: prr-1
    ... id Σ 0..1 id Logical id of this artifact
    ... meta Σ 0..1 Meta Metadata about the resource
    ... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
    ... language 0..1 code Language of the resource content
    Binding: CommonLanguages (preferred): A human language.
    Additional BindingsPurpose
    AllLanguages Max Binding
    ... text 0..1 Narrative Text summary of the resource, for human interpretation
    This profile does not constrain the narrative in regard to content, language, or traceability to data elements
    ... contained 0..* Resource Contained, inline Resources
    ... extension 0..* Extension Additional content defined by implementations
    ... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
    ... identifier Σ 0..* Identifier Identifiers assigned to this order
    ... instantiatesCanonical Σ 0..* canonical(ActivityDefinition | PlanDefinition) Instantiates FHIR protocol or definition
    ... instantiatesUri Σ 0..* uri Instantiates external protocol or definition
    ... basedOn Σ 0..* Reference(CarePlan | ServiceRequest | MedicationRequest) What request fulfills
    ... replaces Σ 0..* Reference(ServiceRequest) What request replaces
    ... requisition Σ 0..1 Identifier Composite Request ID
    ... status ?!SΣ 1..1 code draft | active | on-hold | revoked | completed | entered-in-error | unknown
    Binding: RequestStatus (required): The status of a service order.
    ... intent ?!SΣ 1..1 code Note: To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document
    Binding: RequestIntent (required): The kind of service request.
    ... Slices for category SΣ 0..* CodeableConcept Classification of service
    Slice: Unordered, Open by value:$this
    Binding: ServiceRequestCategoryCodes (example): Classification of the requested service.
    .... category:us-core-pmo SΣ 0..* CodeableConcept ​Multiple portable medical order categories vs a single "PMO" category (2 vs 3 level code heirarchy)?
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders (extensible)
    ... priority Σ 0..1 code routine | urgent | asap | stat
    Binding: RequestPriority (required): Identifies the level of importance to be assigned to actioning the request.
    ... doNotPerform ?!Σ 0..1 boolean True if service/procedure should not be performed
    ... code SΣ 1..1 CodeableConcept ​What is being requested/ordered
    Binding: http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code (extensible): Portable Medical Order panel answers - mostly free-text
    Additional BindingsPurposeDocumentation
    Cardiopulmonary Resuscitation Procedures Grouping . Extensible
    SeviceRequest.category = Cardiopulmonary resuscitation orders
    Initial Treatment Portable Medical Order Procedures Grouping . Extensible
    SeviceRequest.category = Initial portable medical treatment orders
    Additional Portable Medical Order Procedures . Extensible
    SeviceRequest.category = Additional portable medical orders or instructions
    .... id 0..1 string Unique id for inter-element referencing
    .... extension 0..* Extension Additional content defined by implementations
    Slice: Unordered, Open by value:url
    .... coding Σ 0..* Coding Code defined by a terminology system
    .... text SΣ 0..1 string Plain text representation of the PMO procedure or service.
    ... orderDetail SΣC 0..* CodeableConcept Additional order information
    Binding: ServiceRequestOrderDetailsCodes (example): Codified order entry details which are based on order context.
    .... id 0..1 string Unique id for inter-element referencing
    .... extension 0..* Extension Additional content defined by implementations
    Slice: Unordered, Open by value:url
    .... coding Σ 0..* Coding Code defined by a terminology system
    .... text SΣ 0..1 string Plain text representation to capture additional PMO order details.
    ... quantity[x] Σ 0..1 Service amount
    .... quantityQuantity Quantity
    .... quantityRatio Ratio
    .... quantityRange Range
    ... subject SΣ 1..1 Reference(US Core Patient Profile) limited to Patient
    ... encounter SΣ 0..1 Reference(US Core Encounter Profile) **NOT USED WHEN PART OF A PMO DOCUMENT**
    ... occurrence[x] SΣ 0..1 Often just a start date
    .... occurrencePeriod Period S
    .... occurrenceDateTime dateTime
    .... occurrenceTiming Timing
    ... asNeeded[x] Σ 0..1 Preconditions for service
    Binding: SNOMEDCTMedicationAsNeededReasonCodes (example): A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.
    .... asNeededBoolean boolean
    .... asNeededCodeableConcept CodeableConcept
    ... authoredOn SΣ 0..1 dateTime Date Order signed vs date of PMO document - same if part of PMO document
    ... requester SΣ 0..1 Reference(US Core Practitioner Profile S | US Core Organization Profile | PractitionerRole) Authored only by Practitioner
    ... performerType Σ 0..1 CodeableConcept Performer role
    Binding: ParticipantRoles (example): Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.
    ... performer Σ 0..* Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) Requested performer
    ... locationCode Σ 0..* CodeableConcept Requested location
    Binding: ServiceDeliveryLocationRoleType (example): A location type where services are delivered.
    ... locationReference Σ 0..* Reference(Location) Requested location
    ... reasonCode SΣ 0..* CodeableConcept Explanation/Justification for procedure or service
    Binding: US Core Condition Codes (extensible)
    ... reasonReference SΣ 0..* ​Reference(US Core ADI DocumentReference Profile S | us-core-condition | us-core-observation | us-core-diagnosticreport) US Core ADI DocumentReference Profile or other US Core profiles that support the requested PMO service.
    ... insurance 0..* Reference(Coverage | ClaimResponse) Associated insurance coverage
    ... supportingInfo 0..* Reference(Resource) Additional clinical information
    ... specimen Σ 0..* Reference(Specimen) Procedure Samples
    ... bodySite Σ 0..* CodeableConcept Location on Body
    Binding: SNOMEDCTBodyStructures (example): Codes describing anatomical locations. May include laterality.
    ... note 0..* Annotation Comments
    ... patientInstruction Σ 0..1 string Patient or consumer-oriented instructions
    ... relevantHistory 0..* Reference(Provenance) Request provenance

    doco Documentation for this format

    Terminology Bindings

    Path Status Usage ValueSet Version Source
    ServiceRequest.language Base preferred Common Languages 📍4.0.1 FHIR Std.
    ServiceRequest.status Base required RequestStatus 📍4.0.1 FHIR Std.
    ServiceRequest.intent Base required RequestIntent 📍4.0.1 FHIR Std.
    ServiceRequest.category Base example Service Request Category Codes 📍4.0.1 FHIR Std.
    ServiceRequest.category:us-core-pmo Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-portable-medical-orders ? Unknown
    ServiceRequest.priority Base required Request priority 📍4.0.1 FHIR Std.
    ServiceRequest.code Base extensible ​ http://hl7.org/fhir/us/core/ValueSet/us-core-pmo-procedure-code ? Unknown
    ServiceRequest.orderDetail Base example Service Request Order Details Codes 📍4.0.1 FHIR Std.
    ServiceRequest.asNeeded[x] Base example SNOMED CT Medication As Needed Reason Codes 📍4.0.1 FHIR Std.
    ServiceRequest.performerType Base example Participant Roles 📍4.0.1 FHIR Std.
    ServiceRequest.locationCode Base example ServiceDeliveryLocationRoleType 📦3.0.0 THO v6.5
    ServiceRequest.reasonCode Base extensible US Core Condition Codes 📦9.0.0-ballot This IG
    ServiceRequest.bodySite Base example SNOMED CT Body Structures 📍4.0.1 FHIR Std.

    Constraints

    Id Grade Path(s) Description Expression
    dom-2 error ServiceRequest If the resource is contained in another resource, it SHALL NOT contain nested Resources contained.contained.empty()
    dom-3 error ServiceRequest If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
    dom-4 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
    dom-5 error ServiceRequest If a resource is contained in another resource, it SHALL NOT have a security label contained.meta.security.empty()
    dom-6 best practice ServiceRequest A resource should have narrative for robust management text.`div`.exists()
    ele-1 error **ALL** elements All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
    ext-1 error **ALL** extensions Must have either extensions or value[x], not both extension.exists() != value.exists()
    prr-1 error ServiceRequest orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()

    This structure is derived from ServiceRequest

    Summary

    Mandatory: 1 element
    Must-Support: 15 elements

    Structures

    This structure refers to these other structures:

    Slices

    This structure defines the following Slices:

    • The element 1 is sliced based on the value of ServiceRequest.category

    Maturity: 3

     

    Other representations of profile: CSV, Excel, Schematron

    Notes:

    Quick Start

    Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile's information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

    • See the Scopes Format section for a description of the SMART scopes syntax.
    • See the Search Syntax section for a description of the US Core search syntax.
    • See the General Requirements section for additional rules and expectations when a Server requires status parameters.
    • See the General Guidance section for additional guidance on searching for multiple patients.

    US Core Scopes

    Servers providing access to pmo order data SHALL support these US Core SMART Scopes:

    Mandatory Search Parameters:

    The following search parameters and search parameter combinations SHALL be supported:

    1. SHALL support searching for all servicerequests for a patient using the patient search parameter:

      GET [base]/ServiceRequest?patient={Type/}[id]

      Example:

      1. GET [base]/ServiceRequest?patient=1137192

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient (how to search by reference)

    2. SHALL support both read ServiceRequest by id AND ServiceRequest search using the _id search parameter:

      GET [base]/ServiceRequest/[id] or GET [base]/ServiceRequest?_id=[id]

      Example:

      1. GET [base]/ServiceRequest/1032702
      2. GET [base]/ServiceRequest?_id=1032702

      Implementation Notes: (how to search by the logical id of the resource)

    3. SHALL support searching using the combination of the patient and category search parameters:

      GET [base]/ServiceRequest?patient={Type/}[id]&category={system|}[code]

      Example:

      1. GET [base]/ServiceRequest?patient=f201&category=http://loinc.org|100821-8

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient and a category code (how to search by reference and how to search by token)

    4. SHALL support searching using the combination of the patient and code search parameters:
      • including optional support for OR search on code (e.g.code={system|}[code],{system|}[code],...)

      GET [base]/ServiceRequest?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}

      Example:

      1. GET [base]/ServiceRequest?patient=1032702&code=http://loinc.org|LA33471-6

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient and report code(s). SHOULD support search by multiple report codes. (how to search by reference and how to search by token)

    5. SHALL support searching using the combination of the patient and category and authored search parameters:
      • including support for these authored comparators: gt,lt,ge,le
      • including optional support for AND search on authored (e.g.authored=[date]&authored=[date]]&...)

      GET [base]/ServiceRequest?patient={Type/}[id]&category={system|}[code]&authored={gt|lt|ge|le}[date]{&authored={gt|lt|ge|le}[date]&...}

      Example:

      1. GET [base]/ServiceRequest?patient=f201&category=http://loinc.org|100821-8&date=ge2025-10-01T00:00:00Z

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient and date and a category code (how to search by reference and how to search by token and how to search by date)

    Optional Search Parameters:

    The following search parameter combinations SHOULD be supported:

    1. SHOULD support searching using the combination of the patient and status search parameters:
      • including support for OR search on status (e.g.status={system|}[code],{system|}[code],...)

      GET [base]/ServiceRequest?patient={Type/}[id]&status={system|}[code]{,{system|}[code],...}

      Example:

      1. GET [base]/ServiceRequest?patient=1137192&status=active

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient and status (how to search by reference and how to search by token)

    2. SHOULD support searching using the combination of the patient and code and authored search parameters:
      • including optional support for OR search on code (e.g.code={system|}[code],{system|}[code],...)
      • including support for these authored comparators: gt,lt,ge,le
      • including optional support for AND search on authored (e.g.authored=[date]&authored=[date]]&...)

      GET [base]/ServiceRequest?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}&authored={gt|lt|ge|le}[date]{&authored={gt|lt|ge|le}[date]&...}

      Example:

      1. GET [base]/ServiceRequest?patient=f201&code=http://loinc.org|LA33471-6&date=ge2025-10-14T00:00:00Z

      Implementation Notes: Fetches a bundle of all ServiceRequest resources for the specified patient and date and service code(s). SHOULD support search by multiple report codes. (how to search by reference and how to search by token and how to search by date)