Implantable device list - 2015 ONC MU3 a14

OpenEMR Development
,
21

Now let’s take a look at the device lookup API.

It can also return the data in json or xml format.

It can take in as input the full Universal Device Identifier(UDI) in the above example (01)51022222233336(11)141231(17)150707(10)A213B1(21)1234

Or the DI, or Device Identifier string. 51022222233336 in the above example.

However the string must be put percent/url encoded. I think for the device identifier it should just be alphanumeric characters.

For a UDI API request it should look like this:
https://accessgudid.nlm.nih.gov/api/v2/devices/lookup.json?udi=(01)51022222233336(11)141231(17)150707(10)A213B1(21)1234

For a DI API request it should be:
https://accessgudid.nlm.nih.gov/api/v2/devices/lookup.json?di=51022222233336

We’ll need to decide what information to collect store locally. My initial thoughts are the sterilization method and contact fields. Also MRI safety information. If a person has a device with MRI concerns we’ll want to put that on the dashboard for sure.

However instead of pulling out all the device information and making it look pretty, we can also just create a link that directs the clinician to the device information page.

For example a device with DI D0470046351
The below link sends you to the GUDID site with a nice GUI.
https://accessgudid.nlm.nih.gov/devices/D0470046351

Let’s generate this link in PHP. We’ll need to make a string with this format:
link text

But since we’re going to be appending strings within strings you’ll need to make sure you escape the double quotes you want to keep without.
http://www.hackingwithphp.com/2/6/2/escape-sequences

$DevicePage= “<a href=“https://accessgudid.nlm.nih.gov/devices/” . $Parsed[“di”] . “”>Visit Access GUDID Device Information Page”;

echo $DevicePage

This creates a link that says:
Visit Access GUDID Device Information Page
and sends you to
https://accessgudid.nlm.nih.gov/devices/51022222233336

Which isn’t a real medical device but if it were that should work.

22

So I know it doesn’t appear to be mandated by the standard but let’s go ahead and add a field for tracking where in the body the device is implanted. Since each clinic will likely have their own top n implantatation sites that will vary based on services provider, let’s use the Manage Lists tool to allow them to customize what body parts list by default.

First let’s take a look at the surgery issue list. Navigate to Administration → Lists

image
image1914×680 57.1 KB

Next Procedure Body Sites

image
image1895×347 20.2 KB

Procedure Lateralities

image
image1822×399 20.8 KB

Procedure Routes

image
image1917×405 21.1 KB

One thing to consider is that the guidance says that an implantable device should be associated with a procedure. But at least with how the system appears to handle things now, the surgery issue list contains the types of procedures, like appendectomy, tonsilectomy, etc.

The location, laterality, and routes are listed under the name procedure.

But what about nonsurgical procedures? Like the Epley Maneuver? Could we maybe change the surgery issue list to procedure issue list and have both stored in the same table?

Let’s consider an example. Cochlear implants.
The body site might be considered “ear” or something more specific.

The laterality for the procedure might be left, right, or both(bilateral).
Then again if you need to know which serial number is in which ear it might necessitate coding as two separate procedures or listing multiple implantations in the same procedure/surgery window.

The procedure route would be surgical

The Surgical issue would be Cochlear Device implantation with CPT code 69930.

At some point the implant would need to be removed(explanted) or replaced (explant followed by implant)
These appear to have separate codes.

So perhaps when allowing the clinician to record a surgery/procedure there should be the option to remove an existing implanted device and implant new device(s) at the same time. Making sure that they have independently recorded locations and lateralities.

23

To get all listed issues recorded in the columns above you’ll want to run the below SQL commands.
SELECT title FROM list_options WHERE list_id = ‘surgery_issue_list’;

SELECT title FROM list_options WHERE list_id = ‘proc_body_site’;

SELECT title FROM list_options WHERE list_id = ‘proc_route’;

SELECT title FROM list_options WHERE list_id = ‘proc_lat’;

However if you only want to grab the active ones, you 'll want to add an additional check as seen below.

SELECT title FROM list_options WHERE list_id = ‘surgery_issue_list’ AND activity =1;

While using the title field to get the “pretty” text to display in the GUI I’d recommend also grabbing the option id like below to use to reference in your code.
SELECT option_id FROM list_options WHERE list_id = ‘surgery_issue_list’ AND activity =1;

24

Let’s make a first pass at making an ImplantableDevice Table. In PHPmyadmin click the openemr database on the left navigation pane. Scroll to the bottom of the page, Type a name in the box and click create new table with 21 columns.

image
image1067×1214 53 KB

image
image1452×516 24 KB

Under index, set primary for the ID row, this will be a unique number given to each implanted device to be used throughout the codebase.

Click preview SQL to get the below.

CREATE TABLE openemr.ImplantableDevices(IDINT NOT NULL ,PIDINT NOT NULL ,DeviceTitleVARCHAR NOT NULL ,DeviceDescriptionTEXT NOT NULL ,ImplantDateDATE NOT NULL ,ExplantDateINT NOT NULL ,DeviceIdentifierVARCHAR NOT NULL ,UDIVARCHAR NOT NULL ,IssuingAgencyVARCHAR NOT NULL ,ExpirationDateVARCHAR NOT NULL ,SerialNumberVARCHAR NOT NULL ,MRI_Safety_InformationTEXT NOT NULL ,DevicePackagedAsSterileVARCHAR NOT NULL ,RequiresSterilizationBeforeUseVARCHAR NOT NULL ,SterilizationMethodsTEXT NOT NULL ,StorageAndHandlingNotesTEXT NOT NULL ,ContactPhoneVARCHAR NOT NULL ,ContactEmailVARCHAR NOT NULL ,AssociatedProceduresVARCHAR NOT NULL ,AssociatedSurgeriesINT NOT NULL ,Comments TEXT NOT NULL , PRIMARY KEY (ID)) ENGINE = InnoDB;

Hit save to get your new table.

25

First, let’s take a look at device expiration dates.

Here’s what an example GS1 UDI Parsing API returns:
{“udi”:“(01)51022222233336(11)141231(17)150707(10)A213B1(21)1234”,“issuingAgency”:“GS1”,“di”:“51022222233336”,“manufacturingDateOriginal”:“141231”,“manufacturingDateOriginalFormat”:“YYMMDD”,“manufacturingDate”:“2014-12-31”,“expirationDateOriginal”:“150707”,“expirationDateOriginalFormat”:“YYMMDD”,“expirationDate”:“2015-07-07”,“lotNumber”:“A213B1”,“serialNumber”:“1234”}

We know that the database wants dates in format YYYY-MM-DD. Let’s take a look at the other issuing agency formats.

26

And here’s an example HIBCC:

{
"udi":"+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ456789012345678/16D20130202C",
"issuingAgency":"HIBCC",
"di":"H123PARTNO1234567890120",
"expirationDateOriginalFormat":"YYMMDDHH",
"expirationDateOriginal":"20020216",
"expirationDate":"2020-02-02",
"lotNumber":"LOT123456789012345",
"serialNumber":"XYZ456789012345678",
"manufacturingDateOriginalFormat":"YYYYMMDD",
"manufacturingDateOriginal":"20130202",
"manufacturingDate":"2013-02-02"
}

Here’s what ICCBBA returns:

{
"udi":"=/A9999XYZ100T0944=,000025=A99971312345600=\u003e014032=}013032\u0026,1000000000000XYZ123",
"issuingAgency":"ICCBBA",
"di":"A9999XYZ100T0944",
"serialNumber":"000025",
"donationId":"A99971312345600",
"expirationDateOriginalFormat":"YYYJJJ",
"expirationDateOriginal":"014032",
"expirationDate":"2014-02-01",
"manufacturingDateOriginalFormat":"YYYJJJ",
"manufacturingDateOriginal":"013032",
"manufacturingDate":"2013-02-01",
"lotNumber":"000000000000XYZ123"
}

So it looks like the API handles converting the original date time formats to one that’s acceptable to the MySQL database. So in theory all we should need to do is grab the expirationDate field.

27

In addition to MRI safety information the API returns additional information regarding natural rubber latex, or NRL, which is a common allergy.

Here’s a snippet of what the device_lookup v2 api json returns.

labeledContainsNRL: false,
labeledNoNRL: false,
MRISafetyStatus: “MR Conditional”,

I’d like to create a warning that pops up if a clinician tries to add an implantable device made or packaged with NRL to a person known to have a latex allergy.

A latex allergy isn’t one of the four included in the add/edit allergy issue page by default.

One can query the lists table for patient pid=?, activity=1, type=allergy, title=latex to capture hand typed documented allergies. It doesn’t appear to be case sensitive but this will not take into account things like shorthand, misspellings, other languages, alternate names like NRL, etc.

One thing we could do is add it to the list_options table.

image
image1660×141 12.9 KB

As for how to handle the default latex allergy coding:
https://www.icd10monitor.com/coding-of-allergies-presents-unique-challenges

It would appear that the ICD10 code for latex allergy is Z91:040

To add this as an option via a SQL query, we should be able to use the below:

INSERT INTO list_options (list_id, option_id, title, seq, is_default, option_value, mapping, notes, codes, toggle_setting_1, toggle_setting_2, activity, subtype, edit_options, timestamp) VALUES (‘allergy_issue_list’, ‘latex’, ‘Latex’, ‘0’, ‘0’, ‘0’, ‘’, NULL, ‘ICD10:Z91.040’, ‘0’, ‘0’, ‘1’, ‘’, ‘1’, CURRENT_TIMESTAMP)

image
image793×736 19.1 KB

28

hi @RachelEllison ,

Here’s where you can add this to database.sql:
https://github.com/openemr/openemr/blob/master/sql/database.sql#L4266

We are also in luck on the translation front. Note that the title of the allergy (in this case Latex, which is taken from title in list_options) is stored in title in lists:

image
image1920×1080 367 KB

And the option_id from list_options entry (in this case latex) is then stored in the list_option_id of in lists:

image
image1920×1080 317 KB

So searching for latex in list_option_id of lists is going to work for all languages. Also good to store the ICD10 code as you do.

29

Hi @RachelEllison @Rachel_Ellison (which is it:))
Implantable Device is a part of the U.S FHIR Core required by ONC. So we are starting to consider inclusion to both our standard and FHIR API.
Is there somethings our FHIR team can help with to move this along. Looks like you are close with the infrasture, can we help with integration?

30

Hi Jerry, here’s some code I had been messing around with if that helps.

1 Like
31

Looks like you have the makings for a service. Organizing into a controller/service will make serving your UI much easier. Plus it could then support a REST API endpoint for our API. Also putting all your external REST calls in one place will make reuse better.

I assume you’re still actively pursuing this.

32

Hi @RachelEllison, @sjpadgett,
you can extract or reuse some code/class from here it’s an http consumer for Gudid api

It’s not ready for production environments (i’ should add more test,docs, and fix 1 bug).

33

I haven’t really had a chance to work on this lately. I got a bit sidetracked by implementing a check to see if the patient has a documented latex allergy for devices using or packaged with natural rubber latex.

34

Looks good @zerai. Wouldn’t take much to slip into a service, give it a controller and add route to API routes. Whala, we have a new API endpoint plus a service for forms and report integration.

35

Last updates:

  • Bug fixed
  • Docs ready

It’s an opensource library, you can integrate it with ‘composer require’ if needed.

i’m writing my custom software but there are some part can i can share as separate library for other php projects.

36

@RachelEllison
Any progress on this? If anything we need to get the support table structure into database.
Mainly we need so a FHIR resource endpoint can be added.

@zerai Anything you can contribute?

37

No unfortunately I haven’t made any progress since I last posted. Life/class got pretty crazy.

I guess what remains to be done is figure out how to represent this tree-like structure the columns of a table. Then map the GUDID fields to the table.
https://www.hl7.org/fhir/device.html

I can try to make a first pass at table.

Here’s the bare minimum.

38

Working on this here:

1 Like
39

Suggestion regarding medical devices:
May want to add a line when searching the UDI to remove leading ZEROS (“0”)
I performed a UDI search ONLINE to get the UDI number for an implantable cardiac monitor.
OpenEMR could not find it unless I removed the leading ZEROS:

Boston Scientific Implantable Cardiac Monitor Model M301
UID: 00802526607103 from the website:

https://accessgudid.nlm.nih.gov/devices/00802526607103
was only found via the UDI lookup in openEMR when changing the lookup number to:

802526607103

FYI

1 Like