Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
comments_alex #105
comments_alex #105
Changes from all commits
066e270
41dcb98
fe44b72
fba8f1e
fafa843
6a7dd26
536de08
a7f0aef
e72efc9
bf6fa50
aec8e14
6d54a9c
773b42b
f4242dc
0a7915e
6dc0f07
bb48072
0a49929
9400fb4
b23aac3
4d59133
30888ca
22c29d7
e3cf01b
396607d
a7a1240
03dc925
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
TORCH - Transfer Of Resources in Clinical Healthcare
Transfer Of Resources in Clinical Healthcare
Goal
The goal of this project isTransfer Of Resources in Clinical Healthcare or Torch is a project that aims to provide a service that allows the execution of data extraction queries on a FHIR-server.The tool will take an DEQ, Whitelists and CDS Profiles to extract defined Patient ressources from a FHIR Server and then apply the data extraction with the Filters defined in the DEQ. Additionally Whitelists can be applied.
The tool will take a CRTDL and StructureDefinitions to extract specific resources from a FHIR server. It first extracts a cohort based on the cohort definition part of the CRTDL using either CQL or FLARE and FHIR Search. It then extracts resources for the cohort as specified in the cohort extraction part of the CRTDL, which specifies which resources to extract (Filters) and which attributes to extract for each resource.
The tool internally uses the HAPI implementation for handling FHIR Resources.
CRTDL
The Clinical Resource Transfer Definition Language or CRTDL is a JSON format that describes attributes to be extracted with attributes filter.
The Clinical Resource Transfer Definition Language or CRTDL is a JSON format, which specifies a data request. This request is composed of two parts: The cohort definition (for who (which patients) should data be extracted) The data extraction (what data should be extracted)
Prerequisites
Local FHIR Server with test data and a Flare server with a cohort Endpoint Torch interacts with these components for the data extraction.
TORCH interacts with the following components directly:
The reverse proxy allows for integration into a site's multi-server infrastructure and provides a means of serving the extracted data.
CQL Support
CQL is supported. If your FHIR server does not support CQL itself then the FLARE component must be used to extract the cohort based on the cohort definition of the CRTDL.
Component Interchangeability
All components work with well-defined interfaces making them interchangeable. Thus, there are different middleware clients and FHIR servers to chose from.
This leads to the following setup options:
The Setup can be set using the TORCH_USE_CQL setting in the enviroment variables
Build
Run
Docker
For simplicity torch is integrated in the feasibility-triangle of the feasibility-deploy repository, but can also be installed without it.
Environment Variables
format in hours/minutes/seconds. Default 90 days
_SPRINGFRAMEWORK_WEB_REACTIVE_FUNCTION_CLIENT
_REACTOR_NETTY
_DE_MEDIZININFORMATIKINITIATIVE_TORCH
_CA_UHN_FHIR
Examples of Using Torch
Below, you will find examples for typical use cases. To demonstrate the simplicity of the RESTful API, the command line tool curl is used in the following examples for direct HTTP communication.
Flare REST API
TORCH REST API (based on FHIR Bulk Data Request)
Torch implements the FHIR Asynchronous Bulk Data Request Pattern.
$extract-data
The $extract-data endpoint implements the kick-off request in the Async Bulk Pattern. It receives a FHIR parameters resource with a
CRTDLcrtdl parameter containing a valueBase64Binary.The Parameters resource created by
scripts/create-parameters.sh
look like this:Response - Error (e.g. unsupported search parameter)
Response - Success
That location header can be used in the following status query: E.g. location:"/fhir/__status/1234"
Status Request
Torch provides a Status Request Endpoint which can be called using the location from the extract Data Endpoint.
Response - In-Progress
Response - Error
Response - Complete
the result is a looks something like this:
Metadata
Response -Success
Output Files
After Response Complete is returned the result files in ndjson format are located in Output directory set in enviroment variables.
Download Data
If a server is set up for the files e.g. NGINX, the files can be fetched by a Request on the URL set in NGINX_FILELOCATION in enviroment variables.
curl -s "http://localhost:8080/da4a1c56-f5d9-468c-b57a-b8186ea4fea8/f33634bd-d51b-463c-a956-93409d96935f.ndjson"
NDJSON: Result Bundles
The ndjson will contain one transaction bundle per Patient with "Dummy Resources" for maintaining referential integrity for Patient and Encounter resources, if the adequate Resources were not part of the extraction process. I.e. there is always at least a Patient resource containing profile and id set.
For example:
Analogously an Encounter containing profile, status and id is set.
Masked Fields
Required fields that were not extracted and slices that are unknown in the Structure Definition are set to Data Absent Reason "masked".
For example a CRTDL only extracting Condition.onset will result in this:
Supported Features
CDSStructureDefinitionsOutstanding Features
iyying against the CDS ProfilesLicense
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an " AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.