Validating incoming resources

You can have Firely Server validate all resources that are sent in for create or update. The setting to do that is like this:

"Validation": {
  "Parsing": "Permissive", // Permissive / Strict
  "Level": "Off", // Off / Core / Full
  "AllowedProfiles":
  [
      "http://hl7.org/fhir/StructureDefinition/daf-patient",
      "http://hl7.org/fhir/StructureDefinition/daf-allergyintolerance"
  ]
},

Parsing

Every incoming resource - xml or json - has to be syntactically correct. That is not configurable.

Beyond that, you can choose between Permissive or Strict parsing. Permissive allows for:

  • empty elements (not having any value, child elements or extensions)

  • the fhir_comments element

  • errors in the xhtml of the Narrative

  • json specific:

    • array with a single value instead of just a value, or vice versa (json specific)

  • xml specific:

    • repeating elements interleaved with other elements

    • elements out of order

    • mis-representation (element instead of attribute etc.)

Validation

You can choose the level of validation:

  • Off: no validation is performed.

  • Core: the resource is validated against the core definition of the resource type.

  • Full: the resource is validated against the core definition of the resource type and against any profiles in its meta.profile element.

Allow for Specific Profiles

To enable profile-specific validations, set Level to Full.

Configuring AllowedProfiles

  • When you leave the AllowedProfiles list empty, Firely Server will permit any resource, provided it passes the general validations set by Parsing and Level.

  • Adding canonical URLs of StructureDefinitions to the AllowedProfiles list instructs Firely Server to perform specific checks:

    1. Profile Existence Check: Firely Server will verify whether the incoming resource declares any of these profiles in its meta.profile element.

    2. Conformance Validation: Firely Server will validate the resource against any profiles it claims to conform to in its meta.profile element. This validation step is governed by the Level setting, not specifically by AllowedProfiles.

Example: If you add the DAF Patient and DAF AllergyIntolerance profiles to AllowedProfiles, Firely Server will only allow resources that declare and conform to these profiles.

Important Notes

  • The resource must explicitly declare conformance to a profile in its meta.profile for Firely Server to validate against it. Firely Server will not try to validate a resource against all the Validation.AllowedProfiles to see whether the resource conforms to any of them, only those that the resource claims conformance to.

  • AuditEvent Logging and AuditEvent Signatures: If enabled, AuditEvent and Provenance resources generated by these processes will also be subject to checks against the AllowedProfiles. It is necessary to include the HL7 core canonical URLs of these resources in AllowedProfiles to ensure they are saved in the database without issues.

{
  "Validation": {
    ...
    "AllowedProfiles": [
      "http://hl7.org/fhir/StructureDefinition/AuditEvent",
      "http://hl7.org/fhir/StructureDefinition/Provenance"
      ...
    ]
  }
}