> > This project is not yet going, it is just my personal idea and I don't > even know if I can spend any resources on this. I appreciate any of > your thoughts to add to the little "brain-storm" here. Also, I would > appreciate to know whether you would consider helping in such a > project, either through commitment of time or through funding. > I will need to create some HL7 components for some open source projects that are coming up in the next year or so. This means that I can commit some time to such a project and that there is some possibility of funding down the road (although nothing specific yet). As for potential customers, I think that there are really three types: 1) Traditional vendors using the reference implementation as a code base to start their own efforts. 2) Open source vendors embedding the reference implementation as part of larger open source projects. 3) Vendors and users of all sorts using the reference implementation as an interoperability testing tool and design model. My own ideas on this topic have centered on the third customer type because it is the most general. A parsing library, while useful, is not as interesting as a parsing library as part of a generally useful toolkit. I have been dreaming about a kind of web based HL7 monitor that could take a file or communication channel of HL7 messages and convert them to HTML for browser display. Perhaps it could also generate test messages and diagnostics for protocol and profile violations. Other tools in the kit could include an "anonymizer" that replaces patient and physician identifiers, HL7 version / format converters, filters that can do uniform substitutions on HL7 fields, or extractors that build tables of observed field values. For my purposes, C++ is the right technology for this. I think that the most useful product for VB/Corba/Scripting users would be to have an activeX/Corba interface so that they could drive a parsing/communication engine from their preferred environment. Java is another choice for this, but I would worry about performance issues. There are also problems calling into Java code from some other programming environments as you point out, although getting Corba/COM interfaces seems to be easier than C++. The most portable choice is probably still "C", since nearly any modern environment can call into "C" code. My only problem is a personal one -- C seems so restrictive after C++. -Brian
