Once becoming language agnostic, the next logical step forward would
be to become OS agnostic as well (unless the goal of a language
agnostic CDD tool is to make the tool OS agnostic - then a web based
tool would solve both of these issues).
Also, any changes made to the tool would affect everyone at the same
time (no re-downloading the program for updates or new versions).
Scalable, reliable, and very available. It would basically be building
a dedicated, schema-compliant "form" like Roberto said, using schemas
stored on a back end database/server accessed through a web portal.
The user could designate their domain which would filter the schema
appropriately, and select an archetype or create a new one based on
the selected schema - appropriate buttons would be on the web form.
Therefore base schema could be updated and uploaded right to the
server if any changes were needed (as listed by Luciana earlier).
Other tasks can be performed based on requirements or other desired
capabilities - this is just a rough outline.
This is just an idea, but it really would cover everyone I believe,
assuming they have web access.
- Justin
On Thu, May 6, 2010 at 1:51 PM, Tim Cook <timothywayne.cook@xxxxxxxxx
<mailto:timothywayne.cook@xxxxxxxxx>> wrote:
Hi Justin,
I have copied this to the OSHIP-dev list so that others may
benefit from the conversation.
On Thu, May 6, 2010 at 9:33 AM, Roberto Siqueira
<siqueira@xxxxxxxxxxxxxxx <mailto:siqueira@xxxxxxxxxxxxxxx>> wrote:
Hi all:
Let me try to address the "XMLSpy" part:
> - why can't XML spy be used? (or similar xml editor) - there are
> existing tools to build xml files from xsd files. Converting
the xsd
> files to Glade widget is basically converting xsd to xml -
since glade
> is an xml in its entirety.
You're perfectly right [in fact, that's precisely the reason why
moving from ADL to XML was a big step forward: we don't need to
"reinvent the wheel" any more]. There are even XSD-aware,
context-sensitive editors like Oxygen
( http://www.oxygenxml.com/intelligent_xml_editing.html ) and
Serna Free
(
http://www.syntext.com/products/serna/features/xml-validation/
), that
are *very* user-friendly.
But you must remember that our main users are MDs (medicine
doctors),
not ITs (information technologists). On the long run, some of
them will
get well acquainted with the XML tools, but most of them will
rather use
something like http://www.phpform.org/ (by the way, the nicest
"form
buider" I've found so far!) instead. Indeed, that's is the
main paradigm
of this 2-tier project: to separate the medical knowledge
"layer" from
the IT one, so each specialist can concentrate only on his/her own
domain.
I'm not certain that I was clear in past emails about the use of
XML Schemas as concept constraint definitions (CCDs), aka.
archetypes in openEHR and in template constraint definitions
(TCDs), aka. Templates in openEHR.
Both the CCD and TCD should be represented as an XML Schema NOT
just an XML file. Remeber that an 'archetype' does not contain
data. It is a defining framework for data. The 'instance' of an
archetype is similar to an XML file. These contain data and must
validate against the archetype/template or CCD/TCD respectively.
So, for CCD and TCD schemas; they will 'include' the XML schemas
of the reference model and then define the clinical concept (CCD)
or a group of clinical concepts (TCD).
Comments? / Suggestions?
Tim
--
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.
------------------------------------------------------------------------
_______________________________________________
Mailing list: https://launchpad.net/~oship-dev
Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~oship-dev
More help : https://help.launchpad.net/ListHelp
