oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Luciana and All,
 
On Mon, 2010-06-21 at 16:05 -0300, Luciana Tricai Cavalini wrote:
> Hi all,
> 
> Some of us from Brazil had a meeting here and here are the questions 
> that arouse:
> 
> 1) After the upgrade to Grok 1.1, the test runner is not working anymore;

We need something more specific than this.  Is it that the test runner
doesn't execute or are the tests failing?  Are you talking about the
Grok Testing framework or just the Python test framework? I only see
test code.  No application code to test against.  

> 2) Now we know how to persist and retrieve data, we are just finishing 
> doing that for the demographic use case, in order to retrieve name;
> 3) There are few details to finish implementing the RM, we got a list 
> that is outdated: some things are already done, but some things are 
> missing, but we are going to upload it on the OSHIP.org website;

Okay.  I noticed that there haven't been any commits since mine on 17
June. If there is application code then it should be committed so others
can participate in evaluation and testing. 

> 4) We have doubts about the internal terminology server: how can we 
> access it? Suggestion: using "utility" from Grok;

I assume you mean programatically? But anyway, I will ask if the text on
http://localhost:10117/oship/terms is unclear? An example of how to use
the Grok framework for creating and accessing information in the
terminology server is in app.py beginning around line 105.  While it
could be done better, there are examples of code to
add/list/search/retrieve etc.; LOINC, RxTerms, ICD and of course the
openEHR terminology. If the developers have a specific question, please
ask.

> 5) A question: if we want to perform a search of an attribute that comes 
> from the archetype, should we build catalogs from the attributes of the 
> archetype?

This is really  application dependent.  What are you putting in, what do
you want to get out.  But to be more generic, you should expect to be
able to build queries that look similar to AQL. For example, if you look
at the Python code for
openEHR-DEMOGRAPHIC-PARTY_IDENTITY.person_name_iso.v1 (it is in
oship/km/openehr/demographics/person_name_iso_v1.py)  you will see
things like:

nodeid=u'at0013'

Element(value,nullFlavor,nodeid,uid,name,atdetails,fdraudit,links)
        #u'*'
        #1
        #u'..'
        #1

DvText(value,mappings=None,formatting=None,hyperlink=None,language=None,encoding=None)
        #u'value'
        #1
        #u'..'
        #1
        #u'occurrences'


So at nodeid at0013 you will have an ELEMENT that is a DV_TEXT.  Without
some of the []s etc in AQL these paths map to URLs in order to locate
data in the ZODB.

It may also help to notice in the bptrack_templates directory there are
examples of templates used to capture input for archetyped information.
Notice how the nodeids are used as variable names in files like
deviceinfo.pt

Device Information:<br />
Serviced By:<input type="text" name="at0011" length="30" value=""  />
Date/Time Calibrated: <input type="text" name="at0010" length="19"
value="'yyyy-??-??T??:??:??'" />
Date/Time Serviced: <input type="text" name="at0009" length="19"
value="'yyyy-??-??T??:??:??'" /><br />
Manufacturer Details:<br />
Serial Number: <input type="text" name="at0006" length="30" value=""  />
Model: <input type="text" name="at0005" length="30" value=""  />
Manufacturer: <input type="text" name="at0003" length="30" value=""  />
<br />
Description: <input type="text" name="at0002" length="30" value=""  />
Name: <input type="text" name="at0001" length="30" value=""  />

<hr />

When this form is submitted it calls the Grok framework to save the
information in a class that is instantiated in memory from
blood_pressure_v1.py Well, it should anyway, this is where I quit
working on the OSHIP demo. It should be a simple matter to persist that
information.  It is already being created in the context of that
patient's ehrid.
   
> 6) If yes, does that mean that we need a catalog with all the attributes 
> from the RM and from the archetypes?
> 7) The implementation has little connection between the Grok and the 
> Python code, what to do?

Hmmmm, that is a very good question. I will have to leave that answer up
to whomever made that design decision.  But in fact if you are using the
RM classes then you do have a connection to the persistence and
locatable information.  However, the templating system will need to be
called explicitly and you will need to edit the zcml files so that your
application is included in the Grok/ZTK framework.  I'm not sure how
easy that is.  That is why I chose to use Grok so that the zcml is built
automatically.  It is quite complex to edit by hand.   


> 
> Sorry for the technical cluelessnes of the message, I was just the 
> secretary of the meeting!


No problem.  I hope this is somewhat helpful. But asking specific
questions and committing code often helps me to be able to answer
better.

Cheers,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part