← Back to team overview

oship-dev team mailing list archive

Re: CDD Questions

 

Hi Justin,

The answer for your both questions below is "yes". So, in fact, is not a matter or OR, is a matter of AND. Both might happen.

[And Sergio, I didn't skip your message about archetype slots, but I have to thiiiiiiiiink about it.]

Cheers, Luciana.


Justin Duperre escreveu:
Hi Team,

"Your arguments below are excellent. I can't see why not developing CDD as a web application. But I can't see why being exclusive. Of course we are thinking about almost 99,99% of the cases of knowledge modeling that will take place, especially in the developed world, but there are some areas down here that you have to travel 3 days in order to find the first electrical outlet. OK, we know that healthcare professionals in those conditions won't be the ones modeling knowledge, because that should ideally be always performed under controlled situations, but what about a catastrophe or a new unknown epidemic? I know, this is so unlikely that it shouldn't be taken into account, but I'm here only asking us for not to make a certain technological choice without covering all the scenarios that can be devised."

Luciana, are you referring to a situation such as a traveling professional encounters a new epidemic, has their laptop on battery power, and needs to make a knowledge model (without having access to internet)? Or a catastrophe occurs and there are limited electrical/internet access points?
If so, I see what you mean.

On Fri, May 7, 2010 at 7:41 PM, Luciana Tricai Cavalini <lutricav@xxxxxxxxx <mailto:lutricav@xxxxxxxxx>> wrote:

    Hi Justin,

    Again, here I am only addressing the issues I feel comfortble with:

    Justin Duperre escreveu:

    Luciana, Tim, and Roberto - Thank you for the informative replies
    - I have a very clear picture of the objectives now. With your
    approval I would like to document some of the information from
    this email chain to our project wiki.
    Of course you have my approval, but I can't talk on the behalf of
    Roberto and Tim, but knowing them I think I can guess their
    answer. ;-)


    So, the archetypes generated are another xsd file? since an
    archetype instance is like an XML file.

    I was thinking - Since most of the MDs would rather use something
    like www.phpform.org <http://www.phpform.org/>, what are your
    thoughts on having the CDD as a web based system?
    Your arguments below are excellent. I can't see why not developing
    CDD as a web application. But I can't see why being exclusive. Of
    course we are thinking about almost 99,99% of the cases of
    knowledge modeling that will take place, especially in the
    developed world, but there are some areas down here that you have
    to travel 3 days in order to find the first electrical outlet. OK,
    we know that healthcare professionals in those conditions won't be
    the ones modeling knowledge, because that should ideally be always
    performed under controlled situations, but what about a
    catastrophe or a new unknown epidemic? I know, this is so unlikely
    that it shouldn't be taken into account, but I'm here only asking
    us for not to make a certain technological choice without covering
    all the scenarios that can be devised.

    Cheers, Luciana.

    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
    <https://launchpad.net/%7Eoship-dev> Post to :
    oship-dev@xxxxxxxxxxxxxxxxxxx
    <mailto:oship-dev@xxxxxxxxxxxxxxxxxxx> Unsubscribe :
    https://launchpad.net/~oship-dev
    <https://launchpad.net/%7Eoship-dev> More help :
    https://help.launchpad.net/ListHelp

-- Esta mensagem foi verificada pelo sistema de antivírus e
    acredita-se estar livre de perigo.



--
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.

--
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.


References