Profile Comparison between http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest vs http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ServiceRequest

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-27T20:42:33+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.	Profile for service requests that address Social Determinants of Health.	Values Differ
experimental
fhirVersion	4.0.1
jurisdiction
jurisdiction[0]	urn:iso:std:iso:3166#US
kind	resource
name	USCoreServiceRequestProfile	SDOHCCServiceRequest	Values Differ
publisher	HL7 International - Cross-Group Projects	HL7 International Patient Care WG	Values Differ
purpose
status	active	draft	Values Differ
title	US Core ServiceRequest Profile	SDOHCC ServiceRequest	Values Differ
type	ServiceRequest
url	http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest	http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ServiceRequest	Values Differ
version	6.1.0	2.1.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 address an SDOH condition, observation or goal.	Elements differ in short: 'A request for a service to be performed' vs 'A request for a service to address an SDOH condition, observation or goal.' Elements differ in definition: '\-' vs 'For service requests that address SDOH conditions, observations or goals.' Elements differ in comments: '\-' vs 'Many of the SDOHCC profiles reference one another. One flow supported by this IG is that QuestionnaireResponses result in Observations that can be used as evidence for Conditions that can lead to Goals, ServiceRequests and Procedures. However, alternatives paths are also possible.'
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		0..*	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'
modifierExtension	?!	0..*	Extension	Extensions that cannot be ignored	?!	0..*	Extension	Extensions that cannot be ignored
identifier	Σ	0..*	Identifier	Identifiers assigned to this order	Σ	0..*	Identifier	Identifiers assigned to this order
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)	What request fulfills Slice: Unordered, Open by profile:resolve()
replaces	Σ	0..*	Reference(ServiceRequest)	What request replaces	Σ	0..*	Reference(ServiceRequest)	What request replaces
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' Elements differ in comments: 'The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, competed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding event (see [Event Pattern] for general discussion) or using the [Task] resource.' vs 'The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, competed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding event (see [Event Pattern] for general discussion) or using the [Task] resource. While all values are currently allowed, there may be a constraint on the values in future releases based on implementation feedback.'
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.	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' Elements differ in comments: 'This element is labeled as a modifier because the intent alters when and how the resource is actually applicable.' vs 'This element is labeled as a modifier because the intent alters when and how the resource is actually applicable. While all values are currently allowed, there may be a contraint on the values in future releases based on implementation feedback.'
Slices for category	SΣ	0..*	CodeableConcept	(USCDI) Classification of service Slice: Unordered, Open by pattern:$this Binding: ?? (example): Classification of the requested service.	Σ	0..*	CodeableConcept	Classification of service Slice: Unordered, Open by value:$this Binding: ?? (example): Classification of the requested service.	Elements differ in short: '(USCDI) Classification of service' vs 'Classification of service' Elements differ in definition: 'A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").' vs 'A code that classifies the service for searching, sorting and display purposes (e.g., Education).' Elements differ in definition for mustSupport: 'true' vs 'false'
priority	Σ	0..1	code	routine | urgent | asap | stat Binding: ?? (required): Identifies the level of importance to be assigned to actioning the request.	SΣ	0..1	code	routine | urgent | asap | stat Binding: ?? (required): Identifies the level of importance to be assigned to actioning the request.	Elements differ in definition for mustSupport: 'false' vs 'true'
doNotPerform	?!Σ	0..1	boolean	True if service/procedure should not be performed	?!Σ	0..1	boolean	True if service/procedure should not be performed
code	SΣ	1..1	CodeableConcept	(USCDI) What is being requested/ordered Binding: ?? (extensible)	SΣ	1..1	CodeableConcept	What is being requested/ordered. Binding: ?? (required): Codes for tests or services that can be carried out by a designated individual, organization or healthcare service.	Elements differ in short: '(USCDI) What is being requested/ordered' vs 'What is being requested/ordered.' Elements differ in definition: 'A code that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested.' vs 'A code that identifies a particular service (e.g., procedure) that has been requested.'
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 Slice: Unordered, Open by pattern:coding Binding: ?? (example): Codified order entry details which are based on order context.
quantity[x]	Σ	0..1	Quantity, Ratio, Range	Service amount	Σ	0..1	Quantity, Ratio, Range	Service amount
subject	SΣ	1..1	Reference(US Core Patient Profile)	(USCDI) Individual or Entity the service is ordered for	SΣ	1..1	Reference(Group | US Core Patient Profile | US Core Location 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' Type Mismatch: Reference([CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient]]) vs Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/Group], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-location]])
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	SΣ	0..1	dateTime, Period, Timing	When service should occur	Elements differ in short: '(USCDI) When service should occur' vs 'When service should occur'
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..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.
authoredOn	SΣ	0..1	dateTime	(USCDI) Date request signed	SΣ	0..1	dateTime	Date request signed	Elements differ in short: '(USCDI) Date request signed' vs 'Date request signed'
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	SΣ	0..1	Reference(RelatedPerson | Device | US Core PractitionerRole Profile | US Core Practitioner Profile | US Core Patient 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' Type Mismatch: Reference([CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient], CanonicalType[http://hl7.org/fhir/StructureDefinition/PractitionerRole], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-relatedperson], CanonicalType[http://hl7.org/fhir/StructureDefinition/Device]]) vs Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson], CanonicalType[http://hl7.org/fhir/StructureDefinition/Device], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitionerrole], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization]])
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(HealthcareService | Device | RelatedPerson | US Core Patient Profile | US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core CareTeam Profile)	Requested performer	Elements differ in definition for mustSupport: 'false' vs 'true' Type Mismatch: Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/Practitioner], CanonicalType[http://hl7.org/fhir/StructureDefinition/PractitionerRole], CanonicalType[http://hl7.org/fhir/StructureDefinition/Organization], CanonicalType[http://hl7.org/fhir/StructureDefinition/CareTeam], CanonicalType[http://hl7.org/fhir/StructureDefinition/HealthcareService], CanonicalType[http://hl7.org/fhir/StructureDefinition/Patient], CanonicalType[http://hl7.org/fhir/StructureDefinition/Device], CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson]]) vs Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/HealthcareService], CanonicalType[http://hl7.org/fhir/StructureDefinition/Device], CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitionerrole], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam]])
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	Σ	0..*	Reference(Location)	Requested location
reasonCode	Σ	0..*	CodeableConcept	(USCDI) Explanation/Justification for procedure or service Binding: ?? (extensible)	Σ	0..*	CodeableConcept	Explanation/Justification for procedure or service Binding: ?? (example): Diagnosis or problem codes justifying the reason for requesting the service investigation.	Elements differ in short: '(USCDI) Explanation/Justification for procedure or service' vs 'Explanation/Justification for procedure or service' Elements differ in comments: 'This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. Use `CodeableConcept.text` element if the data is free (uncoded) text as shown in the [CT Scan example].' vs 'This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. Use `CodeableConcept.text` element if the data is free (uncoded) text as shown in the [CT Scan example]. Information represented by ServiceRequest.reasonCode may overlap significantly with information represented by ServiceRequest.reasonReference. Multiple approaches to representing the same information may negatively impact interoperability. Therefore, where similar information could be provided by either ServiceRequest.reasonCode or ServiceRequest.reasonReference, it is recommended that ServiceRequest.reasonReference be used to provide a reason for why a service request was made..'
reasonReference	Σ	0..*	Reference(Condition | Observation | DiagnosticReport | DocumentReference)	(USCDI) US Core Profile that supports the requested service	Σ	0..*	Reference(Condition | Observation | DiagnosticReport | DocumentReference)	Explanation/Justification for service or service Slice: Unordered, Open by profile:resolve()	Elements differ in short: '(USCDI) US Core Profile that supports the requested service' vs 'Explanation/Justification for service or service' Elements differ in comments: 'This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to *Observation* or *Condition* should be used if available. Otherwise when referencing *DiagnosticReport* it should contain a finding in `DiagnosticReport.conclusion` and/or `DiagnosticReport.conclusionCode`. When using a reference to *DocumentReference*, the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in `ServiceRequest.reasonCode` if the data is free (uncoded) text as shown in the [CT Scan example].' vs 'This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to *Observation* or *Condition* should be used if available. Otherwise when referencing *DiagnosticReport* it should contain a finding in `DiagnosticReport.conclusion` and/or `DiagnosticReport.conclusionCode`. When using a reference to *DocumentReference*, the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in `ServiceRequest.reasonCode` if the data is free (uncoded) text. Additionally, see Comment on reasonCode.'
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 Slice: Unordered, Open by profile:resolve()	Elements differ in definition: 'Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.' vs 'Additional clinical information about the patient that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations.'
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.	Σ	0..0			Element maximum cardinalities differ: '2147483647' vs '0'
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