# Overview
Our cloud-based, API-powered platform is HITRUST i1 certified and designed to enable seamless data exchange across the healthcare ecosystem.
## Supported Implementation Guides for FHIR resources
* Claims Data — [CARIN Blue Button IG Profiles](http://hl7.org/fhir/us/carin-bb/STU1/artifacts.html)
* Clinical Data — [US Core IG Profiles](https://build.fhir.org/ig/HL7/US-Core-R4/profiles.html)
* Provider Directory Data — [DaVinci PDEX Plan Net IG Profiles](https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/profiles.html)
* Formulary Data — [DaVinci PDEX US Drug Formulary IG Profiles](http://hl7.org/fhir/us/davinci-drug-formulary/artifacts.html#3)
## FHIR server Capability Statement
A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server for a particular version of FHIR®.
To see the Capability Statement of a specific server, use the following URL format: `{baseUrl}/{fhirVersion}/metadata`.
The 1up demo environment's Capability Statement can be viewed at `https://api.1uphealthdemo.com/r4/metadata`.
## FHIR server provenance
Provenance resources capture metadata about the origin and lineage of FHIR resources. They are automatically created in the 1up FHIR Server for all FHIR resources created and updated.
Provenance of a FHIR resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that FHIR resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.
The 1up FHIR Server creates a Provenance resource when you first create a FHIR resource. When you update a FHIR resource, it creates a new Provenance resource. Each Provenance resource has a version-specific reference to the related FHIR resource.
## Validate FHIR resources
All FHIR® resources are automatically validated for conformance. Aggregated data from other organizations is canonicalized to the FHIR standard.
When FHIR resources are posted to the FHIR Server, 1up automatically performs base R4 specification validation. If the posted resource doesn’t contain valid JSON, the 1up FHIR Server sends a 400 Bad Request response.
Example 400 bad request
```json Example 400 bad request
Error
Bad Request
```
If the posted resource is valid JSON, additional validation checks are performed, and any errors are identified. Some examples of errors include:
* Incorrect type (string instead of array instead of Boolean)
* Missing required FHIR resource attribute
If any of these errors are present, the FHIR resource isn’t persisted in the FHIR Server, and the POST request to create the FHIR resource returns a 400 Bad Request status code with details in the response about the specific validation errors.
Example error
```json Example error
{
"resourceType": "OperationOutcome",
"id": "0uaptsuljvl",
"issue": [
{
"severity": "error",
"code": "value",
"details": {
"text": "child \"resourceType\" fails because [\"resourceType\" with value \"PractitionerRoler\" fails to match the required pattern: /^PractitionerRole$/]"
}
}
]
}
```