Posted by vsarmiento, 11/26/2009 8:31:14 AM

Being a former biomed person and part of planning for a new hospital being constructed in NYC in the mid 90’s, I had worked on this patient equipment networking connectivity issues. I envisioned that upon completion, the patient care systems put in place will be the state of the art for 2000 and beyond in patient care.

Since patients are the subjects and source of all needed information, I specified that any equipment used and connected to them, must be capable and have a way of collecting and relaying collected patient data back to a database where patient’s medical records will reside. Information such as patient weights registered by the bed’s built-in scale, different drugs infused via IV pumps, vital patient monitored parameters, etc., will automatically be uploaded once the device is plugged into the patient’s headwall.

At that time, most medical equipment manufacturers were just in the process of developing and debating which communication standards to be used, adapted by or to be developed as standards for the industry. Various IEEE communication protocols, and other methodologies were either proprietary, “home-brewed”, or rather experimental in nature were all considered. HL-7 standard is one of many being or under development at that time. But being more popular then, it was adapted by most major physiological monitor manufacturing companies.

To insure security as well as confidentiality of patient data, the pt. monitoring system was decided to be a small sub-network with its own local gateway to isolate yet enable connection to the main IT infrastructures. It is a network with-in a network, so to speak. This IT structure concept was also used for radiology as well as other laboratory applications. Each of which utilizes either proprietary platforms for individual data collections, prior to inclusion and storage into the medical records.

Enormous inter-connectivity problems were encountered along the way. Connectivity problems mostly associated to having differing devices, lacking proper software and hardware device drivers, etc. Problems that are directly attributed to lack of available industry standards at the time. Nevertheless, resolutions had to be found and implemented before the scheduled “go live” date.
Late 1999 when patients were moved into the new hospital and since, the systems architecture that were laid out and put in place has been and to date, still considered as the “State of the Art” in patient care.

Posted by Todd Cooper, 12/1/2009 6:08:53 PM

We DEFINITELY have and continue to feel your pain!  The good news is that there has been quite a bit of progress in at least the "baby steps" within the IHE PCD with their Device Enterprise Communication (DEC) standards-based solution.  If you look at the companies who are working on this they are all familiar (GE, Philips, Draeger, Spacelabs, Welch Allyn, etc.).

If you look at the Roadmap in the technical note, you will see that the 2011 deliverable is based on this success.  Pretty basic stuff, to be sure; however, the ONC HIT Standards committe in hearings late October heard the message from HITSP interoperability specification implementors:  "think big, start small" or adhere to the 80/20 rule.  

If you look at the roadmap, getting to the 2011 deliverables does just this ... but it is only a first step.  Getting to the items in the subsequent years will require quite a bit of support (including federal) - and to be sure, that is the true challenge outlined by this TN.

Please take a look at the roadmap and TN contents, based on your experience, and provide some feedback that will help improve the document!

Posted by vsarmiento, 12/5/2009 6:03:05 AM

The objectives, approaches, methodologies, and directions described in the HITSP Technical Report pretty much resembles what we had encountered  and resolved in the past. One can also note that changes in the manufacturer’s design philosophies can be influenced, at times dictated by the end-user’s well laid out plan and technical specifications.    

Different medical equipment manufacturers with products competing with another will always have their own unique approach and design philosophies. From data sensing, processing, and to how the data streams will be presented to the outside world. These ever changing design approaches, methodologies, and ways of data delivery are by in large dictated or limited by whatever available technologies. These differing design methodologies ultimately will become, and use as the key selling points of the company, over other competing brands.

Understanding the above mentioned inherent manufacturing industry characteristics, means Connectivity Standards can only be achieved or implemented successfully via the Interface Level.

A)  Device Drivers - Interface mechanisms,(both SW and HW), that enabled the differing products to talk and be interconnected to one another in a closed loop manner. A mechanism serving as the individual device’s interpreter.

B)  The connectivity standards should begin right at each product’s output terminal or connectors. This standard is normally governed by and/or adapted via IEEE or ANSI standards / communication protocols.

C)  Next, adapting a standardized communication language /protocols as in HL-7, etc. for medical devices. This will be used as a data encoding /decoding tool, along the main communication highway of the patient information network.

D)  Next, An operating software that links all devices, both wired and wireless, using the pre-established communications protocols, and capable of sampling and collecting patient data that are available from all ports connected in the system. The ports sampling time and speed should be independent, and not affected by the number of live devices connected or being sampled in the system. Sampling time at minimum should match real-time sampling criteria used in patient’s physiological monitoring. The bandwidth of which is governed by, as in i.e.,(Nyquist sampling criteria).

E)  All sampled and collated patient data are temporarily stored on a scratch-pad kind of storage prior to being validated by medical staff and stored into the patient’s individual medical records. This is done thru the computerized patient charts.

F)  Other medical data, related application devices, such as bar code readers, alarms and remote monitors, POC devices, med carts, etc. can be all interconnected via patient’s headwall onto the networked patient information system.

Major applications other than monitored patient data, (Radiology, Laboratory data, ADT, Patient Records /Billings, etc.), using other proprietary programs can utilize the same approach, running simultaneously /parallel into the patient network via individual gateways and ultimately into the Patient Medical Records database.