Being a software engineer is like being a superhero of code! We have to learn all the ins and outs of different programming languages, and how to make them work together like a well-oiled machine. But our real superpower is understanding the industry we’re working in. A manager of mine once said, “the most important thing to learn is the process”, which as I’ve grown I can say is definitely true. I’m interested in pursuing software engineering in healthcare, which has its own unique complexities. In the healthcare world, the job of an engineer job is to make sure that all the different systems talk to each other seamlessly and keep patient information safe and secure. They use industry standards to ensure everything is running smoothly, and they have to know rules and regulations to keep patient data under wraps like a top secret government document. And when it comes to interfacing with medical equipment, there are specific protocols designed to retrieve patient data. No easy task, to be sure. I wanted to take this blog post as a research exercise in digging around into some of the big topics involved in healthcare domain knowledge… so enjoy!
HL7
Imagine you have an electronic health record (EHR) system and a laboratory information system (LIS). The EHR system is used by doctors and nurses to document patient information, such as demographics, vital signs, and medical history. The LIS is used by laboratory technicians to process and report on test results.
A lab test is ordered in the EHR system, so a message has to be sent to the LIS with patient information, which then sends back results in another message. But… how do we actually transmit that information? Well, traditionally, this was done using a messaging standard called HL7.
HL7 (Health Level Seven) is an international standard for electronic health information exchange that provides a framework for structuring and sending messages between healthcare systems. It enables software engineers to integrate different systems and ensure data is exchanged correctly and securely.
HL7 messages are made up of segments, fields, and components, with each segment representing a specific type of data. One such HL7 message might look like:
MSH|^~&|EHR|Lab|LIS|Hospital|201910101200| |ORU^R01|12345|P|2.3 PID|1|12345|67890|Smith^John^M^Jr^MD|19850201|M|||123 Main St^Apt 4B^Springfield^IL^12345^USA||(123)555-1234|(123)555-1234||S|123456789 OBR|1|3456^Lab Test^L|3456-1^Blood Test^L|201910101200|||F|||John^Smith^MD|Lab^John OBX|1|ST|3456-1^Blood Test^L|Result|Positive|H|||FThis HL7 message is an ORU (Observation Result) message, which is used to send test results from a lab to an EHR system (you can read more about these types of messages here). The message consists of a segments labeled MSH (Message Header), PID (Patient Identification), OBR (Observation Request), and an OBX (Observation Result).
Each segment is separated by a pipe “|” character, and each field is separated by a caret “^” character. The message is read from left to right, and the software can extract the information using this format. I’ve had to work with barcode scanners a bit, and I can only imagine the suffering involved in configuring your field parsers to handle all those field separations…
FHIR
Move over HL7! FHIR (Fast Healthcare Interoperability Resources) is a newer standard for electronic healthcare information exchange, based on RESTful web services and using JSON or XML formats. It is more flexible and easier to implement than HL7, making it popular for modern healthcare applications. Unlike the “legacy” HL7 example above, a software engineer today might use this format to develop a mobile app that allows patients to access their health information and communicate with healthcare providers. FHIR is typically what we use today to access servers containing patient data, such as demographics, medications, allergies and lab results. FHIR has only been around since 2012, but with the explosion of health data, software engineers needed a way to overhaul how to easily access and manipulate records, enabling the building of more powerful and, hopefully, more user-friendly healthcare applications.
FHIR data structures, also known as FHIR resources, represent specific types of healthcare information such as “patients”, “observations”, and “encounters”. Each resource has a unique URL and can be accessed and manipulated using standard HTTP methods. A repository of samples JSON snippets can be found here. For example, an FHIR Observation resource record looks very familiar if you’ve ever worked with JSON:
{
"resourceType":"Observation",
"id":"example-lab-result",
"status":"final",
"category":{
"coding":[
{
"system":"http://hl7.org/fhir/observation-category",
"code":"laboratory",
"display":"Laboratory"
}
],
"text":"Laboratory"
},
"code":{
"coding":[
{
"system":"http://loinc.org",
"code":"30522-7",
"display":"Complete blood count [Volume]"
}
],
"text":"Complete blood count"
},
"subject":{
"reference":"Patient/example"
},
"effectiveDateTime":"2022-01-01T09:00:00+01:00",
"performer":[
{
"reference":"Practitioner/example"
}
],
"valueQuantity":{
"value":4.2,
"unit":"10^3/uL",
"system":"http://unitsofmeasure.org",
"code":"10^3/uL"
},
"referenceRange":[
{
"low":{
"value":3.5,
"unit":"10^3/uL",
"system":"http://unitsofmeasure.org",
"code":"10^3/uL"
},
"high":{
"value":10.5,
"unit":"10^3/uL",
"system":"http://unitsofmeasure.org",
"code":"10^3/uL"
}
}
]
}This resource represents a complete blood count test, the patient the test was performed on, the practitioner who ordered the test, the test result and the range of the result. This is the kind of “modern” resource that could be sent from a our LIS to the EHR system above using FHIR APIs, such as RESTful web services.
HIPAA
Shifting gears a bit, lets talk about HIPAA (Health Insurance Portability and Accountability Act).
If you haven’t heard of it before, this is a US law that sets standards for protecting the privacy and security of personal health information. Software engineers working in healthcare must be familiar with HIPAA regulations to ensure that any applications they build comply with the law and protect patient data. This includes implementing secure communication protocols, user authentication, and access controls, as well as regular monitoring and testing to detect and respond to security breaches.
Software engineers need to build their applications to comply with HIPAA in many situations, primarily involved in the collection and transfer of sensitive data. Medical devices must implementing secure communication protocols, such as HTTPS, to ensure that data is transmitted securely over the internet. Applications must have robust user authentication and access controls in place to ensure that only authorized users can access Personal Health Information (PHI). This includes implementing multi-factor authentication, and regularly monitoring and auditing user access to PHI.
Applications must encrypt PHI both in transit and at rest to protect it from unauthorized access. So, if your PHI is stored in a database or being transmitted anywhere over the internet, it has to be encrypted. Healthcare applications must also be regularly monitored and tested to detect and respond to security breaches. This includes performing regular vulnerability scans and penetration testing, as well as implementing a robust incident response plan. I work at a medical device manufacturing company, and recently we just paid a huge sum of money to a consultant to do penetration testing on some of our devices. Lucrative job if you’re looking for the big bucks!
Needless to say, there is a lot to consider when handling healthcare data. Software engineers in this field also have to design for robust data backup and have disaster recovery plans in place to ensure that PHI can be recovered in the event of a data loss or disaster, and those same applications must be able to produce audit logs and reports as required by HIPAA regulations to demonstrate compliance with security and privacy requirements. Even though I work for a manufacturing company, the largest department in the office is Quality, which is most concerned with documenting every scrap of process data in the fear that when we get audited, because we will get audited, that our data is in line.
DICOM
The final big kid on the block when it comes to healthcare tech acronyms: DICOM (Digital Imaging and Communications in Medicine). This is effectively the standard for handling, storing, printing, and transmitting information in medical imaging. It’s used in everything from patient management to treatment planning to making sure your CT scans and MRIs are stored and displayed correctly.
Think of it like this: imagine a radiologist who wants to view and analyze medical images. They use a special DICOM viewer application to do that. This application uses DICOM to communicate with a DICOM server, where all the medical images are stored in a special DICOM format. The application then displays the images in a user-friendly way for the radiologist to view and analyze. They can even add their own notes, measurements and other information to the images, which are then saved back to the DICOM server.
I don’t know much about image processing (I’ve never written a graphics program and man, was Parallel Programming a eye-opener into how complex that topic can be), but DICOM has been around since 1983 and there isn’t really a big alternative that I could find, so its essentially a standard way of processing images that all medical imagery equipment and applications have to be built to handle.
Conclusion
Every industry is different, and sometimes engineers focus on the tech stack when they should be focusing on understanding how to best solve the problems of the domain. The core of the healthcare domain is all about securely generating, storing and transmitting personal health data, so the technologies and tools used in healthcare reflect that. There are many pieces involved in this industry, and this research gave me a chance to learn a lot about how regulations impact software engineering. I hope you found this interesting, I certainly did. Anyways, thanks for coming to my Ted talk!
