Download OpenAPI specification:Download
The PHDI Orchestration app offers a REST API for processing messages through a series of microservices.
The Orchestration app can be run using Docker (or any other OCI container runtime e.g., Podman), or directly from the Python source code.
To run the Orchestration app with Docker, follow these steps.
docker -v. If you do not see a response similar to what is shown below, follow these instructions to install Docker.❯ docker -v
Docker version 20.10.21, build baeda1f
docker pull ghcr.io/cdcgov/phdi/orchestration:latest. docker run -p 8080:8080 orchestration:latest.Congratulations, the Orchestration app should now be running on localhost:8080!
We recommend running the Orchestration app from a container, but if that is not feasible for a given use-case, it may also be run directly from Python using the steps below.
git clone https://github.com/CDCgov/phdi./phdi/containers/orchestration/.python -m venv .venv.source .venv/bin/activate (MacOS and Linux), venv\Scripts\activate (Windows Command Prompt), or .venv\Scripts\Activate.ps1 (Windows Power Shell).pip install -r requirements.txt into your virtual environment.localhost:8080 with python -m uvicorn app.main:app --host 0.0.0.0 --port 8080.To build the Docker image for the Orchestration app from source instead of downloading it from the PHDI repository follow these steps.
git clone https://github.com/CDCgov/phdi./phdi/containers/orchestration/.docker build -t orchestration ..When viewing these docs from the /redoc endpoint on a running instance of the Orchestration app or the PHDI website, detailed documentation on the API will be available below.
Wrapper function for unpacking an uploaded file, determining appropriate parameter and application settings, and applying a config-driven workflow to the data in that file. This is one of two endpoints that can actually invoke and apply a config workflow to data and is meant to be used to process files.
:param message_type: The type of stream of the uploaded file's underlying
data (e.g. ecr, elr, etc.). If the data is in FHIR format, set to FHIR.
:param data_type: The type of data held in the uploaded file. Eligible
values include ecr, zip, fhir, and hl7.
:param config_file_name: The name of the configuration file to load on
the service's back-end, specifying the workflow to apply.
:param upload_file: A file containing clinical health care information.
:return: A response holding whether the workflow application was
successful as well as the results of the workflow.
| message_type | string (Message Type) |
| data_type | string (Data Type) |
| config_file_name | string (Config File Name) |
| upload_file | string <binary> (Upload File) |
{- "message": "Processing succeeded!",
- "content": {
- "foo": "bar"
}
}Wrapper function for unpacking a message processing input and using those
settings to apply a config-driven workflow to a raw string of data.
This endpoint is the second of two workflow-driven endpoints and is meant
to be used with raw string data (meaning if the data is JSON, it must be
string serialized with json.dumps).
:param request: A response holding whether the workflow application was successful as well as the results of the workflow.
| message_type required | string (Message Type) Enum: "ecr" "elr" "vxu" "fhir" The type of message to be validated. |
| data_type required | string (Data Type) Enum: "ecr" "zip" "fhir" "hl7" The type of data of the passed-in message. Must be one of 'ecr', 'fhir', or 'zip'. If |
| config_file_name required | string (Config File Name) The name of a config file in either the |
required | Message (object) or Message (string) (Message) The message to be validated. |
| rr_data | string (Rr Data) If an eICR message, the accompanying Reportability Response data. |
{- "message_type": "ecr",
- "data_type": "ecr",
- "config_file_name": "string",
- "message": { },
- "rr_data": "string"
}{- "message": "Processing succeeded!",
- "content": {
- "foo": "bar"
}
}Get a list of all the process configs currently available. Default configs are ones that are packaged by default with this service. Custom configs are any additional config that users have chosen to upload to this service (this feature is not yet implemented)
{- "default_configs": [
- "all.json",
- "test_config.json"
], - "custom_configs": [ ]
}Get the config specified by 'processing_config_name'.
:param processing_config_name: The name of the processing configuration to retrieve. :param response: The response object used to modify the response status and body.
| processing_config_name required | string (Processing Config Name) |
{- "message": "Config found!",
- "workflow": {
- "workflow": [
- {
- "service": "ingestion",
- "url": "some-url-for-an-ingestion-service",
- "endpoint": "/fhir/harmonization/standardization/standardize_names"
}
]
}
}Upload a new processing config to the service or update an existing config.
:param processing_config_name: The name of the processing configuration to be uploaded or updated. :param input: A Pydantic model representing the processing configuration data. :param response: The response object used to modify the response status and body.
| processing_config_name required | string (Processing Config Name) |
required | object (Workflow) A JSON-formatted config dict containing a single key |
| overwrite | boolean (Overwrite) Default: false When |
{- "workflow": {
- "property1": [
- {
- "service": "string",
- "endpoint": "string",
- "params": { }
}
], - "property2": [
- {
- "service": "string",
- "endpoint": "string",
- "params": { }
}
]
}, - "overwrite": false
}{- "message": "Config uploaded successfully!"
}