<style>.markdown-body { max-width: 1500px; }</style>

<!-- Portable Medical Order -->

## Portable Medical Order: Proposed <span style="font-size:3em;width:100%;text-align:center;">:new:</span> US Core PMO ServiceRequest Profile
<!-- image of summary of changes-->

<!-- Draft -->



<!-- markdown table summary of proposal use adobe to convert to excel and then script to markdown or just copy/paste -->

DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)<br/>Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. Where an applicable vocabulary standard has not been identified, this field will remain empty.|US Core V8 Proposal
---|---|---
**Portable Medical Order**<br/>Provider-authored request for end-of-life or life-sustaining care for a person who has a serious life-limiting medical condition.<br/><br/>Usage note: These are meant to follow a person regardless of when and where such an order might be needed (e.g., hospital, care facility, community, home). There are variations in requirements and names for portable medical orders based on jurisdiction.<br/><br/>Examples include, but are not limited to, POLST (Portable Medical Order for Life-Sustaining Treatment), MOLST (Medical Orders for Life-Sustaining Treatment), and out-of-hospital DNR (do-not-resuscitate).|| <span style="font-size:3em;width:100%;text-align:center;">:new:</span> US Core PMO ServiceRequest Profile

### CCDA Design Notes

[Orders v6](https://confluence.hl7.org/spaces/SD/pages/358884590/Orders+v6)

### Known issues

1. The [USCDI submission](https://www.healthit.gov/isp/taxonomy/term/3626/draft-uscdi-v6#uscdi-proposal-mode-uscdi-data-element-page-display) discusses using "service request" within an EHR and for ECQ reporting. For additional specifications they refer to [QI-Core](http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-servicerequest.html), US Core's Future's page ?? and the [QM Guides Library](http://hl7.org/fhir/us/cqfmeasures/Library-Hospice.html) Based upon this submission, ther is no difference using US Core ServiceRequests for these order than for other procedures in FHIR and the USCDI Procedure Order Data Element.
2. PACIO commenters state that:

- They are in essence orders that are written without a known final destination when they come into effect.
- They do not expire when a patient is discharged from a facility
- and they do not need to be rewritten by a receiving clinician to remain actionable.

:::warning
:thinking_face: What exactly is being requested?
- a PMO* document?
- Specific procedures defined in the source PMO (for example, a DNR in A POLST) ... a PMO could cover many procedures so would there be many ServiceRequest orders generated for a single POLST? For example, see the [National Polst Model Form](https://polst.org/wp-content/uploads/2021/03/2020.05.11-National-POLST-Form-with-Instructions-r2.pdf)

digraph POLST_to_ServiceRequests {
  graph [rankdir=LR];  // Layout from left to right for clarity
  node [shape=box, style=filled, fillcolor=lightblue, fontname="Arial"];
  edge [arrowhead=normal];

  POLST [label="POLST Document\n(1)"];

  SR1 [label="FHIR ServiceRequest\n(e.g., CPR Order)"];
  SR2 [label="FHIR ServiceRequest\n(e.g., Antibiotics Order)"];
  SR3 [label="FHIR ServiceRequest\n(e.g., Nutrition Order)"];
  SR_more [label="... (more as needed)"];

  POLST -> SR1;
  POLST -> SR2;
  POLST -> SR3;
  POLST -> SR_more [style=dashed label="1 to many"];

  {rank=same; SR1 SR2 SR3 SR_more}  // Align ServiceRequests horizontally
}

**Assumption**: An PMO order "follow[s] a person regardless of when and where such an order might be needed" *only* in the context of a PMO Document, otherwise its lifecycle is like any other clinical order.

\* The term "Portable Medical Order" commonly means a POLST (Physician Orders for Life-Sustaining Treatment) form and these are typically clinical Documents (e.g., a paper document or a PDF) There are no other specific formats mandated beyond these (see PRIOR ART below).
:::

### PRIOR ART

1. C-CDA: [HL7 CDA® R2 Implementation Guide: ePOLST: Portable Medical Orders About Resuscitation and Initial Treatment, Release 1 - US Realm](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7)

1. [PACIO Advance Directive Interoperability Implementation Guide](https://build.fhir.org/ig/HL7/fhir-pacio-adi/index.html)

- The Portable Medical Order ServiceRequest Profiles are designed to be in the context of a FHIR Document:

This figure represent a FHIR document and the dark green column on the right represents the PMO order


- [ADI PMO ServiceRequest](https://build.fhir.org/ig/HL7/fhir-pacio-adi/StructureDefinition-ADI-PMOServiceRequest.html)

### Proposal

1. :+1: **New US Core PMO ServiceRequest Profile**

**Basic Outline:**

Summary: Idea is a ServiceRequest that references a scanned PMO. From this can create service requests for DNR, Full/ Selective/Comfort-focused Treatment, etc

- USCore ServiceRequest with these additional constraints:
- To allow for the resource life cycle, no constraint on intent, use "directive" in PMO document'
- category - (code starter set: National POLST Form: A Portable Medical Order panel [100821-8](https://forms.loinc.org/100821-8))
- code = codes ( code starter answers to National POLST Form: A Portable Medical Order panel and Pacio valueSets )
- code.text since most answers to the panel are free-text
- orderdetail =  to support additional detals that are likely textual so MS/add'l USCDI on .text
- reasonReference - [US Core ADI DocumentReference Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-adi-documentreference.html) linking to a scanned POLST,MOLST, etc

- :point_right: [Draft Profile](https://healthedata1.github.io/test-stuff/StructureDefinition-us-core-pmo-servicerequest.html) :point_left:
- :point_right: [Example DNR Order](https://healthedata1.github.io/test-stuff/ServiceRequest-example-pmo-servicerequest.html) :point_left:

Pros:
- Satisfies the USCDI intent for an instantiated order based on a PMO document
- Reference to scanned document indirectly satifies the literal interpretation of USCDI definition i.e.,"follow a person regardless of when and where such an order might be needed"
- Fit for purpose Order to support current needs
- Assume most most of these PMO documents are shared through scanned images housed in EMRs, EHRs and other systems.
- Assume these Orders are not in the the context of a Document, but make sure they could be and align within Pacio's framework as part of a PMO FHIR document.

Cons:

- new profile

### Other Options

1. **Updated guidance in existing US Core ADI Observation and US Core ADI DocumentReference Profiles**

For example:
>Use the US Core ADI Observation and US Core ADI DocumentReference* to reference PMO orders such as a scan of a POLST form. See the [PACIO ADI](https://build.fhir.org/ig/HL7/fhir-pacio-adi/artifact_resource_type.html#servicerequest) guide for further guidance on using FHIR-based PMO.

Pros:
- Satifies literal interpretation of USCDI definition i.e.,"follow a person regardless of when and where such an order might be needed"
- No new profiles

Cons:
- Does not Satisfy the USCDI intent for an instantiated order based on a PMO document (See rest of options to address this)

\* Docref is underspecified [FHIR-52273 - Update profile to support attestors for ADI use cases](https://jira.hl7.org/browse/FHIR-52273)

1. **Additions/Modifications to the US Core ServiceRequest Profile**

- a category to "tag" the ServiceRequest as a PMO
- additional bindings on `code`
- a reference to DocumentReference (e.g., POLST) -> `.reasonReference`

Pros:
- Satisfies the USCDI intent for an instantiated order based on a PMO document
- No new profiles

Cons:
- Does not Satify the literal interpretation of USCDI definition i.e.,"follow a person regardless of when and where such an order might be needed"

1. 1. and 2.

Pros:
- Satisfies both the literal interpretation of USCDI definition i.e.,"follow a person regardless of when and where such an order might be needed" and the USCDI intent for an instantiated order based on a PMO document
- No new profiles

### Decisions

Based on the Argonaut design calls ( see [Summary of Design Decisions](/u8iAyzZ0SGahQdbVzYpfoQ)) and subsequent Sept 2025 WGM discussion:
- [Sept 2025 WGM Slides](https://confluence.hl7.org/download/attachments/358885005/USCDI%20v6%20Design%20for%20US%20Core%20and%20C-CDA.pptx?version=1&modificationDate=1759008895006&api=v2)
- [Wed Q4 WGM Minutes](https://confluence.hl7.org/spaces/CGP/pages/358284575/Cross+Group+Project+2025+September+-+Wed+Q4)
- [Thur Q2 WGM Minutes](https://confluence.hl7.org/spaces/CGP/pages/358285044/Cross+Group+Projects+-+2025+September+-+Thursday+Q2)

1. Add new PMO ServiceRequest Profile

1. Add NOTE TO BALLOTERS summarizing concerns and explicitly requesting comment on certification implications and get more feedback from commenters

1. Add guidance to the ADI DocumentReference Reference Profile

### IG Updates

- [x] USCDI Mapping Table
- [ ] Create Profile
- [ ] create all addl bindings
- [ ] Add codes to VSAC
- [X] Create Intro page
- [X] Create Notes page (review search examples - and update manually for now)
- [ ] update to liquid later
- [ ] Update CapabilityStatement
- [ ] Update Scopes page
- [ ] Update Provenance Profile pages
- [ ] Update IPA/IPS page
- [x] add Implementation Specific Guidance to ADI Doc Ref
- [ ] New Example(s)

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

for the The [US Core ADI DocumentReference Profile](#) add this bullet

> - The US Core ADI DocumentReference Profile can communicate the contents of a Plan of Medical Orders (PMO) document, such as POLST, MOLST, or other state-specific forms. It is referenced by the [US Core PMO Service Request Profile](#), which represents an order based on the PMO document. PMO documents, typically stored as scanned images in EMRs/EHRs, follow the patient across care settings. Together, these profiles satisfy the USCDI's PMO Order Data Element's intent to represent orders based on an individual's PMO.

for the PMO Serveice request add these bullets

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

- [x] Add STU Note

> NOTE TO BALLOTERS: The decision to add the US Core PMO Service Request Profile and to meet the the USCDI's PMO Order Data Element definition spurred a healthy debate on whether `ServiceRequest` is needed for actionable orders or if `DocumentReference` suffices 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 ordevia 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 is 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 on the clinical utility of this profile and its implications for certification.

- [ ] New Example(s)
- [ ] Update target references to it
- [ ] Update Add'l USCDI table
- [ ] Update MS Reference table

---