Groundspeed turns unstructured data from common insurance documents into structured data that can be quickly and easily analyzed to power data driven decision making for insurance carriers.
At a high level, clients work with Groundspeed to configure how they will send documents to Groundspeed for processing, and receiving back the structured data from said documents once they've been processed.
The following concepts within our platform are important to understand.
Accounts within Groundspeed are intended to represent a collection of files that represent the detail of a single insured party.
An extract is a zip file that typically contains two or more files.One is the extracted structured data, and the other is the error report which contains any errors encountered processing the data, or documents that were considered out of scope within the account.
A manifest file is an optional file that is included with a submission that is used to describe the documents contained within the submission, and override or supplement the data extracted from the submission with data from the manifest.
A manifest file which contains supplementary information regarding the source files may be included in the zip file. The manifest file must be a csv file in the root directory of the zip file and be named as follows:
Each row of the manifest file will be matched to a source file in the zip. The manifest file should have the following information:
Field | Description | Required |
---|---|---|
file_name | The name of the source file | Yes |
doc_id | Client specified doc id for each source file | Optional |
customer_account_id | Client specified account id for each source file | Optional |
customer_account_name | The name of the account assigned by the customer | Optional |
project_id | Source file listed under project name | Optional |
submission_effective_date | Date used to allocate claims to the correct policy year. If loss date is before submission_effective_date then the claim is assigned to the previous policy year, if after, then policy year is set to loss date year. Must be in the format “MM/DD” | Optional |
fill_effective_date | When an effective date is not present, use this date to fill in the effective date. Must be in the format “MM/DD/YYYY”. | Optional |
fill_valuation_date | When a valuation date is not present, use this date to fill in the valuation date. Must be in the format “MM/DD/YYYY” | Optional |
fill_line_of_business | When an LOB is not present, use this value to fill in the LOB. | Optional |
fill_insurance_carrier | When a carrier is not present, use this value to fill in the carrier. | Optional |
fill_policy_number | When a policy is not present, use this value to fill in the policy number. | Optional |
Groundspeed supports receiving accounts via three different methods: Email, SFTP, and API.
Groundspeed systems can ingest documents in one of three ways. Each of which is described in detail below.
Documents can be sent in a zip file container. The list of support file types that can be contained within a zip file are listed below:
Files fail to ingest to Groundspeed system? Please see FAQ section
This is the entrypoint for all document processing requests into the Groundspeed pipeline.
curl -X POST \ https://intake.groundspeed.com/api/v1/process \ -H 'cache-control: no-cache' \ -H 'content-type: multipart/form-data; boundary=----FormBoundary' \ -H 'x-api-key: $API_KEY' \ -F accountId=$ACCOUNT_ID \ -F projectId=$PROJECT_ID \ -F file=@/path/to/testfile.zip \ -F callbackUrl=https://dummy-url.com
Clients that wish to send documents to Groundspeed can do so via our rapid fusion email pipeline. Users are issued a dedicated email address (XXX@groundspeedrapidfusion.com) which they can send accounts to as email attachments. In some cases, documents may already be in email form, and the underwriter can just forward the email to Groundspeed.
In order for a customer to send documents via email to Groundspeed, we will need the following information as to configure our intake and delivery system:
Groundspeed returns data back to the user's registered callback URL. Users must share the callback URL and the appropriate authorization details to ensure that the data can be returned successfully. Users also have the ability to overwrite the registered default callback URL as part of the request.
A delivery callback mechanism for uploading a result is also available. This requires deploying a HTTP service capable of receiving a POST method with a multipart/form payload including the payload of a zip file.
curl -X POST -H 'Accept: */*' -H 'Accept-Encoding: gzip, deflate' \ -H 'Connection: keep-alive' -H 'Content-Length: 385' \ -H 'Content-Type: multipart/form-data; boundary=9610effdb6e2da9d69bc6b5649353ed2' \ -H 'User-Agent: python-requests/2.21.0' -H 'x-api-key: test' \ -d '--9610effdb6e2da9d69bc6b5649353ed2 Content-Disposition: form-data; name="accountId" 1 --9610effdb6e2da9d69bc6b5649353ed2 Content-Disposition: form-data; name="projectId" 1 --9610effdb6e2da9d69bc6b5649353ed2 Content-Disposition: form-data; name="file"; filename="example.zip" Content-Type: application/zip Binary contents goes here --9610effdb6e2da9d69bc6b5649353ed2-- ' http://localhost:47303/upload
Groundspeed has four key data products. Each of which is listed below with it's data points described in detail. means Groundspeed derived when data not present in source document,
means field is sourced from a 3rd party provider and is only available in our Premium subscription tier. More details in Child Attributes.
Insurance data can come in multiple forms, and it's possible that the same data could be captured in multiple places, creating duplicate data. Groundspeed mitigates this risk by making reasonable best efforts to identify duplicate data and omit it from the extracted data that's delivered.
Handling duplicate data is tricky because introducing deduplication measures introduces the possibility that data is omitted when it may in fact just be similar.
As a general rule, Groundspeed systems look for explicitly duplicate data, and prefer to share data that isn't clearly duplicate. We take this approach to ensure that data is not ignored, and provide downstream consumers the opportunity to remove or ignore data at their own discretion.
To learn more about de-duplication process, please see FAQ section