Operation Definition

<?xml version="1.0" encoding="UTF-8"?>


  
  
    
    
      
      
      
      
      
        The validate operation checks whether the attached content would be acceptable either
           generally, as a create, an update or as a delete to an existing resource.  The action
           the server takes depends on the mode parameter:

        

          [mode not provided]: The server checks the content of the resource against any schema,
             constraint rules, and other general terminology rules

          create: The server checks the content, and then checks that the content would be acceptable
             as a create (e.g. that the content would not violate any uniqueness constraints)

          update: The server checks the content, and then checks that it would accept it as an update
             against the nominated specific resource (e.g. that there are no changes to immutable fields
             the server does not allow to change, and checking version integrity if appropriate)

          delete: The server ignores the content, and checks that the nominated resource is allowed
             to be deleted (e.g. checking referential integrity rules)

        

        Modes update and delete can only be used when the operation is invoked at the resource
           instance level.   The return from this operation is an 
          
        

        Note that this operation is not the only way to validate resources - see 
           for further information.
        

      
      
      
      
      
        
          
            
          
          
            
          
          
            
          
          
            
          
          
            
          
          
            
          
        
        
          
          
          
          
            
          
          
          
            
              

            
          
        
        
          
          
          
          
            
          
          
             (Required)
          
          
            
              

            
          
        
        
          
          
          
          
            
          
          
          
            
              If this is nominated, then the resource is validated against this specific profile. If
                 a profile is nominated, and the server cannot validate against the nominated profile,
                 it SHALL return an error

            
          
        
        
          
          
          
          
            
          
          
          
            
              If the operation outcome does not list any errors, and a mode was specified, then this
                 is an indication that the operation would be expected to succeed (excepting for transactional
                 integrity issues, see below)

            
          
        
      
      
        This operation may be used during design and development to validate application design.
           It can also be used at run-time. One possible use might be that a client asks the server
           whether a proposed update is valid as the user is editing a dialog and displays an updated
           error to the user. The operation can be used as part of a light-weight two phase commit
           protocol but there is no expectation that the server will hold the content of the resource
           after this operation is used, or that the server guarantees to successfully perform an
           actual create, update or delete after the validation operation completes.

        This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error
           means that the validation itself could not be performed, and it is unknown whether the
           resource is valid or not.

        Note: the correct behaviour of validation with regard to language (especially for Coding.display)
           is currently undefined, and further development and testing may lead to specific requirements
           or recommendations in subsequent releases

        Future versions of this specifcation may add additional validation parameters. A candidate
           list is maintained with the 
          
        

      
    
  
  
    
  
  
    
  
  
  
  
  
  
  
  
  
  
  
    
      
      
    
    
      
      
    
  
  The validate operation checks whether the attached content would be acceptable either
   generally, as a create, an update or as a delete to an existing resource.  The action
   the server takes depends on the mode parameter:  

* [mode not provided]: The server checks the content of the resource against any schema,
   constraint rules, and other general terminology rules 
* create: The server checks the content, and then checks that the content would be acceptable
   as a create (e.g. that the content would not violate any uniqueness constraints) 
* update: The server checks the content, and then checks that it would accept it as an
   update against the nominated specific resource (e.g. that there are no changes to immutable
   fields the server does not allow to change, and checking version integrity if appropriate)
   
* delete: The server ignores the content, and checks that the nominated resource is allowed
   to be deleted (e.g. checking referential integrity rules)  


<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-validate"/> 
  <text> 
    <status value="extensions"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p> URL: [base]/Resource/$validate</p> 
      <p> URL: [base]/Resource/[id]/$validate</p> 
      <p> Parameters</p> 
      <table class="grid">
        <tr> 
          <td> 
            <b> Use</b> 
          </td> 
          <td> 
            <b> Name</b> 
          </td> 
          <td> 
            <b> Scope</b> 
          </td> 
          <td> 
            <b> Cardinality</b> 
          </td> 
          <td> 
            <b> Type</b> 
          </td> 
          <td> 
            <b> Binding</b> 
          </td> 
          <td> 
            <b> Documentation</b> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> resource</td> 
          <td/>  
          <td> 0..1</td> 
          <td> 
            <a href="resource.html">Resource</a> 
          </td> 
          <td/>  
          <td> 
            <div> 
              <p> Must be present unless the mode is &quot;delete&quot;</p> 
            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> mode</td> 
          <td/>  
          <td> 0..1</td> 
          <td> 
            <a href="datatypes.html#code">code</a> 
          </td> 
          <td> 
            <a href="valueset-resource-validation-mode.html">Resource Validation Mode</a>  (Required)
          </td> 
          <td> 
            <div> 
              <p> Default is 'no action'; (e.g. general validation)</p> 
            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> profile</td> 
          <td/>  
          <td> 0..1</td> 
          <td> 
            <a href="datatypes.html#canonical">canonical</a> 
          </td> 
          <td/>  
          <td> 
            <div> 
              <p> If this is nominated, then the resource is validated against this specific profile.
                 If a profile is nominated, and the server cannot validate against the nominated
                 profile, it SHALL return an error</p> 
            </div>           </td>         </tr>         <tr>           <td> IN</td>           <td> usageContext             <a href="versions.html#std-process" style="padding-left: 3px; padding-right: 3px; border: 1px grey solid; font-weight: bold;

             color: black; background-color: #fff5e6" title="Standards Status = Trial Use">TU</a> 
          </td>           <td/>            <td> 0..*</td>           <td>             <a href="metadatatypes.html#UsageContext">UsageContext</a>           </td>           <td/>            <td>             <div>               <p> Indicates an implementation context that applies to this validation.  Influences

                 which 
                <a href="terminologies.html#binding">additionalBindings</a>  are relevant.  NOTE: Expectations around subsumption testing, etc. are not yet

                 defined and may be server-specific.
              </p>             </div>           </td>         </tr>         <tr>           <td> OUT</td>           <td> return</td>           <td/>            <td> 1..1</td>           <td>             <a href="operationoutcome.html">OperationOutcome</a>           </td>           <td/>            <td>             <div>               <p> If the operation outcome does not list any errors, and a mode was specified, then

                 this is an indication that the operation would be expected to succeed (excepting
                 for transactional integrity issues, see below)</p> 
            </div>           </td>         </tr>       </table>       <div>         <p> This operation may be used during design and development to validate application

           design. It can also be used at run-time. One possible use might be that a client
           asks the server whether a proposed update is valid as the user is editing a dialog
           and displays an updated error to the user. The operation can be used as part of
           a light-weight two phase commit protocol but there is no expectation that the server
           will hold the content of the resource after this operation is used, or that the
           server guarantees to successfully perform an actual create, update or delete after
           the validation operation completes.</p> 
        <p> This operation returns a 200 Ok provided that it was possible to perform validation,

           irrespective of whether validation issues were found.  However, it is possible
           that certain errors in the validated content (e.g. invalid character set, broken
           JSON, etc.) may cause the overall validation operation to fail with a 4xx or 5xx
           series response.</p> 
        <p> Note: the correct behavior of validation with regard to language (especially for

           Coding.display) is currently undefined, and further development and testing may
           lead to specific requirements or recommendations in subsequent releases</p> 
        <p> Future versions of this specifcation may add additional validation parameters.

           A candidate list is maintained with the 
          <a href="https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator">FHIR Validator Documentation</a>         </p>       </div>     </div>   </text>   <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm">    <valueInteger value="5"/>   </extension>   <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status">    <valueCode value="normative"/>   </extension>   <url value="http://hl7.org/fhir/OperationDefinition/Resource-validate"/>   <version value="5.0.0"/>   <name value="Validate"/>   <title value="Validate a resource"/>   <status value="active"/>   <kind value="operation"/>   <experimental value="false"/>   <date value="2023-03-26T15:21:02+11:00"/>   <publisher value="HL7 (FHIR Project)"/>   <contact>     <telecom>       <system value="url"/>       <value value="http://hl7.org/fhir"/>     </telecom>     <telecom>       <system value="email"/>       <value value="fhir@lists.hl7.org"/>     </telecom>   </contact>   <description value="The validate operation checks whether the attached content would be acceptable

   either generally, as a create, an update or as a delete to an existing resource.
    The action the server takes depends on the mode parameter:  
* [mode not provided]: The server checks the content of the resource against any
   schema, constraint rules, and other general terminology rules 
* create: The server checks the content, and then checks that the content would
   be acceptable as a create (e.g. that the content would not violate any uniqueness
   constraints) 
* update: The server checks the content, and then checks that it would accept it
   as an update against the nominated specific resource (e.g. that there are no changes
   to immutable fields the server does not allow to change, and checking version integrity
   if appropriate) 
* delete: The server ignores the content, and checks that the nominated resource
   is allowed to be deleted (e.g. checking referential integrity rules)  

Modes update and delete can only be used when the operation is invoked at the resource
   instance level.   The return from this operation is an [OperationOutcome](operationoutcome.html)

Note that this operation is not the only way to validate resources - see [Validating Resources](vali
  dation.html) for further information.
  
  
  This operation may be used during design and development to validate application design.
   It can also be used at run-time. One possible use might be that a client asks the server
   whether a proposed update is valid as the user is editing a dialog and displays an updated
   error to the user. The operation can be used as part of a light-weight two phase commit
   protocol but there is no expectation that the server will hold the content of the resource
   after this operation is used, or that the server guarantees to successfully perform an
   actual create, update or delete after the validation operation completes.

This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error
   means that the validation itself could not be performed, and it is unknown whether the
   resource is valid or not.

Note: the correct behaviour of validation with regard to language (especially for Coding.display)
   is currently undefined, and further development and testing may lead to specific requirements
   or recommendations in subsequent releases

Future versions of this specifcation may add additional validation parameters. A candidate
   list is maintained with the [FHIR Validator Documentation](https://confluence.hl7.org/display/FHIR/U
  sing+the+FHIR+Validator)
  
  
  
  
  
    
    
    
    
    
    
  
  
    
    
    
    
    
    
    
      
        
      
      
      
    
  
  
    
    
    
    
    If this is nominated, then the resource is validated against this specific profile. If
     a profile is nominated, and the server cannot validate against the nominated profile,
     it SHALL return an error
    
  
  
    
    
    
    
    If the operation outcome does not list any errors, and a mode was specified, then this
     is an indication that the operation would be expected to succeed (excepting for transactional
     integrity issues, see below)
    
  

   instance level.   The return from this operation is an [OperationOutcome](operationoutcome.ht
  ml)
Note that this operation is not the only way to validate resources - see [Validating
   Resources](validation.html) for further information."/> 
  <jurisdiction>     <coding>       <system value="http://unstats.un.org/unsd/methods/m49/m49.htm"/>       <code value="001"/>       <display value="World"/>     </coding>   </jurisdiction>   <affectsState value="false"/>   <code value="validate"/>   <comment value="This operation may be used during design and development to validate application

   design. It can also be used at run-time. One possible use might be that a client
   asks the server whether a proposed update is valid as the user is editing a dialog
   and displays an updated error to the user. The operation can be used as part of
   a light-weight two phase commit protocol but there is no expectation that the server
   will hold the content of the resource after this operation is used, or that the
   server guarantees to successfully perform an actual create, update or delete after
   the validation operation completes.
This operation returns a 200 Ok provided that it was possible to perform validation,
   irrespective of whether validation issues were found.  However, it is possible
   that certain errors in the validated content (e.g. invalid character set, broken
   JSON, etc.) may cause the overall validation operation to fail with a 4xx or 5xx
   series response.
Note: the correct behavior of validation with regard to language (especially for
   Coding.display) is currently undefined, and further development and testing may
   lead to specific requirements or recommendations in subsequent releases
Future versions of this specifcation may add additional validation parameters.
   A candidate list is maintained with the [FHIR Validator Documentation](https://confluence.hl7
  .org/display/FHIR/Using+the+FHIR+Validator)"/> 
  <resource value="Resource"/>   <system value="false"/>   <type value="true"/>   <instance value="true"/>   <parameter>     <name value="resource"/>     <use value="in"/>     <min value="0"/>     <max value="1"/>     <documentation value="Must be present unless the mode is &quot;delete&quot;"/>     <type value="Resource"/>   </parameter>   <parameter>     <name value="mode"/>     <use value="in"/>     <min value="0"/>     <max value="1"/>     <documentation value="Default is 'no action'; (e.g. general validation)"/>     <type value="code"/>     <binding>       <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName">        <valueString value="ResourceValidationMode"/>       </extension>       <strength value="required"/>       <valueSet value="http://hl7.org/fhir/ValueSet/resource-validation-mode|5.0.0"/>     </binding>   </parameter>   <parameter>     <name value="profile"/>     <use value="in"/>     <min value="0"/>     <max value="1"/>     <documentation value="If this is nominated, then the resource is validated against this specific profile.

     If a profile is nominated, and the server cannot validate against the nominated
     profile, it SHALL return an error"/> 
    <type value="canonical"/>   </parameter>   <parameter>     <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status">      <valueCode value="trial-use"/>     </extension>     <name value="usageContext"/>     <use value="in"/>     <min value="0"/>     <max value="*"/>     <documentation value="Indicates an implementation context that applies to this validation.  Influences

     which [additionalBindings](terminologies.html#binding) are relevant.  NOTE: Expectations
     around subsumption testing, etc. are not yet defined and may be server-specific."/> 
    <type value="UsageContext"/>   </parameter>   <parameter>     <name value="return"/>     <use value="out"/>     <min value="1"/>     <max value="1"/>     <documentation value="If the operation outcome does not list any errors, and a mode was specified, then

     this is an indication that the operation would be expected to succeed (excepting
     for transactional integrity issues, see below)"/> 
    <type value="OperationOutcome"/>   </parameter> 


</

OperationDefinition

>