Health Language Blog

Overcoming the Complexity of Customizable Data

Posted on 03/01/17

iStock-497281146.jpgEMR and other healthcare software applications must maintain dropdown lists of codes, which are regularly updated by the standard bodies. As a software vendor you need to ensure that you are monitoring for updates, analyzing each update to determine what actually changed, and then incorporating the updates and shipping updated code to all of your customers. In this blog, I discuss the challenge of managing codes and dropdown lists on your own, as opposed to using a terminology management solution to manage these frequent updates for you.

Certain dropdown lists are easy to maintain on your own, such as lists of US states, for example. Most people are familiar with filling out an online form on which you enter an address, state, and zip code: one of the fields on that form usually has a list of states to choose from. State data is easy to maintain as of course the list of states rarely changes. Static data like this is typically manageable on your own.

In your application, however, you will likely find that you need a list of entries that do not comprise industry-standard values, such as geographic data. An example of this would be a dropdown that contains “regions.” Most likely your clients do not all serve the same region, or their breakdown of regions is different than the default standard set of values. Part of this challenge is that customers can update default values, as well as add their own values. And you wouldn’t want one customer seeing another customer’s set of values for this field. This scenario also introduces more complexity when you need to add or change one of the default regions that ship with the product. You must make sure a customer hasn’t already changed or deleted one of the regions that you are about to update.

Your application likely also includes dropdown lists for information maintained by a standards body, such as the UB-04 billing codes. The National Uniform Billing Committee (NUBC) owns and maintains these codes and will issue updates from time to time to add, remove, or change codes in the standard. If you are using this data in your application, you must continually monitor the NUBC website for changes. When you detect a change, you then must determine what changed and how to incorporate those changes into your application.

For instance, so far in 2017 NUBC has introduced three new codes that you would need to add to your application. One of those codes is 0815, Acquisition of Body Components – Stem Cell Acquisition – Allogeneic. If you are managing a pick list of these codes yourself, you had to write the scripts to propagate this content to all of your customers’ databases. Two other codes were also added as part of the UB-04 update that you had to detect and place in your system.

This is just a single example of a routine terminology maintenance task. Imagine having 100 of these dropdowns that you are maintaining, for 100 clients that each have customizations. This becomes an unwieldy process that is error prone and difficult to maintain on your own. Monitoring all the standards bodies for updates and writing scripts to place all of them in customer databases would require multiple full-time employees—it would be time intensive and can result in errors. Further, this requires your employees to focus on a part of your business that may not be a core competency.

However, with a terminology solution such as Health Language, no database design is required and you do not need to detect and curate industry-standard terminology data for your dropdown lists, as Health Language does this for you. You simply integrate our web service into your application, and set up the web service to identify each customer’s custom picklist, and the system will return the appropriate values. You can sit back and watch your system display the most up-to-date codes for your customers’ custom dropdown lists, while we take care of the mundane but critical task of keeping the industry standard data up to date.

 Customised code groups - CGM technical blog.png

Example of integration with Health Language’s Customizable Code Group feature.

The call to the web service would look something like this:

As you can see, certain dropdown lists are easy to maintain yourself, while for others you should rely on solutions like Health Language to save time and effort as well as to increase customer satisfaction by reducing the potential for submitting invalid codes.

What are some of the challenges you face in keeping your codes up to date or creating custom dropdown lists? Please share them below.

Topics: code groups, customizable code groups, custom dropdown list, healthcare software applications

About the Author

Brian Laberge, Jeff Williams, and Jeremy Kasmann - Brian Laberge is our Director of Client Service Strategy. Brian joined Health Language in September 2010 and has served in multiple capacities including Technical Consultant, Project Manager and Director Of Client Implementations. He brings 18+ years of implementation and software deployment experience to Health Language. He has managed several Data Normalization and ICD-9 to ICD-10 projects for Payers and Providers during his tenure at Health Language. Jeff Williams is the Director of Client Operations. Before joining Health Language five years ago, Jeff built a foundation of technology leadership working as a software developer, leading development teams, and focusing on product design and architecture. Jeff is responsible for the technical services team at Health Language, and creates client success and satisfaction through proven integration strategies, operational excellence, and service differentiation within the Customer Support, Implementation, and Solution Architecture areas. Our Development Manager, Jeremy Kasmann brings 13+ years of software development and architecture experience to Health Language. He currently manages development of Health Language's product suite and interoperability APIs.