The healthcare industry is undergoing a profound transformation due to technological advancements that result in streamlined processes, elevated patient care, and enhanced communication efficiency among industry participants. From EHRs and EMRs to telemedicine solutions to healthcare wearables, digital technology is paving the way towards a more interconnected healthcare landscape.
To ensure the safety, efficiency, and interoperability of healthcare software solutions and services, compliance with rigorous standards is paramount. In our lineup of interviews, we have thoroughly addressed HIPAA, PHIPA, DICOM, HL7, and other well-known healthcare regulations. Today we are going to focus on two less familiar but important standards — ONC and FDA 21 CFR Part 820. And since we have a lot to cover, buckle up, we are diving right in.
Let’s start with ONC. What is it all about?
The Office of the National Coordinator for Health Information Technology (ONC) operates within the U.S. Department of Health and Human Services. Founded in 2004, ONC is dedicated to fostering the advancement and widespread adoption of health IT and ensuring the secure exchange of health information.
Essentially, ONC is responsible for establishing standards, issuing certifications, and overseeing the exchange of healthcare information. ONC standard applies both at the federal and state levels. The overarching objective is to ensure the development of reliable and thoroughly tested healthcare software solutions.
In addition, ONC provides out-of-box solutions that can be used by private and state organizations:
- Apps – tools that help to visualize and analyze open data;
- Quick Stats – visual representations showcasing essential health IT data and statistics;
- Data Biefs – offering statistics on health IT adoption and usage, derived from surveys and administrative data, along with comprehensive analysis of health IT policies and programs.
- Datasets – comprising data sourced from surveys and programs sponsored by the government.
Let’s talk about the ONC Health IT Certification Program. What does it entail?
Introduced in 2010, the ONC Health IT Certification Program aims to guarantee that health IT solutions adhere to essential standards for security and interoperability. The program is grounded in the principles set forth by ISO and IEC.
It should also be mentioned that ONC Health IT Certification Program is voluntary. If you are developing a healthcare solution just for your own use, you can skip the certification process altogether. However, considering that most software solutions are used by a wide range of medical and non-medical organizations, certification becomes mandatory.
That said, ONC doesn’t directly perform conformity assessment or provide certification. For that purpose, ONC collaborates with authorized third parties. These parties include a testing laboratory responsible for testing activities and an accreditation body that provides the official certification. It’s clear that without passing the tests first, a solution or a software module will not be eligible for the certification process.
Those health IT modules that have been tested and certified through the Certification Program are included in the Certified Health IT Product List (CHPL). Every software solution listed on the CHPL is assigned a CHPL Product Number by the authorized certifying body.
As for the process of certification, it follows the stages described below:
Let’s circle back to the ONC certification criteria. What do they include?
The ONC certification criteria are functional requirements that must be met when developing a health IT solution. To offer additional insights and clarifications to the certification criteria, ONC has also crafted a Certification Companion Guide.
Since the inception of the Certification Program, ONC released three versions of the certification criteria, each time building upon federal laws and rulemaking. The latest edition is the 2015 Edition Cures Update, which specifically addresses modifications required by the 21st Century Cures Act.
There are sixty certification criteria, organized into 8 categories as follows:
Source: HealthIT.gov
ONC has set up the Conditions and Maintenance of Certification requirements, specifically describing how to maintain the necessary level of qualification for both developers and the system itself.
Do you have any recommendations for those who develop healthcare solutions?
In my experience, dealing with ONC requirements can be tricky. Below I have summed up some practical tips that work:
- If you are developing a healthcare software solution for the US market, it is recommended to have a medical or health adviser on board. Having this expert in your corner allows you to get the necessary guidance without inconveniencing the client.
- Regulatory compliance, particularly in the healthcare industry, is very complex, expensive, and time-consuming. Whenever possible, try to engage with an ONC-certified adviser who can consult you on the standard’s requirements, help with preliminary assessment, and provide support throughout the entire ONC certification process.
- Although some parts or modules of the system under development may not be certified in compliance with the ONC standard yet, they can be used within the organization. Full ONC certification is only mandatory when the system is intended for use at the federal or national level.
Indeed, ONC plays an important role in advancing interoperability and driving patient-centered healthcare. Now, what about FDA 21 CFR Part 820? What is this standard for?
FDA 21 CFR Part 820 is a set of guidelines set by the Food and Drug Administration (FDA) as a way to guide manufacturers in the right direction when it comes to making medical devices.
This quality system regulation (QSR) is like a handbook that guides the design, monitoring, and maintenance of manufacturing facilities and processes. Its main aim is to ensure that the end product – medical devices – is safe and effective.
Below you can see the place of Part 820 in the overall hierarchy of FDA regulations:
Let’s break down some of the key terms in FDA 21 CFR Part 820:
- Quality system refers to the overall setup — structure, responsibilities, procedures, processes, and resources — for effective quality management.
- A manufacturer is anyone involved in designing, making, assembling, or processing a finished device. If a manufacturer does some but not all the activities mentioned in this regulation, they only need to comply with the applicable requirements for those specific operations. The term also extends to entities involved in installation, re-labeling, re-manufacturing, re-packing, specification development, and initial distribution.
It’s important to note that the FDA considers someone a “manufacturer” even if they outsource all manufacturing activities. However, this regulation doesn’t apply to those making only components or parts of finished devices. Yet, such component manufacturers are encouraged to follow relevant parts of this regulation as guidance.
The FDA keeps tabs on compliance through two types of inspections: planned ones that are announced ahead of time and unannounced inspections. They use the Quality System Inspection Technique (QSIT) to check if internal quality processes line up with regulatory requirements.
Non-compliance with any relevant provision renders a device adulterated, and both the device and any party responsible for the non-compliance are subject to regulatory action. Violations may lead to the issuance of Form 483 Observations and warning letters.
While the FDA does not mandate a pre-registration audit, legal compliance with applicable sections of the Quality System Regulation (QSR) before introducing a device to the market is obligatory.
FDA 21 CFR Part 820 seems similar to ISO 13485. What are the key differences?
Both standards address quality management systems for medical devices, but they have different scopes, purposes, and regulatory contexts. The main differences include:
- FDA 21 CFR 820 is obligatory, while ISO 13485 is optional;
- FDA 21 CFR 820 is specific to the United States;
- ISO 13485 adheres to a modernized structure, whereas FDA 21 CFR 820 has maintained the same format since 1997;
- FDA 21 CFR 820 is solely developed by the FDA, whereas ISO 13485 was created through collaboration;
- There is a planned effort by the FDA to align the Quality System Regulation (QSR) with ISO 13485.
What does this standard mean for software development companies?
A software development company can support manufacturers by developing electronic QMS (eQMS) solutions for medical device companies to meet compliance requirements. This eQMS can include the following components:
- Design controls to ensure that medical devices are designed according to their requirements.
- Document control module to enable approval and distribution of key documents, ensuring they are both secure and accessible when needed.
- Supplier management to evaluate suppliers and contractors as well as to manage records and purchasing data.
- Records and complaints management to make sure that records are available for FDA inspection.
- Implementing closed-loop traceability so that the medical device can be traced back to its source.
The bottom line
Building a healthcare solution is not an easy feat, and at Elinext we understand this reality well. Technological decisions must always be balanced with stringent regulations to ensure efficiency, interoperability, data security, and patient privacy. Our healthcare domain knowledge stems from over 20 years of delivering custom medical solutions including EHRs and EMRs, mobile healthcare apps, pharmaceutical solutions, medical billing platforms, and beyond. To illustrate the case in point, have a look at a case study about a large-scale 21 CFR Part 11-compliant SaaS platform. This platform was specifically designed for clinical trial management and collaboration, showcasing our commitment to meeting high regulatory standards in the healthcare industry.
