This page is part of the US Patient Care Summary (US-PCS) Implementation Guide (v1.0.0: STU 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

General Guidance

Page standards status: Trial-use

Highlight text changes?

The US-PCS Bundle and Composition profiles derive from guidance in FHIR Clinical Documents (1.1.0) and apply additional constraints relevant to the United States. These include header information in the US-PCS Composition and the use of US Core clinical profiles when available. The US-PCS conforms to the International Patient Summary (IPS) Implementation Guide (2.0.1) by using the same document code and sections as defined in the IPS. In addition, when a US Core profile is not available within a specific section, references to IPS clinical profiles are retained. Variances between US-PCS and IPS are documented in the "US Variance to IPS" portion of this guide.

Figure 3: US-PCS Relationships to Other Guides

US Core Versioning

The US-PCS uses clinical profiles from US Core version 6.1.0 that SHALL be the minimal version of US Core resource to send in the US-PCS.^§guidance-1 These profiles are required through US Core Data for Interoperability (USCDI) in 2026 and are generally available by most US health information technology vendors and organizations. While possible to package resources from earlier US Core versions and remain conformant to the IPS specification, implementers SHALL NOT declare conformance to US-PCS when using US Core versions before 6.1.0.^§guidance-2 In the event that resources conformant to a newer version of US Core are available, this guide recommends that implementers SHOULD send more recent versions.^§guidance-3 For example, a US-PCS document creator can include more recent versions such as US Core 9.0.0 and still conform to this guide.

The US Core profiles referenced by US-PCS have demonstrated a high degree of stability across successive US Core releases, with most changes consisting of clarifications, terminology updates, or incremental enhancements rather than incompatible structural changes. As a result, resources conformant to newer US Core versions can generally be understood and processed in the context of US-PCS. Furthermore, because US-PCS is a document-based exchange specification that requires human-readable narrative in Composition.section, receivers can interpret clinical content from the narrative representation when automated processing of a specific FHIR resource is not supported. Implementers SHOULD avoid mixing multiple US Core versions within data produced by a single EHR or source system whenever possible.^§guidance-4 However, receivers and intermediaries that aggregate data from multiple FHIR API endpoints may encounter and exchange resources conforming to different US Core versions, and such aggregation is permitted provided the resulting content remains clinically understandable and otherwise conforms to the requirements of this guide.

Regardless of US Core version used, systems are not required to send any items in conflict with any applicable laws and regulations, which may vary by jurisdiction and over time.¹ The "US Variance to IPS" portion of this guide compares the clinical profile from US Core 6.1.0 to the IPS 2.0.1 profiles, and consideration of IPS alignment is recommended when sending different US Core versions.

Aligning US-PCS Sections with IPS, C-CDA and US Core

The US-PCS profiles 6 sections to align with the sections in the IPS Implementation Guide and adds a section on encounters not profiled in IPS 2.0.1. The US-PCS, like the IPS and C-CDA documents, remains open at the section level, which means that additional sections can be added so long as they have different Composition.section.code coding. Like the IPS, the US-PCS only requires a summary to have the three sections of Problems, Allergies and Medications. This enables systems to create concise summaries while allowing additional sections to be included when clinically relevant. For more guidance about what content can be included in IPS-aligned US-PCS sections, we refer readers to Data Inclusion in Summary Documents and IPS Guidance.

The Consolidated Clinical Document Architecture (C-CDA) is a library of clinical documents in wide usage in the United States. The US-PCS is not intended to replace any of these documents. A comparison of Continuity of Care Document (CCD) sections (from C-CDA 2.1) to IPS sections (from FHIR IPS 2.0.1) and US-PCS sections is shown below with guidance about US Core profiles appropriate for each section.

The following table includes a row for each section referenced in US-PCS, IPS or CCD. Each includes:

1. The Section Name and corresponding LOINC code
2. The CCD Conformance which lists the conformance strength of that section as defined in C-CDA 2.1 CCD
3. The IPS Recommendation which lists the strength of the section as defined in the IPS Structure
4. The US-PCS Guidance which is the profiling specified in the US-PCS Composition
5. Relevant US Core Resources (when available) for inclusion in each respective section

Section Name (LOINC)	CCD Conformance	IPS Recommendation	US-PCS Guidance ▼	US Core Resources
Allergies (48765-2)	SHALL2	Required	Required	US Core AllergyIntolerance Profile
Medications (10160-0)	SHALL2	Required	Required	US Core MedicationRequest Profile
Problems (11450-4)	SHALL2	Required	Required	US Core Condition Problems and Health Concerns Profile
Encounters (46240-8)	MAY2	Not profiled in IPS	Must Support	US Core Encounter Profile
Immunizations (11369-6)	MAY2	Recommended	Must Support	US Core Immunization Profile
Procedures (47519-4)	SHOULD2	Recommended	Must Support	US Core Procedure Profile
Results (30954-2)	SHALL2	Recommended	Must Support	US Core Laboratory Result Observation Profile US Core Observation Clinical Result Profile US Core DiagnosticReport Profile for Laboratory Results Reporting US Core DiagnosticReport Profile for Report and Note Exchange
Advance Directives (42348-3)	MAY2	Optional	Not profiled in US-PCS	Not profiled in US Core 6.1.0. See US Core 9.0.0 Observation ADI Documentation and ADI DocumentReference profiles
Alerts (104605-1)	Not profiled in CCD	Optional	Not profiled in US-PCS	Not profiled in US Core 6.1.0
Care Plan (18776-5)	SHOULD2	Optional	Not profiled in US-PCS	US Core CarePlan Profile
Family History (10157-6)	MAY2	Not profiled in IPS	Not profiled in US-PCS	Not profiled in US Core 6.1.0
Functional Status (47420-5)	MAY2	Optional	Not profiled in US-PCS	US Core Condition Problems and Health Concerns Profile Other profiles do not match IPS expected resources (Observation, QuestionnaireResponse)
History of Past Problems (11348-0)	Not profiled in CCD	Optional	Not profiled in US-PCS	US Core Condition Problems and Health Concerns Profile
Medical Devices (46264-8)	MAY2	Recommended	Not profiled in US-PCS	Device Use Statement not profiled in 6.1.0 US Core Implantable Device Profile
Mental Status (10190-7)	MAY2	Not profiled in IPS	Not profiled in US-PCS	US Core Simple Observation Profile US Core Condition Problems and Health Concerns Profile US Core Observation Screening Assessment Profile US Core QuestionnaireResponse Profile
Nutrition (61144-2)	MAY2	Not profiled in IPS	Not profiled in US-PCS	Not profiled in US Core 6.1.0
Patient Story (81338-6)	Not profiled in CCD	Optional	Not profiled in US-PCS	Any resource permitted
Payers (48768-6)	MAY2	Not profiled in IPS	Not profiled in US-PCS	US Core Coverage Profile
Pregnancy (10162-6)	Not profiled in CCD	Optional	Not profiled in US-PCS	US Core Observation Pregnancy Status Profile US Core Observation Pregnancy Intent Profile
Social History (29762-2)	SHALL2	Optional	Not profiled in US-PCS	US Core Smoking Status Observation Profile US Core Simple Observation Profile US Core Observation Occupation Profile US Core Observation Sexual Orientation Profile
Vital Signs (8716-3)	SHALL2	Optional	Not profiled in US-PCS	US Core Blood Pressure Profile US Core Body Height Profile US Core Body Weight Profile US Core Heart Rate Profile US Core Respiratory Rate Profile US Core Body Temperature Profile US Core Pulse Oximetry Profile US Core Pediatric BMI for Age Observation Profile Pediatric Weight for Height Observation US Core Pediatric Head Occipital Frontal Circumference Percentile Profile

Entries within US-PCS Sections

For each US-PCS section, entry slicing is not limited to US Core profiles. In addition to the US Core profiles identified for a given section (see table above), other profiles based on the same FHIR resource type and/or DocumentReference resources MAY be included as section entries.^§entries-1 This flexibility allows clinically relevant content to be exchanged when it cannot be represented using the preferred US Core profile or when the information is available only as a document rather than as discrete FHIR data.

This approach is consistent with the design of the International Patient Summary (IPS) Composition profile, which uses open slicing for section entries and explicitly permits DocumentReference as an allowed entry type alongside section-specific structured resources. Accordingly, DocumentReference provides a mechanism for exchanging document-based clinical content while preserving the clinical intent of the section. While no content constraints (e.g., reference to a full document or a PDF of section information) are made on the referenced DocumentReference, these resources SHOULD be linked from the section where most applicable.^§entries-2 This approach promotes alignment with IPS and supports progressive interoperability across diverse systems.

In addition, as specified in the FHIR Composition profile and the FHIR Clinical Documents Bundle profile, all resources referenced directly from Composition.section.entry must be included in the Bundle. While secondary and tertiary references may be included in the Bundle when clinically relevant, often these data will be omitted. For example, the encounters sections is intended to include relevant visit history without having to include all associated clinical data with each encounter. Referencing encounters allows additional data to be found and more readily requested as explained in the US-PCS use case. See guidance on Additional Sections and Data in US-PCS for further guidance.

Summary Creation

Operations for US-PCS Generation

• US-PCS Document Creators SHALL be able to generate US-PCS documents using the $summary operation from IPS .^§guidance-5

IPS outlines two different methods available for summary generation. These include 1) a $summary operation defined in the IPS guide, and 2) a $docref operation defined in both US Core and International Patient Access (IPA) 1.1. Although servers can support $docref for US-PCS retrieval, requiring document creators to support the IPS $summary operation ensures a common method will be available for all implementers.

For additional guidance on what data to include in a US-PCS, please refer to below, the definitions of Must Support in US-PCS as well as US-PCS use cases.

Data Inclusion in Summary Documents

The IPS international guides, both ISO 27269 and FHIR IPS Implementation Guide, do not provide detailed rules for generating a patient summary. The use case for US-PCS remains aligned with these global guides with its intent to provide a minimal, non-exhaustive summary that supports clinical decision-making at the point of care for both planned and unplanned care across organizational boundaries. The data relevant for clinical decision making will not always be the same and is subject to clinical judgment. Nevertheless, implementers have requested best practices for summary generation acknowledging many data are not relevant for patient care summaries. For the required and Must Support sections of the US-PCS, the following recommendations are provided for implementer consideration, particularly when automated summary generation is employed. When a human authors a clinical summary, information relevant for care will diverge from the guidelines below. Implementers are not required to implement these recommendations and may apply their own logic for content recency and relevancy.

We seek continued implementer feedback on these recommendations. The content of this section is not definitive guidance and subject to change based on further feedback and implementation experience.

Required Sections

Section	Recommended Inclusion Criteria	Recommended Exclusion Criteria
Problems	Condition.clinicalStatus of active, recurrence, relapse, or remission. (Inactive or resolved problems can be included when clinically relevant.)	Condition.verificationStatus of entered-in-error
Allergies	AllergyIntolerance.clinicalStatus of active. (Inactive or resolved allergies can be included when clinically relevant.)	AllergyIntolerance.verificationStatus of entered-in-error
Medications	MedicationRequest.status of active and MedicationRequest.intent of order or plan. (Refer to US Core Guidance for active medication lists.)	MedicationRequest.doNotPerform if true

Must Support Sections

Section	Recommended Inclusion Criteria	Recommended Exclusion Criteria
Encounters	Encounters in past 18 months	Encounter.status of cancelled or entered-in-error
Immunizations	Short-term immunity (e.g., flu, COVID) if occurrenceDateTime is in the past 24 months. All other immunizations administered in lifetime of patient.	Immunization.status of entered-in-error
Procedures	Major procedures (e.g., bypass, bowel resection, implants, mastectomy, organ transplant) in lifetime of patient. All other procedures (past 90 days).	Procedure.status of entered-in-error or not-done
Results	DiagnosticReport and corresponding result observations (past 90 days). Observation.category of laboratory and imaging (past 90 days). Abnormal clinical results when currently relevant from anytime in past.	DiagnosticReport.status or Observation.status of entered-in-error or cancelled

Implementers can include additional sections as well when relevant to the US-PCS use case, although no specific content recommendations are provided for optional or additional sections.

Open Slicing, Additional Sections and Data in US-PCS

Consistent with the IPS goal of being both "minimal and non-exhaustive" and "specialty-agnostic and condition-independent," US-PCS begins with a constrained set of sections and data elements that are expected to be relevant for most exchanges. At the same time, the open-section design allows additional sections and content to be included when they are clinically relevant and appropriate for a specific use case. This design conforms with IPS.

When including sections that are not profiled in this guide:

1. Document Creators SHOULD include the logic for the inclusion, within each Composition.section using the section-note extension.^§guidance-6
2. Document Creators SHALL include only the sections, data elements, and resources needed to create a concise, clinically relevant patient summary.^§guidance-7
   • This guide does not provide a computable definition of clinical relevance, as relevance varies by care setting, exchange purpose, and use case. Whether additional sections are included depends on the purpose of the exchange, the clinician's judgment, and the patient's preferences.
3. Document Creators SHOULD use the guidance and LOINC codes for content corresponding to an existing section definition in the Aligning US-PCS Sections table above.^§guidance-8
   • For example, to define a section for Payers, use the LOINC code 48768-6 (Payment sources Document) and US Core Coverage Profile documented in the table's "Payers" row.

Authorship and Provenance in US-PCS

The author and custodian of a US-PCS document are required in US-PCS as detailed in the US-PCS Composition profile. While not required in US-PCS, more information is often appropriate at a granular level, often through the use of US Core Provenance resources. This guide recommends implementers review Basic Provenance from the US Core Implementation Guide for further guidance.

Must Support Definition

The US-PCS inherits Must Support flags from FHIR Clinical Documents and assigns additional Must Support in the profiles. The US-PCS definition of Must Support is aligned with the FHIR US Core definition with adaptations to a document context:

The Profile elements may be defined as Mandatory or Must Support. The sections below define the document creator and consumer expectations for processing these elements and illustrates how they are displayed and documented.

Mandatory Elements

Mandatory elements are elements with a minimum cardinality of 1 (min=1). When an element is Mandatory, the data is expected to always be present. Very rarely when unavailable, guidance for missing data is provided in Missing Data.

Must Support Elements

For generating a US-PCS, Must Support on any profile data element is to be interpreted as follows:

• US-PCS Document Creators SHALL be capable of populating all data elements as part of the document creation.^§guidance-9
• US-PCS Document Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.^{§guidance-10} For example, processing may range from choosing to display the text for human use or incorporate and store individual resources and data. Any level of processing chosen cannot cause the application to fail.
• When information on a particular data element is not present, and the reason for its absence is unknown, US Core Responders:
  • SHALL populate mandatory elements (minimum cardinality > 0) according to the methodology in the Missing Data section.^{§guidance-11}
  • SHALL NOT include elements with a minimum cardinality of 0 (including elements labeled Must Support) in the resource instance returned as part of the query results.^{§guidance-12}
• When information on a specific data element is missing, and the precise reason for the absence of data is known, US Core Responders SHOULD send the reason for the missing information.^{§guidance-13} This is done by following the methodology in the Missing Data section, but using the appropriate reason code instead of unknown. For suppressed data, refer to the Suppressed Data guidance.
• When querying US Core Responders, US Core Requestors:
  • SHALL interpret missing data elements within resource instances as data not present in the US Core Responder's system.^{§guidance-14}
  • SHALL be able to process resource instances containing data elements asserting missing information.^{§guidance-15}

Comparing Must Support between US-Core, IPS and US-PCS

As noted, the Must Support definition in US-PCS is aligned with US Core and is not the same as IPS definition of Must Support. The following table highlights major differences between US Core, IPS and US-PCS Must Support definitions:

	US Core Definition	IPS Definition	US-PCS Definition
Actors in Must Support	Only defined as part of Must Support definition: - Responders - Requestors	Defined with Actor profiles and Obligations: - Document Creator and Document Server - Document Consumer	Only defined as part of Must Support definition: - Document Creator - Document Consumer
Must Support Scope & Definitions	Does not use obligations, so flags universally mean: - SHALL be capable of populating3 - SHALL process3 - SHALL populate mandatory elements3 - SHALL NOT send missing data with 0.. cardinality3 - SHALL interpret missing data as not present3 - SHOULD send missing reason when known3 - SHALL process missing information assertions3	Must Support defined by use of obligations. Obligations vary strength and by element including: - SHALL:able-to-populate3 - SHALL:populate-if-known3 - SHOULD:populate-if-known3 - SHALL:handle3 - SHOULD:display3	Meant to mirror US Core with "Document Creators" instead of "Responders" and "Document Consumers" rather than "Requestors"
Source of Full Guidance	https://hl7.org/fhir/us/core/must-support.html	https://hl7.org/fhir/uv/ips/STU2/Must-Support-and-Obligations.html	Defined above in this guide

Conformance

Id	Expectation	Rule
	SHALL  SHALL NOT  SHOULD  MAY  SHOULD NOT
§bund-1	SHALL	All entries in the Bundle SHALL include a fullUrl, and a resource.
§bund-2	SHALL NOT	All entries in the Bundle SHALL NOT include: any Composition resource other than the first, a search attribute, a request attribute, or a response attribute.
§comp-1	SHALL	Each section SHALL include: a title, a code, a textual narrative of the data in the section (See IPS guide on Narrative).
§comp-2	SHALL	The corresponding US Core Implementation Guide resource SHALL be sent in a given section when available. For example, when sending a plan of care section (LOINC: 18776-5), US Core CarePlan Profile resources will be used when available. A list of sections with corresponding US Core resources are included in the Aligning US-PCS Sections with IPS, C-CDA and US Core table in this guide
§comp-3	SHALL	Each section SHALL contain a unique code to identify that section. For example, it would not be appropriate to send two separate Advance Directives sections (LOINC: 42348-3). This is enforced through the discriminator profiling on section.code
§entries-1	MAY	In addition to the US Core profiles identified for a given section (see table above), other profiles based on the same FHIR resource type and/or DocumentReference resources MAY be included as section entries.
§entries-2	SHOULD	While no content constraints (e.g., reference to a full document or a PDF of section information) are made on the referenced DocumentReference, these resources SHOULD be linked from the section where most applicable.
§guidance-1	SHALL	The US-PCS uses clinical profiles from US Core version 6.1.0 that SHALL be the minimal version of US Core resource to send in the US-PCS.
§guidance-2	SHALL NOT	While possible to package resources from earlier US Core versions and remain conformant to the IPS specification, implementers SHALL NOT declare conformance to US-PCS when using US Core versions before 6.1.0.
§guidance-3	SHOULD	In the event that resources conformant to a newer version of US Core are available, this guide recommends that implementers SHOULD send more recent versions.
§guidance-4	SHOULD	Implementers SHOULD avoid mixing multiple US Core versions within data produced by a single EHR or source system whenever possible.
§guidance-5	SHALL	US-PCS Document Creators SHALL be able to generate US-PCS documents using the $summary operation from IPS .
§guidance-6	SHOULD	Document Creators SHOULD include the logic for the inclusion, within each Composition.section using the section-note extension.
§guidance-7	SHALL	Document Creators SHALL include only the sections, data elements, and resources needed to create a concise, clinically relevant patient summary.
§guidance-8	SHOULD	Document Creators SHOULD use the guidance and LOINC codes for content corresponding to an existing section definition in the Aligning US-PCS Sections table above.
§guidance-9	SHALL	US-PCS Document Creators SHALL be capable of populating all data elements as part of the document creation.
§guidance-10	SHALL	US-PCS Document Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
§guidance-11	SHALL	SHALL populate mandatory elements (minimum cardinality > 0) according to the methodology in the Missing Data section.
§guidance-12	SHALL NOT	SHALL NOT include elements with a minimum cardinality of 0 (including elements labeled Must Support) in the resource instance returned as part of the query results.
§guidance-13	SHOULD	When information on a specific data element is missing, and the precise reason for the absence of data is known, US Core Responders SHOULD send the reason for the missing information.
§guidance-14	SHALL	SHALL interpret missing data elements within resource instances as data not present in the US Core Responder's system.
§guidance-15	SHALL	SHALL be able to process resource instances containing data elements asserting missing information.
§ip-1	SHALL	Implementers and testers of this specification SHALL abide by the license requirements for each terminology content artifact utilized within a functioning implementation.
§ip-2	SHALL	Terminology licenses SHALL be obtained from the Third Party IP owner for each code system and/or other specified artifact used.
§terminology-1	SHOULD NOT SHOULD	While mapping to IPS-preferred terms remains optional for US-PCS implementers, document creators SHOULD reference published mapping resources and SHOULD NOT create custom maps to IPS concepts whenever possible.
§terminology-2	SHOULD	Document creators SHOULD retain US codes and concepts when adding international concepts.