One of our value props is allowing you to reason at the level of orders, without having to think about individual test kits, home visits, and so on. An order may consist of multiple parallel subcomponents - e.g. a test kit may be sent to a patient, while simultaneously a phlebotomist is scheduling a visit. Additionally, multiple instances of a subcomponent may be required. For example, the first kit sent to a patient may get lost in the mail, and a second kit would need to be sent out. Accordingly, our API reflects these nuances.
order object represents the lifecycle of a real-world diagnostic order from start to finish. Here are a few examples of real-world diagnostic orders:
- A consumer buying a hormone test from an e-commerce website. The order starts with the purchase and ends when the patient receives their results.
- A doctor ordering a lipid panel for a patient. The order starts with the doctor placing the lab order in their EHR and ends when the doctor and patient receive the results.
order is usually associated with a payment from the end consumer of the test, and ends only when results are ready or you or the patient choose to cancel the order.
order object contains arrays of other objects that represent different concepts involved in the lifecycle of an order:
kitsrepresents test kits mailed to the patient, either for patient self-sampling or for use by a phlebotomist. If a phlebotomist is required, an appointment will be facilitated and
order.home_visitswill contain a
home_visitsrepresents visits by a healthcare provider to the patient's home to draw blood. A test kit with the tubes will be mailed to the patient and
order.kitswill contain a
walk_in_visitsrepresents patient visits to a draw center to have their blood drawn.
order_definition object represents the details of a specific type of order you can place, including:
- Whether it's involves a patient self-sampled at-home test kit, mobile phlebotomy, or going to a draw center.
Updated 4 months ago