-
Notifications
You must be signed in to change notification settings - Fork 53
TestOrder vs TestEvent
- TestOrders are mutable and TestEvents are immutable.
- TestEvents are reported to ReportStream and TestOrders are not.
- They are cyclically referenced, such that TestOrder has a referenced TestEvent and TestEvent has a referenced TestOrder.
- They contain a good deal of duplicate information, including patient, organization, facility, device, results, and correction status. See
BaseTestInfo
for a full list. - For corrections and mutations, the original TestOrder is altered but a new TestEvent is created.
- Test results used to be stored as a column on both TestOrder and TestEvent. Nowadays, there's a separate Result table that includes references to both the TestEvent and TestOrder, as well as the actual result and disease information.
- A TestOrder gets created as soon as a patient is added to the queue. The TestEvent is only created once the queue item is submitted.
At the dawn of time (also known as late 2020) SimpleReport needed a data schema.
This schema had many purposes. It had to be able to send data to public health departments through ReportStream, but it also had to store internal SimpleReport data so that users could view their historic test records. It needed to link tests to specific facilities and organizations, but also to providers who were ordering the tests. There was also the concept of mutability - records that had already been sent to ReportStream couldn't be edited once they hit the public health departments, but within SimpleReport users needed to be able to edit or update their results. What's an engineering team to do?
In this case, they created both a TestOrder and a TestEvent. The TestOrder was pretty literal - it meant that a health care provider had ordered a test, the same way your doctor might order an X-ray. The order had information about the patient, the ordering provider, the facility that the test was order to, when it was ordered, etc. This order was created as soon as you put someone onto the queue within SimpleReport, and given a status of PENDING
.
A TestEvent meant that a testing event had finished, and needed to be reported to the public health department. Once created, these records were immediately passed on and reported, so they couldn't be edited after creation.
Initially, the intention was to have TestOrder reference TestEvent as a kind of parent-child relationship. The TestOrder would know about the TestEvent but the Event would remain blissfully unaware of its counterpart. This changed with test corrections, when it was necessary for both TestOrder to know about TestEvent and TestEvent to know about TestOrder. During a correction, Events would be orphaned by their parent Order, so a reference was needed to link the two together. This did have the unfortunate side effect of creating a cycle between TestOrder and TestEvent, to the later frustration of the devs trying to serialize the database for audit logging. But I digress.
Today, TestOrders are still created as soon as a patient is put onto the queue. They can have three potential states - PENDING
, COMPLETED
, or CANCELLED
. Only COMPLETED
orders should have an associated TestEvent. The TestEvent is created when the user submits a test (calling the addTestResult
mutation).
- Getting Started
- [Setup] Docker and docker compose development
- [Setup] IntelliJ run configurations
- [Setup] Running DB outside of Docker (optional)
- [Setup] Running nginx locally (optional)
- [Setup] Running outside of docker
- Accessing and testing weird parts of the app on local dev
- Accessing patient experience in local dev
- API Testing with Insomnia
- Cypress
- How to run e2e locally for development
- E2E tests
- Database maintenance
- MailHog
- Running tests
- SendGrid
- Setting up okta
- Sonar
- Storybook and Chromatic
- Twilio
- User roles
- Wiremock
- CSV Uploader
- Log local DB queries
- Code review and PR conventions
- SimpleReport Style Guide
- How to Review and Test Pull Requests for Dependabot
- How to Review and Test Pull Requests with Terraform Changes
- SimpleReport Deployment Process
- Adding a Developer
- Removing a developer
- Non-deterministic test tracker
- Alert Response - When You Know What is Wrong
- What to Do When You Have No Idea What is Wrong
- Main Branch Status
- Maintenance Mode
- Swapping Slots
- Monitoring
- Container Debugging
- Debugging the ReportStream Uploader
- Renew Azure Service Principal Credentials
- Releasing Changelog Locks
- Muting Alerts
- Architectural Decision Records
- Backend Stack Overview
- Frontend Overview
- Cloud Architecture
- Cloud Environments
- Database ERD
- External IDs
- GraphQL Flow
- Hibernate Lazy fetching and nested models
- Identity Verification (Experian)
- Spring Profile Management
- SR Result bulk uploader device validation logic
- Test Metadata and how we store it
- TestOrder vs TestEvent
- ReportStream Integration
- Feature Flag Setup
- FHIR Resources
- FHIR Conversions
- Okta E2E Integration
- Deploy Application Action
- Slack notifications for support escalations
- Creating a New Environment Within a Resource Group
- How to Add and Use Environment Variables in Azure
- Web Application Firewall (WAF) Troubleshooting and Maintenance
- How to Review and Test Pull Requests with Terraform Changes