Transcript: Sean Doyle, Amicas Inc., 9/26/98

Audio Tape 1/1

C: I'm hoping to talk today about open standards and open systems, which I've been thinking about. Starting with open standards, what does that mean to you?

S: It's a word I'm deeply suspicious of, because its, um, its, uh [texas accent] I ne'er met one ov them opun standards um the closest was probably HTTP and HTML and that's because it started getting defined outside of the commercial realm, you know it was like a commercially trivial thing, there were like these researchers trying to set up this global mind, you know, to communicate around the world, and some of them were really clever and they did a good job and they were focussed on what they did and so you ended up with something that actually worked. Um, but then the W3C formed and they got more corporate sponsorship and even though now, as far as I can tell, the quality of their work is very very good, you know, a lot of the deliberations are done in private and there are a lot of people who don't trust them, you know, people on the XML groups, people don't trust what the W3C is up to, and so, even though it's open and there are like comment periods and all that stuff, no one, its not really open, there's a lot of suspicion, because people don't trust Microsoft and they certainly don't trust Netscape— all those people they viewed as having run roughshod over the previous standards so there's very good reasons to be suspicious.

C: But do people make a distinction between standards that are, they can be suspicious of that are still open in the sense of 'freely available', versus standards that are owned by someone such as MS, like ActiveX?

S: Yeah, I think there's a big difference, and I think what most of the fear and cynicism with the W3C is, at this point, is that they are going to basically end up being captive to Microsoft. All the resources that Microsoft is pouring into XML for instance. I heard a rumor, though I don't have any evidence to support this, that they fund a lot of academics to go to different conferences, W3C, people that are associated with the Web. Once when there was a graduate student that didn't want to go, or rather, didin't want to do the Microsoft thing, they were the only one that funding was denied for. So it would be very interesting to look at what the money flows are, cause it's a sort of great web conspiracy thing that there could be all these urban myths about, whats really open or closed but there's a big fear of Microsoft, there's less of a fear I suppose of Sun, everyone recognizes that Sun really invented Java and people are willing to cut them a little more slack, although that's probably because they perceive it as they only way to bludgeon Microsoft, so its not that Sun's somehow better, its just that if you want to beat back the Microsoft beast, it's the only weapon that they have, so. There's open standards like XML, HTML, HTTP, they're imperfect processes but they're moving along, and people, I think people are probably unhappy with some of the processes, but in general its going forward. But with standards like DICOM, it's much harder, because those really are owned by industry groups, they didn't spring out of academia in the same way, um, lots of people that pushed them were very academic folks and wanted to interconnect different things and get images for research purposes, but there's been so many games played with the committee, that its hard to really know. I mean why did they reject wavelet compression this last time? And who knows, from what I heard it was the industry groups that squelched it saying it wasn't appropriate for now, and a lot of this is probably because, if you did this wavelet compression, then maybe you wouldn't have to sell it to the archives. Um, for years, GE, and GE is in some way the hero of DICOM, they're the ones who really pulled it together, made our company possible, and a bunch of other companies because it finally reached a certain level of standardization, for years they played with the standard too, they had a, you know with ACR/NEMA 2, they had a special card, everything was like Ethernet, same as ethernet, same resistance characteristics for the cable, lot of the same signaling stuff, but the plug was a different shape. And they did this, as far as I can tell, well the stated reason was that they didn't really trust ethernet and they wanted to have a medical protocol. But rather than adopt something off the shelf that worked really well, they said "In order to be ACR compliant you need to have this card (which only GE makes)," I think it was a few years before anyone made it commercially, so all that it really did was it served to push things out to the future. I remember talking with someone, I think it was in 91 at RSNA, where we were trying to, we knew that they had a toolkit, so within their own network they could send these ACR/NEMA messages back and forth, and we wanted to have access to that. They had some sort of a program they were talking about, but basically it was made really clear to me by this one engineer slash sales guy that it really wasn't in their interest to let other people connect to GE stuff, you know, if they could sell, like a tape drive that they got from HP and put a private label that said GE on it and then charge a lot more money for it, that was a lot more lucrative for them, and he also said it was better for the customer, because the components on the market weren't really components, they really required a prime vendor like GE to pull them all together and when things failed in a hospital they wanted a single point of contact in the hospital, they wanted to call GE. If GE's gonna take that call, they need to get the reimbursement, so I thought what they did was rather extreme, but there is some truth to their argument. But now it's what seven years later, and components are much more real. You know different SCSI devices from different manufacturers really do work together. Ethernet cards from different manufacturers, even at MGH in 1990 or so, just putting different PC's on the local net was problematic because different vendors equipment worked very differently. So its not that there , that it's all nefarious motives, it's that the world has become a much more open place, where different devices and protocols are commodities. But I think DICOM is still very slow, in the sense that I view it as a cumbersome protocol, even though it's in the eyes of the beholder whether its beautiful or not, um and as with the message I sent you last night, I think it is the best thing since sliced patient. But um, I think if you look at what most people actually use equipment for, the, a more HTTP model where when you ask for something you get it, and there would be a MIME type for DICOM, that would be far superior.

C: Isn't that threatening to happen to DICOM along the way?

S: Its being resisted fiercely by the DICOM committee, or by certain people on the committee

C: well, then if that's the case, then what are the consequences of not using DICOM, are they technical, or liability issues?

S: I don't think of any of this stuff as really being liability, as long as you're not really transforming the data or if you're transforming it in a way that's semantically well defined, I don't think there's any real liability there. Um but , there are social and technical issues, you know there are a number of academics who have made it (I put 'academic' in quotes there, people who work for academic medical centers that are funded by industry, you know they get grants and research monies and all that), there are a number of people that really built their careers on DICOM, and um, you know for a lot of them the motives were, they really wanted things to be open, but I think a lot of them just didn't notice what was happening on the internet, and right now it looks like the thing they built their career on could cave. So some of them are very defensive that way um, it's also a big, it's a big barrier to entry, once you've done the DICOM work , saying oh, we're DICOM compliant and anything else is really not standard is a way of keeping people out. And it's um, there's good and bad sides to that; on the one hand you don't want everyone to say oh I'm making a medical device, if they don't do things like, you know they get this thing and they check to see if this patient name is really the thing they asked for, you really want there to be some consistency there, (though DICOM doesn't enforce that on it's own [laughter]), so you really want some barriers, its hard to know how this is gonna play out, cause it's really a train-wreck of social things, uh, you know, can you get security things into DICOM without compromising the way it works, can you put in um, SQL, and define that unholy standard to work with DICOM, when they are fundamentally different data models? I view that as an abomination, but I can understand that for people that want to get access to their images and DICOM query mechanism is so complex, that something like SQL that you can go down to any bookstore and you can buy a dozen books on (you know, if it's a small bookstore, with only a dozen books) then its really really attractive, because you can hire people that know about this stuff, or you can read a book about it and understand it, so you know there's, people wanting to extend DICOM in ways that its needed to make it really useful for people, you know, not just so that people can like, plug a CT scanner into the network, but so that people can make their own tools. You know, we get asked for things, people are like "What I really want to see is this graph, you know, where are my studies done during the day?" and uh, if we could get the data to them in a way that they could plug into excel, then they'd be really happy, we wouldn't even have to give them any feasible interface, if we just gave them the data, that's what some people really want. And if you're just giving them the data, then there's the possibility of someone else building a product that could make it friendly or easy to use or stuff like that. and I think that a lot of these guys, people that have large DICOM products, don't really want people to get in behind the back door because:

C: It dilutes the power or the name of DICOM

S: well it's the name, but its also, if you look at the contracts for a lot these things, anything you install their software on you're not allowed to install any other products on, and for a diagnostic workstation, you can make the case that that makes sense. But if you have a diagnostic workstation, and you want to plug in a voice recognition system so you can do reports, or you want to put in a web browser because your reports are available on the web, or your telephone directory is on the web, and you need to call up the doctor, but you don't have their number, why should you have to go to another computer? It doesn't make sense, I really think it is a way of trying to control the site and control the customers. A lot of the larger hospitals have reps that are right on the site, you know and I think that they tend to view the equipment as belonging to them, or it's their thing to protect; and the world of internet standards is much more: you download it— you own it. And you're responsible for figuring it out on your own, or you have to hire a consultant or someone to help you do it. But it doesn't have to be maintained or tended to in the same way, and there's lot of chaos that results but a lot of people are willing to accept that cause they can control their own chaos.

C: Well that relates to the fact, for me, that the terms open systems and open standards are often confused, or people use them interchangeably all the time. Its seems to me that open standards sort of refers to what you are talking about, that kind of libertarian, or quasi-libertarian ethic on the internet, as opposed to freely available standards available in some sort of nirvana of interest-free organizations.

S: Well, its also, very hard, because if the standards are sufficently complex— and almost all standards that are worth anything are complicated— if they don't come with a sample implementation then you know you're toast, cause if you look at the definition of the C language, you know, it's pretty terse, if you look at the one for Java, I guess [gossleen? Geisteel?] it's really much longer, even thought the language is much more semantically clean, and its that they spent a lot of time trying to be really serious about having a language that is cross platform. If you, the main thing is that they had a working implementation that other people could test against you know, if you think of a standard like the mac-user interface, it wasn't enough that the mac had [garble] things just running out by itself, but that they had this sort of ideological cover of saying well this is the way things have to work on this. and written in such a way that people in trade magazines could read it and say oh yes that belongs or doesn't belong, um, you sort of need both the written and the implementation in order to make it go along. I've heard, and this may be a bit of folklore, I believe that TCP/IP when that, you know one of the reasons that worked so well as a standard was that some of the initial implementations were part of the UNIX kernel and they were made free, and so when there were things that weren't in the spec., you could look back at the implementation and say "I want to make it compatible with this one" then you could make it work that way. So it's really not enough to have the paper, you need to have an implementation, and it's really hard to have the incentives, for people to release both the implementation and release the code.

C: Especially without any kind of institutional support or reward.

S: With HTTP or HTML it happened because there were enough industry groups that because it was cool or because it was useful, they spent the time.

C: So much of the outraged discussion that happens, for example, on the Linux advocacy group is still about this issue, about open standards being something that happens in a realm outside of research in order to maintain this either cool or useful quality so that they can then be given away, or so that the people responsible then get the proper recognition.

S: Its hard to be, I mean, there were a lot of people that jumped into XML sort of to be the first, and some of them are like authors of books and um, that are on the xml-dev list, that are in it either for money or for glory, and well , hey that's the western tradition, um, but none of those guys could of gotten— you know they're making innovations around the edges and those innovations may turn out to dominate five years from now, but for right now, it's a relatively small product from Netscape, Sun, IBM, Microsoft, that are pushing that.

C: Then how do you feel about the kind of strategy that Adrian has around this, which may be a different meaning of the word standard, where you are trying to capture market share by becoming the standard, it's the network economics version, the more people you have using it the more power you control over that standard, how do you think about that?

S: Part of it is that its um, well, it feels fine [laughter]. Part of it is that there's this idea that there's no HTTP standard for how you query for a DICOM record, it's relatively easy to build such a thing, so if we build it, and it's useful, then we're hoping that it becomes like a de facto standard, we would love to work with a standards body to work out such a thing. The problem is that everyone at the moment has their own version of how these things work, or they're working on their own versions. So I suspect that there's going to be a period when things aren't going to play very well with each other. But one of the nice things about this very thin HTTP layer, it's sort of this very flat layer that sort of levels all contenders, so if there's things that another company does that looks like they really meet a customer's needs then we can emulate that. I'm sure, since these things are on our web page, that people are copying that, I'm not sure how, cause we're not tracking that. In some ways the legitimacy of our approach is validated if other people copy it. So theres not a big thing on saying oh we invented it here first or, holding back some implementation.

C: You don't even have anything really proprietary though right?

S: Well you could make an argument, though I think it's a very narrow argument, that the way that we specify the URL's you know the actual arguments on them are themselves proprietary, um

C: but they're not trademarked or patented

S: Oh No, we use 'pname' instead of "patientname" we have an internal id, uniqueness name that is an internal number only meaningful to us. You can query us with it, and we'll give it back and you can use it to uniquely index into the system, those things are probably not very exciting, but they're not standard, and so people could argue its just another prorietary interface. For someone to make a URL, once we've decided that we have things like accession numbers, we have patient names, we have medical record numbers um, if they take one company's URL and replace it with another, its really just five minutes of programming. SO there is a sense in which even though what were doing at one layer is a even a little bit proprietary, it's based on this very open system that there are tool kits— Visual Basic, C, Lisp, Java— its pretty straightforward to build that stuff, so in that sense it really is open by the definition that people can hook to it pretty much for free with whatever deveopment environment they have and they only have to read our documents to figure out how to do it. So in that sense its pretty open and accessible, but there are so many meanings of the word open, you know we didn't have a committee where we decided on it, and we didn't submit it to the DICOM committee for two reasons, one is that its sort of too trivial, its just too simple

C: And its probably gonna be six years before they get around to it anyway

S: Right, and the other is that I've only been to one DICOM meeting ever, and it was very interesting it was on DICOM structured reporting and I was extremely impressed with the quality of all the people there and what they were trying to come up with, but what we've done here is in some sense so much simpler that if we put it through that same process it would just slow us down, and slow down the whole market. What I think is a better model is, is to put something out there that works, having it be a lightweight enough mechanism that it's easy for people to play with or you know, propose alternative mechanisms, and then eventually it should go through that same standards process but after clinical needs are understood a bit better, I mean, to what degree, if you're gonna be a URL based interface, what security model do you want to enforce? And you know, we're kind of agnostic about that but trying to define a URL structure so that people can build in their own security thing, and then they can use our system as a passthrough to another system, that's sort of one of the things that's in the next version of it. Um, you know how do we define it so that people can have products on both sides of the client and the server and that if they're going through some of our intermediate stuff, we pass through all the information that they need for their other component, which may have information needs that we don't need, make it more open that way is a good thing, but that's really just refinement, adding a few more arguments, making documentation more explicit,

C: All under the assumption that if you can get it fairly widely distributed you have a shot at becoming a standard ex post facto?

S: Right and because we're also aiming to make this a really low cost thing where it really is possible for people to take the toolkit of their choice and hook up to it for free, were trying to make that layer of it very simple, straightforward, there's no licensing fees or anything like that, that if we're wrong and some other closely related mechanism dominates, we'll be able to switch our stuff over. Or its no great problem to have multiple implementations and have that be part of the product, because in terms of the amount of code that represents, because of the way we've structured the whole product is relatively small. So we want to be flexible too, the notion of becoming the standard is getting a lot of things to a lot of different places and building something that has real value. I think it's interesting to compare it with things like CORBA, that there has been a trememndous amount of history of participation in and a lot of the things that they come up with are absolutely wonderful, but there's no like really inexpensive CORBA implementations that you can get that are high performance. That'll probably change in a few months when the new version of Java has Corba built in. but it's, they've worked on this for years to make this an open standard they've done all the things right, they've come up with some elegant designs, I mean they're complicated, but there's a lot of good design things that went into it. Um, and um, I think it has just been a lot slower to hit the world than HTTP which was much smaller much more limited, um but, met a good enough need, I mean, we'll probably need something like CORBA for the next generation, I think the fact that there weren't any implementations out there for free that people could experiment with, was kind of the death of it or the

C: I wanted to ask you again if you thought this open systems approach as being able to solve problems in healthcare that a proprietary system if it were more efficient or more autharitarian or something.

S: Yeah, because, well if you look at the CAS system here, it took a lot to convince these guys that they just needed to write a URL interface and they could do it in Visual Basic and it would just work. But it did. If it was some prorietary thing, maybe we could have charged them money for it, maybe they would have charged us money for the pleasure of working with them or something but you know, what we ended up with is something that we can turn around and talk to another hospital and sell our system to them and on their part if a competitor comes along that does the imaging part better than us, they can show them the two HTML pages and say we want you to emulate this interface, and if they're structured well its very straightforward so I think its uh,

C: I've been sort of thinking about this as a kind of metastandard, a standard way of producing standard products or components

S: But in some sense the notion of standard here is much more lightweight than something like HTTP or TCP/IP, there are many virtues to having a slow standards process for those guys cause, because it's the infrastructure you want it to move a little bit more deliberatly and slowly, while this stuff is more on the application level, you want room for innovation and you want it to be as lightweight and as inexpensive as possible so people can play with it, so I think that there's different notions of open, I mean the fact that there's this open HTTP thing meant that theres tools in Visual Basic, C++ and Java and all these other environments that meant that there could be a lot more experimentation on the level above, and previously you would have to have like a DICOM committee come in from all over the country they stay in expensive hotels there's plane fare, it's not a trivial thing to participate, with this internet stuff, its possible because the investment in making the interface is itself lower, you can to some degree delegate to lower people, to some degree do it remotely just with email, eventually you have to meet face to face to talk it out, but right now in the experimentation phase uh, we can sort of be open in the sense that we share with a lot of people and that we let them build their own implementations as interfaces to it, and you know, we wouldn't sue anyone if they said oh we like your interface so we're going to copy it, um, at that point, we might actually want to sit down and talk with someone so that we can say "as we change it and you change it, how do we do it in such a way that both of our customer bases benefit from it. And so that people who have older systems don't get screwed and all those good sorts of things. So its hard for me to define what open really is here, there's the pragmatic of open which is can people just use it? and then there's open like in DICOM where people can use it but it might take them 3 months with a good C++ programmer to download this code and then understand it, there's very different thresholds for what open means there.

Last Modified 11-Sep-99 9:33 PM ckelty@mit.edu

Go Back to the Start