We were re-affirmed in our growth trajectory with this project which eventually became our first product offering. Navigating healthcare claims is a complex and costly process. Providers often get stuck in a cycle of inaccurate claim submissions, denials, corrections and re-billing that delays reimbursement and negatively impacts business performance. Cleaning up clinical coding on the front-end can have a significant impact on the settlement from payers and how quickly it’s made available to your practice. The customer - a medical billing and coding services company - approached us with the requirement to develop a claims validator/scrubber for improving the efficiency of their client's (medical providers) claim acceptance rates. FHIT.IO's goal was not to come up with just another variation to the existing scrubbers in the market, but to use our knowledge of the industry and advanced technological tools to help create an adaptive scrubber which is simple to use. What emerged is our first SaaS product offering - FusionInspector (Fi). A unique product capability that we focused on is the ability to allow medical billing professionals to write their own custom validation rules without having the need to write or know software coding or programs. The core of Fi's rules engine will eventually be advanced enough to extend the product directly to medical professionals themselves who might have smaller practices which might negate the requirement to have dedicated medical billing/coding services. The core service is completely API based RESTful integration. Our customer will integrate with system with our services using the API, pass the claim information to processed in EDI 835/837 format for batch or FHIR format for real-time on-demand. The web interface which uses the API core service will allow any user to use it from browser without API integration. The service core has a learning algorithm that can flag any data that is classified as outlier, generate standard report to explain every finding. FusionInspector (Fi) - provides extensive set of rules and validations for Medicare, Mediclaim as well as other payers. We have incorporated rules around CCI (correct coding initiative) which is promoted by CMS (Centers for Medicare and Medicaid Services), and have defined rules around LMRP, MUE, PTP edits, Add on edits, etc. The services by default has been built with extensive coding edits and a number of rules checking against male only diseases/procedures, female only disease/procedures, pediatric diseases, new born diseases/procedures, etc. In addition, it has business-logic based rules like validating claims against per-authorization and referrals, checking for correct modifier codes, checking to see if the claim is recent and relevant, etc. A number of rules have also been custom built based on specific providers request. For example: (a) A provider wanted to manually approve high value claims, before sending it to the payer. (b) Another provider wanted a rule, which will make sure relevant lab test values meet certain threshold, before a claim can be sent to insurance company. While it is currently used by our customers for code validation in claim files, with its powerful rule engine, the product will be extended to include clinical rules (using CQL/CDS). The Tech Stack: This engine is developed using JAVA, SQL and using DROOLS as the rules engine. The validator functions are exposed as Restful APIs and the request/response will have the payload in JSON format. The application is built to read EDI837, 835 and CCDA files. Reading the "Claim - FHIR v4.0" based resource is on our short term road map. Solution Architecture:
1. The Claims information is ingested as the standard EDI837 and CCD file format. A Claims processor will convert the EDI837 in an XML form and store it along with CCD (which is by default an XML file) which is further parsed and stores the claims information in the database. 2. Fi rules engine will pick up the claims data and will run it against the configured rules and the configured rules will use the terminology database having coding edits, LMRP , MUE data sets, along with other master data that is needed to perform validations. Most frequently used codes (like ICD10, CPT/HCPCS, SNOMED) can be configured for individual providers. Data in the terminology server will be synchronized and kept current by FHIT's interval based sync calls to the respective standardized publications. 3. Any validation failure will result in a response message sent to the candidate application, with proper error codes in JSON format. 4. A rules editor will be provided where an user (who does not have to know programming or coding) can easily create rules and deploy it in real time. At this point we intend to go with Drools, integrating Drools IDE into our application. A configuration database will be maintained to store credentials, audit information, configuration of rules for individual providers, etc. Phase II: In phase II, we will introduce direct configuration of rules in Drools where claim process users can write the rules using CQL (Clinical Quality Language) in HQMF (Health Quality Measurement format), and these will be converted into Drools rule by Fi's engine and deployed automatically in real time. This capability can be used for clinical validation as well as billing claim processing. The application will eventually have the capability to read EDI835, similar to reading EDI837. EDI 835 will carry denial and rejection information. This information will be fed into a learning engine, which will use machine learning algorithm to train and alert on any outlier it may find in a claim file Reception: Our initial alpha and beta candidate releases have been well received by our beta customers. We have received great feedback and financing support for the development. We are currently looking for more beta customers. If you are interested to try out this solution or know more about our product road-map, please reach out to email@example.com. We will be happy to setup a short demo and discuss incentives and pricing. -Team FHIT.