When creating an application that will be used by health care providers, a developer will often need to access data about a patient. This data is kept in Electronic Health Record (EHR) systems.
As a developer, one of the main struggles of creating such an application is that EHRs are not guaranteed to follow the same formatting, standards, etc. This means that a developer might have to rewrite an application for each hospital that wants to use the application because they’ll need it to fit into their unique EHR system.
On the flip side, this makes it quite difficult for a hospital to try out different applications because they can’t simply swap a new application in and out of the EHR system without going through the trouble to make sure that the new application will work with their specific EHR.
This makes it hard for both new applications to come into existence, and for hospitals to try out new applications. If only there were Substitutable Medical Applications and Reusable Technologies that allowed hospitals to try out solutions from various developers until they found what they needed.
Sounds like a SMART idea, right? Sorry, it had to happen.
What is SMART?
SMART provides a standard for how EHR systems and their applications authenticate and integrate. By standardizing these processes, health care providers can utilize more apps, and developers can write apps for a wider audience.
There are several things that SMART does for the developers creating these applications. SMART handles the authorization of a user accessing a patient’s data and maintains an open source library for developers to use. It also provides and maintains free API “sandbox” servers that developers can use for testing their application. These sandboxes are important for development because a SMART application cannot be launched a by simply navigating to a URL. SMART provides a **context **to the application when it is launched from the EHR that contains information about the user and the patient. The sandbox simulates a healthcare provider launching the application with one of many fake contexts with generated patient data.
While “patient data” is an idea that can be bundled up into two succinct words, it is far from simple or consistent. On the contrary, humans are complex and unique, and the data that a health care provider might need to accurately understand and assist a given patient is rightfully complex as well. What’s worse is that this complex data may be structured differently depending on the hospital or region in which an application is used. Take a patient’s name for example. Some people have a middle name, some do not, and some have more than one. Some people have prefixes, suffixes, more than one given name or last name, and so on. A developer may have to write special code just for handling how names are structured in a given healthcare provider’s data warehouse, let alone the rest of the data.
What is FHIR?
As you may have guessed from the title of this article, SMART is not enough to bring the kind of desired consistency to software in the healthcare world. FHIR (Fast Healthcare Interoperability Resource) is a technology that is beginning to provide some consistency to the data that SMART-compliant EHR systems access. FHIR provides an API and a set of data models for structuring and accessing medical data. This way, a developer doesn’t have to worry about releasing a special version of their application so that it will properly handle the way that data is structured in a given system.
This is how the name SMART on FHIR came to be. It refers to a SMART-compliant EHR system on top of a FHIR server.
Developing a SMART on FHIR application
I’ve been developing an application that uses SMART on FHIR for a few months now and I’ve learned a lot about it. It’s an incredible step for software in the medical community, but it comes with its challenges.
First, it’s a young technology and there are times when you can feel it’s growing pains. When you run into an error or need to ask someone a question, it takes a lot more searching to find someone with the same problem as you (if you ever find that someone). Often, you will be left to figure it out on your own.
Also, while FHIR is a great step in the direction of consistency, that doesn’t mean that it gives a lot of guarantees about what data will be provided. Most values you get from FHIR will be optional because some patients won’t have a value provided for them.
Going back to our example of patient names, in FHIR, a name is made up of many parts (prefixes, given names, family names, suffixes, and so on). Notice that all those words are plural (and therefore represented as arrays). A person could have more than one of any of those name-parts or not have it at all (optional). That means that even the ‘simple’ task of showing the patient’s name on the screen might take multiple conditional statements and loops.
To be clear, this isn’t FHIR’s fault, but rather a product of trying to standardize the broad world of medical data. It can, however, make development more complex and the code a little messy at times.
Tips for developers:
If you’re getting started with SMART on FHIR development, here are a couple other miscellaneous tips as you get started:
- Your application will be launched from an EHR system. This means your application is being launched inside another application, so try to stay away from things like external links because they may not behave the way you expect in the real world.
- The data in the SMART Sandbox is reset nightly, so don’t be surprised if data you have created for a specific patient is disappearing on you the next day.
- If you find you would like to have more control over the sandbox and it’s reset times, you can set up a self-hosted sandbox. This has been a very helpful tool for our team.
- You can even go one step further and create a mock sandbox from scratch and only return the things you need from it. This can be useful, especially when writing automated tests for your application.
- Also, you are given access to a lot of information from the SMART context. It can be easy to ask for more than you need, so make sure to limit your requests down to what is only necessary when dealing with patient information.
- If you’re looking for documentation on FHIR ir data types, check their website: https://www.hl7.org/fhir/
- For more information about SMART visit their website: https://smarthealthit.org/
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
