Twenty years ago, just one hospital, one laboratory, and one payer may have had access to a patient’s data. Today, it is dispersed across countless different health systems, hospitals, pharmacies, payers, and other critical care providers. This has made it extremely challenging for organizations to exchange, access, and use healthcare data, given the different systems and methods they employ to store it.
On the administrative side of healthcare, inefficient data exchange can significantly delay prior authorization, medical billing, reimbursement, and other processes critical to maintaining the financial health of provider organizations. In recent years, a number of initiatives have been launched to overcome these interoperability challenges, including Fast Healthcare Interoperability Resources (FHIR). Developed by Health Level 7 (HL7), FHIR is a set of standards that defines how healthcare information is electronically exchanged between different systems, such as hospital servers, vendor applications, devices, and more. Systems that use FHIR standards can quickly and securely exchange healthcare information in real-time, regardless of how the data is stored in each system.
For a deeper dive into the technical aspects of FHIR, visit HL7’s Overview of FHIR.
At Nym, we’re leveraging FHIR to make it easier and faster for our clients to get our autonomous medical coding engine up and running. When it comes to autonomous coding, FHIR has proven to be an invaluable tool that facilitates interoperability and implementation, and enables flexibility and scalability.
Nym’s medical coding engine, which uses AI to decipher the full medical record and instantly assign medical charge and diagnosis codes, requires healthcare data to be in a standardized format. When we receive medical records from our clients, the healthcare data can be in a variety of different formats depending on the EHR the client uses (Epic, Oracle Cerner, Allscripts, etc.). The data formats can also vary based on client-specific documentation guidelines.
Before adopting FHIR, we invested considerable time configuring the Nym engine prior to go-live so that our engine could parse through the specific EHR format each client uses and restructure the data in patient records into a standard format. Today, using FHIR, this level of configuration is no longer required. Nym’s engine can now retrieve healthcare data in a standardized format from any client using an EHR platform that supports FHIR.
It’s a win-win for both Nym and our clients, and here’s why:
Faster Implementation: By reducing the time required for engine configuration, FHIR accelerates Nym’s implementation process. This means that clients who support FHIR can go-live much faster and start to reap the benefits of autonomous coding such as improved coding quality, reduced costs, and accelerated payment cycles.
Reduced IT Lift: Without FHIR, clients must allocate time and resources to manually configure and validate the format in which patient data is sent to Nym, which can take weeks and even months. This is typically handled by health IT departments, who are notoriously overburdened. FHIR standardizes the format for healthcare data and enables organizations like Nym to pull the data they need via an application programming interface (API), versus relying on health system IT teams to set up a full integration. The result is a meaningful reduction in the number of IT staff needed on the client’s side for successful implementation.
Health systems, electronic health record (EHR) companies, software vendors, and other types of healthcare organizations have been quick to adopt FHIR standards to improve interoperability, with widespread adoption expected by 2024. Looking to the future, we are excited to keep a pulse on any new FHIR updates and features that the Nym can leverage to continue providing the highest level of service to our clients.
If you’re interested in learning more about Nym and the benefits of automating medical coding, we would love to hear from you!
Powering automation in revenue cycle management.
.png)