The bi-partisan Federal policy incentivizing healthcare providers to adopt, upgrade and implement electronic medical record systems is fostering Health Information Exchanges (“HIE”) throughout the United States. The HIEs are developing at local and national levels to exchange patient information between providers regardless of the patient or provider’s location. Among other benefits, HIEs generally permit a patient living in a remote region to receive consultations from specialists without leaving his or her home because the patient information may be electronically exchanged between providers and made available through the HIE. The value of an HIE varies depending upon how many sources of information are being exchanged and the region that it is serving. Depending upon the sources of the information, the HIE structure may also trigger additional regulatory controls.
Electronically exchanging data requires either a regional or national database to maintain patient information or the direct exchange of data by and between remote providers. If the patient’s data is stored in a regional database, the providers and in some instances medical devices electronically submit the patient’s data. For example, a diabetes patient may monitor his or her sugar levels through a medical device monitoring system which electronically sends the test results to the database on the patient. The database through its system programming matches up a sufficient number of individual identifiers between the data in the database and the patient information received from the various sources to ensure the patient’s record is populated with his or her accurate information. Providers often query these databases to obtain information and render treatment to the patients. If there is a mismatch of a patient’s information, it may lead to a provider receiving inaccurate data which causes improper treatment and adverse patient outcomes.
Because the information contained within the HIE databases is used for patient care and in light of the potential adverse impact of inaccurate information, the Food and Drug Administration (“FDA”) has promulgated regulations to govern such medical devices data systems. A “Medical Device Data System (“MDDS”) is a device that is intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. An MDDS acts only as the mechanism by which medical device data can be transferred, stored, converted, or displayed. An MDDS does not modify the data or modify the display of the data.” Therefore, as the MDDS receives and displays the patient information, the software that connects or stores the medical device data may be subject to the FDA requirements. Because the MDDS may inaccurately receive or display patient information, an MDDS is required to comply with the quality controls and the requirements of a Class I medical device.
The FDA categorizes medical devices into three categories based upon the level of risk posed to patient care. Here, because an MDDS does not modify data and instead merely stores and displays the data received from a medical device, the FDA elected to classify MDDS as a Class I medical device. The Class I classification requires the least amount of regulatory filings and registrations with the FDA. In the MDDS regulations, the FDA has made it clear that an electronic medical record system that merely receives data through direct data entry from the provider is not a MDDS. However, receipt of patient information from a medical device and displaying such information would trigger the FDA Class I requirements. On the other hand, if the MDDS changes or modifies in any form the patient information received by a medical device and displays that information in a different format, the data system may be subject to a Class II or Class III control requirements.
For an HIE, it is possible that the data system will receive patient information from multiple sources, including providers, medical devices and patients. As the patient information from medical devices is aggregated together and ultimately displayed to either the patient or the provider, the HIE exchange should be registered and listed with the FDA. In addition, the quality design specification and any adverse events that arise as a result of the use of the HIE must be reported to the FDA for review and control.
As HIEs continue to expand and develop, a HIE must evaluate its unique functionality. If the HIE intends to aggregate data, from providers and medical devices, and analyze it to provide reports or graphs for display, the HIE may exceed the FDA Class I general controls. Ultimately, if the HIE exceeds mere display, without analysis or modification, the HIE may rise to a Class III level which in turn requires the most stringent regulatory filings, including pre-market approval.
In an industry that is continually developing and expanding, the FDA regulatory requirements will likely impact the functionality of HIEs. HIEs desire to collect as much data as possible about a patient to be useful for providers and patients. However, if a source of patient information is from a medical device and not just from providers, the HIE may be subjecting itself to additional regulatory controls. Therefore, all software programmers and HIEs being developed should not lose sight of the FDA oversight and the quality control requirements.