Project SENTINEL Venture R092013R7 (PDF)




File information


Author: Michael Janeček

This PDF 1.5 document has been generated by Microsoft® Word 2010, and has been sent on pdf-archive.com on 20/09/2013 at 11:13, from IP address 62.77.x.x. The current document download page has been viewed 847 times.
File size: 2.16 MB (15 pages).
Privacy: public file
















File preview


Content
1

I n n o v a t i o n

i n t e l l i g e n c e

i m p l e m e n t a t i o n

2

2

Project introduction ..............................................................................................................................................3
1.1

Sentinel / M Tier (middleware) specifics ......................................................................................................4

1.2

First on market ..............................................................................................................................................5

1.3

History .........................................................................................................................................................10

System architecture and development environment .........................................................................................11
2.1

Limits given by technology and development environment ......................................................................11

2.2

Dataflow scheme ........................................................................................................................................12

2.3

Data model..................................................................................................................................................13

2.4

Artificial Intelligence and differential diagnostics ......................................................................................14

1 Project introduction
System SENTINEL consists of 3 major parts: Cortex (communication and system integration),
SENTINEL/M (middleware with several LIMS-like services and expert systems) and on top of everything SENTINEL/E (large scale expert system for differential diagnostics).
Cortex functional design refers to experience
gained from LIMS communication server development,
what proved us that this tier should act more like
Hardware Abstraction Layer as known from Windows
operating systems, just with caching transitional database
(due to non-homogenous environment in laboratories).
The keyword there is messages – and multiple instances
able to receive them. This way of online communication
will speed up entire system and data viability on any tier.
SENTINEL/M represents knowledge gained from
experience with bacteriology and epidemiology expert
systems from Aspiag’s BACMED® and applied research
from LIMS consultation support development. This subsystem should replace any LIMS functionality in postanalyze processing and so weaken LIMS vendor’s market space, turning LIMS into just a platform for financial
reporting and samples ordering – what may be further direction of development.
SENTINEL/E – “and here comes the science”. Once we have all LIMS data in general (gained by
Cortex, processed by SENTINEL/M), we transfer them to one central storage. There we use an artificial
intelligence to reverse-engineer the patterns of separate treatment procedures, converting them to
vectors, allowing to perform match marking later on. Then, we can let the system check for cases similar to
the ones which we are currently solving, showing us what processes led to a successful treatment, possible
complications and no-go procedures. This way we dramatically increase treatment efficiency and reduce its
cost. Then there is one very important overlap: Although all the data located in central repository will be
anonymous, original data owners will have key to re-combine them with real patients. This may be
considered not just like a security fuse (external backup), but more importantly – data owner can provide
the key to another institution in order to share the patient’s documentation.
Reverse-engineering of biomarkers development patterns: There is large list of studies proving that
mentioned patterns can be used in predictive cancer diagnostics. New studies also prove that there is much
more
we
can
learn
from
biomarkers.
Recent
study
(published
in
Nature,
http://www.nature.com/news/predictors-of-suicidal-behaviour-found-in-blood-1.13570) tells us, that biomarker
signatures may reveal depression or even suicidal behavior.
Resource complexity in differential diagnostics: Another reason to use enhanced computing and expert
systems for differential diagnostics in a simple example – what will ordinary cardiologist do, when digoxin-based
therapy fails? Most likely will change therapy to something else or – with Sentinel, considers bacterial blockade
caused by Eggerthella lenta, performs microbiology examination and if proved - simply adjusts a diet (study
published in Harvard gazette, http://news.harvard.edu/gazette/story/2013/07/bacterial-blockade/). All, what
Sentinel needs to know is diagnosis and therapy that failed so it can re-calculate the procedural decision tree.
3

1.1 Sentinel / M Tier (middleware) specifics
Middleware tier takes over most of agenda that usually belongs to LIMS systems. While Cortex tier
replaces all the communication with analyzers, M – tier brings functionality like consultations, statistics,
bacteriology and small-range epidemiology expert system… Generally: Laboratory that is considering change of
LIMS system, should keep the old one for legislatively binding functionality such as financial/insurance
reporting, but the extended functionality should be entirely on Sentinel. This marketing model should freeze
LIMS market and give us time for replacing functionality required by area of implementation. As we will already
have system integration tools previously required by Cortex. Therefore – final transition phase from middleware
to full-bodied LIMS will be swift and (relatively) easy.

On LIMS remain tasks like ordering methods and financial reporting, which, inter
alia, frees our middleware from legislatively binding functionality, which opens up foreign
markets without requiring changes to the application logic.

Specificity of the SENTINEL project consists, among other things, of its platform independence, focusing
on post-analytical processes solved through a shared data base and above-operating expert system with neural
network. The market currently has two (seemingly) similar systems, but both are supplied as part of the "total
automation", that is offered as an application extension linking groups analyzers; those are BD / Kiestra and
BioMériux / Myla, do not have cloud solution, expert systems or artificial intelligence.
Both of those, however, managed to reach important breakthrough: defending the necessity and
benefits of middleware-like systems, but have none (or just small) experience with expert systems (especially
Kiestra) and bacteriological data-mining (BioMériux / Myla). The commercial potential of both (Kiestra in 2012,
acquired via giant BD - Becton Dickinson) is currently being held back by maximum possible platform
dependency forcing the customer to purchase analyzers from one or the other and just lack of experience in the
fields of expert systems and effective bacteriological and microbiological data warehouse management .
Situation described above creates a gap
on the market - for platform-independent
provider of middleware solutions. For such
contractor (or the creator of the system) is,
moreover, a strong development experience and
expertise to the development of bacteriological
expert systems, data-mining and management of
laboratory data warehouses.

4

1.2 First on market
Market, regardless of the platform dependency, already provides some middleware solutions. How is
the idea of SENTINEL system unique then?
First, it provides a comprehensive range of expert tools able to effectively assist in solving of complex
diagnostic and therapeutic situations. As an epidemiological expert system, it searches through the database of
applicants (departments) for a presence of microorganisms with similar characteristics and estimates a
probability of a previous transfer between patients. Diagnostic and therapeutic expert system, using neural
networks, searches similar states of the patient and assesses the effectiveness of the chosen therapy,
depending on the clinical response.
As we mentioned technology and expert systems – there already is one world primacy achieved by
ASPIAG: Bacteriology expert system built on Sentinel core, released in 2009. Equation builder for bacteriology
test results with capability of re-interpretation of those results - where were identified relevant phenotypes.
Easy to adjust and update regarding to EUCAST/CLSI directives; Easy-to-customize reporting and description for
clinicians.
Further images describe how easy it is to implement or adjust new directives:
1) Define variables: those may be results of another sub-equations, constants (string or numeric) or
measurement results: Zone size, MIC value, interpretation (according to breakpoints), “Rconvergence” (position in intermediate zone, expressing convergence to resistant in %) or synergy
shape between 2 specific discs.

5

2) Create equation: Use variables defined above to create own equation – as is usually described in
EUCAST guidelines by non-structured decision tree.

6

3) Define consequences: What should be done when phenotype is identified… There are 2 types:
Executive and announcing. Executive performs corrections in final interpretation, announcing
further splits to 2 – “published” and “private”. If published, pre-defined text will appear in result list
for final consumer. Private hints are for laboratory use – such as reporting of irrelevant results that
should not be released to final consumers and usually indicate some issues in laboratory procedures
(QC).

4) Assign equations to taxonomic groups: Define groups of strains above which should be performed
previously created routines.

7

Bacteriology (rule-based) expert system described above can impress by speed as well – usual time
required for calculation above one sample takes from 5 to 15 ms (milliseconds). As outcome – we have complex
result list with PACS reference and expert findings description as below:

In brackets there are interpretations
“before” expert system, crossed-out,
calculated MIC values are values marked as
irrelevant by expert system – due to
phenotype findings. Regarding to calculating
MIC values from inhibitive zones size –
description is on image below, based on USFDA 510(k) and BSAC. Yet again, calculation
lasts split a second (below 1ms to be
accurate).

Another remarkable tool is the
epidemiology expert system. Here it comes to
more powerful computing resources, as comparing
1000 samples (usual batch size analyzed in
reference hospitals) may last up to 1 minute on
ordinary PC (including expert system recalculations).
Epidemiology expert system (IDEA – “In-depth Expert Analysis”) was released to market at September
2011 and so far, unrivalled in routine use.
How does it work?
Using basic assumption, that each strain, in
certain amount of generations, keeps same or very
similar characteristics in AST discs interactions, allows
the system to create fingerprints for each strain – and so
enables its tracking across various samples, patients or
even departments.
We can never be 100% sure of a transfer, as mutations
may occur randomly and anytime. But even after
considering such an option, this tool gives lots of points for further investigation...
Let the numbers talk first. Even after we admit that part of the conclusion is a dead end, recent studies confirm
over 85% patient-to-patient transfers on over 3.000 samples. Considering massive amount of data to be
8

analyzed, yet again, system was designed to create reports “on the fly”. In numbers – match marking of 1.000
samples requires below 1 minute of analysis, including side statistics. Image below is part of the IDEA report:

IDEA module was successfully tested and is
running on regular bases with great clinical feedback
for 2 hospitals (by 2013) – Litomyšl and Svitavy, Czech
Republic since November 2011.

Where to move further, what’s the “BIG THING” about Sentinel?
Knowledge base of entire (not just laboratory) data can be shared in a central repository of system’s
provider (data will be anonymised - patient identification is not important, the important thing is the diagnostic
and therapeutic journal). Basically, the system analyzes the patient's condition, observes similar cases on the
basis of data from the ATB centers, finds what therapy was used in which cases - and if it led to a successful
treatment (cure).

We talk about tools for the differential diagnosis possessing shared experiences (both good and
bad) of all laboratories involved in the system, capable to provide information: "Therapy, which You
suggest, failed in 70% of patients with this clinical condition, while therapy XYZ was successful with a
93% success rate " during a medical consultation... We talk about the equivalent of human diagnostics
with experience of hundreds of doctors during their service with unlimited ability to absorb new
information, never forget and always take the relevance of each case filtered by neural network into
account.

It is most likely that a similar idea has been here before, but there had never been a situation
in which it would be possible to implement this functional model: middleware is now able to obtain all
necessary data for the expert system, possessing virtually unlimited potential of private cloud
computing. At the same time (and this is probably most important aspect) – the relevance of
microbiological results has never before been on a level, that could be effective for this purpose.
9

1.3 History
History of project SENTINEL dates back to 2004, when ASPIAG s.r.o. started development of Colosseum.
The ambition of this project was to fill in the missing part on the market - in the field of microbiological postanalytic systems and was also a response to the lack of professionally developed LIMS in general.
In 2006, STAPRO unsuccessfully initiated acquisition of the project, willing to purchase the data model,
based on ASPIAG’s know-how in bacteriological data-mining and experience in the development of related
expert systems. ASPIAG s.r.o. still wanted to keep the trend of development in their directives and business
processes.
The beginning of 2009 brought iteration of the project Colosseum (now known as SENTINEL) in
connection with the new version of the product BACMED® (inhibition zones reader and analyzer with
bacteriological expert system, this time in its fifth iteration), reflecting the new technological trends. At the
same time abandoned the idea of moving towards LIMS product category, mainly due to market definition to
legally binding region (Reporting) - which opened the possibility of global distribution.
The end of 2009 brought one more acquisition attempt, this time by other technology company - Bruker
Corporation. The combined product Bruker /
Maldi TOF (world leader in identification of
microorganisms for routine laboratories by massspec) and SENTINEL concept would create an
interesting combination, but we decided to
continue own, separate way.
Year 2011 brought further and very
important iteration of Sentinel concept, in
connection with release of the analyzer Bacmed®
6iG2. For Bacmed® it meant final form of tools for
bacteriological expert system, for SENTINEL then
further need for changes in data-mining and the
next iteration in the direction of pure postanalytical machine using latest cloud technologies
for data storing and processing.

Picture: Sentinel íntroduction, 2009

10

Professional level of SENTINEL concept
was established, contradicted and consulted by
leaders on the field during international
conferences ECCMID in Nice (2006), Helsinki
(2009), Vienna (2010) and most recently in
London (2012), where the application logic was
successfully presented and confirmed by world
leaders in the field, among others, Prof.
Livermore.

2 System architecture and development environment

During the preparatory stages of development (concepts after 2009) and related case, there was first
conceived a minimalistic plan, for purely "virtual analyzer", with user interface just for setting up connectivity to
real analyzers. Over time, epidemiological expert system came into the game - that already requires intensive
cooperation with users – and in the last stage: consultations, ATB center and diagnostic expert system. This has
become to be necessary part of the UI, bringing two alternatives: "fat client" written in Delphi XE2 (due to the
option of compiling it for Apple, which means easier entry to the U.S. market), or thin client (JAVA), both based
on Oracle databases.

2.1 Limits given by technology and development environment
Up to year 2011, the model counted with use of a grid computing technology, due to the assumption of
an enormous load given by epidemiological expert system. This has led the architecture design to a "thick
client", where each client would provide part of their computing potential to the central application server. Such
an option would significantly reduce investment in server-side hardware (and de facto, system would have
positive performance coefficient, as increasing the number of clients would
empower global system’s performance). Implementation complexity,
however, hand in hand with availability of private cloud solutions, made the
grid model no longer appear to be optimal.
At the end, we can reach a conclusion, that dev. environment of
choice should be .NET with all functionality on a server, accessed by web
client. Needless to say, expert system performing above such a large data
warehouse will require powerful computing potential – where comes the
cloud computing as only possible way to go.
Question of database solution isn’t anyhow crucial for the project;
model performance did undergo stress tests on MSSQL 2008 and metrics
measurement on Oracle 11g – both with great results.

Picture: „baby cloud“ Dell
vStart 50 with two PowerEdge
R610 servers.

11

2.2 Dataflow scheme

The system needs data from several sources to be able to effectively fulfill the expectations:
1) Consolidated LIMS - patient identification, worksheets for data analyzers and other specialists (eg.
biochemical), not going through middleware
2) Analyzers – return values to worklists
3) Users – therapy suggestions, sending e-recipes to pharmacy and physicians
4) Pharmacy – information about delivering a drug to the patient (considered to be start of therapy)
5) Department (physician) / HIS
a. information about delivering a drug to the patient (from medicine storages on department)
b. Biometric data (weight, temperature, oxygen saturation…)
c. Subjective description of patient’s condition

SENTINEL EXPERT
CLOUD
(via Internet)

MIDDLEWARE
(SENTINEL)

LIMS

DATA BROKER

HIS

12

PHARMACY

PHYSICIAN
SOFTWARE

Order Server /
ComServer

ANALYZERS

NON-CONSOLIDATED
LIMS

2.3 Data model
SENTINEL project concept was developed and is maintained for a long time. Its data model served many
years as draft for next iteration of Bacmed®. Went through three iterations, the fourth (and most recent) was
adapted and re-designed for needs of statistical module OpenLIMS (RS), but with regard to the possibility of
using this model further as basic building block of a new product - the SENTINEL. Performance tests shown that
this proposed data model would be appropriate for the intended use. Its specific feature is the ability to
consolidate all data into a single structure complement and significantly improve the performance of expert
systems operating over it.
Big advantage is already-made
data model, even tested below large
laboratory data warehouses (Faculty
Hospital in Hradec Kralove, Faculty
hospital U Sv. Anny Brno and many
others). Average performance increase,
when compared to LIMS operational
database (Stapro OpenLIMS, 50% of CZ/SK
market by July 2013) was stunning – over
2700% in overall.
There are two data storages in
the design - with nearly identic structure.
One designed for laboratories - with
specific patient data, and one
Image: Core of SENTINEL’s data model
(anonymized) in a central cluster, where
the patient identification will be changed
for a "meaningless" ID. So, before any
data leaves the DMZ of a laboratory, it will be translated; at the lab, there will remain a matching table, allowing
to restore the entire local repository back from central cluster. In general, personal data will not be transmitted
over the Internet or stored in central repository.
What we need in central cluster – is data consistent enough, so that the expert system can re-engineer a
clinical case. It’s all about math modeling, surveillance and statistics, in case of (theoretical) security leak,
attacker would only get snarl of numbers. On the other hand – institution that would be authorized and given
mentioned matching table (respectively relation between patient’s personal identification and central
repository ID), would be able to obtain patient’s documentation. This might be solution for integrated healthcare data repository on a national level.
Example: End-user on ICU (let’s call it hospital X) needs information about incoming patient in critical state.
Central repository gives his system addresses of other health care facilities connected to system, so local client
can broadcast data request for specific patient. System in hospital Y will answer positively and after successful
credentials verification provides a patient’s code in the central repository. System in hospital X will download
relevant data from the central repository, replace covering code by patient’s identification and list the data to
own database as any other patient’s documentation. Easy as that – data and key to them came from different
locations, with different security level … quick and safe.

13

2.4 Artificial Intelligence and differential diagnostics
Diagnostic / therapeutic expert system is the system’s key idea, but it is necessary to prepare for possible
doubts, especially from physicians who might be considering “some neural network”, solving differential diagnosis
decision tree, at least unrealistic. Therefore, the topic should be approached sensitively and from the start you go
through the possible objections and the answers to them.

14

Objection

Answer

Differential diagnosis is too complicated process to be
manageable purely using computer technology.

Neural networks are now designed and commonly used to solve even
more complex problems, it depends on the right sort of input
parameters evaluation.

Parameters of the assessment in the differential diagnosis of
dynamically developed, a finite number of parts cannot be
determined in advance.

Not even the neural network of SENTINEL CLOUD EXPERT has limited
number of criteria; Learns from individual case reports, the new case
may ask the applicant to address the lack of evaluation and thus to
propose an extension diagnosis.

How the system will absorb "non-structured" data like family
anamnesis, possible effects of environment in which the
patient works or lives - therefore, assessment of exposure to
potentially hazardous substances, etc..

In principle, any data can be structured - such as family anamnesis
represents the relationship of genetic predisposition and diagnosis. If
there is no DNA analysis, family history is understood as an
approximation of the same. Regarding to influence by environment potential contact with hazardous substances (toxins) is a special case
of medication, which is solved by the ATB center module. From data
architecture point of view, the system understoods the patient same
way as a department, building or geographic unit - thanks to the
epidemiological module, SENTINEL can extrapolate possible future
findings based on the virulence of strains in populated place which the
patient visited.

How system knows what should it ask for?

The system does not know it at the beginning - it learns from case to
case. Let's say that at the beginning, it has a description of the
patient’s clinical condition with a family history, data from laboratory
complement and information about medication. When dealing with
another patient a month later and 1,000 kilometers elsewhere,
operator enters a similar case, with no family anamnesis, but with
information about potential patient's contact with hazardous
substances. Sentinel, in order to be able to perform most efficient
possible pairing, realizes request for information about family
anamnesis and at the same time saves reference about contact with
hazardous substances as it may be an important aspect - and may
place such question in future.

May happen then, that after some time the system will
overload the physician by a huge amount of queries, which
physician will not be able to answer?

Number of questions will initially increase rapidly, but later will
reduced, when the system detects that some information is not
relevant to the model example - or their importance is negligible.
However, the system will assess a compliance with other cases already
with a very small amount of data - naturally with a rating of
compliance and warning if the match was approaching the
predetermined critical level. In this case, the system may refuse to
provide solutions and request delivery of more information - see
previous answer.

How is it possible to take account of medical intuition and
psychic condition of the patient?

Intuition, in this context, can be understood as an empirical
approximation relevant to similar cases - an experience that occurred
in the distant past, and now we are "somehow" reminded. In fact,
neural network is continuously learning and experience he will never
forget is the greatest strength of the whole idea. Mental condition is,
from the perspective of conformity assessment, a type of secondary

diagnose.
Thus, can it be understood that the system will take (ad
absurdum) depressive patient with pneumonia as different
from case to mentally balanced patient with the same
diagnosis?

Both yes and no. Sentinel assesses the case of the patient at once,
while respecting the parallelism of given issues and need to address
them separately, although they may interact. Similar example is the
selection of a medicinal product in the case of sepsis for patient with
failing renal function. Let's say, that system knows an effective
solution for the sepsis, but also knows, that it must take account on
renal function and the best medicine for sepsis is not best regarding to
situation. Therefore it splits the solution into 2 parts - the first
suggests the earliest possible (albeit less effective) medicine for
solving sepsis, in the second part it seeks a solution to manage the
kidney problem. Mental state is similar - system could theoretically
recommend placing the patient to inducted coma, if it doesn’t expect
a need for interaction with a patient in the subjective assessment of
the clinical condition, the use of appropriate psychotropic or other
solutions. Importantly, the system from scratch does not have any
pre-prepared solutions, it learns from examples, which are daily
delivered from dozens of places.

Probably the most common objection is "a lot of people have tried, but it never worked out." There are many
answers for such an objection: 1) For epidemiological expert system it was similar - and solutions are functional, 2)
The diagnostic methods has never before been so precise, so that it would be possible to build an accurate picture and the development of genetic analysis will bring even more opportunities to expand, 3) no one had previously
tried to connect all data sources from NIS through laboratory complement to the pharmacy and effective monitoring feedback and finally 4) Never before have we had such a powerful computing resources, such as private could.
Naturally, the system will be as effective as accurate and comprehensive information for their decision-making
gets. Interest is therefore the resistance of the artificial intelligence against "bad data" - it should be noted that it is
the development of artificial intelligence, what made important steps in this direction and what can effectively
eliminate such data showing the internal contradictions and inconsistencies.

15






Download Project SENTINEL Venture R092013R7



Project_SENTINEL_Venture_R092013R7.pdf (PDF, 2.16 MB)


Download PDF







Share this file on social networks



     





Link to this page



Permanent link

Use the permanent link to the download page to share your document on Facebook, Twitter, LinkedIn, or directly with a contact by e-Mail, Messenger, Whatsapp, Line..




Short link

Use the short link to share your document on Twitter or by text message (SMS)




HTML Code

Copy the following HTML code to share your document on a Website or Blog




QR Code to this page


QR Code link to PDF file Project_SENTINEL_Venture_R092013R7.pdf






This file has been shared publicly by a user of PDF Archive.
Document ID: 0000124529.
Report illicit content