When an organization purchases or develops an IT system, that system is set up with various “copies” or instances of those systems. The copies of the delivered software may be called environments, or pathways, or just systems. For the remainder of this post, I’ll call them environments. This structure is required so that IT systems can be configured to support several phases of implementation. You can’t have configuration, testing, and training happening on the production system, right? This post will explain IT systems architecture, and we will look at what happens at the various stages of development and implementation.
An environment is a complete instance of a software package that includes databases, configuration options, and the user interface.
For our example, let’s suppose we have an electronic health record (EHR), medication tracking system, or Lab software. The vendor will deliver code on servers that are split out into the following environments:
- Release environment (usually called REL)
- Development or Build environment
- QA or Test environment
- Training environment
- Production environment
- Staging environment
- Reporting environment
Depending on the vendor or software product, there may be some variation; but probably 90% of the time, it will be pretty close to this:
The horizontal arrow represents the process of migrating data throughout an implementation or development phase, as well as delivery of routine changes and updates. The vertical arrows represent the tasks of copying configuration options and data for supporting functions outside the production realm.
Release Environment – (REL)
This is a copy of the vendor delivered out-of-the-box configuration that has no customer-specific changes. Customers are usually not allowed to make any edits to this environment but can log in with vendor ‘dummy’ logins to explore basic functionality. The customer’s IT department will usually have access to the release environment, but end users like Lab techs will not.
The reason the release environment is needed is if something goes wrong with one of the customer-configured environments, we need a place to go to see if the problem is with the customer’s setup, or the vendor’s released product. You’ll hear the question, “Is it broken in REL?”
Development Environment (DEV, BLD)
The development or build environment is just what it sounds like. It’s the place where customer-specific configuration is done. If it’s our Lab system example, then we would build all the tables for departments, users, Lab orders, and other data. The system would likely have interfaces to other systems and all sorts of configuration options. Work that has been done in the dev/build environment will at some point be redone or migrated to the next environment, QA/Testing.
Testing Environment – (TST, QA)
The test environment is usually where final testing is done before configurations are moved to production. While the IT staff who did the work in the build environment performed testing there, that build environment is kind of a “sandbox”, whereas the test environment is where official testing gets done.
A Word About Testing: The kind of testing that goes on in build is usually called “unit testing”. This is where we test basic functionality in a controlled environment that may not be connected to other systems. The testing that goes on in the QA/test environment is usually “integrated testing”. This is where we test a more complete set of steps that is closer to what happens in production, such as data passing to external systems via interfaces.
Production Environment (PRD)
When changes or configurations are successful in test, we move the configuration settings, tables, or files to production. At this point, we do some sort of validation in production to confirm things are working. We don’t like to say that we “test in production”, as it’s expected we already did our testing. However, it’s always good practice to make sure things made it to production as expected. Some organizations allow a limited number of test users, departments, and patients in production, but this approach needs to be managed very carefully.
Training Environment (TRN)
The training environment is just what it sounds like. It’s for trainers to provide hands-on guidance of the system. It may be a copy of the test environment configuration, or there may be a dedicated environment that is copied to one or more training environments. Also, training environments usually have a unique set of test patients, users, and other information. Training environments tend to have some unique challenges:
- They don’t always get updated as frequently as other environments
- Because users are playing around in the training environment, they sometimes make mistakes and mess up one thing or another
Staging Environment
The staging environment is a replica of the production environment for purposes of troubleshooting production issues. In a healthcare system, it will contain copies of production patients, users, departments, orders, and other data. It is a very useful tool for analysts to resolve issues. Also, because it contains protected health information, it needs to be audited for inappropriate access.
Reporting/Shadow Environment
The reporting environment is a copy of a production system, and serves the purpose of connecting to reporting tools so that users can run reports and queries against a copy of the production data without directly touching the real production data. It may also be called the shadow environment. If users ran reports against the actual production data, system performance could be affected. It is common for the reporting environment to not be an exact real-time copy of the production data. Some reporting environments have data that is between a few hours older and a day older than production.
IT Systems Architecture Wrap-up
So there you have it. Systems are delivered from vendors in multiple iterations of the same software product for the purpose of handling implementations, ongoing support, testing, and training. An understanding of how Healthcare IT systems are configured is critical to anyone in Healthcare IT, and I believe I am providing unique and valuable content here. If this has helped you, please do use the sharing buttons and help me keep this site going. You can always contact me from the site, or reach out on Twitter @HealthITSkills.
Next Up:
Read More
