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
------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Care2002-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/care2002-developers
