When an organization purchases an IT system, just about every vendor delivers various “copies” or environments of those systems. This structure is required so that Healthcare 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 Healthcare IT architecture. The copies of the delivered software may be called environments, or pathways, or just systems. For the remainder of this post, I’ll just call them environments.
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 (usually called REL)
- Build or Staging
- QA (for testing)
- Training
- Production
- Production Shadow
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 phase, as well as delivery of routine changes and updates. The vertical arrows represent the tasks of copying data for supporting functions outside the production realm.
Release Environment
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 REL environment, but end users like Lab techs will not.
The reason the REL 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?”
Build/ Dev Environment
The 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 Build environment will at some point be redone or migrated to the next environment, QA.
QA/ Test Environment
The QA 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 Test is usually “integrated testing”. This is where we test a more complete set of steps that is more like what happens in Production, such as data passing to external systems via interfaces.
Production Environment
When changes or configuration is 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 “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 used very carefully.
Training Environment
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, but has 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
Shadow Environment
The Shadow 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. If users ran reports against the actual production data, system performance would likely be affected. It is common for the Shadow environment to not be an exact real-time copy of the production data. Some Shadow systems have data that is between a few hours older and a day older than Production.
Healthcare IT Architecture Wrapup
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
