Islands of Data in Healthcare Organizations | DataOps Day

Hi, thank you for, uh, joining me for this presentation for DataOps Day 2023. Uh, my name is Scott Mallonee. I work for medical imaging and division of Lead Technologies, uh, incorporated, uh, the head of business development and health tech.

Um, I've been working here for, uh, about 20 years, um, and that, uh, is about the length of time that I've had experience within the IT healthcare industry as well. Um, just to give you a, a very brief overview of, of, of the differences between, uh, the, the, the medical imaging division and lead technologies. Uh, lead basically caters, uh, to the needs of software developers while as, uh, medic caters to the needs of, uh, healthcare end users.

Uh, so we at medical develop, uh, end user products, uh, that are meant to be deployed in a healthcare enterprise, uh, where lead, uh, sells, uh, software development toolkits, which can be used to build products for development within healthcare, uh, develop, uh, enterprise. Um, I am personally, uh, a voting member on the A d A standards committee. That's the American Dental Association Standards Committee for Dental Informatics, uh, otherwise known as the A D A S C D I.

Um, also a member, uh, personal and corporate member of dicom Working Groups 22, uh, will get into what DICOM means if that, uh, term doesn't ring a bell, uh, uh, here in just a few slides. Uh, so to get it started off, uh, let's just talk about what the goals of this discussion, uh, are. Um, and, uh, basically to define what, uh, what are these islands of data in small and mid-size healthcare organizations, um, the, the benefits of, of, of, uh, industry standards.

And there you see that word, DICOM again. Uh, and again, I'll get into, uh, what, what DICOM and, uh, and, and the, the term PACS means. Um, so we all have a fully full understanding of, of, of, of that.

Uh, during this presentation, um, wanna talk about the barriers to centralizing, uh, healthcare data storage, um, in pacs. Um, and, uh, talk about how small to mid-size healthcare organizations can implement PACS on a small budget rather than, um, some of the, the larger PAC systems out there, which range into the millions as, as we'll see in a few slides. Um, also want to talk about how, uh, implementing A A A PACS can help seamlessly communicate, uh, help devices seamlessly communicate, ensure, uh, you know, all all your healthcare data is backed up, um, secure access to, to patient health information.

And then, uh, improve user workflows on top of that. Um, so let's, let's first just talk about what are these islands of data that I'm, that I'm talking about? And, and generally these are, uh, healthcare, usually imaging devices.

Um, and, uh, those, those imaging devices might be ultrasound devices or CT scanners or M r I scanners. Um, we see some within the dental industry as well that are specific to dental, um, that are, uh, cadcam basically same day implant systems, um, ECGs, EKGs, really any other medical device or modality, uh, modality being just an, an imaging or, or, or, uh, uh, information gathering device that, uh, uh, that is, is used within healthcare. Um, any of these devices often have internal storage or might externally ex store to a, uh, a n share or u n c share, uh, and, and connect to a database.

Um, but often, uh, these islands are neglected. Um, so locally, uh, on the device's internal storage, um, is, is is where the data is typically stored. And, and these devices, uh, don't usually run windows.

They usually run a custom Linux use muni or, uh, distribution, um, with a GUI that's, that's only intended to operate the device. Um, so basically you boot the ultrasound, uh, machine up, and, uh, the first thing you see is it's ready to operate, um, ready to, to query for patient information. There's no, you know, uh, uh, log into windows or anything like that.

Uh, um, so this makes backups a challenge, um, because, um, you know, this, this data that's stored locally on a Linux device, uh, how, how does that get integrated into your, uh, backup within your organization? Um, and, uh, the ability to apply group policies to these, uh, devices is virtually impossible. Um, when, uh, the images are stored on a network share instead of in internal storage, um, it's often stored, unprotected with, uh, improper permissions restricted.

We've, uh, seen, uh, plenty of lo of, of, uh, occasions where, uh, healthcare data is just stored out in the NAS on the, on the, uh, network. And, um, it's, it's just not secured to the people that need to view it, uh, which is the way it should be. Um, and o often, uh, these devices store information in a proprietary, uh, database or format.

Um, so it makes it difficult for interoperability with other systems, um, unless we depend on a, uh, some sort of standard, um, that internally stored data is, uh, well, it's rarely backed up, um, if ever backed up. Um, another downside to it is that it's not available for viewing from a central location. So if, uh, if, if, if a patient were to have a, an ultrasound or an E K G captured on a device, well, that ultrasound or E K G is stored on that device, um, we've, we've seen users often rely on thermal printouts from ultrasounds, and they scan that printout into the E H R as permanent storage for the image.

Um, so, you know, original image is, is stored in, in, in data on, on the actual device. Um, they've, they've printed out this, you know, small thermal scan, you know, if you've been to a, a, a, a baby appointment and they printed out an ultrasound of your baby at, you know, whatever weeks. Um, that's, that's the type of thermal printout that I'm, that I'm talking about.

Um, and, and that's what's actually scanned permanently into the patient's record rather than the full, than the full fidelity, uh, ultrasound, uh, which is still, you know, located, uh, on the internal storage for that device. Um, so this makes it, uh, these, makes these files susceptible to description and failure. You know, if something happens to that device, um, then the data, the, the full fidelity data that you've got, uh, stored on there is just gone.

Um, and, uh, it's often forgotten about until it's too late. Um, it's, uh, makes it difficult or impossible to provide, uh, patients with a C or D V D, um, of the, uh, of, of, of their patient, uh, healthcare information if they've requested it. Um, so just not, not, not, not a, not a good situation to have, uh, situation or, or, uh, data stored on these, uh, internally, uh, in this internal storage.

So what's the solution to ensuring that all data is centralized, backed up and viewable, viewable from outside the device itself? Um, well, we need a central places for these files to be stored. Um, we need, and, and I'm talking from all modalities, not, not just, uh, from, you know, a particular ultrasound device.

I'm, I'm talking x-ray ultrasound, M R I CT everything. We need a central place for all these files to be stored. Um, we need a way to, uh, to get the files from the medical device to the central storage location, just from point A to point B.

Um, we need a way for the clinicians to be able to view the images. Uh, so, um, rather than making them go back to the device or viewing that, you know, scanned thermal printout inside their E H R, um, actually giving them a proper viewing, um, application to be able to, you know, manipulate images, make measurements on images, uh, do the things that they need to do. Um, and, um, we need to wait to provide these images to patients, uh, when requested as well.

So, uh, if the patient wants to take their images home with them, um, I know as, as someone in the in industry, I, I, I al always ask for my images on a cd, um, just, just so I can have them, uh, in our, uh, and my, my, my personal family's archive of DICOM files. And, uh, of course, it needs to be backed up. So there is a solution, um, and it's utilizing a, a universally accepted medical standard called DICOM to implement a pacs.

Um, and as I mentioned earlier, we're gonna go over what those terms actually mean, uh, in case you are not familiar. Um, so DICOM is the international standard to transmit store retrieve, print process, and display medical imaging information. Um, it stands for Digital Imaging and Communication and Medicine.

The standard's been around for, uh, over 30 years now that it's been in development. 0, uh, of the standard. And, uh, it's, it's, it's a very lengthy medical standard, uh, printed out.

Um, I've been told that if, if it were printed out, you know, page for page, it would be probably taller than I am, and I'm six three. So, uh, it is a, uh, uh, certainly a long, uh, standard. Um, but, but, uh, there have been a num a number of working groups, uh, divided up to develop the standard to make sure that, um, as long as devices follow the DICOM standard, they are in interoperable.

Um, so, uh, the DICOM standard allows for an easy conversion from one imaging platform to another. And the reason for this is because pretty much all PACS platforms and imaging platforms already utilize the DICOM standard. Um, if it's, uh, not available on a particular imaging device, um, it is often available as an add-on for that imaging device.

So, generally speaking, uh, all medical devices, uh, with, with the exception of few, uh, do support the DICOM standard already. Um, and, uh, it allows for the, uh, exchange of files amongst multiple providers. Um, so rather than, uh, exchanging like a, a JPEG file, which doesn't have any patient information, um, tied into it, uh, they could, uh, exchange a DICOM file instead.

And as long as, uh, both the, the sender and the receiver, how do we have viewed DICOM files? Um, then they would not only receive the imaging data. Um, and, and I, I'm possibly, uh, getting, uh, ahead of myself here, uh, with, with, with the slide coming up.

But, uh, they, they would be able to see the imaging data as well as the actual, uh, acquisition data about the device, the time the images was, was taken, the anatomy of the image, et cetera. Um, so, uh, there, there's, there's metadata that's, that's baked into each DICOM file. Um, and, um, the, that, that includes, uh, the patient identification.

Um, so basically, if I have a DICOM file, uh, versus a, uh, standard JPEG file, um, a DICOM file, I'm able to, uh, look into the metadata and find out what, what patient it belongs to, um, without having to reference a database to a file pointer to a jpeg. Um, all that information is just baked in the DICOM file. Um, it also provides, uh, interoperability with other medical systems and imaging devices.

Um, like I mentioned, uh, you know, most devices out there have DICOM compliance may not come with it by default, but it's usually available as an add-on module to those devices. Um, and it, uh, provides interoperability with specialty imaging software and devices. Uh, for example, if, uh, I had a, uh, specific cardiology based viewer that had cardiology specific functionality that maybe a, uh, uh, ophthalmologist might have no interest in, um, then, uh, there is such a thing as a generic DICOM medical viewer, which basically handles, you know, 95% of all, uh, medical, uh, image viewing cases.

Um, and then there it would be a cardiology specialty viewer, which would be DICOM compliant and would be able to download those images no matter where they were captured from any DICOM compliance server. Um, so the, the DICOM standard is, is currently used universally in medicine. Um, it allows for the exchange of digital images among practitioners.

Um, it allows for integration of imaging devices from different vendors into one system. And what I mean by that is that, um, let's say, uh, let's say you're one of the big boys, you're one of the big hospitals, and you've got a multimillion dollar GE pack system, um, that, uh, that manages all your, uh, your, your healthcare imaging data, um, then that, that doesn't mean that you have to buy GE devices for all of your imaging devices. You could buy a, a Siemens ultrasound and an agfa, uh, printer, and a, uh, a different brand of, of a CT device and a different brand of, uh, E K G.

Uh, it, it doesn't matter the brand, as long as they all talk the language of dicom, then they would be compatible. Um, it's, uh, an actively developed and maintained standard, uh, to meet the evolving needs of technologies and, and, uh, medical imaging in general. Um, we're constantly, uh, adding, uh, technical reports and, um, additions to the DICOM standard, um, to, uh, ensure that, uh, all devices, uh, are covered as in including any new technology that might be emerging.

Um, so that, uh, once it does in fact emerge, we'll have a definition within the DICOM standard of, uh, how to handle those particular images or, uh, information. Um, it's an accredited, voluntary, consistent, uh, consensus development process, um, that involves and vendor, uh, vendors, uh, such as myself, um, industry experts. Um, so we've got, um, members from, uh, universities, uh, and, uh, other in institutions, uh, such as the, uh, D O D D H A, um, are all part of the DICOM standards committee.

And, uh, end user volunteers are also included, um, to just ensure that the end users', uh, requirements are, are, are met. Obviously, we don't, don't wanna set the requirements as the vendor. We wanna make sure the end user's happy.

Um, and, um, yeah, I think I've already reiterated that one that allows devices and applications from, uh, different vendors to communicate with one another. Um, so what, what, what I like to do to kind of help describe what the DICOM standard form, uh, is, is, is divided into really two pieces. Now, uh, this is sort of my thing.

Um, this is not necessarily, uh, you, you, you won't necessarily find it in the, uh, DICOM standard, uh, listed this way. Um, but, but, but I think as long as you can understand these two things, um, then, um, DICOM should make sense. Um, so the first thing is an imaging file format, um, just like, uh, jpeg or tiff or bitmap or, or, or, uh, docx or, or MP three or, or, or whatever.

Um, but, um, the DICOM file is different, and then it includes that metadata. Um, and that metadata could include, uh, all sorts of information about the actual device and the, uh, information about the patient, um, about the, the anatomy imaged, about the, um, person that was actually capturing the image, um, et cetera. So there's a lot of baked in information inside the DICOM file itself.

Um, even if you just have that one file, uh, you can know a lot about the patient, excuse me. Um, and the second part of the dotcom standard is the communication protocol. Um, so this, we would be kind of comparing this to like H T T P or FT T P or email, um, basically the, the language, um, the way that, um, two nodes on a network can talk to each other using the DICOM standard.

Um, so, uh, it basically, uh, begins with a T C P IP connection and, um, an association and then transaction begin going on, um, during that T C P IP connection. And that, uh, facilitates the transfer, uh, to or from of the DICOM images, uh, from either to a, a, a storage server where they're gonna be stored or, uh, back to a viewer where they're gonna be viewed. Um, as I mentioned, the, the DICOM file format, and I, I won't necessarily go through, uh, all of these, um, but, uh, the metadata is embedded into the files header, including, um, as I mentioned, patient demographics.

Um, the equipment manufacturer model name, serial number that captured the image is an important one because you can actually track an image back to a particular serial number of device. Uh, just again, with that one single file, all that information's baked in. Um, the imaging pixel data is of course, in included, um, and, uh, display positioning information.

So if, uh, an image should be displayed in the left or the right, or the top or the bottom or, uh, in, in a certain format, um, then that, that display information or, uh, protocol information is included, uh, in the DICOM metadata. Um, and there's, there's too much to list here. It's a ton of tags.

This is just to give you an example of what dicom, uh, file, uh, the DICOM file format might look like. Um, this is just a screenshot from, uh, my company's, uh, storage server opening up by dcom file. Um, this is obviously Bob tests from an anonymized patient, so I'm not, uh, revealing any, uh, P h I or anything here.

Um, but, um, these are just some of the tags that are included. And this list, uh, does go on. And as you can see, I've not expanded out all of these, uh, options on the tree.

So there really is a lot that's stored inside the file, um, in, in inside of a DICOM file. Now, the, the DICOM communication protocol, uh, portion of things, um, is, uh, it communicates over T C P I P. Um, it does have a iana, uh, designated T C P IP port.

Um, that port is port 1 0 4. However, uh, it's not a necessity to run PAC Services on port 1 0 4. Um, the, uh, that, that's just the, the designated port, it can certainly run on a different one.

Um, it is the, uh, the, the standard method of data exchange for images, radiology reports, and, and other captured medical data, either from devices to a central server or back from a central server to actual viewing locations. Um, so images can be retrieved from a PAC server as well as stored to a PAC server. Um, and, uh, of course, we've gotta allow the, the user to be able to search, uh, because they can't just open the, the viewing software up and, and immediately know what, what, uh, image they, uh, need to be able to pull up.

They need to need to be able to query and search the PAC servers. So they need to search for Sally Smith and, and know that, uh, Sally Smith's got a CT waiting to be viewed, um, on the server, uh, to download it. Um, and additionally, one other thing that, that the DICOM communication protocol can provide is a work list.

Um, and this is generally, um, when, uh, integrated with a radiology information system, um, where, uh, images, imaging procedures can be ordered. Um, so for example, a provider would order a ct and upon ordering that ct, um, in an item would appear on a, uh, sort of like a to-do list, uh, it's called a modality work list. And, um, then from the CT device itself, uh, the CT technician could simply, uh, query the PAC server, and the PAC server would tell the, the user that, Hey, there's a, you know, CT waiting to be captured that's been ordered for, uh, for a specific patient.

Um, and, uh, it would pass along all that patient demographic information, um, so that the user's not manually typing in that information themselves. Um, so, uh, as I mentioned, it provides a standard language for all devices and, and applications to communicate with one another. Um, it allows for the exchange of images between applications without having to use import export.

Um, like you might have to with, uh, importing and exporting a JPEG file, um, from one application to another. Um, and, uh, storage mediums such as CDs, thumb, Dr. Thumb drives, et cetera, um, provides, uh, correct patient demographics and order information from the system of record.

Um, and that's what I was speaking of with the, uh, modality work lists. Um, we'd actually be getting that order from the system of record being the, uh, the electronic healthcare record, uh, rather than depending on the user, uh, to manually type that information in, uh, which of course leads to mistakes. So, utilizing the DICOM standard, um, we have a standardized file format that we can use for all captured healthcare data, uh, imaging, or otherwise.

It doesn't just include images. You can capture other healthcare data as well in DICOM files. Um, we, we also have a way to exchange information from point A to point b i, uh, image and non image data, uh, between applications.

So for example, between a ultrasound device and a PAC server, or between a PAC server and a PACS viewer. Um, and, uh, we also have a way to, uh, burn, uh, CDs, uh, and, and, and, and create storage media. Uh, also, um, So software that supports the DICOM standard, um, you've heard me utilize the term pacs, um, and, uh, what that stands for is picture, archive and communication System.

Um, now PAX is the industry term for, uh, basically the imaging system within a healthcare organization. Um, the, uh, the, the, the terminology is a little confusing because it stores more than images, but since this has been around for 30 years, and it started with images, uh, that's just been the defined term. Um, there's no concrete definition of the term pacs other than it must be dotcom compliant.

Um, everyone's sort of got their own definition of what a PACS is. Uh, some people, uh, even claim to, uh, have a PAC system that's not DICOM compliant. Um, I, I don't know that I would be in agreement in agreement with that.

But, uh, simply put a PAC system is, is, is software that fully supports the DICOM standards, both the file format and the communication protocol. So what are the differences between DICOM and pax? Um, DICOM is the name of the developed standard, and PAX is the imaging system, which can, uh, as I mentioned, accept images from any DICOM compliant, uh, device or application.

Um, can store the images, uh, to, uh, local storage, uh, including into a database. Um, doesn't have to be a specific type of database, just whatever the application has, has chosen in its full ly per, uh, full fidelity format, uh, permanently, rather than relying on, uh, scans of, of thermal printouts or, or things of that sort. Um, it, uh, sends images to any DICOM compliant devices or applications.

So examples of those are DICOM compliant printers and CD burners. There are actually DICOM compliant printers and CD burners, D V D burners out there where you can store DICOM files directly to them using the DICOM protocol. And, uh, it will either create a film x-ray printout or burn a CD with the patient's information printed on the CD automatically.

Um, we can, uh, provide imaging procedure order information and patient demographics to the, uh, capturing devices and applications, uh, so that the user's not manually having to type that information in. Um, now what medical, uh, devices often don't include the module that enables the device to communicate on the network using the DICOM protocol. So this is one of the barriers.

I, I'm sorry, I forgot to, to mention. I, I sort of switched subjects, switched subjects there. The barriers to centralizing healthcare data storage, uh, generally these upgrades to devices, to an ultrasound device, for example, might cost anywhere from 2,500 to $10,000 per device.

So there is an investment, um, that, that, that, that is required. Um, software solutions that support the DICOM protocol can be very expensive. Uh, PAC systems often run into the multimillions of dollars.

Some major players are ge, acta, Siemens, Phillips, Fuji, et cetera. Um, at smaller health centers, a local IT team may not be able to implement a PAC system. Uh, they just aren't affordable, they aren't manageable, um, from, from a a, a, a small to mid-size healthcare organization.

Um, they, um, some devices don't have support for the DICOM standard. Uh, this is prevalent in dental and ophthalmology, where these devices simply output files in formats other than dicom, and we don't have an option. Um, a lot of times in what we do in these cases that is encapsulate those DICOM files is binary data inside, uh, or, or encapsulate those files as binary data inside a DICOM file so that it can be stored to a PAC server.

Um, and some PAC systems require extensive knowledge of Linux in order to implement, um, which isn't always available at, at, at, uh, smaller healthcare centers. Um, PACS implementation can be expensive, but it doesn't have to be. Um, we've mentioned the large players in the, in, in, in the PAC systems.

Um, they come with large price tags. And despite these costs, uh, these, these PAC systems are, uh, often rely on on antiquated code. Um, they've been around for years, they've been around since the DICOM standard was developed.

They're often command line based, um, and, uh, we've heard that they're, uh, difficult to deal with. Um, less expensive options are available if you know where to look. Uh, there's several open source free pack systems, uh, that can run on Windows, Linux, and servers.

Uh, a couple of those are our orang, uh, supports. Windows, Mac, oss, and Linux-based operating systems, uh, includes a very basic, very, very basic, uh, web-based zero footprint viewer. Um, DICOM four Q is another option.

Um, it's a Java based open source PACS component system. It's not necessarily a P system, but what you can do is piece together, uh, different components of that system to create your own PAC system. Um, this generally, generally relies on a very knowledgeable IT team and one that's, uh, willing to implement, uh, systems that, that might be a little out of their comfortability zone.

Um, there are also, uh, commercial lesser known PAC systems, which can be implemented on a much lower budget, um, as low as $10,000, not $10 million. Um, I, uh, have to mention our own, uh, PAC system, which is called Medical imaging, uh, mypac Enterprise pacs. Um, it runs on a Windows server, um, includes a fully featured zero footprint web-based viewer, um, and can fully integrate with an E H R system for one click access to patients', uh, healthcare and imaging data.

And, uh, supports multi clinic organizations also that need to centralize their healthcare data into one, uh, location. And it, it does support every imaging, uh, file format within the DICOM standard. So no matter what type of devices, uh, the, the customer's using, whether it's an ultrasound or CT or M R I or chest x-ray or mammography, or, uh, you, you name it, um, it is, uh, supported in, in, in, in, in inside of mypac.

So, uh, free open source, uh, lowcost viewers are also available. Um, some options for free and low cost viewers are, uh, I don't wanna necessarily list them all, uh, but we've got several options here. Uh, merge film is currently being sunset by I B m.

Um, some popular ones that we hear about are ROS on our Cyrex. Those are for Mac OSS only. Um, and they actually require for their f d A cleared version.

It is a paid viewer. It is not free. Uh, they offer a free version for non-diagnostic purposes.

Um, they're gonna be deficiencies in their, in, in, in these free viewers. Uh, they are not fully featured with the exception of, uh, horo Eno Cyrex, which are fully featured viewers. Um, but as I mentioned, those come with a price tag, and I believe that price tag is, uh, around $2,500 a workstation.

Um, I, I, I don't know that for a fact though. Um, a simple but effective, uh, PACS can be implemented by combining, uh, components from different PAX compliance, uh, compliant applications, uh, for your low-cost PAC server, uh, for your low-cost DICOM compliant viewer, which can retrieve images from a PAC server. And, um, you know, since these applications use the DICOM standard, they can come from different vendors.

Uh, so you can have one brand of a server and a different brand of viewer. Um, and I know I'm going just a couple minutes over, but I think I've got two more slides. com files.

Um, so images are no longer scattered amongst the, uh, internal storage of these imaging devices. They are now backed up into one location, um, and all modalities are configured to store the capture captured imaging data to that single location. So anytime you take an ultrasound, it's automatically stored to the organization's PAC server, which then, uh, is automatically, uh, follows their, their standardized backup procedures.

Um, so, so we've now got a backup of, of, of this patient data, not to mention the fact that we can centrally, uh, view this patient data rather than having to go to the actual device that the image was captured on, or rely on a, uh, scan of a, of a printout. Um, and I, I, I, I think I've, uh, actually covered these. I, I got ahead of myself.

I I covered these on the last slide. Um, so, um, to, uh, some things up, um, implementing PAX and small healthcare, uh, facilities, um, secures patient healthcare information behind an optionally secure service. 3, um, and it's only permitted to communicate with all authorized devices.

Uh, you can restrict what, uh, IP addresses or what host names, or what AE titles, which is, uh, an AE title is sort of like the DICOM identifier for host name. Um, and un, unless it's in a promiscuous anonymous mode, um, you can, uh, require the PAC server to authenticate with these devices so that you can ensure that no devices, uh, are present on your network that are not authorized to communicate with your PAC server. Um, the, um, so they, many, many small to mid, uh, size healthcare institutions don't currently utilize PAX because they think it's outta their price range.

Um, in these organizations, uh, healthcare imaging data is scattered amongst their multiple images imaging devices, um, in these islands of data. They're stored, uh, locally on these devices. Um, implementing a PAX doesn't have to cost millions of dollars.

Um, it can drastically improve, uh, the user workflow. Um, just because they're not required to go back, um, you know, you re regardless of the backup, regardless of the, uh, the having everything in one central location, um, the, the users are able to view images without having to go back to the actual device that the image was captured on, or rely on a scan of a printout. Um, it can, uh, pack systems, oh, sorry, I skipped ahead.

By accident, uh, PAC Systems can help ensure that all patient data is properly backed up. And, um, utilizing in industry standards like DICOM ensures that your devices and applications can communicate with one another using a standard, uh, protocol that, uh, where, where everything can harmoniously communicate with each other. Um, and, uh, that will, uh, wrap up my presentation.

Um, thank you for your time. Uh, please. Uh, if you are interested in learning more about, um, our low-cost PAC system, um, feel free to contact me.

Uh, my, my information's on the screen there. Um, and I thank you all for your time.