Hi, How about a non-health care specific open source project? Ad and link below.
the universal information client Haystack is a tool designed to let every individual manage all of their information in the way that makes the most sense to them. By removing the arbitrary barriers created by applications only handling certain information "types", and recording only a fixed set of relationships defined by the developer, we aim to let users define whichever arrangements of, connections between, and views of information they find most effective. Such personalization of information management will dramatically improve each individual's ability to find what they need when they need it. http://haystack.lcs.mit.edu/ Sincerely yours, Tim Tim Flewelling Information Architect/Architecte de l'informatique Health and Wellness/Sant� et Mieux-�tre Government of New Brunswick/Gouvernement du Nouveau Brunswick Tel (506) 453-2871 Fax (506) 444-5505 [EMAIL PROTECTED] http://app.infoaa.7700.gnb.ca/gnb/pub/DetailPersonEng1.asp?RecordID=17800 Confidentialit�/Confidentiality: Le contenu de cet envoi, privil�gi� et confidentiel, ne s'adresse qu'au(x) destinataire(s) indiqu�(s) ci-dessus. Il est interdit par toute autre personne, de le divulguer, le communiquer ou le reproduire. Si vous avez re�u cet envoi par erreur, veuillez en aviser l'exp�diteur imm�diatement et supprimer le message de tout ordinateur. / The content of this e-mail is privileged and confidential and intended solely for its designated recipient(s). Any dissemination, distribution or copying of this material, other than by its intended recipient(s), is strictly prohibited. If you have received this message in error, please contact the sender and delete the material from any computer. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 2:33 PM To: [EMAIL PROTECTED] Subject: Re: medical systems framework Hi All, Building modular systems that inter-operate within a well-defined 'framework' requires that each module be consistent with, at least, the requirements of the 'framework', e.g., I would like to architect a 'system that is to some extent 'self-repairable' so I can travel to Mars. Since the environment and tasking are 'specific' yet to some extent 'unknown' each module should be designed to 'co-operate' within subsets of modules to at least get the 'specific' tasks covered. The 'unknown' tasks are a bit harder. Certainly a justification for putting a trained, competent, rational, capable human onboard to provide a means of altering the overall design in-flight (refer to NASA moon shots). Switching focus to the 'general' problem of designing 'frameworks' the 'specifics' are the less stressful since they can be 'canned', reviewed in meetings, and implemented using existing code, procedures, etc.. The 'unknowns' are harder, speculative, and basically unknown, the 'What if?' that few Project Managers want to hear in a review meeting but the issues the Customer wants covered, e.g., What happens if there is a power failure or a computer system fails? Perhaps the most difficult problem for the designer is responding to a question, or request, that the system accomplish one or more tasks that it was not designed to perform, e.g., Can it handle my CEO's personalized medicine for his special condition? (presuming designer prescription medicines achieve market success). My interest in 'frameworks' is directed at a Patient's ability to 'tailor' a system and its GUI for their specific Healthcare issues and history, e.g., a Patient-configurable GUI driving a reconfigurable set of tools where specific tools include Patient interface and others can be classified as 'background, enabling' tools. The 'system' would interface with appropriate Practitioners, Payers and support groups with the Patient's knowledge and permission. By necessity it would be a 'multi-user' system (e.g., Patient, Provider, Support Groups, Maintenance). A similar approach could be taken to develop a 'framework' for a Provider, the main feature being the selection/de-selection of specific functions, tools and features. For example, legacy and future systems could be integrated or masked and multiple views contracted to handle different Patients and their requirements. OpenEHR and OIO could be user-selectable with appropriate interfaces. A Practitioner may also create unique systems, e.g., extract and condense information. Unless the 'framework' can adapt continually it will eventually be replaced by one that can. Regards! -Thomas Clark Andrew Ho wrote: >On Tue, 8 Jun 2004, Elpidio Latorilla wrote: > > > >>On Monday 07 June 2004 16:20, Horst Herb wrote: >> >> >>>We really should each focus on designing a small module with a well defined >>>scope, implement it well, and publish a platform/language independent RPC >>>API for it. If we could work out a common *framework* in which such >>>independent modules can exist and cooperate efficiently (and pain free for >>>the developers), >>> >>> > >Horst, > OpenEHR and OIO are both attempting to do exactly that. The independent >modules that you speak of are the OpenEHR archetypes and OIO forms, >workflows, schedules, and reports. > >... > > >>The idea of modules created by more or less independent groups but still can >>work together as building blocks and fully interchangeable is great. We >>should really work in this direction. >> >> > > Framework-oriented projects face many obstacles. Frameworks take much >longer to engineer and implement. The promise may be great but delivery is >quite difficult. > > > >>But I see a problem with each group ( or module developer) freely >>creating his own set of RPC API's. >> >> > > OIO provides a common set of "API" to its plug-and-play modules. For >example, the XML schema for describing OIO forms. > >... > > >>I hope that what you mean with "common framework" is a "common set of API" >>that all those modules strictly adhere to. >> >> > >Publishing an API is not sufficient. We also need adequate tools to create >modules that use the API. > >... > > >>Technically this is very easy to achieve but we all know that the >>problem lies somewhere else (it is not the technology). >> >> > >We face both technological and dissemination challenges. I am happy to >share our experiences from the OIO project if they are of interest to you. > >Best regards, > >Andrew >--- >Andrew P. Ho, M.D. >OIO: Open Infrastructure for Outcomes >www.TxOutcome.Org > > > >
