GET
/
mr
/
api
/
v1
/
docs
/
{document_id}
/
result
cURL
curl --request GET \
  --url https://api.eka.care/mr/api/v1/docs/{document_id}/result \
  --header 'Authorization: Bearer <token>' \
  --header 'X-Pt-Id: <x-pt-id>'
{
  "status": "queued",
  "error": [
    {
      "code": 123,
      "message": "<string>"
    }
  ],
  "data": {
    "fhir": "aSDinaTvuI8gbWludGxpZnk=",
    "output": {
      "data": [
        {
          "test_name": "<string>",
          "data": {
            "value": 123,
            "unit": "<string>",
            "unit_processed": "<string>",
            "normal_range_report": "<string>",
            "normal_range_eka": "<string>",
            "unit_eka_id": "<string>",
            "display_range": "<string>"
          },
          "normalised_data": {
            "value": 123,
            "unit": "<string>",
            "normal_range_report": "<string>",
            "normal_range_eka": "<string>",
            "unit_eka_id": "<string>"
          },
          "confidence": 123,
          "test_eka_id": "<string>",
          "loinc_id": "<string>"
        }
      ],
      "pii": {}
    }
  }
}
  • Processing Time: Record parsing typically takes 1–2 minutes for documents up to 10 pages and 2–4 minutes for those exceeding 10 pages, depending on the document size.
  • Understanding the Components of Response

    • ​
      Lab Report

      ​
      Lab test

      Every lab test will have:
      • test_name : Verbatim as written in the lab report
      • test_eka_id : Eka identifier for the test
      • loinc_id : LOINC identifier for the test
      • NOTE: we use method agnostic LOINC identifiers in majority of the lab tests. Mapping of all Eka identifiers with LOINC identifiers can be obtained from here.

      ​
      Lab test data (value | unit | range)

      Lab test observation is parsed and shared in two variants

      ​
      Non unit-normalised data (data )

      This data is not unit-normalised, meaning this is verbatim as written in the report. The keys comprise
      • value : value of the test as given in the report
      • unit : unit of the test as given in the report, parsed by OCR (Non post processed). NOTE: at times OCR reads 10^3 u/ml as 103u/ml
      • unit_processed : unit of the test as given in the report, parsed by OCR and then processed by eka. In the above example 103u/ml is converted back to 10*3u/ml after applying post processing
      • normal_range_report : normal range parsed object basis the low-high values given in the report
      • normal_range_eka : normal range parsed object basis EkaCare’s database considering age / gender information of the person from the report.
      • unit_eka_id : Eka id for unit
      • display_range : Verbatim range display text (string) parsed from the report.

      ​
      Unit-Normalised data (normalised_data )

      This object contains unit normalised data for Value, Unit and range objects mentioned above. Normalisation is explained in detailed in the subsequent section. This object contains all the fields mentioned above except display_range and unit_processedsince that is verbatim and normalisation does not make sense.

      ​
      Normalisation process

      In order to create longitudinal lab investigation trends across lab reports across time, one needs to convert lab values and ranges to a standard unit. For every lab test, EkaCare defines a standard unit (basis highest frequency across millions of records). List of standard units for every test can be found here. Normalisation is process of multiplying values and normal ranges with a factor that converts the numerical results in the report to EkaCare standard unit for that lab test.

      ​
      Range-object

      Range objects contain structured low and high values of the normal range. Note that our parsers only structured low-high normal range format. Any other formats such as: normal: < 200 borderline high: 200-240 high: 240+ While this data is available in “display_range” field in non unit-normalised object as string, we do not parse and structure this kind of structure. However, EkaCare ranges in structured formats are available for someone to still interpret the results if need be.

      ​
      PII data

      This section outlines the structure and components of Personally Identifiable Information (PII) as provided within medical documentation. The information captured includes page number, document dates, patient details, and report specifics.

      ​
      Components of PII Data

      <unique_file_path>: A unique identifier representing the file path is utilized to group related PII information. Each file path is mapped to a collection of PII data for different pages in the document..
      • PageNum: Represents the page number within the document where relevant PII data is found.
      • DocumentDate: Captures the document date in Unix timestamp format for consistent time-related operations.

      ​
      Patient Details

      • Name: Verbatim representation of the patient’s name as found in the document.
      • Age: The patient’s age is detailed in years, months, and days, providing a comprehensive age identification.
      • Gender: Captures the patient’s gender, e.g., “male” or “female”.

      ​
      Report Details

      • SampleCollectionDate: (only for Lab-reports) The date and time when the sample was collected, in “dd/mm/yyyy hh:mm:ss” format.
      • SampleReceivedDate: (only for Lab-reports) The date and time when the sample was received, in “dd/mm/yyyy hh:mm:ss” format.
      • GeneratedDate: (only for Lab-reports) The report generation date and time in “dd/mm/yyyy hh:mm:ss” format.
      • Doctor: The doctor’s name, if available.
      • Facility: The name of the facility or laboratory where the test was conducted, e.g., “LalPath Labs”.

Authorizations

​
Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Headers

​
X-Pt-Id
string
required

eka user id (OID)

Path Parameters

​
document_id
string
required

Document ID to update the document details.

Example:

"2df9e795-d368-4ceb-be9d-b44281703827"

Response

200
application/json

Successful response

The response is of type object.