Software Developer

At 4-Ti we decided to take a hard look at our development process and see how we could improve as an organization. One of our goals with this planning was to standardize our development process so that no matter how many projects, customers, and developers we have, we will consistently create high-quality products.

We did this in a few ways. The first step was to define the development process and then to figure out how we can best act on that definition. The team discussed a few different interpretations, but we agreed as a team to define “development process” as The process of transforming a requirement into a deliverable.

Great! Now we have the definition...so what is the next step?

We ended up having a series of meetings about the agile process and how we can better ourselves as a team and individual developers to follow the agile methodology. One of the first assignments given to junior members of the team was to review the Agile Manifesto in preparation for group discussions on the topic.

As a team, we broke down the development process into four steps- Planning, Implementation, Testing, and Deployment. With these steps in mind, we structured time to discuss each step and how it relates to agile development and our work as an organization.

Let’s dive into the highlights and takeaways from each step.

Our general approach is to take requirements and write stories that contain acceptance criteria and a plan of how to implement the requirement. In our conversation about planning, we talked about the pros and cons of different approaches and how stories can sometimes become entangled in one another. This is obviously not desirable, and neither is going into a planning meeting with stories that are not clearly defined. 

Our solution was to commit to two-week sprints and midway through the sprint to have a refinement meeting so there was time to get clarification on any stories well ahead of the next planning meeting. So now, at the beginning of a sprint, we have a backlog of well-formed and clear stories and halfway through the sprint, we have a refinement meeting looking at upcoming requirements for the next sprint. 

This continuous cycle of planning and refinement had rapid effects on the team and we all noticed smoother collaboration in our work.

A few interesting topics came up when discussing implementation. This includes the reusability, and readability of code that is developed, and how we review our team member’s code.

Having simple code that is reusable and easy to understand is the goal of many development teams, but this does not always happen when you are fulfilling complicated requirements.

Having components and code blocks that are sharable is usually advantageous, but we agreed that this should be decided in the planning phase.

We also agreed that a significant way to help the team develop smoother and faster is to make it a priority to review and run another team member’s code that is ready to be tested and provide feedback as quickly as possible.

We have automated unit tests in all of our projects, but we how do we truly follow the Agile Manifesto and ensure that we are satisfying “...the customer through early and continuous delivery of valuable software.”

We took a hard look at our current working style and decided we as a team needed to test more often and more thoroughly on our dedicated test environment. Not all dev teams have this available, but once we committed to testing each requirement on our production testing environment, very quickly we saw our customers complimenting us on a job well done, and there were fewer issues and bugs reported. 

One issue we identified was our deployment frequency. We decided it was best to deploy more frequently...essentially deploying one story at a time. This deployment into our production testing environment allows our team to test requirements in multiple environments, and also identify bugs and side effects of deployments much more easily compared to deploying a batch of requirements all at once.

Our first go of this went remarkably well...even with a bug involved! We isolated an issue after it was deployed, created a “hot fix” and within 20 minutes the patch was implemented and it really showed us the value of testing on multiple environments and the benefits of deploying at a high frequency.

To conclude, we recognized that there was room for improvement and growth in our development process and we committed to taking steps to help better serve our customers and grow as a team and individual contributors. 

This blog is going to focus on agile development at 4-Ti and the outcomes of introspective conversations about our development process

Agile Development

When building a project there are a number of options to handling data and state in the frontend. The entire internet operates on HTTP. HTTP stands for Hypertext Transfer Protocol. For those not familiar with IT and websites, just know that HTTP is stateless (meaning it cannot hold information) and that every website you look at is built from a series of requests and responses. 

The user requests data (i.e. typing in a website URL and hitting enter), and then a server responds with the appropriate data. What is amazing is that every “request” for data is independent of the request beforehand. There is no record of what has been requested, and what has been served. 

Imagine ordering food at a restaurant and the waiter cannot remember any of your previous requests, but they reliably fulfill your request every time. Pretty quickly you would think about how to optimize your requests. Maybe you want to bundle them together...but there’s a lot of other factors to consider. How much could a waiter carry back on a tray at one time?  Would requesting too much at once mean that the kitchen would be overwhelmed, if the kitchen could handle the request would you have to wait an unreasonable amount of time? Just like restaurants have a system for handling customers, the internet has a system for handling clients. While this is not a perfect analogy, think of the customer as the ‘client’, the waiter as the API, the kitchen as the server, and the table where you are sitting in the browser. The browser makes requests possible for users, and for developers, there are quite a few options to handle state so that the servers can handle the load and the users have a good experience.

This blog is going to discuss two options- Redux and Context. Both have their pros and cons, but we will walk through some simple examples of when either option could be effective.

In React 16.8, ‘hooks’ were introduced. This allowed for more flexible state management in React components without having to create classes. Previously, if a component in React had to update any state, a class component was required which included a ton of boilerplate code and according to React’s official documentation “​​classes confuse both people and machines”. Now we can update and manage state with hooks. Hooks rely on an API in the React library which allows for functional components to handle more complicated tasks and allows components to be more sharable and reusable.

Part of this update included ‘Context’. Context allows a developer to have access to data globally within their application. In previous versions of React if a button on a form needed to be displayed in multiple languages it could be tedious to make that happen.  Most likely, it was a different button that allowed the user to change the language. Then that language-changing button needed to update the state at the page level (through a series of magical `componentDidUpdate` calls, and then once it is updated at the page level, that piece of information (the user’s preferred language) is passed down from component to component (sometimes needing to be passed up to a dozen times) in a process affectionally known to developers as ‘prop-drilling.’

With the introduction of hooks, that button on the form can now tap into the context of the application and check which language the user prefers and display the text in that language. This process not only makes development easier, but is also optimized for performance.

Lightweight. This is already built into newer versions of React so it is great that you do not have to install any additional packages to be up and running. 

Documentation. The React Docs provide easy-to-follow examples of how to use hooks and context in your application, and there are plenty of online tutorials and videos of people walking through the concepts.

Flexible. You can set all sorts of data types into Context and you are off and running.

Performance. If used correctly, this should not be an issue, however, Context should be used in addition to local state in React components, not a complete replacement. A change to Context will re-render all other child components that are affected by that change. So for a language, or a theme, or something like that it is not a big deal because you want it to re-render. But if a user is simply inputting their name into a form and the value of the form is held in Context, every single key stroke will trigger a re-render of all components. This may be invisible to the user, but it can easily cause lagging and performance issues.

Here’s a simple example of using context to keep the theme of your website stored globally, but also having a way to update the theme from any component. This assumes that you have only two themes (light and dark)

import React, { useContext, useState } from 'react'
 
const ThemeContext = React.createContext(null)
const ThemeUpdateContext = React.createContext(null)
 
export const useTheme = () => {
   return useContext(ThemeContext)
}
 
export const useThemeUpdate = () => {
   return useContext(ThemeUpdateContext)
}
 
export const ThemeProvider = ({ children }) => {
   const [lightTheme, setLightTheme] = useState(true)
 
   const toggleTheme = () => {
       setLightTheme(theme => !theme)
   }
 
   return (
       <ThemeContext.Provider value={lightTheme}>
           <ThemeUpdateContext.Provider value={toggleTheme}>
               {children}
           </ThemeUpdateContext.Provider>
       </ThemeContext.Provider>
   )
}
 
export const ThemeConsumer = ThemeContext.Consumer

If you are using Next.js (our favorite React framework), your `_app.tsx` should look something like this:

import { AppProps } from 'next/app'
import { ThemeProvider } from '../context/themeContext'
// import css files here
 
function App({ Component, pageProps }: AppProps) {
   return  (
       <ThemeProvider>
             <Component {...pageProps} />
       </ThemeProvider>
           )
}


But no matter your framework, if you want the logic and state available to all components, then just wrap the Provider around the entire application.

Now when you want to have a checkbox that can toggle the theme it is as easy as grabbing the Context from your Context folder and your simple checkbox input can control the state in your entire application.

import React from 'react'
import { useTheme, useThemeUpdate } from '../../context/themeContext'
 
export const ThemToggle: React.FunctionComponent = () => {
 
   const lightTheme = useTheme()
   const toggleTheme = useThemeUpdate()
 
   return (
       <div >
           <input checked={lightTheme} type="checkbox" onChange={toggleTheme}/>
       </div>
   )
}


Redux is for many the gold standard of state management in React applications. At 4-Ti we use it in several projects. Redux is a state container for Javascript apps and allows for a single source of truth so that different parts of your application have access to the same data and can mutate it in a predictable way.

Redux is predictable, yes, but it is a decision to made carefully. If you have a static website that has a bit of user interaction that needs an interface that responds to that interaction, then you may not need Redux. However, if you are building a full-stack application with a RESTful API connected to a database and relying on third-party APIs, then Redux could be a great option. 

According to the Redux Documentation, Redux Toolkit is the recommended approach to implementing Redux Logic. We use the same approach in our projects and here’s why...it is so easy to implement! Like early versions of React, the earlier versions of Redux required a lot of out of boiler-plate code, but the logic is simplified using the Redux Toolkit.  Here are some pro’s and cons of this state management system:

Reliable. The library is very reliable and predictable. It is well maintained and there is an active community creating updates and improvements as well as addressing issues.

Insightful. Redux Toolkit allows developers to see when a request has been fulfilled, when it is pending, and when it has been fulfilled or rejected. It is easy to tap into these different stages of the request, and this nugget of information can be used to create a better user experience. It becomes easier to show a user an error message that they can act on, or display a loading spinner to indicate that clicking a button actually did something.

Maintainability. If you have a smaller application, think hard before implementing Redux because as easy as it is to use, it will become another piece of your code that you need to implement and maintain.

Learning Curve. It takes a developer some time to become familiar to how Redux works. While this is true of a lot of frameworks and libraries, I will say from personal experience that Redux was one of the more challenging libraries to wrap my head around, while the implementation is not overly complicated.

I won’t go too deep into the implementation of Redux, there are much better tutorials for that, but it can be good to have some information about different frontend state management systems.

This post will dive into different options for handling state in the frontend. Mainly we will look at the useContext hook from React and the Redux Toolkit

Frontend State Management

HL7 is a standard format used by medical facilities and healthcare providers around the world to communicate and send data. These standards were created by the Health Level Seven International and it provides a system and definitive outline for the structuring of patient and medical data. This allows for electronic medical records to be distributed globally with reduced risk of errors related to misinterpretation.

MSH|^~\&|EPIC|^LINDAS TEST
ORGANIZATION|||||VXU^V04^VXU_V04|225|P|2.5.1||||AL|PID|1||E46749^^^^MR^||DOE^JOHN^C^JR^^^L|SMITH|2
140515|M|SMITH^JOHN|2106-3^WHITE^HL70005|115 MAINSTREET^^GOODTOWN^KY^42010^USA^L^010||^PRN^PH^^^270^6009800||EN^ENGLISH^HL70296||||523968712|||2186-5^NOT HISPANIC OR LATINO^HL70012||||||||N|
PD1|||LINDAS TEST ORGANIZATION^^SIISCLIENT818|^^^^^^^^^^^^MR|||||||02^Reminder/recall-any method^HL70215|||||A^Active^HL70441|20150202^20150202 NK1|1|DOE^MARY|MTH^MOTHER^HL70063|
PV1||R||||||||||||||||||V02^20150202|
ORC|RE||9645^SIISCLIENT001||||||20150202111146|2001^HARVEY^MARVIN^K|
RXA|0|1|20150202|20150202|20^DTaP^CVX^90700^DTAP^CPT|.5|ML^mL^ISO+||00^New immunization
record^NIP001|JONES^MARK|^^^SIISCLIENT818||||A7894-2|20161115|PMC^SANOFI
PASTEUR^MVX||||ARXR|ID^INTRADERMAL^HL70162|LD^LEFT DELTOID^HL70163
OBX|1|CE|64994-7^VACCINE FUNDING PROGRAM ELIGIBILITY CATEGORY^LN|1|
V02^MEDICAID^HL70064||||||F|||20150202|||VXC40^ELIGIBILITY CAPTURED AT THE IMMUNIZATION
LEVEL^CDCPHINVSOBX|2|CE|30956-7^VACCINE TYPE^LN|2|88^FLU^CVX||||||F|||20150202102525
OBX|3|TS|29768-9^Date vaccine information statement published^LN|2|20120702||||||FOBX|4|TS|29769
7^Date vaccine information statement presented^LN|2|20120202||||||F
RXA|0|1|20141215|20141115|141^influenza, SEASONAL 36^CVX^90658^Influenza
Split^CPT|999|||01^HISTORICAL INFORMATION – SOURCE UNSPECIFIED^ NIP001||||||||||||A

All messages will start with ‘MSH’ which stands for ‘Message Header.’  The ‘MSH’ is an example of a segment, which can indicate any number of things, and is always three characters, and is located at the start of a new line. For example, the segment ‘NK1’ indicates the Next of Kin, and ‘OBX’ is an observation or result. Caristix does a great job breaking down the segments, giving context to their meanings, and also providing information about the individual fields within each segment.

If you are working in health tech, learning how to handle HL7 files is crucial. There are several options for how to work with this data. The two main routes are cloud vs. library.

Major cloud providers offer a solution to handling this sort of data. Depending on the scale of your project, the data privacy requirements, and the types of product you are engineering, there is a solution out there that is best suited for you.

Google Cloud provides and API with excellent documentation on how to best parse and transform the data. Their API works with Python, Go, Node.js, and Java. Azure’s Healthcare API for FHIR is also a very comprehensive solution that can assist enterprise solutions in the world of health tech. FHIR is a standard which is published by HL7, and any implemented solution should adhere to this standard.

If for whatever reason a cloud solution does not work for you...maybe you want a lighter-weight solution or want to hit the ground running a bit faster, there are libraries out there than can help developers parse and understand the contents of HL7 files. Here is a useful tutorial for someone building with Django and Python use the hdl7apy library. If you are building in Node.js, hl7-standard is an equally lightweight solution that can help make this hard to understand data much easier to work with.

The moral of the story is that while HL7 data is a bit wonky and not very easy on the eyes, the standards it is built on is crucial for the healthcare industry and there are solutions out there that can make hard to understand data a dream to work with.

Diving into a few options for handling HL7 documents in a web application, including working in javascript and python.

Handling HL7 Documents in the Modern Era

About 20 years of experience in IT from developer to architect. Co-founder of 4-ti. In recent years I helped building digital assets in the finance- and insurance industry.

Dani

FOUNDER, MANAGING DIRECTOR AND SOFTWARE ENGINEER

About 15 years of experience in IT, started as programmer and quickly moved to software architectures.

Tomas

Engineer with experience on a multitude of frameworks and languages and always eager to build and learn more!

Antoine

SOFTWARE ENGINEER

Business Analyst with a penchant for programming, adept at system analysis and driving quality improvements through analytical insight and technical expertise.

Kang

BUSINESSS ANALYST

Senior Software Engineer fluent in C# and .NET, seamlessly integrating with React and Angular for cutting-edge solutions.

Eliot

Full Stack Developer skilled in the latest TypeScript frameworks like Next.js and React, crafting comprehensive solutions with a passion for the latest technologies.

Nino

Software Engineer adept in modern frontend frameworks, innovatively integrating them, with a strong interest and solid knowledge in artificial intelligence.

Building software is our craft

We are proud of building software that is
robust, durable, and beautiful.

THIS IS HOW WE DO IT

Blog

Building software is our craft

We are proud of building software that is robust, durable, and beautiful.

THIS IS HOW WE DO IT

Blog

We are proud of building software that is
robust, durable, and beautiful.