FQL is a query language that allows you to retrieve, filter and project data from any data source containing FHIR Resources. It brings the power of three existing languages together: SQL, JSON and FhirPath. It allows you to create tables and is useful for gaining insight and perform quality control.
-
Default
What is FQL?
-
FQL Query resources
FQL Playground
Try Firely Query Language in our playground by using this scope as data source.
- FQL Documentation
-
FQL Language
Syntax specification
To learn more about FQL syntax choose this menu item.
-
YamlGen Generate resources
YamlGen Playground
Try YamlGen in our playground by using this scope as data source.
-
YamlGen Language
YamlGen Syntax specification
To learn more about YamlGen syntax choose this.
-
FHIRPath Inspect resource
FHIRPath Playground
Try out the FHIRPath playground and navigate inside this resource.
-
FHIRPath Documentation
FHIRPath Documentation
Find out what FHIRPath is or learn how to write FHIRPath scripts.
-
Project FHIR API
This is the location where you can find your resource using a FHIR client.
-
Simplifier FHIR API
The global endpoint is where users can search for all resources in Simplifier. Resources have a globally unique guid Id here.
-
Custom Example generation
Custom Example generation beta
Experiment with resource instance generation using YamlGen and based on this profile.
This feature is in beta. You can help us improve it by giving feedback with the feedback button at the top of the screen.
Signature
Base StructureDefinition for Signature Type: A signature along with supporting context. The signature may be a digital signature that is cryptographic in nature, or some other signature acceptable to the domain. This other signature may be as simple as a graphical image representing a hand-written signature, or a signature ceremony Different signature approaches have different utilities.
- type Profile on Signature
- FHIR R4
- status Draft
-
version4.0.0
The canonical from this resource does not match any claim in this context and conflicts with a claim from another scope.
http://hl7.org/fhir
Canonical claims are used to verify ownership of your canonical URLs.
Signature | Element | Element idSignature A Signature - XML DigSig, JWS, Graphical image of signature, etc. DefinitionA signature along with supporting context. The signature may be a digital signature that is cryptographic in nature, or some other signature acceptable to the domain. This other signature may be as simple as a graphical image representing a hand-written signature, or a signature ceremony Different signature approaches have different utilities. The elements of the Signature Resource are for ease of access of these elements. For digital signatures (Xml DigSig, JWS), the non-repudiation proof comes from the Signature validation, which includes validation of the referenced objects (e.g. Resources) (a.k.a., Content) in the XML-Signature Detached form.
| ||
id | 0..1 | There are no (further) constraints on this element Element idSignature.id Unique id for inter-element referencing DefinitionUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
| ||
extension | 0..* | Extension | There are no (further) constraints on this element Element idSignature.extension Additional content defined by implementations Alternate namesextensions, user content DefinitionMay be used to represent additional information that is not part of the basic definition of the element. 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. There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. Unordered, Open, by url(Value) Extensions are always sliced by (at least) url Mappings
| |
type | Σ | 1..* | CodingBinding | Element idSignature.type Indication of the reason the entity signed the object(s) DefinitionAn indication of the reason that the entity signed this document. This may be explicitly included as part of the signature information and can be used when determining accountability for various actions concerning the document. Examples include attesting to: authorship, correct transcription, and witness of specific event. Also known as a "Commitment Type Indication". An indication of the reason that an entity signed the object.
|
when | Σ | 1..1 | instant | Element idSignature.when When the signature was created DefinitionWhen the digital signature was signed. This should agree with the information in the signature.
|
who | Σ I | 1..1 | Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) | Element idSignature.who Who signed DefinitionA reference to an application-usable description of the identity that signed (e.g. the signature used their private key). This should agree with the information in the signature. Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) Constraints
|
onBehalfOf | Σ I | 0..1 | Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) | Element idSignature.onBehalfOf The party represented DefinitionA reference to an application-usable description of the identity that is represented by the signature. used when the signature is on behalf of a non-signer. The party that can't sign. For example a child. Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization) Constraints
|
targetFormat | 0..1 | codeBinding | Element idSignature.targetFormat The technical format of the signed resources DefinitionA mime type that indicates the technical format of the target resources signed by the signature. "xml", "json" and "ttl" are allowed, which describe the simple encodings described in the specification (and imply appropriate bundle support). Otherwise, mime types are legal here. The mime type of an attachment. Any valid mime type is allowed.
| |
sigFormat | 0..1 | codeBinding | Element idSignature.sigFormat The technical format of the signature DefinitionA mime type that indicates the technical format of the signature. Important mime types are application/signature+xml for X ML DigSig, application/jose for JWS, and image/* for a graphical image of a signature, etc. The mime type of an attachment. Any valid mime type is allowed.
| |
data | 0..1 | base64Binary | Element idSignature.data The actual signature content (XML DigSig. JWS, picture, etc.) DefinitionThe base64 encoding of the Signature content. When signature is not recorded electronically this element would be empty. Where the signature type is an XML DigSig, the signed content is a FHIR Resource(s), the signature is of the XML form of the Resource(s) using XML-Signature (XMLDIG) "Detached Signature" form.
|