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

Left:SDOHCC ServiceRequest (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ServiceRequest)
Right:SDOHCC ServiceRequest (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ServiceRequest)

Messages

ErrorStructureDefinition.versionValues for version differ: '1.0.0' vs '1.1.0'
WarningServiceRequest.statusElements 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. While all values are currently allowed, there may be a constraint on the values in future releases based on implementation feedback.' '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.'
WarningServiceRequest.codeElements differ in comments: 'As the Gravity Project continues to refine content for the SDOH categories (e.g., food, housing, transportation, etc.), this value set will be refined to codes that pertain to SDOH categories.' 'As the Gravity Project continues to refine content for the SDOH categories (e.g., food, housing, transportation, etc.), this value set will be refined to codes that pertain to SDOH categories. For further guidance on external value sets vetted by the Gravity Project see: [SDOH terminology guidance]'
WarningServiceRequest.code.codingElements differ in comments: 'Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.' 'Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true. Where more than one coding is used, the codings should have overlapping meaning. For example, a code related to providing meal vouchers and a code related to home delivered meals may be appropriate. However, a code related to providing meal vouchers and a code related to providing transportation vouchers would not be appropriate.'
ErrorServiceRequest.code.codingElements differ in definition for mustSupport: 'false' 'true'
WarningServiceRequest.reasonReferenceElements 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]. Additionally, see Comment on reasonCode.' '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.'

Metadata

NameValueComments
.abstractfalse
    .baseDefinitionhttp://hl7.org/fhir/StructureDefinition/ServiceRequest
      .copyright
        .date2020-12-14T04:01:34+00:00
          .descriptionThis profile constrains the ServiceRequest resource for requests that address Social Determinants of Health.Profile for service requests that address Social Determinants of Health.
          • Values Differ
          .experimental
            .fhirVersion4.0.1
              .jurisdiction
                ..jurisdiction[0]urn:iso:std:iso:3166#US
                  .kindresource
                    .nameSDOHCCServiceRequest
                      .publisherHL7 International - Patient Care WG
                        .purpose
                          .statusdraft
                            .titleSDOHCC ServiceRequest
                              .typeServiceRequest
                                .urlhttp://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ServiceRequest
                                  .version1.0.01.1.0
                                  • Values Differ

                                  Structure

                                  NameL FlagsL Card.L TypeL Description & ConstraintsR FlagsR Card.L TypeL Description & ConstraintsCommentsdoco
                                  .. ServiceRequest II
                                    ... id ΣΣ
                                      ... meta ΣΣ
                                        ... implicitRules ?!Σ?!Σ
                                          ... language
                                            ... text
                                              ... contained
                                                ... Slices for extension ExtensionExtension
                                                  ... modifierExtension ?!?!
                                                    ... identifier ΣΣ
                                                      ... instantiatesCanonical ΣΣ
                                                        ... instantiatesUri ΣΣ
                                                          ... Slices for basedOn ΣΣ
                                                            ... replaces ΣΣ
                                                              ... requisition ΣΣ
                                                                ... status ?!SΣ?!SΣ
                                                                • 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. While all values are currently allowed, there may be a constraint on the values in future releases based on implementation feedback." "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Σ?!SΣ
                                                                  ... Slices for category ΣΣ
                                                                    ... priority SΣSΣ
                                                                      ... doNotPerform ?!Σ?!Σ
                                                                        ... code SΣSΣ
                                                                        • Elements differ in comments: "As the Gravity Project continues to refine content for the SDOH categories (e.g., food, housing, transportation, etc.), this value set will be refined to codes that pertain to SDOH categories." "As the Gravity Project continues to refine content for the SDOH categories (e.g., food, housing, transportation, etc.), this value set will be refined to codes that pertain to SDOH categories. For further guidance on external value sets vetted by the Gravity Project see: [SDOH terminology guidance]"
                                                                        .... id
                                                                          .... Slices for extension ExtensionExtension
                                                                            .... coding ΣSΣ
                                                                            • Elements differ in comments: "Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true." "Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true. Where more than one coding is used, the codings should have overlapping meaning. For example, a code related to providing meal vouchers and a code related to home delivered meals may be appropriate. However, a code related to providing meal vouchers and a code related to providing transportation vouchers would not be appropriate."
                                                                            • Elements differ in definition for mustSupport: "false" "true"
                                                                            .... text ΣΣ
                                                                              ... orderDetail ΣIΣI
                                                                                ... quantity[x] ΣΣ
                                                                                  ... subject SΣSΣ
                                                                                    ... encounter ΣΣ
                                                                                      ... occurrence[x] SΣSΣ
                                                                                        ... asNeeded[x] ΣΣ
                                                                                          ... authoredOn ΣΣ
                                                                                            ... requester SΣSΣ
                                                                                              ... performerType ΣΣ
                                                                                                ... performer SΣSΣ
                                                                                                  ... locationCode ΣΣ
                                                                                                    ... locationReference ΣΣ
                                                                                                      ... reasonCode ΣΣ
                                                                                                        ... Slices for reasonReference ΣΣ
                                                                                                        • 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]. Additionally, see Comment on reasonCode." "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
                                                                                                          ... Slices for supportingInfo
                                                                                                            ... specimen ΣΣ
                                                                                                              ... bodySite ΣΣ
                                                                                                                ... note
                                                                                                                  ... patientInstruction ΣΣ
                                                                                                                    ... relevantHistory

                                                                                                                      doco Documentation for this format