Smile CDR v2022.08.PRE
On this page:
   5.1    FHIR Storage Modules
  • FHIR Storage
  • 5.0 Concepts in Smile CDR
  • 5.1 FHIR Storage Modules
  • 5.2 FHIR Endpoint Module
  • 5.3 FHIRWeb Console
  • 5.4 OpenAPI / Swagger Support
  • 5.5 Resource IDs
  • 5.6 Search Parameters
  • 5.7 Search Parameter Features
  • 5.8 Phonetic Search Parameters
  • 5.9 Custom Search Parameters
  • 5.10 Search Parameter Tuning
  • 5.11 Searching for Data
  • 5.12 Creating Data
  • 5.13 Reading Data
  • 5.14 Updating Data
  • 5.15 Deleting Data
  • 5.16 Binary Data
  • 5.17 Request Tracing and Provenance
  • 5.18 FHIR Versions
  • 5.19 Versioned Resource References
  • 5.20 Tags, Profiles, and Security Labels
  • 5.21 Clinical Quality Language (CQL)
    • 5.3    FHIRWeb Console   
       Table of Contents

    FHIR Endpoint Module

    5.2FHIR Endpoint Module

     

    The FHIR Endpoint module is an HTTP Server (i.e. a web server) that allows external clients to interact with the FHIR Storage module.

    5.2.1Creating the Module

     

    When creating a FHIR Endpoint module, you must first choose which version of FHIR it will support. There are multiple types of FHIR Endpoint modules, and each one supports a specific version of FHIR. The version of FHIR must match the version of FHIR supported by the FHIR Storage module.

    Server Configuration

    There are only a few settings that absolutely must be set when creating this module:

    • Port – The port that the server will listen on (e.g. 8000).
    • Fixed Value for Endpoint Base URL – Tells the server what it should advertise as the FHIR base URL (e.g. http://acme.org:8000).
    • Dependency FHIR Persistence: This is a reference to the FHIR Storage module that backs this endpoint.

    5.2.2Capturing Source Information

     

    When processing incoming resources (i.e. for create, update, etc.) some basic details about the resource provenance are captured in Resource.meta.source. Smile CDR stores both the Source System URI (typically the identity of the system that was used to create the data) as well as the Transaction ID (typically a unique identifier for the specific HTTP request involved).

    When Smile CDR is storing FHIR data (using a FHIR Storage module) these two fields are automatically combined using a hash symbol. For example, given a Source System URI of http://example.com/some-app and a Transaction ID of 000001 the system might capture the following value:

    {
  "resourceType": "Patient",
  "meta": {
    "source": "http://example.com/some-app#000001"
  }
}

    It is possible to supply both of these properties using HTTP Request Headers in environments where it is easier to capture/inject this data using network infrastructure. The following two headers may be used:

    Searching

    See Storing Source Information for information on how this information is stored and how it can be used for searching.

    5.2.3Validation

     

    You can configure a FHIR endpoint to validate resources as they enter or leave the system (i.e. request and response payloads). See Endpoint Validation for information.

    5.2.4Configuration

     

    Reference

    A complete reference of configuration items follows:

       5.1    FHIR Storage Modules
  • FHIR Storage
  • 5.0 Concepts in Smile CDR
  • 5.1 FHIR Storage Modules
  • 5.2 FHIR Endpoint Module
  • 5.3 FHIRWeb Console
  • 5.4 OpenAPI / Swagger Support
  • 5.5 Resource IDs
  • 5.6 Search Parameters
  • 5.7 Search Parameter Features
  • 5.8 Phonetic Search Parameters
  • 5.9 Custom Search Parameters
  • 5.10 Search Parameter Tuning
  • 5.11 Searching for Data
  • 5.12 Creating Data
  • 5.13 Reading Data
  • 5.14 Updating Data
  • 5.15 Deleting Data
  • 5.16 Binary Data
  • 5.17 Request Tracing and Provenance
  • 5.18 FHIR Versions
  • 5.19 Versioned Resource References
  • 5.20 Tags, Profiles, and Security Labels
  • 5.21 Clinical Quality Language (CQL)
    • 5.3    FHIRWeb Console