The Redox FHIR® sandbox allows you to test your workflows with test patients. All you need to do is send requests to redox-fhir-sandbox.
Our FHIR® sandbox is seeded with a robust set of test patient data covering most of the FHIR® resources in our API suite. You can test several API actions, including reads, queries, and even writebacks. Use this fully-featured sandbox during your implementation to test a full end-to-end integrated workflow against a FHIR® server—and to mirror how an integration may look when connecting to legacy systems.
Sandbox scheduled maintenance
We want to ensure our sandbox stays clean and useful. So, we refresh the sandbox bi-annually (typically in April and October), 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.
Visit our status page to review our maintenance schedule, which includes when the next refresh will be.
Discover test patient data
Review some of our test patients in the table below. You can use this data to test read and query requests.
Writeback not supported for Redox patients
You can only perform writeback requests for test patient records you've created, not Redox test patients.
Test Patients CSV file
We actually have hundreds of available test patients with associated clinical data seeded within the sandbox environment. They're all available in the Test Patients CSV file in the Developer Test Tools page of the Redox dashboard. The patients in the CSV file support read, query, and writeback requests.
Just a heads up, we used an open-source dataset from Synthea™ to generate some of our test data.
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
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 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.
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.
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. You should have gotten this from a previous _search or read request. This should be a UUID for the FHIR® sandbox.
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 show 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.
When a new resource ID is assigned, you'll see i tin 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).
If your connections use HL7v2, we recommend including as many resources and as much information 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.
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®.
