System and method for using unique identifying data for precautionary determination to send notifications to a user to reduce potential negative health outcomes related to implantable devices and recall, adverse event data

Abstract

One method involves pulling, or receiving, a list of recalled device data. Subsequently, the recalled device data is compared to information in a user's TrackMy health record. Based on this comparison, a determination is made as to whether one or more matches exist between any of the recalled devices in the list and the TrackMy health record information, the match relating to the potential for a negative health outcome if the user is not notified of this. If a match exists, a response is outputted relating to each match and a notification is sent to the user's contact information stored TrackMy health record.

Claims

1. A method in a computing system for preemptive determination of the potential to send a notification to reduce potential negative health outcomes related to implantable devices and recall, adverse event data to a person having an electronic health record, the method comprising the steps of: accessing device-person tables that maintain specific sets of unique device identifier data including device identifier, lot number, serial number, expiration date; accessing extracted device-recall tables that maintain specific sets of unique device recall data including device identifier, lot number, serial number, expiration data, recall data, reason for recall; access extracted device-adverse_event tables that maintain specific sets of unique device adverse event data including device identifier, lot number, serial number, expiration date; employing a control server to compare the device-person table data against device-recall data; determining that at least one match exists between any of the selected devices included in the device-person, and device-recall tables, wherein at least one match indicates the potential for a negative health outcome if the user is not notified; determining that at least one match exists between any of the selected devices included in the device-person, and device-adverse_event tables, wherein at least one match indicates the potential for a negative health outcome if the user is not notified; sending a notification to a user following determination of a match existing using a user's demographic contact information stored in person table and sending said notification to medical staff of the user; storing said notification in said device-match table for future reference; and, creating a user to device list wherein upon a recall occurring the present invention tracks which users previously received said notification and sending this list of previously informed user to medical staff of them.

2. The method of claim 1, wherein the accessing device-person tables include: data population of this table through one of the user manually using a User Interface (TrackMy Implants Application) to search and save an Implantable device, the capturing of unique device data through the use of Smart on FHIR integration with electronic medical records, the direct interface of unique device data to server (TrackMy) through an HL7 established interface with another healthcare related technology system, and the manual upload/data entry into the device-person table by an individual or through an automated scanning process.

3. The method of claim 2, wherein the user manually uses the TrackMy Implants User Interface to populate the device-person table consists of using a search box that is connected to a central database for devices that get manufactured and contains corresponding identifying information for an individual device.

4. The method of claim 2, wherein the capturing of unique device data through the use of Smart on FHIR integration with electronic medical records to populate the device-person table consists of a user clicking a button that calls a FHIR API endpoint for either an electronic medical record or a patient portal system.

5. The method of claim 2, wherein the direct interface of unique device data and user demographic data to server (TrackMy) through an interface with another healthcare related technology system consists of the direct interface sending of unique implantable device data and this data to be matched to unique user demographic data, the server then saves this data to the device-person table used for ongoing tracking

6. The method of claim 1, wherein the data population of the extracted device-recall table consists of a making a direct API call a central database that stores devices that have been recalled and corresponding recall details.

7. The method of claim 1, wherein the data population of the extracted device-adverse event table consists of a making a direct API call a central database that stores devices that have had adverse events and corresponding adverse event details.

8. The method of claim 1, wherein the potential negative health outcomes include: death wherein a recall occurs without dissemination to a user who perishes; life-changing injury wherein a recall occurs with delayed dissemination to a user who endures injury until acting upon the recall; and, injury wherein a recall occurs from metallosis.

9. The method of claim 1, wherein determining that at least one match exists between any of the selected devices of the device-person table and the device-recall tables further comprises: matching at least one of device identifier, lot number, serial number, expiration date; and, verifying at least a minimum match upon device identifier and wherein no match on device identifier occurs the present invention does not notify a user and wherein a match on device identifier occurs the present invention generates an action on the control server to send a notification to the user said notification informing the user to seek immediate medical attention.

10. The method of claim 1, wherein determining that at least one match exists between any of the selected devices included in the device-person table and the device-adverse_event table further comprises: matching at least one of device identifier, lot number, serial number, expiration date; and, verifying at least a minimum match on device identifier and wherein no match on device identifier occurs the present invention does not notify a user and wherein a match on device identifier occurs the present invention generates an action on the control server to send a notification to the user said notification informing the user to seek immediate medical attention.

11. The method of claim 1, wherein the server sending out a notification on a positive matched recalled device utilizes user demographic data stored on the person table and care team information for that user stored on the person table; the present invention generates an electronic mail sent to the email address of the user from the person table and generates a text message and a phone call message sent to the phone number stored on the Person table.

12. The method of claim 1, wherein the storing of the notification on the device-match table comprises saving this notification timestamp to this table.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In referring to the drawings,

[0024] FIG. 1 provides a block diagram of the operation of the invention;

[0025] FIG. 2 provides a block diagram of the invention during manual usage; and,

[0026] FIG. 3 provides a block diagram of the invention integrating with electronic medical records.

[0027] The same reference numerals refer to the same parts throughout the various figures.

DETAILED DESCRIPTION

[0028] Our invention is an application and website that notifies patients of applicable active and inactive recalls impacting their implantable devices. Securely collate data around patients, their implanted devices, and any recalls and adverse effects in order to offer solicitations that the user would find relevant

[0029] Core Features: 1.) Application and website (hereafter referred to as A&W) to meet HIPAA certification guidelines. 2.) A&W shares user database and content. Adding a device to a user profile in either A or W synchronizes across both and any future platforms. 3.) A&W permits access to iOS and Android technology platforms as well as common web browsers.

[0030] Data Population Processes [0031] The user manually using a User Interface (TrackMy Implants Application) to search and save an Implantable device or [0032] The capturing of unique device data through the use of Smart on FHIR integration with electronic medical records or [0033] The direct interface of unique device data to server (TrackMy) through an HL7 established interface with another healthcare related technology system or [0034] The manual upload/data entry into the device-person table by an individual or through an automated scanning process

[0035] Detailed Data Population Processes

[0036] Software application details/process steps for user manually using TrackMy User Interface to populate the device-person table: [0037] 1.) Software application allows Device search from the FDA “DeviceUDI” API dataset. The API is being called from the FDA through the mobile application using one of three search types (see Device Search screenshot in Visual tab section):

[0038] App Search field name App Display field name DeviceUDI API field name Device ID Primary DI Number “results_identifiers_id” Name Brand Name “results_brand_name” Company Name “results_company_name” [0039] 2.) In addition to the App Display field names shown above, two additional fields are displayed to the user. App Display field name DeviceUDI API field name Regulation Number “results_product_codes_openfda_regulation_number” Device Description “results_device_description ” [0040] 3.) Once the user has saved the appropriate devices to their profile, the devices are checked against the “Device-Recall” Parsed out table nightly (the recall check process is run every 24 hours) using the Device Identifier value. The Device-Recall table is created through TrackMy triggering a pull from the OpenFDA Device Enforcement Report API, and we then parse out the “code_info” field to pull out Device Identifiers through an algorithm and rules we have created. [0041] 4. ) If a recall match is found, then the user receives a notification through the application. Along with a text message (if the user saved their contact information), and a phone message automated call notification as well [0042] In addition to using the recall and device data, we are leveraging Device Adverse Event data to derive the needs for a notification, additional details on adverse events are as follows [0043] Detailed description of Adverse Event usage—Adverse Events impact devices that have not yet been recalled. They indicate that something has happened involving a particular device, but the device itself has not yet been identified as causing the incident. This information may be available months or years in advance of a recall. As such, sharing of such information with patients must be handled lightly. Methods of joining “DeviceUDI” to “Adverse Event” are ‘results_device_catalog_number’ or ‘results_device_model_number’

[0044] The capturing of unique device data through the use of Smart on FHIR integration with electronic medical records [0045] 1.) To assist users in building their device profiles, the use of Smart on FHIR APIs are leveraged. This allows the user to connect to their EHR records and download their implantable device data into TMS database (this is further defined in Model C below and in the drawings for Model C). [0046] 2.) In addition, we will be offering patient education tied to the user's device list (patient education content company to be named TBD; ex- UpToDate) [0047] 3.) Users should be contacted by email as well as push notification along with phone messages [0048] 4.) Load article links in app to push to users. Linking WordPress blog so that as we post to the blog, link to user. [0049] This is further detailed in the following sections.

[0050] The direct interface of unique device data to server (TrackMy) through an HL7 established interface with another healthcare related technology system or [0051] 1. ) An established relationship would be built between TrackMy and a given client (i.e.—Hospital); a unique identifying data element—i.e.—SSN, Patient ID, etc., would be exchanged between TrackMy and Client to positively identify a given patient. [0052] 2.) Once this is done, Client can send patient data (once patient has went in and consented) to TrackMy to be loaded on the device-person table.

[0053] The manual upload/data entry into the device-person table by an individual or through an automated scanning process

[0054] 1.) For this process/data upload, this assumes patient consent has been established upon account creation.

[0055] 2.) Patient/User allows TrackMy to work with Surgeon/Provider to upload Device Identifier data into database and load on the device-person table

[0056] TrackMy Implants Architecture

[0057] As currently notated, there are three models for the architecture.

[0058] Model A, as shown in FIG. 1 is as follows

[0059] FIG. 1—Model A—Manual—TrackMy Technology Patent is being submitted to cover all of these model flows, as we reserve the right to leverage enhancements to technology for optimal performance for our end-user community as well as there is more than one way to get data into the TrackMy database/servers.

[0060] FIG. 1 utilizes the following reference characters shown in index form:

[0061] 100 TrackMy Implants Website

[0062] 110 TrackMy Implants App

[0063] 120 Open FDA API Recall UDI

[0064] 130 Open FDA API Device UDI

[0065] 140 TrackMy Database

[0066] 10 line between 100 and 120, call recall API by Device Details, recall returned if matched

[0067] 11 line between 100 and 130, recall process

[0068] 40 line between 100 and 140, flow

[0069] 41 line between 100 and 110, like user experience

[0070] 42 line between 110 and 120, user search call to API, user search results returned from API, bidirectional dataflow

[0071] 43 line between 110 and 130, user search call to API, user search results returned from API, bidirectional dataflow

[0072] 44 line between 110 and 140, flow

[0073] Flow [0074] User has downloaded TrackMy Implants technology or logged in via Web App [0075] User Signs in with Email address, Single Sign On with Facebook, Google, or Creates a New Account [0076] User clicks search button (see on app visual tab), enters data to search (only can search what API allows today (leads to Model B)) and it evokes the API call to Device UDI [0077] User sees information on device (see on app visual tab) and saves device [0078] Recall API call runs nightly and triggers on saved device information [0079] If Recall Match takes place, push notification and text message and phone call (if have data) is sent to user (see recall visual) [0080] TrackMy Database [0081] User Data Saved to Database; Saved Devices Show to User from Database; Alerts saved to Database once triggered [0082] Every 24 hours, we look for new data by repulling the API data, normalizing it, and reloading into our Database Schema [0083] The Following OpenFDA APIs we are pulling into our Database, normalizing and allowing for a more robust user search/recall process [0084] OpenFDA APIs we are using, are all that exist today at—https://open.fda.gov/device/ [0085] https://open.fda.gov/device/event/ [0086] https://open.fda.gov/device/classification/ [0087] https://open.fda.gov/device/510k/ [0088] https://open.fda.gov/device/pma/ [0089] https://open.fda.gov/device/registrationlisting/ [0090] https://open.fda.gov/device/recall/ [0091] https://open.fda.gov/device/enforcement/ [0092] https://open.fda.gov/device/udi/

[0093] The application and website hit the OpenFDA APIs on demand, store retrieved information in a user profile database shared across all A&W platforms. As noted above, the profile would also eventually include information retrieved from the user's Electronic Health Records (EHR), which would be used to trigger the Recall API. The Recall API is called at least nightly for all user devices in the database. The Device API will continue to be called on demand by manual search. Exception reports would be enabled on a weekly or daily basis to ensure that all devices in the database can be matched to records from the Device API (ensuring data integrity for items added through EHR integration).

[0094] Model B, as shown in FIG. 2 is as follows

[0095] FIG. 2 utilizes the following reference characters shown in index form:

[0096] 100 TrackMy Implants Website

[0097] 110 TrackMy Implants App

[0098] 140 TrackMy Database

[0099] 150 Open FDA API

[0100] 12 line between 100 and 140, call database for recall by device details

[0101] 13 line between 110 and 140, call database for recall by device details

[0102] 40 line between 100 and 140, flow

[0103] 41 line between 100 and 110, like user experience

[0104] 44 line between 110 and 140, user search call to API, user search results returned from API, bidirectional dataflow

[0105] 49 line between 140 and 150, flow

[0106] Flow [0107] User has downloaded TrackMy Implants technology or logged in via Web Application [0108] User Signs in with Email address, Single Sign On with Facebook, Google, or Creates a New Account [0109] User clicks search button (see on app visual tab), enters data to search (this search is controlled by TrackMy and is from our database, where we can provide an improved user search) [0110] User sees information on device (see on app visual tab) and saves device [0111] Recall Match Process call runs nightly and triggers on saved device information [0112] If Recall Match takes place, push notification and text message and phone call (if have data) is sent to user (see recall visual)TrackMy Database [0113] User Data Saved to Database; Saved Devices Show to User from Database; Alerts saved to Database once triggered [0114] Every 24 hours, we look for new data by repulling the API data, normalizing it, and reloading into our Database Schema [0115] The Following OpenFDA APIs we are pulling into our Database, normalizing and allowing for a more robust user search/recall process [0116] OpenFDA APIs we are using, are all that exist today at—https://open.fda.gov/device/ [0117] https://open.fda/gov/device/event [0118] https://open.fda.gov/device/510k) [0119] https://open.fda.gov/device/classification/ [0120] https://open.fda.gov/device/510k/ [0121] https://open.fda.gov/device/pma/ [0122] https://open.fda.gov/device/registrationlisting/ [0123] https://open.fda.gov/device/recall/ [0124] https://open.fda.gov/device/enforcement/ [0125] https://open.fda.gov/device/udi/

[0126] Directing all query calls to a hosted database containing all available API content from the FDA. The FDA makes these datafiles available on a daily basis, thus giving TrackMy more control over the data and reduce our API calls to the FDA by regularly downloading the files. This allows flexibility to add additional API datasets should they become available (potentially in the Medicare Claims space).

[0127] Model C, as shown in FIG. 3 is as follows

[0128] FIG. 3 utilizes the following reference characters shown in index form:

[0129] 100 TrackMy Implants Website

[0130] 110 TrackMy Implants App

[0131] 140 TrackMy Database

[0132] 150 Open FDA API

[0133] 160 Authentication

[0134] 170 EMR Integration Smart on FHIR API

[0135] 180 Electronic Medical Record

[0136] 12 line between 100 and 140, call database for recall by device details, recall returned if match

[0137] 13 line between 110 and 140, call database for recall by device details, recall returned if match

[0138] 41 line between 110 and 160, flow

[0139] 45 line between 100 and 140, augmented device details, search

[0140] 46 line between 100 and 160, bidirectional flow

[0141] 47 line between 160 and 170, bidirectional flow

[0142] 48 line between 170 and 180, bidirectional flow

[0143] 49 line between 140 and 150, flow

[0144] Flow [0145] User has downloaded TrackMy Implants technology or logged in via Web Application [0146] User Signs in with Email address, Single Sign On with Facebook, Google, or Creates a a New Account [0147] User Authenticates through Identity Provider of Healthcare Organization (ie—Patient Portal Credentials; Oauth Process) [0148] User is presented with Available Medical Device Data from Electronic Health Record Vendor (ie—Allscripts; dependent who is connected to our business) [0149] User Accepts Medical Device Data and Signs Patient Consent to save data into TrackMy Database [0150] Recall Match Process call runs nightly and triggers on saved device information [0151] If Recall Match takes place, push notification and text message and phone call (if have data) is sent to user (see recall visual) [0152] TrackMy Database [0153] User Data Saved to Database; Saved Devices Show to User from Database; Alerts saved to Database once triggered [0154] Every 24 hours, we look for new data by repulling the API data, normalizing it, and reloading into our Database Schema [0155] The Following OpenFDA APIs we are pulling into our Database, normalizing and allowing for a more robust user search/recall process [0156] OpenFDA APIs we are using, are all that exist today at—https://open.fda.gov/device/ [0157] https://open.fda.gov/device/event/ [0158] https://open./fda./gov/device/classification/ [0159] https://open.fda.gov/device/510k/ [0160] https://open.fda.gov/device/pma/ [0161] https://open.fda.gov/device/registrationlisting/ [0162] https://open.fda./gov/device/recall/ [0163] https://open.fda.gov/device/enforcement/ [0164] https://open.fda.gov/device/udi/

[0165] Replaces the Manual search and save by adding in the Smart on FHIR Integration with varying Electronic Medical Records (ie—Allscripts). There still is an augmented search tied into the FHIR/EMR Integration should relevant data not be brought fully in via the EMR Integration. There is an authentication process the user has to complete using OAuth and authenticating through the Identity Provider (in this case an example is the Hospital Systems/organizations Patient Portal). The recall process remains intact/the same for all Models. This technology is not limited to a particular Electronic Medical Record Vendor (ie Allscripts), our technology is vendor agnostic and we will determine through agreements between various EMR vendors and

[0166] TrackMy; based on business needs and ongoing partnerships etc.

[0167] Any architectural model used must accommodate three stakeholder groups. 1) The patients who log into the application are assured they maintain control of their data. 2.) Admin ability to monitor changes in data and resolve exceptions where stored user devices cannot be reconciled against the DeviceUDI dataset. 3.) Third Party options to pay for leads to patients impacted by Recalls (initially) and Adverse Effects (later). Users may not be contacted without providing permission first; at minimum this will require an agreement checkbox or opt out capability. Further discussion will be required to determine the nature of these solicitations, but development has proceeded with this objective in mind.

[0168] Examples of how it will be used: [0169] Patients can/will use technology to track and receive alerts of recalled medical devices [0170] Patients can/will receive electronic patient education through technology [0171] Attorney usage—through patient consent be able to communicate to patients with potential recalls [0172] Device Manufacturers—partner with TrackMy technology to improve their recall strategy [0173] Surgery Centers/Physicians—use technology to notify their patient population of medical device recalls/adverse events based on what devices they have FDA/CDRH—use technology to better enforce recall strategy and track what patients have been notified—leading to an increase public health [0174] This software will increase patient safety and lead to an overall improved public health [0175] This software has real potential save a patient's life through real-time notifications This software allows a user to better manage their overall health through better information [0176] This software educates a user of a device recall they have on a saved device