The Redox FHIR® sandbox allows you to test your FHIR® workflows with test patients. Use this full-featured sandbox during implementation to test an end-to-end integrated workflow against a FHIR® server—and to mirror how an integration might look when connecting to legacy systems.
Send sandbox requests to redox-fhir-sandbox. We seed our sandbox with a robust set of test patient data covering most of the FHIR® resources in our API suite. See our FHIR® specs.
You can test reads, queries, and even writebacks.
When Redox refreshes the sandbox
We want our sandbox to be useful to everyone. To achieve that, we occasionally refresh the sandbox, which reverts the environment to its original state with only Redox-seeded test data. This keeps test data valuable to all customers and clears the sandbox of any potentially confidential test data. We only refresh as necessary to ensure the overall health of the sandbox.
Discover test patient data
Our FHIR® sandbox supports reading and querying for data. This allows you to test your search workflows.
Search tips
The Redox FHIR® sandbox uses exact matching for patient searches.
For identifiers, we include one or more of the following for each test patient:
For demographics, we include one or more of the following for each test patient:
given name
family name
gender
birthdate
address-city
address-state
address-postalcode
home phone
mobile phone
email address
Phone and address parameters
A couple of things to note for patient searches:
First, the phone parameter matches either a home or mobile phone.
Second, you may notice that the address is split into three parameters (address-city, address-state, address-postalcode) and doesn’t include the street address. The FHIR® API sandbox doesn’t support searching for a street address. Instead, you can search by city, state, or postal code—or a combination of the three.
See the pre-seeded Redox test patients below. Most of these test patients can’t be modified.
Patient
Identifiers / Demographics
Resources
Synthia Davis
FHIR® ID: fbee8d6b-5acf-370c-7edd-af0d84f5288c
MR: 3Y67hJYUopQywm8frKLGBf
DOB: 2000-10-10
gender: female
address: Revere, MA 02151
Appointment
CarePlan
CareTeam
Condition
Coverage
Device
DiagnosticReport
DocumentReference
Encounter
Goal
Immunization
MedicationRequest
Observation
Patient
Procedure
ServiceRequest
Micheal Shields
FHIR® ID: 307b6419-5147-4716-10b1-bb458ac191c3
MR: 5Z89kLZWqrSzvn9gtNMHCh
DOB: 2003-07-19
gender: female
address: Fairhaven, MA
AllergyIntolerance
Appointment
CarePlan
CareTeam
Condition
Coverage
DiagnosticReport
DocumentReference
Encounter
Medication
MedicationAdministration
MedicationRequest
Observation
Patient
Procedure
Narcisa Torphy
FHIR® ID: 18022a84-1fd7-ba38-3567-efbc6a50e9d4
MR: 7A12mNXYstUvop2huOPJDi
DOB: 1967-05-11
gender: female
address: Dedham, MA 02026
Condition
Coverage
DiagnosticReport
DocumentReference
Encounter
ImagingStudy
Observation
Patient
Procedure
Roosevelt Turner
FHIR® ID: 7673112e-f252-3c46-a7e7-ac1e1fe3fa45
MR: 9B34oPZWuwQxyj4kvQRKEj
DOB: 1994-08-29
gender: male
address: Boston, MA 02467
AllergyIntolerance
CarePlan
CareTeam
Condition
Coverage
DiagnosticReport
DocumentReference
Encounter
Observation
Patient
Procedure
ServiceRequest
Keva Green
FHIR® ID: 81c2f5eb-f99f-40c4-b504-59483e6148d7
MR: kyHGADnvX3xbkU4V9ayaqh
DOB: 1995-08-26
gender: female
address: Hillsboro, OR 97123
Note: This is an editable test patient, so demographic data may be different from what you see listed here.
Account
AllergyIntolerance
Appointment
Condition
Coverage
DiagnosticReport
DocumentReference
Encounter
Immunization
MedicationRequest
MedicationAdministration
RelatedPerson
ServiceRequest
Specimen
Test patients CSV file
Our sandbox environment has hundreds of available test patients seeded with associated clinical data. Find the Test Patients CSV file on the Developer > Test Tools > Dev Tool Downloads page of the Redox dashboard. The patients in the CSV file support read, query, and writeback requests. Learn how to use developer test tools.
FYI: Data from Synthea
We generated some of our test data from an open-source dataset called Synthea™.
Jason Walonoski, Mark Kramer, Joseph Nichols, Andre Quina, Chris Moesel, Dylan Hall, Carlton Duffett, Kudakwashe Dube, Thomas Gallagher, Scott McLachlan, Synthea: An approach, method, and software mechanism for generating synthetic patients and the synthetic electronic health care record, Journal of the American Medical Informatics Association, Volume 25, Issue 3, March 2018, Pages 230–238, https://doi.org/10.1093/jamia/ocx079
Example search responses
Refer to the code examples below to see what kind of responses to expect. So you know, the bundle.id field in the response is different for each request.
Example: Response for a patient search with MR identifier
You shouldn’t include confidential data, like personal health information (PHI), when writing data to the Redox FHIR® sandbox. Since it’s a testing environment, users from multiple organizations may save data with yours. Or if they query, they may unintentionally retrieve your saved data. Like its name suggests, our sandbox is a community tool and should be treated as such.
Writeback only available to Redox customers
You must be a Redox customer to use writeback requests in the FHIR® sandbox. Writeback is available to you as a customer, whether you’re testing your initial development or after you’ve already implemented hundreds of connections.
If you’re not a customer yet, you can still perform reads and queries to the sandbox, but not writebacks. Talk to a Redoxer if you’re interested in the writeback feature of our FHIR® sandbox.
Writeback tips
To send a successful writeback request, we recommend reviewing some best practices.
We don’t recommend copying and pasting the examples in our FHIR® API specs. Our examples show the full capacity of each API schema. The schemas don’t contain realistic required values to successfully send a writeback message to the FHIR® sandbox.
All requests to the Redox FHIR® sandbox should first include a Bundle resource type. It should contain an entry array and a type: message. Learn more about the Bundle resource.
Example: Bundle resource in a writeback request
json
1
{
2
"resourceType":"Bundle",
3
"type":"message",
4
"timestamp":"2024-07-15T22:05:54.0335865+00:00",
5
"entry":[]// include objects for additional resources
6
}
You may include an id parameter in the Bundle object to identify the bundle, but it’s not required.
For real-world logs, most FHIR® servers won’t consume a full bundle but will instead consume single resources to specific endpoints. If your connection requires this, we’ll handle the configuration for you.
The MessageHeader resource specifies metadata for the writeback request for the downstream FHIR® server. This includes data about your organization, including the source.name, source.endpoint, and a unique identifier for the source. You should consider this a requirement in your bundle.
This resource also includes a focus array, where you should reference the resource you’re using to exchange data. For example, Appointment/$appointment-create would include the fullURL of the Appointment resource in the bundle. Or, Patient/$patient-create would include the fullURL of the Patient resource in the bundle.
Use the FHIR® resource ID within the id value of the specific FHIR® resources. This should be a UUID for the FHIR® sandbox, which you should've gotten this from a previous _search or read request.
Creating new resources
Though it’s technically allowed, don’t assign a FHIR® resource ID in the entry.resource.id. The destination FHIR® server is typically the source of truth for assigning FHIR® identifiers to a payload.
Instead, assign a fullURL value to the resource. This allows your system to attach an identifier to the resource so you can link it elsewhere within the payload without assigning an FHIR® ID. The destination should assign the actual FHIR® ID.
We recommend using a UUID as the fullURL value, prefaced by urn:uuid, although these can be assigned as URLs by your system as well. For example, you could include urn:uuid:245a33e0-e187-4850-aebc-4e86dd2111b2, where the value after the colon is your system’s unique identifier for the resource. This fullURL can be used as a reference anywhere else you need in the payload.
A bundle is an assortment of related but independent FHIR® resources. A reference indicates a one-way relationship from one resource to another. References are crucial for maintaining data integrity and context in a bundle. Check out the FHIR® glossary for more definitions and details.
You can use references to link to existing resources in the FHIR® sandbox. That means you don’t necessarily have to include the full resource every time you reference it. See the example Observation resource below, which includes references to related Patient and Encounter resources.
Example: Observation resource with Patient and Encounter references
When creating a writeback bundle, make sure the reference fields contain either the:
resource ID
fullURL
The example above shows both types. If the resource already exists in the FHIR® sandbox, use the resource ID. If the resource doesn’t exist, use the fullURL. Including incorrect references in the bundle will cause your message to fail.
Also, the message may fail if you’re copying example payloads from our FHIR® specs. The intent of our FHIR® specs is to show the full schema shape, not necessarily provide a sample call for you to use.
In a writeback message, there are extra FHIR® resources in the bundle. For example, you might send Appointment/$appointment-create, but you’ll see Patient, Practitioner, Location, Encounter, and other resources included. If those extra resources don’t exist in the FHIR® sandbox, your writeback message might create new resources.
To include existing resources in the FHIR® sandbox, include the full resource with the resource ID. If you don’t have the resource ID, you can query for it first. The FHIR® sandbox looks at the resource ID, resource type, and identifiers to determine if there’s already a matching resource.
To include new resources (or if there wasn’t a matching resource in the scenario above), enter all the required elements for the given resource and assign it a fullURL. A new resource will be created and assigned a unique resource ID. This is likely how your connection’s FHIR® server will behave in production as well.
If your connections use HL7v2, we recommend including all the resources and data points you have within the writeback bundle.
If your connections use FHIR®, including extra resources within the bundle (besides the main resource you’re using) is less important.
When a new resource ID is assigned, you’ll see it in the response’s URL (e.g., Appointment/bf4d58c5-aeaa-4c2f-8c69-c57c9f198637: https://fhir.redoxengine.com/fhir-sandbox/Appointment/bf4d58c5-aeaa-4c2f-8c69-c57c9f198637/_history/MTcyMTk0MDUyODQyNDg5NDAwMA).
You’ll typically need to include administrative references for writeback messages, like Practitioner, Location, and Organization. Below are some example references you can use as inputs to leverage existing resources in your test bundles:
Resource
Examples
Practitioner
Practitioner/7efc2275-b837-42d7-af6d-1386f8a618ae
Practitioner/dbed0f85-e3cd-47ac-9305-3f629e138832
Practitioner/264f7ec9-3bd4-3268-b88c-ec9618b4dd1a
Practitioner/fff2db55-4039-42b6-a3c1-c61991b6752b
Practitioner/ffff2b69-26d1-46a8-bd2d-1cdc38eb7ba0
Location
Location/0066e68c-8ea1-46f2-9716-40410b97894d
Location/006eed1d-6691-496a-b36d-90a666f4f27d
Location/ed4afd58-9796-4cc5-aed7-5c47345acec9
Location/02321b8d-5096-4797-a7a7-dece90df4342
Location/02bd7825-dd5f-4264-880b-7d9f846de281
Organization
Organization/1aedcb45-c507-3ad0-9010-6583d264ae72
Organization/308b5efa-a9c2-3728-b1ff-d29c5f060731
Organization/90cf148c-69ed-3d33-aa86-b509c6b0b25f
Organization/700056a6-3aea-3efd-8423-a9acbd38a5ea
Organization/0f7f97f6-693c-3de9-8190-85feaf4632e2
Example writeback responses
You can typically expect either a 200 or 201 in response to your writeback message.
HTTP response
Description
200
A resource that already exists in the FHIR® sandbox was successfully updated with the content in your writeback payload.
The resource ID was updated can be found in the location value.
201
A resource was created within the FHIR® sandbox. This means the the sandbox didn’t locate a resource that matched the input criteria.
Individual resource responses will be included in the entry array of the response. The number of objects depends on the number of resources included within your bundle.
Refer to the example below if you want to know what kind of response to expect.
FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.