Our Work

LTCS was the lead developer for a small team tasked with creating a subscription based web application to translate International Classification of Diseases (ICD) codes from one version to another. The web app named ICDx Converter was needed due to the many versions of ICDs and the complexity of translating from one to another.

The ICDx Converter consisted of three main parts:  (1) user and subscription management, (2) ICD code lookups, (3) ICD code mappings. ICDx is a responsive web app and is required to work on mobile devices.

ICDx’s user and subscription management has a simple registration process that allows a user to register an account with an active email address. Once the email is confirmed the new user will be directed to a payment page to create a subscription. Users are separated into three categories: (1) admins, (2) customers/doctors (3) billers. Admins have access to import and manage ICD codes. Customers with an active subscription can search for codes. Billers can update subscription statuses but not manage codes.

ICDx’s code lookups allow authorized users to find ICD codes. The can enter a common medical ailment or part of an ICD code. From there the customer is asked a series of questions which will lead to the correct ICD code. It was particularly important for this user interface to be responsive as the majority of code searches are done from mobile devices.

ICDx’s code mappings are limited to the admin user type. Authorized users can create new generic codes and description. They then add questions and answers that will map to a specific code. Each question has a selections of answers that can link to new question and answers or to an ICD code. The depth of the question and answer mappings is unlimited.

This project was successfully completed on time and with in budget. The software is now live and in daily use.

Technology Stack:  Objective C

LTCS took over the development of a Beta version of an existing iOS app called Visual Analytics Law Enforcement Toolkit or iVALET. It is designed to allow law enforcement and first responders access to real-time criminal, traffic, and civil incident data via a compatible iOS device.

iVALET has three main functions: (1) viewing of current real-time crime data, (2) reports and views of past crime data, (3) forecasting for future incidents. The main UI interface was built on top of the Google Maps SDK for iOS.

iVALET’s main view displays real-time crime data for a desired set of activities. The types of activities shown are configured in the settings sections of the app. For example you could set the view to only show criminal data or just specific crimes within the criminal data set. Each data point is represented by a pin on the map that can be expanded to access more information. The data is refreshed every 60 seconds if the app was running in the foreground.

iVALET’s reports and views of past crime data allows a users to look at historical data based on date ranges. The app has no internal storage so devices would be have to be connected to data networks to run historical reports or refresh real time data. The app also has a timeline feature that allows a user to watch a graphical representation of changing data points over a set period of time.

iVALET’s forecasting utilizes a temporal prediction algorithms to forecast future criminal, traffic and civil incident levels within a 95 percent confidence interval, meaning the estimates of the collected data could be reliably used to predict future behaviors or actions.

Technology Stack:  Ubuntu. Java, Spring, BootStrap,PostGres

LTCS was the lead developer tasked with building a custom platform to run on medical grade tablets that were used  to calibrate and monitor the pH of fluids in up to 8 separate culture pods.The software (HYDRA) was designed to read and send data to client built optical sensors connected via USB.

We started by helping the client decide on the proper hardware to develop this software on. After trying a few options we settled on the Teguar Medical Tablet PCs. Next we picked Ubuntu 14.04 LTS for the OS and Java Spring web app running on Apache Tomcat. Google’s Chrome browser was used to access the user interface.

HYDRA has four main functions: (1) Calibration and Standardization, (2) Sensor configuration, (3) pH Sensor monitoring, (4) download pH readings.

HYDRA’s calibration and standardization gives the user the ability to implement technical standards to each pod. The user will start the standardization process by equilibrating the sensors overnight. Once this is completed you can configure the pod sensor for use.

HYDRA’s sensor configurations lets you update a sensor’s acceptable pH limits and run quality assurance tests to make sure the sensor was working within acceptable parameters. Each sensors operational lifetime varied.

HYDRA’s ph sensor monitoring had two views. The home page and individual pod views. The home page was a color coded live view of all active pods and their last pH reading. The individual pod page showed a detailed view of the pod and a configurable graph representation of the data.

HYDRA’s download function allowed authorized users to download a CSV file of pH data from the pod sensors. The interface allowed the user to select one or all pods and date range of data to download. The user also had the option to download all available data.

Technology Stack:  PHP, Selenium, MySQL, Laravel, Jquery, BootStrap

LCTS was the lead developer in a small team tasked with creating an automated screen scrape tool for two social media sites. The web application is called Data 360. Data 360 contained a responsive web application that gave users access to the scraped data.

Data 360 had four main components: (1) user and project management, (2) database querying and management, (3) Selenium screen scraper for social media sites, (4) spider a website. Data 360 was designed to automatically scrape two social media sites  Ask.fm and Vkontakte.com.Selinum would crawl the site and scrape data based on some configurable terms and store the results an a full-text search enable MySql database. This data can then be queried and archived from the web interface.

The Data 360 user and project management component has a three tier authentication system. The three role ares: (1) Admin, (2) Read-Only, and (3) Read-Write. Data 360 project management allows authenticated users to create projects that will be used to store specific database queries relevant to that project.

The Data 360 database querying and management section allows authenticated users to query all databases with an open text field. You can preview or export the results. Authorized users can also access a graphical view of the database structure off all associated databases.

The Data 360 Selenium screen scrape tool is two customized instances of Selenium, that would crawl the social media sites Ask.fm and Vkontakte.com. It scrapes and stores postings and some images based configurable search terms. The scrape is automated to fire off every night and there is also an archive procedure to keep the active data set from getting too massive.

The Data 360 spider a website feature allows an authorized user to initiate a web crawl of a certain website and screen scrape data based on certain terms. The data derived from these crawls could be queried and then archived once it was no longer needed.

Technology Stack:  PHP, MySQL ,CodeIgniter., Propel, JQuery

LTCS was the lead developer for a team hired to update the MarketLink Brokerage System (MBS). The MBS was a major overhaul of an existing CRM system and added many features. We made some major revisions to the db structure for new features and performance. There was also a huge code refactor to put the existing codebase into the CodeIgniter framework and Propel ORM.

The MBS system consisted of a custom CRM that allowed clients (farmers) to communicate with brokers who buy their grains.Clients could also track their shipments.from associated carriers.The CRM portion consisted of many common client and sales tracking features.

MBS consisted of four main parts:  (1) client functionality,  (2) broker functionality, (3) carrier functionality, (4) QuickBooks accounting integration. The legacy system had a basic model and authentication system for clients and brokers but this was greatly enhanced and integrated with the new carrier and accounting pieces.

MBS client functions allow an authorized user/farmer to search for brokers to sell their grains to. Clients can also communicate with the brokers and would receive email reminders about new pricing and other news. After selling their grains clients could then search and communicate with carriers who would ship their grains to their destination. Tracking of shipments was also available.

MBS broker functions allow an authorized user/grain broker to post prices and quantities of grains they were looking to buy. Brokers entered their geographical data in to MBS, which allowed clients and brokers to use proximity to decrease shipping costs and prevent spoilage. Brokers can also communicate with clients and carriers.

MBS carrier functionality allow an authorized user/grain shipper to post prices for grain shipments by weight and distance from clients to brokers. Carrier prices are perishable and changed due to the variable price of fuel. Carriers can also communicate with brokers and clients about shipping rates and statuses.

MBS Quickbooks integration allow MBS invoices to by imported into Quickbooks once certain criteria were meet. Both client and carrier invoices were included in the sync. Quickbooks would also update the invoices in MBS once they were marked as paid.