Configuring "Order Types"

The Human API Platform supports a wide range of options for clients to choose from when submitting an order. To simplify the order submission, our team will work with you to determine the right set of configuration options for your use case, and bundle these into an “Order Type”. Every order is then submitted with the appropriate Order Type to communicate to our platform how it should be processed.

Order Types are custom built for you, and can be assigned a name and description that is meaningful to your users. Separate “Order Types” should be created for each use case or business process that requires a different order processing configuration.

Order Type Configuration Options

Name / Description / Code

Choose values that are meaningful to you and your team. The “Name” and “Description” will appear in the client portal when users manually place orders. (See image below. Name is in bold and the description appears underneath). The “Code” is the value that is submitted via API when placing an order.

Order Types representation in UI

Retrieval Channels

Our recommendation to get the highest hit rate and highest quality of data returned is to enable all retrieval channels. However, some use cases may require, for example, digital data only. Your CS representative can work with you to understand your use case and recommend the right combination of retrieval channels. The primary options are:

  • Consumer Mediated
  • Digital HIPAA Auth
  • Traditional HIPAA Auth

Timeouts and Delays

Order Timeout → How long should we keep the order open before timing out.

APS Delay → Recommend 7 days. Our platform will deliver results once we collect sufficient data and cancel any outstanding APS orders already underway. We delay placing the APS order to give the electronic channels time to return results without incurring APS cancellation fees.

Channel specific delays → some use cases (rare) may benefit from fine-tuning individual retrieval options. Work with your CS rep to determine if this is relevant for your use case.

End User Contact

Many retrieval channels could trigger outreach to the end user. For example, if a Special Authorization Form is required, depending on your configuration, we may trigger an email to the end user asking them to sign the form. Some use cases (like a post-issue audit) may desire to block all end-user contact. This can be set at the order type level to specifically prohibit any end-user contact for a given use case.

Order Sufficiency

We are committed to ensuring that orders meet your needs. If your use case requires specific data elements, work with your CS representative to craft “sufficiency” logic which can evaluate the data collected to determine if we have enough information, or if we need to keep the order open and continue searching for additional records.

APS Summarization

Enable Summarization → Would you like APS records to be summarized for this order type?

Conditional Summarization: Some use cases prefer to only summarize APS results in certain situations. Examples could be to only summarize APS records that are more than 60 pages long, or if the Face Amount of the policy is less than $500K. Work with your CS rep if you are interesting in exploring custom summarization logic.


Our standard report offerings are:

  • Clinical History Report → Complete medical record combined from all retrieved digital sources. The standard configuration includes a digital “Highlights” section at the front which overviews key data elements and conditions found in the data.
  • APS Report → PDF of the APS retrieved. APS summaries, if enabled, will be prepended to the front of the pdf output.

For use cases beyond traditional manual underwriting, we support additional options

  • Structured / Digital Data Output → Get the complete record in JSON, following the industry standard FHIR spec
  • “HealthCheck” → A targeted report highlighting key lab results and vitals. Intended as an alternative to ordering labs and formatted to aid accelerate review.
  • Mortality Management → Simple report including a select number of key mortality predictors.

Custom Output? → Do you have a use case that would be best served by a custom report output? Whether digital for integration into a decision engine, or a pdf for targeted manual review, we would love to hear about it. Work with your CS representative to ensure that you get the report output that meets the needs for your use case.

File Delivery / “Shipping”

When we have completed retrieval, data processing, and report generation, the resulting report will be available via API and on our client portal. To facilitate efficient integration:

Subscribe to API push notifications → set at the client level (not order-type specific), we can enable digital notifications to your back end system notifying you about key events in the lifecycle of the order. Subscribing to either “Report Available” or “Order Summary” notifications can alert your backend system that there is a new report available to be retrieved.

Configure automatic deliver of the reports

We support a number of methods for automatically pushing reports to your backend. These options can be set up different for each order type that you configure.

  • HTTPS → Set up an endpoint on your side and we can PUT or POST the file
  • SFTP → We can push to an SFTP site of your choice. We can configure the file name in a structured way to enable routing / handling of the files on your end.
  • Pre-signed URLs → HAPI will request a pre-signed url from your backend, and then push the file to that location.
    • Note: this option can be useful to work around limitations when the file size may be too large to use the HTTP methods.

Adding or Editing an Order Type

Work with your Client Success representative to request new order types or changes to an existing order type. Order Type behavior is locked in for an order when it is placed. Changes to an order type configuration will not be automatically applied to previously submitted orders. There may be some scenarios where it is preferable to create a NEW order type rather than change the behavior of existing order types. This is primarily for clarity in reporting and any potential troubleshooting.