Alvin, One approach - like Synapses is to set in stone the object definitions for what are the equivalent of entities in many systems. This has the problem of requiring a change in the schema each time the objects change (if queries are going to be fast and safe). In GEHR we have really established the classes at a more abstract level to meet the requirements of the EHR and data is added via the archetypes (as a meta-model) - thus new archetypes can be added to enable automatic processing - but all GEHR systems can accept any record (and view it). We believe this is an essential development for future proof EHR systems. Sam Heard __________________________________________ Sam Heard Director, General Practice Education and Research Unit Northern Territory Clinical School, Flinders University PO Box 41326 Casuarina, NT 0811 Ph: +61 8 8922 7937 Fx: +61 8 8922 7928 www.ntmed.flinders.edu.au The Good Electronic Health Record A software innovation for the benefit of patients www.gehr.org ____________________________________________ ----- Original Message ----- From: "Alvin B. Marcelo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 12 January 2000 2:38 Subject: Re: Meeting and Standard objects > Thank you Nancy. > > Now I will try to push the envelope further by asking the following: > > We have seen the data models in the links provided by Nancy Orvis (dod) and > Sam heard (Synapse). And I believe there are also definitions in CORBAmed. > > But these are definitions -- not source code. We need to have the source > code versions of these definitions. > > May we then pool the class definitions of the current projects _in source > code_? Basically, we only need the classes -- not the whole EMR application. > > For example, using Telemed LANL, we would need the java source code for the > classes used by LANL with the Telemed business rules extracted. Not to mean > that we are trashing Telemed or any other project. We just want to extract > those parts of the projects that are reusable and put them in a repository > where they can be grabbed by the alliance. > > Maybe by doing this, we can even find the commonalities across projects. > > And then finally, we'll have code. > > Any comments from the project leaders? > > Alvin > > > > > At 09:17 11/01/00 -0500, you wrote: > >Have we covered the differences between CORBA and CORBAmed > >adequately? If not, here are some details. > > > >CORBA is the Object Management Group's Common Object Request Broker > >Architecture. Many folks think of Object Request Broker products and the > >Object Management Architecture. These services are typically "low level" > >services like naming, trader, IIOP, Security, etc...see the OMG web site > >for further description of the OMA at http://www.omg.org > > > >CORBAmed is the Domain Task Force of the OMG. CORBAmed defines service > >based specifications, written is ISO Interface Definition Language. The > >goal of CORBAmed is to define generic interface specifications in the OO > >Service context that are healthcare specific. The work thus far has > >accomplished basic functionality that any healthcare application might > >potentially use. (As the list discussed, different applications will have > >various business/user requirements). The CORBAmed adopted technology > >specifications include: > > > >PIDS - Person Identification Service. There has been great discussion in > >the OMG about the "P", as one could extend the traits in a PIDS interface > >to identify People, Places, Patients, Property, Party, etc. > > > >TQS - Terminology Query Service. I trust the issues to medical vocabulary > >are well understood by many member of this list. The work of Stan Huff > >(Chair of HL7) and others has brought about a great understanding of > >medical coding systems. The TQS is a service based interface to > >terminology systems. It does not endeavor to define terminology, data > >dictionaries or medical vocabulary, simply the interface for various > >systems to interoperate. Work has been done to coordinate the CORBAmed > >TQS with HL7 definitions. > > > >COAS - Clinical Observation Access Service. A standard interface to > >access data in any data store. The model associated with this > >specification is a hybrid of a variety of information models. This may > >cause issue with the HL7 RIM, however the COAS information model is > >focused on a specific service - access to clinical data. Again, work was > >done to harmonize this with HL7 Templates and HL7 OBR/OBX definitions. > > > >RAD - Resource Access Decision Facility. RAD provides a uniform way for > >application systems to enforce resource-oriented access control policies > >and was designed by security specialists to the requirements of the > >healthcare industry. > > > >A distributed EHR system needs to provide "programming models" (supported > >by languages, libraries, and tools) that are appropriate for healthcare > >environments and a range of '"Services" (for security, fault detection, > >resource management, data access, communication, etc.) that programmers > >can call upon when developing applications. Both CORBA and CORBAmed > >specification might be used to provide the range of "Services" required to > >develop an EHR. Of course, developers may also wish to use non-CORBA > >definitions for a variety of reasons. The CORBA and CORBAmed > >specifications are freely available, thus align with the Open Source > >philosophy. > > > >The CORBAmed Roadmap is an effort to document the service based > >architecture that is emerging in healthcare. It covers not only the > >services that have been identified, but the interactions between those > >services. Input on this emerging healthcare service based architecture is > >welcomed. CORBAmed does not claim to have this area solved; simply to > >provide a concensus based forum for these discussions to continue. > > > >HL7 covers message passing. Since message passing and MOM is one of the > >mechanisms used by OO systems, there is frequently confusion between the > >efforts of the two group. In reality there is an overlap, but not a > >conflict in the work of the two groups. Ken Rubin covered G-CPR work at > >the CORBAmed Roadmap session yesterday that is a good representation of > >the "Information Context" of HL7 and the "Service Context" of CORBAmed. I > >trust that Ken will post that work to the list. This same presentation > >is on the agenda for the Government SIG at the upcoming HL7 session. > > > >Beyond any immediate conflict, I envision the work of CORBAmed to mature > >into environments that allow us to use healthcare information in new > >ways. One example of this is access to libraries of reference information > >(ie. Visible Human DB). Applications that might use this detailed > >reference information in common day healthcare EHR systems is not > >available today. The structure of current healthcare applications have > >not matured to this level, the network infrastructure to support these > >applications is currently under development, and the tools to build these > >types of applications is still maturing. The data processing required to > >enable new types of collaboration is not there today. Will it be there > >next year? The year after that? 3 years? 5 years? 10 years? How far > >out of the box do we want to climb with our discussions? How differently > >will we use healthcare data in VR CAVE environments of the future? How > >will this change the practice of medicine? > >How does middleware evolve from circuits to services?...stopping this > >tangent now. > > > >Maybe we want to stick to reality and what can be deployed for a > >functional EHR system in today's environment...so should we NEVER endeavor > >to implement CORBAmed services, because they are new? Should an XML > >focus, endorsed by HL7, be the focus of these activities? I don't think > >it would be beneficial to kill discussions of application services; it is > >the focus of CORBAmed. > > > >I was disheartened by Gunther's comments to the list. I think the > >discussions here are good, and Gunther's HL7 advocacy adds > >value. However, I was surprised that the potential to embrace CORBAmed > >service based specifications for an Open Source EMR effort met with such a > >response. Many on this list confirm that CORBAmed Service Specifications > >work with HL7's RIM. I don't understand the conflict. A great amount of > >care is taken to assure that these communities align. Perhaps the EHR > >definitions at Regenstrief conflict, that is a site specific choice. I > >encourage Gunther to attend a CORBAmed meeting and bring his issues to the > >table. I hope that HL7 and CORBAmed can continue to pursue joint > >collaboration and that the Open Source community will benefit from those > >efforts. > > > >I am sorry that Gunther feels that some battle has been lost and hope that > >he continues to contribute to these discussions. > > > >Keeping the toy box open, > >Mary > > > > > > > >At 10:31 AM 1/10/00 -0500, you wrote: > >>Alvin Marcelo wrote: > >> > > >> > Is there anyone in the list well versed with Synapse and CORBA and > >> > CORBAmed who can tell us the difference or similarities of each? > >> > > >>I was going to respond and I still might, but I decided to ask someone I > >>know who worked in the Synapses project to join the list and offer a few > >>sentences about this. He has not responded back yet, so I will wait and > >>see if we can the info straight from the source. > > > -------------------------------------------------------------------------- -- > ---------- > Alvin B. Marcelo, M.D. > National Library of Medicine, B1N30 > Office of High Performance Computing and Communications > Bethesda, Maryland 20894 > > Voice: 301-435-3278 > Fax: 301-402-4080 > eFax: 603-452-3657 > > Work: [EMAIL PROTECTED] [EMAIL PROTECTED] > Home: [EMAIL PROTECTED] > > PGP keyID: 0x6E9941D1 > PGP server: http://www.keyserver.net > >
