Froid.io! Ahoi

40 views
Skip to first unread message

lemoene

unread,
Jun 16, 2018, 6:55:53 PM6/16/18
to free...@googlegroups.com

Registered, have server space, installation plan brewing...


Froid.io


Have good weekend, l


A. D Masiakos

unread,
Jun 17, 2018, 6:18:20 AM6/17/18
to free...@googlegroups.com
Great news! A plan and a work of action will be announced in a few days, regarding how the project will roll.
--
You received this message because you are subscribed to the Google Groups "Froid. Free Open Instrument Middleware" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freefroid+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/freefroid/64444b8f-d1e0-bd03-9996-863047f47bba%40bikalabs.com.
For more options, visit https://groups.google.com/d/optout.


-- 
--
--A.D Masiakos
--GIAC REM #4706
--KeyId: 0x48D84811
--http://recodestuff.wordpress.com 
signature.asc

lemoene

unread,
Jun 19, 2018, 4:56:08 AM6/19/18
to free...@googlegroups.com

Great news! A plan and a work of action will be announced in a few days, regarding how the project will roll.

Thank you Apostolos. I met with Mike who'll be holding up the Bika LIMS side, converting the CSV handlers, he has a few ideas too. The CSV handlers are alot simpler and we'll keep it that way using Python and cron only. Schmuk! as they say down under.

Apostolos, all, volunteered to co-ordinate the tech and operational management, huge thank you! I lost the trail of the initial Froid plans heading into my back-ups, it has literally been years. To have it happening is truly awesome.

I'll get me coat, have good week
l

Anousak Souphavanh

unread,
Jun 21, 2018, 12:25:59 AM6/21/18
to Froid. Free Open Instrument Middleware
Great news and thanks Lemoene, Apostolos for your initiative.

Look forward to work with you guys.

Regards,
Anousak

A. D Masiakos

unread,
Jul 6, 2018, 4:38:29 PM7/6/18
to free...@googlegroups.com
A big hello to everyone subscribed on this list. :-)

I'm sharing my initial thoughts on a probable course of action for the Froid project. I look forward to hear your opinion and thoughts.   

    Our goal is to provide a middle-ware that will be able to handle transactions of orders and results to and from laboratory analyzers. The project aims to support both serial and ethernet connections. Most of the manufacturers use the ASTM E-1381-95 [1] (transport level protocol) standard to transport the relevant records across the analyzer. Although this standard is relatively "old" its still being used, it have some revisions but the main concepts remain. I have found some relevant documents online here and there, but if anyone can pinpoint any resource, please feel free to do it.
   
The Froid project should not care -at least at the beginning- to support the application level protocols that a analyzer uses. Every manufacturer adds more or less some extensions to the application level protocol and i cannot see a simple way to acquire all those documents and to implement them. Example of application level protocols are the ASTM E-1238-94 and ASTM E-1394-97.

    Instead, we will design a clean interface to the underlying transport layer. Any application who implements and pushes orders with this interface, will be able to reach the analyzer, and acquire the results through the same interface. My initial though on this was to use redis as a queuing subsystem in which various clients will push orders and take back the results. The orders/results will be defined as .json or .yml files.

    Having froid.io registered there are ongoing conversations to set up a discourse [2] community forum to handle all design - development - testing cycles and communication. I think this will also help to expand the project to other type of instruments.

    Last but not least, we need a "manifesto", an ethical guide to publish to the medical world. We need to state the reasons we are developing the Froid project. Me as a purely technical guy do not have any experience with medical laboratories so I'm assured that the need for an open source middle-ware are better known to you guys.

[1] https://www.astm.org/DATABASE.CART/HISTORICAL/E1381-95.htm
[2] https://github.com/discourse/discourse
signature.asc
Reply all
Reply to author
Forward
0 new messages