oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Diego,

Thanks for the prompt replies.  I'm going to answer both of your emails
here since they are kind of related.

Remember that OSHIP is a platform and can be used for any application.
It is not geared towards any specific healthcare application.

First is from the other email about using a local utility.  My
Terminology Server is not pure according to the openEHR specifications.
Mostly because I didn't take the time to create a real Service.  In Grok
terms this should be a separate application (therefore it should have
it's own site manager) and expose an Interface.  The current
implementation just creates a container for each set of codes.  There is
no generic Interface.  So any application (as a demo) in OSHIP will have
to know specifically the structure of the information in each container.
So, in a deployment situation.  The developers would need to provide
their own Terminology Service.  Either by creating it on OSHIP or using
something like the Apelon DTS http://apelon-dts.sourceforge.net/  
or LexBIG TShttps://wiki.nci.nih.gov/display/EVS/LexBIG+Terminology
+Server+and+LexGrid+Vocabulary+Services  
or even a commercial one like
http://www.oceaninformatics.com/Solutions/ocean-products/Clinical-Modelling/Ocean-Terminology-Subset-builder.html 


On Mon, 2010-06-21 at 22:10 -0300, Diego Manhães Pinheiro wrote:

>         
> Sorry for my mistake. You're right.
> I'll do that when I change the code to allow search actors instead of
> search parties. 
> Until separate the modules using a few of principles, it's hard to me
> to see a place to put the code in a apropriable way. Thanks to the
> advice.

Using the Grok framework, the application code goes into the primary
directory (oship/src/oship in our case).  Notice that app.py (the
default) has the OSHIP code in it as well as the terminology service.
BP Tracker is a separate application and has it's own code.  Note that
each Python code module has a matching template directory
(bptrack_templates).  This is not enforced, it is by convention. Of
course one application can have several code modules but they should all
be in that directory (also note the dsedemo).  So, if I understand your
approach to the Use Case development you would likely have a code module
usecases.py and a template directory usecases_templates.  Your entry
level class would inherit from (grok.Application,grok.Container). See
class bptrack.  But keep in mind that OSHIP itself is a platform that
provides access to multiple models such as the openEHR RM, the NHIN
CONNECT schemas, maybe HL7V3, the CCR/CCD, the WHO SDMX-HD schemas, etc.
These can all be used in one application if needed.  For example; if you
created a HIV/AIDS application and needed to report to the WHO using
their schema based messaging then you can accomplish that easily.  

I hope this all helps answer your questions about how to proceed?
If not, please ask again.  :-)

Cheers,
Tim

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