Profile Comparison between http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest vs http://hl7.org/fhir/us/codex-radiation-therapy/StructureDefinition/codexrt-radiotherapy-planned-phase

Messages

Metadata

Name	Value		Comments
abstract	false
baseDefinition	http://hl7.org/fhir/StructureDefinition/ServiceRequest
copyright	Used by permission of HL7 International, all rights reserved Creative Commons License		Removed the item 'Used by permission of HL7 International, all rights reserved Creative Commons License'
date	2022-10-07	2023-07-28T13:07:08+00:00	Values Differ
description	This profile sets minimum expectations for recording, searching, and fetching the ServiceRequest resource to promote interoperability and adoption through common implementation. It identifies which core elements, extensions, vocabularies, and value sets **SHALL** be present in the resource and constrains the way the elements are used when using this profile. It provides the floor for standards development for specific use cases.	A Radiotherapy Planned Phase is the summary over all radiotherapy plans to deliver a single phase of radiotherapy treatment.	Values Differ
experimental
fhirVersion	4.0.1
jurisdiction
jurisdiction[0]	urn:iso:std:iso:3166#US
kind	resource
name	USCoreServiceRequestProfile	RadiotherapyPlannedPhase	Values Differ
publisher	HL7 International - Cross-Group Projects	HL7 Cross Group Projects Work Group	Values Differ
purpose
status	active	draft	Values Differ
title	US Core ServiceRequest Profile	Radiotherapy Planned Phase	Values Differ
type	ServiceRequest
url	http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest	http://hl7.org/fhir/us/codex-radiation-therapy/StructureDefinition/codexrt-radiotherapy-planned-phase	Values Differ
version	6.1.0	1.0.0	Values Differ

Structure

Name	L Flags	L Card.	L Type	L Description & Constraints	R Flags	R Card.	L Type	L Description & Constraints	Comments
ServiceRequest	C	0..*	ServiceRequest	A request for a service to be performed	C	0..*	ServiceRequest	A request for a service to be performed codexrt-motion-management-none: If the respiratory motion management is 'none', then no other respiratory motion management extensions are allowed. They would also be 'none' or contradict the 'none'. SNOMEDCT code 721031000124102 is "Radiotherapy without respiratory motion management (regime/therapy)" codexrt-free-breathing-technique: The extension for the technique of free-breathing motion management is only allowed if motion management is free-breathing. SNOMEDCT code 721071000124104 is "Radiotherapy with free breathing (regime/therapy)"	Elements differ in definition: '\-' vs 'A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.'
id	Σ	0..1	id	Logical id of this artifact	Σ	0..1	id	Logical id of this artifact
meta	Σ	0..1	Meta	Metadata about the resource	Σ	0..1	Meta	Metadata about the resource
implicitRules	?!Σ	0..1	uri	A set of rules under which this content was created	?!Σ	0..1	uri	A set of rules under which this content was created
language		0..1	code	Language of the resource content Binding: ?? (preferred): A human language. Additional Bindings Purpose ?? Max Binding		0..1	code	Language of the resource content Binding: ?? (preferred): A human language. Additional Bindings Purpose ?? Max Binding
text		0..1	Narrative	Text summary of the resource, for human interpretation		0..1	Narrative	Text summary of the resource, for human interpretation
contained		0..*	Resource	Contained, inline Resources		0..*	Resource	Contained, inline Resources
extension		0..*	Extension	Additional content defined by implementations	S	1..*	Extension	Extension Slice: Unordered, Open by value:url	Elements differ in short: 'Additional content defined by implementations' vs 'Extension' Elements differ in definition: 'May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.' vs 'An Extension' Elements differ in definition for mustSupport: 'false' vs 'true' Element minimum cardinalities differ: '0' vs '1'
modifierExtension	?!	0..*	Extension	Extensions that cannot be ignored	?!	0..*	Extension	Extensions that cannot be ignored
identifier	Σ	0..*	Identifier	Identifiers assigned to this order	SΣ	2..*	Identifier	Identifiers assigned to this order Slice: Unordered, Open by value:use	Elements differ in definition: 'Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.' vs 'SHALL have a display name with use = usual and at least one globally unique technical identifier, for example, the Conceptual Volume UID used in DICOM.' Elements differ in definition for mustSupport: 'false' vs 'true' Element minimum cardinalities differ: '0' vs '2'
instantiatesCanonical	Σ	0..*	canonical(ActivityDefinition | PlanDefinition)	Instantiates FHIR protocol or definition	Σ	0..*	canonical(ActivityDefinition | PlanDefinition)	Instantiates FHIR protocol or definition
instantiatesUri	Σ	0..*	uri	Instantiates external protocol or definition	Σ	0..*	uri	Instantiates external protocol or definition
basedOn	Σ	0..*	Reference(CarePlan | ServiceRequest | MedicationRequest)	What request fulfills	Σ	0..*	Reference(CarePlan | ServiceRequest | MedicationRequest)	What request fulfills Slice: Unordered, Open by profile:$this.resolve()
replaces	Σ	0..*	Reference(ServiceRequest)	What request replaces	SΣ	0..*	Reference(Radiotherapy Planned Phase)	Previous retired phase that is replaced by this phase	Elements differ in short: 'What request replaces' vs 'Previous retired phase that is replaced by this phase' Elements differ in definition for mustSupport: 'false' vs 'true'
requisition	Σ	0..1	Identifier	Composite Request ID	Σ	0..1	Identifier	Composite Request ID
status	?!SΣ	1..1	code	(USCDI) draft | active | on-hold | revoked | completed | entered-in-error | unknown Binding: ?? (required): The status of a service order.	?!SΣ	1..1	code	draft | active | on-hold | revoked | completed | entered-in-error | unknown Binding: ?? (required): The status of a service order.	Elements differ in short: '(USCDI) draft | active | on-hold | revoked | completed | entered-in-error | unknown' vs 'draft | active | on-hold | revoked | completed | entered-in-error | unknown'
intent	?!SΣ	1..1	code	(USCDI) proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option Binding: ?? (required): The kind of service request.	?!SΣ	1..1	code	proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option Binding: ?? (required): The kind of service request. Required Pattern: filler-order	Elements differ in short: '(USCDI) proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option' vs 'proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option'
Slices for category	SΣ	0..*	CodeableConcept	(USCDI) Classification of service Slice: Unordered, Open by pattern:$this Binding: ?? (example): Classification of the requested service.	SΣ	1..*	CodeableConcept	Classification of service Slice: Unordered, Open by pattern:$this Binding: ?? (example): Classification of the requested service.	Elements differ in short: '(USCDI) Classification of service' vs 'Classification of service' Element minimum cardinalities differ: '0' vs '1'
priority	Σ	0..1	code	routine | urgent | asap | stat Binding: ?? (required): Identifies the level of importance to be assigned to actioning the request.	Σ	0..1	code	routine | urgent | asap | stat Binding: ?? (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	?!Σ	0..0			Element maximum cardinalities differ: '1' vs '0'
code	SΣ	1..1	CodeableConcept	(USCDI) What is being requested/ordered Binding: ?? (extensible)	SΣ	1..1	CodeableConcept	What is being requested/ordered Binding: ?? (example): Codes for tests or services that can be carried out by a designated individual, organization or healthcare service. For laboratory, LOINC is preferred and a valueset using LOINC Order codes is available here. Required Pattern: {"coding":[{"system":"http://snomed.info/sct","code":"1222565005","display":"Radiotherapy treatment phase (regime/therapy)"}]}	Elements differ in short: '(USCDI) What is being requested/ordered' vs 'What is being requested/ordered'
orderDetail	ΣC	0..*	CodeableConcept	Additional order information Binding: ?? (example): Codified order entry details which are based on order context.	ΣC	0..*	CodeableConcept	Additional order information Binding: ?? (example): Codified order entry details which are based on order context.
quantity[x]	Σ	0..1	Quantity, Ratio, Range	Service amount	Σ	0..0			Element maximum cardinalities differ: '1' vs '0'
subject	SΣ	1..1	Reference(US Core Patient Profile)	(USCDI) Individual or Entity the service is ordered for	SΣ	1..1	Reference(US Core Patient Profile)	Individual or Entity the service is ordered for	Elements differ in short: '(USCDI) Individual or Entity the service is ordered for' vs 'Individual or Entity the service is ordered for'
encounter	Σ	0..1	Reference(Encounter)	Encounter in which the request was created	Σ	0..1	Reference(Encounter)	Encounter in which the request was created
occurrence[x]	SΣ	0..1	Period S, dateTime, Timing	(USCDI) When service should occur	Σ	0..1	dateTime, Period, Timing	When service should occur	Elements differ in short: '(USCDI) When service should occur' vs 'When service should occur' Elements differ in definition for mustSupport: 'true' vs 'false'
asNeeded[x]	Σ	0..1	boolean, CodeableConcept	Preconditions for service Binding: ?? (example): A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.	Σ	0..0			Element maximum cardinalities differ: '1' vs '0'
authoredOn	SΣ	0..1	dateTime	(USCDI) Date request signed	Σ	0..1	dateTime	Date request signed	Elements differ in short: '(USCDI) Date request signed' vs 'Date request signed' Elements differ in definition for mustSupport: 'true' vs 'false'
requester	SΣ	0..1	Reference(US Core Practitioner Profile S | US Core Organization Profile | US Core Patient Profile | PractitionerRole | US Core RelatedPerson Profile | Device)	(USCDI) Who/what is requesting service	Σ	0..1	Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile)	Who/what is requesting service	Elements differ in short: '(USCDI) Who/what is requesting service' vs 'Who/what is requesting service' Elements differ in definition for mustSupport: 'true' vs 'false'
performerType	Σ	0..1	CodeableConcept	Performer role Binding: ?? (example): Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.	Σ	0..1	CodeableConcept	Performer role Binding: ?? (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	SΣ	0..*	Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)	Requested performer Slice: Unordered, Open by profile:$this.resolve()	Elements differ in definition for mustSupport: 'false' vs 'true'
locationCode	Σ	0..*	CodeableConcept	Requested location Binding: ?? (example): A location type where services are delivered.	Σ	0..*	CodeableConcept	Requested location Binding: ?? (example): A location type where services are delivered.
locationReference	Σ	0..*	Reference(Location)	Requested location	SΣ	0..*	Reference(US Core Location Profile)	Requested location	Elements differ in definition for mustSupport: 'false' vs 'true'
reasonCode	Σ	0..*	CodeableConcept	(USCDI) Explanation/Justification for procedure or service Binding: ?? (extensible)	SΣ	0..*	CodeableConcept	Explanation/Justification for procedure or service Binding: ?? (extensible)	Elements differ in short: '(USCDI) Explanation/Justification for procedure or service' vs 'Explanation/Justification for procedure or service' Elements differ in definition for mustSupport: 'false' vs 'true'
reasonReference	Σ	0..*	Reference(Condition | Observation | DiagnosticReport | DocumentReference)	(USCDI) US Core Profile that supports the requested service	SΣ	0..*	Reference(Condition)	Explanation/Justification for service or service	Elements differ in short: '(USCDI) US Core Profile that supports the requested service' vs 'Explanation/Justification for service or service' Elements differ in definition for mustSupport: 'false' vs 'true'
insurance		0..*	Reference(Coverage | ClaimResponse)	Associated insurance coverage		0..*	Reference(Coverage | ClaimResponse)	Associated insurance coverage
supportingInfo		0..*	Reference(Resource)	Additional clinical information		0..*	Reference(Resource)	Additional clinical information
specimen	Σ	0..*	Reference(Specimen)	Procedure Samples	Σ	0..0			Element maximum cardinalities differ: '2147483647' vs '0'
bodySite	Σ	0..*	CodeableConcept	Location on Body Binding: ?? (example): Codes describing anatomical locations. May include laterality.	SΣ	0..*	CodeableConcept	Body site that is treated with radiotherapy Binding: ?? (required)	Elements differ in short: 'Location on Body' vs 'Body site that is treated with radiotherapy' Elements differ in definition for mustSupport: 'false' vs 'true'
id		0..1	string	Unique id for inter-element referencing		0..1	string	Unique id for inter-element referencing
Slices for extension		0..*	Extension	Additional content defined by implementations Slice: Unordered, Open by value:url		0..*	Extension	Additional content defined by implementations Slice: Unordered, Open by value:url
coding	Σ	0..*	Coding	Code defined by a terminology system	Σ	0..*	Coding	Code defined by a terminology system
text	Σ	0..1	string	Plain text representation of the concept	Σ	0..1	string	Plain text representation of the concept
note		0..*	Annotation	Comments		0..*	Annotation	Comments
patientInstruction	Σ	0..1	string	Patient or consumer-oriented instructions	Σ	0..1	string	Patient or consumer-oriented instructions
relevantHistory		0..*	Reference(Provenance)	Request provenance		0..*	Reference(Provenance)	Request provenance
Documentation for this format