Skip to main content

2 posts tagged with "billing"

View All Tags

· 2 min read
Joshua Kelly

Claims data is a uniquely rich source of financial and clinical data important to many healthcare workflows. The EDI 837 Health Care Claim transaction is one of the oldest forms of electronic data exchange, stemming from being defined as a required data transmission specification by HIPAA.

Today, we are showcasing Flexpa which connects applications to claims data via direct patient consent and a modern FHIR API powered by Medplum.

How does it work?​

Flexpa aggregates and standardizes Patient Access APIs created by payers as required by CMS-9115-F. First, patients authenticate and consent to a data-sharing request from an application.

Then, Flexpa extracts, transforms, and loads payer responses into a normalized FHIR dataset. Flexpa stores data in a temporary FHIR server cache during the period for which a patient has granted access.

Finally, applications receive a patient-specific authorization response which can be used to retrieve data from a FHIR API provided by Flexpa – powered by Medplum.

Flexpa

What problems does Flexpa solve?​

Payer FHIR servers offer an extremely variable API experience and implementing against 200+ of them is painful. Using Medplum as a data cache for their own FHIR API allows for a uniform developer experience on top of the underlying network access. Flexpa allows developers to use claims data to deliver risk factor adjustment scoring to value-based care providers, help patients navigate care, join clinical trials, negotiate bills, and more.

How does Flexpa use Medplum?​

Flexpa takes advantage of several important features of Medplum’s FHIR implementation:

Medplum’s open source implementation provides Flexpa with the ability to contribute back to the project when improvements or changes are required. Additionally, Medplum’s technology choices and stack align perfectly with Flexpa’s making working with Medplum easy for Flexpa’s development team.

· 3 min read
Reshma Khilnani

What is ONC Certification?​

ONC Certification graphic

The Office of the National Coordinator for Health Information Technology (ONC) certification is a program that ensures that electronic health records (EHRs) meet certain standards for interoperability and security. It is designed to help healthcare providers adopt and use EHRs more effectively, and to promote the widespread adoption of EHRs as a means of improving the quality and efficiency of healthcare. To be certified, an EHR must meet a set of standards and criteria that have been developed by the ONC in collaboration with other organizations and stakeholders in the healthcare industry. These standards cover a range of areas, including the exchange of health information(g10), patient access to their own health data (also g10), and the protection of sensitive health information(d1,d13,g12). By achieving ONC certification, EHRs can demonstrate that they meet these standards and are ready for use in a wide variety of healthcare settings.

From a technical perspective - the most important thing to understand about the certification is that it requires FHIR API access - for patients and practitioners.

The Benefits of Certification​

The benefits of certification vary by the type of provider. The following are very tangible benefits to getting certified.

  • For those with a large CMS (Medicare, Medicaid) population, getting reimbursement at the optimal rate will require certification.
  • Supporting CMS Queries will streamline contracting with payors (other than CMS), who want insight into "quality metrics" and technical touch points.

Beyond the above there, certified systems do gain a benefit in contracting and partnerships because partners know they have a streamlined interface to exchange data.

The Certification Process​

The certification process has is driven by examination, there are certification vendors, e.g. Drummond, who proctor vendors through a walk-through of developer products according to a specific script.

Some of the criteria, for example g10 have standardized test harness, like Inferno or Cypress, that verifies that APIs are working as expected.

This video shows an example of the Inferno tool in practice. The proctored exam will have developers walk through the test session like this one, and the output will be verified by the proctor.

Running the Inferno test harness as shown in the video will be meat of what goes on during the certification examination for that g10 criteria.

The Developer Perspective​

For developers, it is important to understand that there are two types of criteria.

  • Self attested criteria: these will not be tested by the examiner, instead organizations will have to self-attest that the functionality is available and provide some documentation.
  • Live tested criteria: these will be tested by an examiner, in accordance with the scripts.

You do not need to certify for all criteria at once, you can batch them up and pursue subsets.

Prepare for frequent requirements changes. The regulations and requirements do change frequently, with amendments coming out each year. If you are on point to deliver a system with a certain compliance profile, you can expect to need to adapt to the changing regulations and requirements.

There are "spot" solutions for many specific functionality types, for example ePrescribe, custom reporting or vaccine registry transmission, which can be composed together to support many configurations.

However, at the core of your system, we recommend a highly programmable, well-documented. FHIR enabled infrastructure like Medplum as a base. This will give you the infrastructure needed to orchestrate the ever-changing suite of tools needed to comply with the required regs.