The Big Picture
Medical device interoperability and standardization is a hot topic, and with the efforts surrounding adoption of the 11073 standard, IHE and patient care device frameworks, and the drive towards implementing electronic medical records, the field has become essential to the future of the healthcare industry. Yet, as we look to realign medical devices and their communication mechanisms away from proprietary intercommunication and towards standards-based communication, we should think "outside the box" to other fields, technologies and technical disciplines for inspiration and guidance on best practices. Perhaps an obvious one that comes to mind is the USB 2.0 standard. The simple idea being proffered is the ability to plug a medical device into a computing platform and have it recognized and joined automatically to the operating system. While we are a long way from this vision as a universal standard, there is ample evidence to demonstrate its feasibility in the existing Windows and MAC OS architectures today.
Driver Bundling
Key to the seamless and universal use and acceptance of USB devices is the bundling of device drivers delivered as part of base operating systems. When a new device is developed, it could be adopted for incorporation within the base Windows and Mac operating system environments. However, even before that adoption, manufacturers of these drivers could consider bundling them as part of hardware delivery. The drivers could be installed at run time or prior to usage and, from there, no other special attention would be required: attaching a medical device to an accompanying computing platform would automatically result in that device "joining" with the base operating system. The challenge, of course, is how best to develop drivers that support consistent and common access to data. While the common Patient Care Device (PCD) framework fosters such an idea, it has yet to be realized as a universal standard.
One theme embodied by the IHE medical device connectivity demonstrations featured at HIMSS 09 (pdf) in Chicago was that of following a patient from admission through a critical care room, in which patient information was gathered at the bedside from and to the various medical devices present there, including infusion, bed, monitor, and mechanical ventilation. The ability to collect and integrate these data into a bedside electronic health record was accomplished in concert among the several medical device manufacturers through access to the communication frameworks peculiar to the many vendors participating in the demonstration. The bundling of device drivers and publishing of a common syntax required to communicate with the various devices could provide a starting point for enabling universal biomedical device communication.
It's about the patient
One possible approach to embrace is the concept of open source development to support creation of such driver bundles. Of course, device manufacturers will have to go along with this approach. But, I believe it is key to recognize that providing access to information seamlessly ultimately enhances business cases.
To maintain restrictions on access under burdensome license agreements may, in the short term, seem to protect the intellectual property base. Yet, this misses a much larger opportunity: it is not about access to the data, it is about what those data do and how they can be used to support and guide the treatment of the patient clinically. This is the proverbial low-hanging fruit.
The access to the data through hardware ports is a distraction that we must get past, collectively, as an industry. Restricting or limiting access to data impacts the healthcare organization but also constrains the ability of a medical device hardware manufacturer to expand into the larger environment that is the healthcare enterprise. The "commoditization" of the medical device interface is precisely the wrong model we should be promoting--it's about the patient and the data brought to bear to make clinical decisions that will be of ultimate benefit.
Open-source frameworks
To this end, one possible "model" would be to create an open-source framework analogous to existing open software development frameworks that could be managed or licensed in a manner comparable to GPL. Now, the challenges are clearly there: how do you control, test, qualify, certify, regulate, and secure such software? All valid and important questions. Yet, let's not dismiss the approach out of hand.
Existing regulatory mechanisms for certifying software exist and can be extended to ensure that appropriate quality controls are applied to such software and device drivers. Controlled development, deployment, and evaluation of software related to medical devices is certainly more challenging because of the very nature and use of those software applications. The development of the drivers themselves and their "care and feeding" can be guided in accord with quality control mechanisms already in place and maintained by individual manufacturers. But, the use of those drivers, their access, and the ability to suggest customization could be in the purview of the open source community. This would not only assist in development, but would also cause the acceleration of key features leading to better, more functional interface products.
Ideation
Having worked in the medical device, healthcare, and other commercial industries these past 24 years I do not come to these suggestions naively. I, too, have developed and brought medical devices to market and have experienced my fair share of the complexities involved, including issues surrounding quality and regulatory certification. The model that allows any device to be identified by simply plugging it into a base operating system makes logical sense and is a growing trend. Furthermore, by employing simple and common query and response syntax (perhaps rudimentary english commands), device information could be retrieved without relying on proprietary commands. This vision, I believe, is key to this evolving field and is necessary to support the larger ideas of personalized medicine and patient-centric healthcare that must come about in order to improve the overall quality of patient care.
I’m proud to note that this is the first contributor post from John Zaleski, perhaps one of the best known industry “connectologist.” John’s a strategic thinker, and offers some interesting ideas to one of the most fundimental problems facing the industry.
At HIMSS09 every vendor I spoke to said they were “open.” But on closer examination, they meant that if they thought it was in their interest, and the third party agreed to sign an NDA and license agreement, they would be glad to share the specifications of their proprietary interface. That’s not open by any definition I know.
The current approach of one-off interfaces with medical devices and systems like EMRs is not sustainable. Each subsequent implementation of the same interface is as expensive as the first. And with each completed interface, both vendors incur sustaining engineering commitments when either side of the interface changes.
The result — like the serial device driver interfaces they mimick — are expensive and time consuming to create and maintain. Sustaining engineering efforts frequently lag their partner’s product enhancements, resulting in broken interfaces that require customers to go back to previous product versions that still work — causing them to miss out on important enhancements and upgrades.
This is competition based on the scarcity of interfaces rather than clinical and patient safety features those interfaces enable. Everyone is poorly served by this approach.
There are ways forward, and John has offered thoughts on a good one.
Great post John!
You better be careful Tim, John might give you a run for your money as the best “connectologist blogger!”
Even if the vendors were to adopt a standard method of connectivity, what data comes across, how that data is structured and how frequently that data is updated will still be proprietary. Each vendor would want to send the data that they consider important, and especially those that give them a competitive advantage. This is similar to the situation with DICOM, which is supposed to be a standard, but each vendor has their own flavour of DICOM.
This means, even with a standard framework, it would still require development of intermediate software “adaptors” to facilitate different devices to communicate with each other. So how would this be any different to what we do today?
Pete-
Correct-syntax is important. This is why I point out that adhering to a simple approach such as english commands would be better. But, the larger point (which is not available today) is that the ability to plug ANY device into a receptacle (USB port) and be recognized for what it is does not exist overall today. Furthermore, an open-source framework (or even one similar to Apache and Tomcat) would promote more rapid development, deployment and scrutiny-resulting in higher quality. This is why I state that device manufacturers need to start thinking about the broader picture. I like to think, by analogy, of the telecommunications market with telephones: the bulk of the cost of a new cell phone is the license and usage agreement. Frequently, the phone is “thrown” in for free or a fairly minimal charge.
Regards,
jz
I’m glad Pete mentioned DICOM. With the addition of some new DICOM objects (patient monitor, infusion pump, ventilator, etc.) and service classes, DICOM has much of what’s required for a medical device connectivity standard.
Unlike 11073, there’s an established ecosystem of both open source projects, commercial libraries and standalone products like workflow engines and archives.
Why start from scratch with 11073 when we can just build on DICOM?
On the subject of DICOM, Philips and Siemens have jumped on the “native DICOM” bandwagon with their PACS offerings. If DICOM is to become more of a universal imaging platform for all the modalities then other companies are going to have to follow their lead by employing pure DICOM with no private attributes in their PACS/RIS solutions!
I agree that there are examples that are a bit farther along in development than 11073… and DICOM is a reasonable example of this. Yet, frameworks need to evolve to the point at which any device can be associated with a compute platform automatically. What I’m describing is different from the universal plug and play initiative… perhaps a step beyond: the focus is on bringing open-source development to the public forum, making driver development less esoteric. You can begin to see what I’m describing in the first few pages of the book (visible in the page sampling up front) at
http://www.amazon.com/Integrating-Device-Electronic-Medical-Record/dp/3895783234/ref=sr_1_1?ie=UTF8&s=books&qid=1240014283&sr=1-1
I discuss this more descriptively through the medical device landscape section and in the accompanying three-dimensional diagrams that identify the expanding degrees of freedom of medical device connectivity.
John - Most medical devices do have standadized connectors today - from RS232 D-Sub to RJ45 LAN connectors. What is missing, as you note, is a standardized connectivity protocol, that also offers plug-and-play. MIB was a great step in this direction, with the promise of plug and play and bi-directional communication. However, when Siemens (now Draeger) decided to implement their own flavor of MIB, the whole thing was scuttled.
Hence my scepticism on a USB based connectivity “standard”. Even with current computer peripherals, there is no standardization among USB drivers. There is an illusion of standardization, due to the fact that Windows OS contains generic drivers for common devices. These generic drivers only offer a very basic level of functionality - even when I use a MX Air mouse, the generic HID driver in windows only gives me the level of performance I get with a two-dollar mouse I pick up from a discount bin.
No medical device manufacturer will be satisfied with performance of generic drivers - infact, for regulatory (and selfish) reasons, they may even refuse to support “generic” drivers. In the end, you will end up buying certified drivers from vendors. These certified drivers will definitely be written to take advantage of the special features in each device (eg. The Logitech driver for MX Air mouse allows use of the accelerometers), making them extremely device/vendor specific. Each vendor will create their own definition/flavour of the “USB standard”, and declare theirs to be the one true standard.
So what will be the difference from the situation today? Instead of developing new “standards” every year to replace the failed “standards” of last year, shouldn’t we focus our efforts on getting at least one of the existing ones to work? MIB and DICOM seem to be good candidates. Why do we need USB and 11073?
This obsession with developing more and more “standards” gives vendors the perfect excuse of continuing to do what they want until the “perfectly standard standard” is developed.
Pete-
I understand your point. I am also very familiar with the Draeger activity. I’m not advocating more standards-I’m advocating implementing those we have and promoting more rapid mechanisms for developing and implementing plug and play. The model I was outlining by analogy was more of a telecommunications model. We need to remove the interface from the sales model. Interface drivers as commodities will cause sluggishness in adoption. The Logitech mouse example is apt and I think we need to start approaching the problem of plug and play in this way. The objective is access to the data. The open source model has been applied in other industries. As I pointed out, I’m not looking at this naively. Rather, I’m looking to shake up the debate and to think out of the box (a little bit).
Cheers
Thanks John. This was my whole point. Having a documented “standard” such as MIB can and will open doors to independent driver development. Whether Draeger, GE or Philips will allow their devices to be used with a driver made by HakrzUnited is another matter altogether.
Industry policy in this regard has always been driven by greed, as clearly shown by your former company’s actions towards MIB. This is what needs to be tackled - not more standards and frameworks.
I work for Draeger Medical and have been involved in IEEE 11073, HL7, and IHE for many years. I would like to offer my personal perspective on some of the comments in this blog…
I am not sure how Siemens/Draeger went from being the first company to invest heavily in and offer an MIB (lower layers) compatible interface to now being blamed for “scuttling” MIB. Our MIB interfaces were and are in full compliance with the original 1073 spec (remember Linktech?) and were then modified to be compliant with the current 11073-30200 spec. This was not simple or inexpensive to develop and resulted in a big yawn from the business perspective. (Yes, MIB and 11073 are synonymous…) Other companies have offered devices with MIB/11073 interfaces but, as far as I know, the world has not beaten a path to their door because of this feature.
I also take exception to the statement “Whether Draeger, GE or Philips will allow their devices to be used with a driver made by HakrzUnited is another matter altogether.” This is actually the case today, where almost all device interface drivers are made by 3rd parties and some make a business out of it (Capsule, Nuvon, Cerner, etc.). Draeger, GE and Philips provide interface specifications, lend devices and otherwise support vendors in developing interfaces to our devices. It is up to those vendors to qualify those interfaces and obtain whatever regulatory approval is appropriate for the Intended Use. Draeger, GE, Philips, etc. would certainly prefer to build to a common specification which would reduce our resource spend in this area. At the same time changing to a new approach would require considerable expenditure on the manufacturer’s part and so far little apparent broad customer demand (MD-Fire notwithstanding).
Unfortunately I am not familiar with the DICOM standards relating to transmission of ECG, pressure, etc. information. My guess is that their focus is for representation within a document associated with an image and not for “real-time” communication with monitoring equipment or clinical documentation systems.
I agree with the comments concerning “USB and plug and play”. Comparing a mouse with a medical device is a very slippery slope!! The sticking point in all this is not the choice of RS232 vs. USB vs. Bluetooth but the ability for medical devices to use the same semantics and nomenclature and potentially even describe their dynamic behavior and this is where we keep getting bogged down. The tendency is for the Standards Bodies to try to solve the most complex use cases which means they end up with infinite development cycles and no progress.
The IHE PCD Domain is making very positive progress in the right direction by biting off small pieces with targetted Use Cases in yearly cycles. This is being done by manufacturers who all realize that proprietary interfaces benefit no one. The proof of the pudding will be when we see vendor products complying with the various IHE PCD profiles. Next week (May 4-6) there will be a Face to Face meeting at NIST in Gaitherburg where there will be more than 26 organizations represented. It will be followed by a IEEE 11073/HL7 Healthcare Devices SIG/ISO TC215 Devices WG joint meeting.
It would be nice if some of the experts voicing their opinions on this blog also found the time to actively participate in some of these standards development efforts.
I agree with Ken. We have made great strides in the IHE PCD profiles. But there are several issues that one must address in this area; we have manufacturers that have “protected” VLANS where communication is a challenge, there are propriety Gateways, there are different back-end databases, and a plethora of other systems that comprise the overall medical device information system. There has been no easy method to communicate with these systems. DICOM is a good example of standardization, however, creating DICOM files from images is a much simpler process than “translating” language, order and values from a device that you need to see the data from in real or near real time. Additionally, DICOM is a historical pointer to the image. Most imaging diagnosis is performed “after the fact” as opposed to real-time. Ken’s statement is correct – “My guess is that their focus is for representation within a document associated with an image and not for “real-time†communication with monitoring equipment or clinical documentation systems.†So, even DICOM is not without challenges.
At Nuvon we have designed a solution that bridges many of the challenges and is able to become an arbiter between systems and devices. With true “intelligence at the edge” grid computing and local storage we are able to acquire, translate, and transmit data directly from the devices at the point of care and deliver real-time data for review and analysis. Nuvon is and has been actively involved in the PCD standards process.
I have been involved in the standards organizations both directly and indirectly throughout the course of the past several years. While I agree with Ken’s general statement that we cannot compare a mouse with a medical device, I firmly believe that plug and play is where we need to evolve as an industry. While many products attempt to achieve this, I must say that Nuvon’s IDM technology is the closest I’ve seen to approaching that goal.
I also agree with John’s vision of where we need to evolve to.
Ken, “investing heavily” in to MIB was exactly how Draeger scuttled the whole thing - by implementing a premature version of MIB that the other industry players had not yet agreed to. That broke the momentum of the whole initiative. As a customer who was watching the whole initiative develop, I was very disappointed by Siemens/Draeger impatience that ruined everything.
You are right, ofcourse, that major players like GE, Philips and you cooperate with reputed companies like Capsule and Nuon to create “drivers” and “adaptors” for your products. This is exactly my point - you select who you want to work with, based on their reputation and quality, and you support them. But this is hardly “plug-and-play” is it? You can’t connect a Draeger ventilator to my laptop, and magically start collecting data - I need to buy and install a DataCaptor server, configure the concentrators etc. All this costs a lot of money, mainly because Capsule and you need to recover your R&D and testing costs.
How realistic then is a “plug-and-play” standard? The idea would be that you plug in the device to a PC, install a driver and viola! data flows in - right? Well, if I have to buy a driver from you, you will charge me a huge amount (again, because you have to recover your costs). Then this is no different to the situation with Capsule and Nuon today.
As John writes in his article, the solution would be “open-source” development of drivers. This is where the hypothetical HakrzUnited comes in - let’s say a couple of people sitting in a garage in Ukraine develop a driver for Draeger Evita. Would you recognize that driver? That’s the moment of truth, my dear Ken. How confident are you, that if the customers use the HakrzUnited driver, you will not void their warranty?
Companies like Philips, GE and Draeger need to make money. You can’t afford to throw away money that we as customers place on the table. Writing software to get data out of your systems is a lucrative money spinner. You will not give that up.
So let’s quit this farce of “open-source” drivers and inventing “new standards” to support them, and focus our energy in to getting one standard right and supporting it whole-heartedly. You can (and should) charge us for drivers. We are not, contrary to the popular belief, willing to risk our patients’ lives to save a few pennies. Just decide on one standard, support it, don’t “enhance” it, don’t add proprietary extensions - make our lives easier. That’s all I ask.
1) Draeger implemented the MIB lower layers against a published, approved, ratified IEEE spec. A spec that was developed in an open environment, reviewed by experts, comments received and resolved, etc. The committee included all the significant industry players of the time (Philips/HP, GE/Marquette, Spacelabs, Cardinal/Alaris just to name a few). Draeger did not even start product development until after the standard was published and it is not our fault that the rest of industry did not follow. My impression is that your opinion comes from one of those other industry players (maybe you are one of them) that did not implement the standard and came up with a very lame excuse…
{ 2) As an aside, I am guessing you are categorically opposed to vendors such as CISCO, Netgear, Aruba, Meru, etc. who are implementing and selling 802.11n gear before the standard is released… }
3) Yes, major players cooperate with Capsule and Nuvon and Epic and Eclipsys and Cerner and Siemens and iMDSoft and Picis and many many others. Some of the people we cooperate with are researchers in hospitals to whom we provide our protocols in the same manner as we do with established players. If we received a request from HakrzUnited we would provide them with the same information. We get no direct financial benefit from doing this and do it only because it is a requirement to enable us to sell devices. So if there is someone out there that wants to write a bunch of drivers and put Capsule out of business then they are welcome to do this !! Maybe you should do this…
4) From a technical standpoint there is nothing in our Evita ventilator interface that needs to recognize the software or the software developer that is interrogating us. We don’t know if it is a Capsule driver or a researcher’s driver or a HakrzUnited driver - this is not of interest to us, contrary to your claims. Let me repeat - we don’t care. However, depending on the Intended Use of the ventilator, driver and the software on your PC that is hopefully doing something useful with the data, the FDA or the regulatory bodies in the country of deployment will be very interested. If you want to trust the driver from HakrzUnited then you are free to use it. This is not Draeger’s issue.
5) Given your accusation that Draeger scuttled MIB because we implemented it, I am not too excited about having Draeger implement another standard before it is generally accepted. I am not sure if there are other companies out there that would be motivated to move ahead on such a basis.
6) I have spent many nights and weekends over the years working on standards related to medical device connectivity, yet here we are without a generally implemented standard. A sort of acceptance of the current situation seems to have set in. I am not sure how many hospital CIOs care about this issue, since they have a solution though it costs some money. This ends up reducing the importance and pressure on the device vendors to change the way they operate. Dr. Julian Goldman (mdpnp.org) is trying to raise the visibility of this issue and maybe you should join forces with him.
As I previously posted, please get involved with the Standards and IHE processes - we need some people in there to help keep things moving forward and focused on the right things !!
Pete - one more question (actually anyone can answer this) …
From your standpoint what applications are you envisioning that this open standard should support? Is this primarily to support CIS/EMR/EHR interfaces, or full-blown hard real-time applications with complex control loops, or ??? Different requirements will drive different solution types…
Ken - I appreciate your answer. Maybe Draeger just didn’t do your PR so well. As a matter of fact, I am opposed to the network hardware vendors releasing so called “draft-N” products. A standard is a standard only when it is accepted by the majority of the big players.
I am amazed by your statement accepting possible “uncontrolled” development of drivers for your products. I do hope that when it comes to the crunch, your decision would not waver.
As to your comment 6, yes I agree that a sense of acceptance has set in. This is mainly due to the fact that people mistake “device connectivity” with “device interoperability’ (yes, I posted a rant about this too in one of the posts here). As far as most CIOs are concerned, if the data gets to the EMR, that is the end of the story. And this can be done (relatively) easily with the help of Capsule or Nuon.
What I dream about (and this is the answer to your question on what applications should be supported), is being able to connect a Draeger ventilator to a Philips monior and a BBraun pump stack, and drive a closed-loop system without fear. EMR interfaces are kids play. Direct device to device communication and intelligent interaction is the holy grail.
Pete-
I agree with your vision of the holy grail. I would caution that issue of interoperability versus integration can extend to the EMR, as well, and is not so trivial. One of the key challenges relates to clinical decision support, which, with due respect to the EMR vendors out there, is NOT all handled through the EMR interface. Quite frankly, to perform true, interventional and diagnostic CDS in real-time is not universally capable with the current EMR paradigm. Medical device data, in its complete and unabridged real-time form, is required for this. The plug and play paradigm is where we need to go.
Pete,
I also agree with your statement of vision, but see so many potholes in the way…
Seeing the difficulty we are having just getting the data from medical devices into the EMR/EHR/CIS is kind of depressing. There is a lot of work just going into nomenclature and terminology consistency. Not direcly related (until you think about pumps) but it seems that we don’t have a standard electronic drug formulary and total inconsistency from one hospital to another when it comes to expressing this information in bar codes…
When it comes to true cross-vendor closed-loop electronically controlled therapy with plug and play we have a lot of work to do. If you really want to swap a device from one vendor with a device from another, not only do you need nomenclature consistency but possibly also electronic exchange of dynamic response information since the systems probably do not act the same way given the same command. Certainly algorithms differ which can also create different results.
We have a lot of work to do…
Ken - I agree with your assessment of the difficulty in creating multi-vendor closed-loop systems. What surprises me is that not even single-vendor closed loop systems exist today. Maybe as an industry representative, you can enlighten me - is it really the technical issues and semantics that prevent it, or is it other factors - regulatory, business etc? Whenever I mention closed loops, I see raw fear flicking across the faces of industry reps.
BTW, I like how this article generated all this lively discussion. Or is it because I kicked the hornet’s nest? 🙂
Why are we allowing standards to be the red herring?
I’ve got to say that I’m in Pete’s camp for most of the comment point-counterpoint (very healthy discussion!!!) and I also like the direction proposed for standardization since it would save me time and money on the technical development but it’s not the barrier that it’s been made out to be.
My offering to this discussion is my own opinion that the business relationship, including a willing to license and terms of that license, is the real barrier. The business drivers deserve at least as much discussion. How many companies can afford to have the rug pulled out from under their product or service when it receives an arbitrary notice from the manufacturer to immediately discontinue the act of interfacing to their device and all that entails.
Is it possible to develop a model license agreement that protects the manufacturer as well as the integrator/customer/end user and ensure that a large enough pool of third parties are able to execute and act on these licenses as long as they operate within the constraints of the license (ie - avoid termination for cause)?
To my mind, the business impediments (both real and imagined) are the long poles here. The “rug pulling” aspect is only one of the challenges. Costs for re-tooling, re-certification, evaluation of potential changes in manufacturing, power requirements, etc. are the real drivers. This is why I suggested that instead of forcing manufacturers to focus on aligning directly, if a method for allowing flexibility to the end user could be employed, then I think we’d have something. Furthermore, if the physical aspect of connectivity could be simplified (e.g., I used the USB 2.0 suggestion, but this may not be optimal) a significant physical impediment could be removed.
Licensing or some type of similar approach that can simultaneously facilitate end-developer & user flexibility while protecting the manufacturers (not just legally, but technically and clinically), would probably be a compromise. My point from the beginning was that device connectivity and use of clinical data are, seemingly, analogous to the old chestnut about draining the swamp versus shooting alligators. Ultimately, we need use of the data for clinical purposes (draining the swamp). We are focused on device connectivity (shooting the alligators) to facilitate this end, for documentation and decision support purposes. I’m for the approach that enables manufacturers to achieve this level of communication as expeditiously as possible without imposing onerous requirements, tariffs, or impacting business cases.
Great blog! Like John, I was an engineer who worked at Siemens in Germany (I was in nuclear safety and simulation) and later moved into medical instrumentation and medical device interfacing/data acquisition for physiologic research. Ultimately I went to medical school and am now in the field of medicine that deals with the highest number of monitoring devices (anesthesiology and critical care).
I think the idea of an open source device driver framework could work if (1) a critical mass of CIO’s and hospitals are educated enough to understand the benefits of open source solutions (2) that these open source solutions are commercially supported. This gives the CIO’s and their IT department confidence that they will not be left unsupported five years down the road.
This is the model of the Connect NHIN (National Healthcare Information Network) based on an open source enterprise system bus (Glassfish ESB), a commercial software donated by Sun Microsystems to the open source community. The same with linux (Red Hat, Ubuntu, and SUSE) which have commercial support. The official operating system for the city of Munich, Germany is SUSE; many other cities and smaller countries are following suit.
Unfortunately, my experience with hospital IT departments is that rather than looking inward to see what their needs are (and develop a robust set of specifications and requirements), they look outwards to the journals and advertisements of vendors for their inspiration. We all know the last place to ask for good advice is from a vendor, but this is in fact what happens. For a paradigm shift to occur, enlightenment must happen first. Education is key.
Keep up the great work!
the problem with “bundling of device drivers delivered as part of base operating systems” is that device drivers usually get updated from time to time. and you would not have the latest update.
Having experienced scenarios where connectivity has interefered with the operation of medical devices the notion of a purely open source approach is unatractive. Saying that a commercialized open source approach with rigourous testing and controls procedures would be more appealing in terms of costs and patient safety.
This discussion has been really an eye opening for me and I truly thankful to everyone who has stated their comments.
So now my question is where do we go from here? What can users expect from various vendors i.e Phillips, Drager/Siemens
What can we do as users to make sure that manufacturers adhere to the path of standardization and eventually provide plug n play devices?
God Bless you all!!
Hi Tim,
GPL is a business-unfriendly license. LGPL is better, and Apache License 2.0 is best (and being adopted by the most open source projects).