Foresight
•
3 likes•687 views
The document discusses Foresight, a clinical decision support system (CDSS). It provides definitions of foresight and describes why the software is named Foresight. It outlines some of the key problems Foresight addresses for a CDSS, including monitoring clinical events in real-time, housing shared clinical logic across applications, and surfacing outcomes to business staff. The document contrasts Foresight with other types of systems and outlines its architecture, core components, and timeline of development from versions 1.0 to 2.0.
Recommended
More Related Content
What's hot
What's hot (15)
Viewers also liked
Viewers also liked (20)
Similar to Foresight
Similar to Foresight (20)
Recently uploaded
Recently uploaded (20)
Foresight
- 1. Foresight Randy Secrist twitter: randysecrist Salt Lake City, 2012
- 2. Definition 1. an act of the power of foreseeing : PRESCIENCE 2. provident care : PRUDENCE < had the foresight to invest money wisely 3. an act of looking forward; a view forward
- 3. Why Foresight? • Needed a name to identify the software that was supporting various clinical protocols. • Blaze (initially used internal to FS) was somebody else’s software product.
- 4. The CDSS Problem • Monitor (in near real time) clinical events as they occur. • Provide a home for clinical logic that is shared across applications. • Provide solutions for surfacing outcomes to business staff.
- 7. The CDSS Problem • Monitor (in near real time) clinical events as they occur. • Provide a home for clinical logic that is shared across enterprise applications. • Provide solutions for surfacing outcomes to business staff.
- 8. Foresight is not a ... • rete based inference engine. • business process / workflow manager. • message broker. • alert service. • scheduling system. • web server.
- 9. Foresight is ... • A message oriented rule engine that uses triggers and state to invoke and execute rules & associated logic. • A way to build finite state machines. • Generates, updates, and tracks outcomes. • Extensible via modules and plugins.
- 10. Foresight is ... • Good at integrating with different systems and working with different model types. • Slightly different in implementation depending on which fork is being discussed. • A flexible system that can still go many different directions.
- 11. Timeline 2002 2003 2006 Collaboration Fork Help 2 Production Line Initial Dev using Removal of Blaze Blaze Advisor by Investigation of Drools Fair Issac MOM -> CEO 2008 2012
- 12. Timeline Version 1.0 2006 Version 2.0 Collaboration Fork 2008 2010 2012 Foresight Dev ECIS Helix / Qualibria EMR Dev
- 13. Milestones • Version 2.0 ran against production data for a period of time under the Moxie umbrella. • Timeline demonstrates a 6 year branch • Work from 2006 to 2008 removed technical debt from the first 4 years. • Proven integration against several EMR Systems and Clinical Model Frameworks.
- 14. Key Differences
- 15. Foresight 1.0 • Deploys inside of Oracle Weblogic • No common datasource abstraction. • One large code tree that used ANT. • Primarily a in-house only application.
- 16. Foresight 1.0 • Event Polling against specific DBMS. • Basic Rule Module API • Out of band cleanup jobs • Rule States loosely defined, and use internal object cache. • Security Abstraction for Outcome Routing
- 17. Foresight 1.0 • Translation Maps • List based driver (service) architecture for configuration and internal services. • Did not use xpath for rule mapper strategy. Used CEPath which had limited search capabilities.
- 18. Harvesting a Framework • We noticed that Foresight code fell into one of three categories • Code specific to the execution engine. • Code specific to a particular EMR system. • Code specific to a particular clinical domain. • So we split Foresight into parts.
- 19. Foresight 2.0 • Uses embedded Jetty for HTTP. • Added common datasource abstraction. • Added common message broker abstraction.* • Split code into several parts; uses MVN. • Designed to be modular.
- 20. Foresight 2.0 • Event Poll model removed. Push only. • Cleaner Rule Module API • No more clean up jobs. • No more rule state cache. • Simplified security abstraction for outcome routing.
- 21. Foresight 2.0 • No more translation maps. • Graph based driver (service) architecture for configuration and internal services. • Xpath based Rule Mapper Strategy. • Windows based administration client. • Windows based alert viewer.
- 22. Foresight Applications Modules Extensions Foresight Core
- 23. Foresight Applications Modules Modules Extensions Foresight Core
- 24. Foresight Abstractions • Foresight Core • Foresight Extensions • Foresight Rule Modules
- 25. Foresight Core Abstractions • Event (message) processing system. • Hot swappable rule module framework. • Support for different database backends.
- 26. Foresight Extension Abstractions • Spring Extensions • Define new services that leverage core which are EMR specific.
- 27. Foresight Rule Modules • Extensible Rule Modules • Test Harness • Client APIs
- 28. Foresight Parts • fs-shared • fs-server • fs-io_* • fs-logging • fs-wsclient • fs-site
- 29. Foresight Parts • fs-annotations • fs-filters • fs-mock • fs-xfire
- 30. EMR Specific Stuff • fs-qualibria_ext • fs-qualibria_modules
- 31. Foresight Binaries • fs-server-rpm • fs-server-zip
- 32. Foresight Boot Order • Foresight run from command line, controls logging. • Foresight starts Jetty • Jetty starts spring app context. • Spring app context loads Foresight services.
- 33. Core Config Files • fs-server/src/main/resources/com/gehc/ce/ foresight/service
- 34. Foresight Services • Gateway • Process Manager • Rule Manager • Module Loader • Thread Pool
- 35. External Tools
- 36. RabbitMQ from vmWare • Written in Erlang • Manages data in motion. • CAP Oriented • Elastic Horizontal Scaling • Alternatives: [ Redis, ActiveMQ ]
- 37. Riak from Basho • Written in Erlang • Manages data at rest. • Eventual Consistency / CAP • Elastic / Horizontal Scaling • Alternatives: [ Cassandra, MySQL ]
- 38. Questions?
- 39. Thank You! • Randy Secrist • randy.secrist@gmail.com • twitter: randysecrist
Editor's Notes
- \n
- Sometimes there are many views, but it is &#x201C;a&#x201D; view.\n
- Lots of data flows through FS. 6 years ago, it was up to 1 mil events per week.\n - babies born in utah, any hospital inpatient, many outpatients, many small clinics, all have data that flows through this system.\n\n\n
- 1) Accept only relevant data from approved sources. Maximize the sources!\n - clinobs (kitchen sink + labs) (ASN.1)\n - encounters (adt) (db trigger, table hook)\n\n\n
- Optimism is good, but without a plan for reality and scalability, this eventually stops making sense.\n
- CDSS != traditional application development. Focus is mostly on pure async analytic (data in motion) stuff. Sync calls are also supported for some applications that want to share logic.\n\nGE, others ask, why all data?\n\nThis is often what it appears we are doing to the rest of the business. Actually, it feels like this sometimes given the amount of data.\n\nWater is the data / logic / alert management problem.\n\nManage the problem.\n
- 2) This is the knowledge management aspect. Foresight only executes rule logic, but it has to know about (and partially define this) in order to execute it. Logic needs structure, and it needs to be executable.\n\nHelp2 knowledge systems had some integration with Foresight to help with the governance process IHC wanted to set up. Governance & socialization of logic (rules / knowledge) provide reduced risk for enterprise mistakes.\n - Keep business logic separate from the parts that move, store, and evaluate data.\n - often, sync calls tend to fall into this area. apps just want to run that shared logic.\n\n3) Create alerts, provide advice, new messages that are developer & clinically friendly that applications can consume.\n\nBe smart; filter out messages that don&#x2019;t have business value, yet allow a rule / knowledge driven ecosystem to flourish. Takes time to iterate and socialize these messages across the care provider&#x2019;s organization.\n\nDeveloper friendly. Outcomes and alerts need to be consumed by applications.\n\nFun to get questions about how CDSS was able to determine outcomes without actually owning any of the data it was reading. (adds value to existing apps). Glucose alert acknowledgement example.\n\nCreating modules is a clinical / technical creative process, which set me on the path of looking for what &#x2018;could&#x2019; be done with what was currently available & stretch the art of the possible. A surprising number of rule modules which add value can be done with just the most primitive data sets and variables.\n\nFrom that respect, &#x201C;all the data&#x201D; is not really necessary, but is a key aspect to getting broader community buy-in.\n\nTuneup (mHealth related app). Never would have thought of that.\n
- Doesn&#x2019;t aim to be any one of these specific things, although it may contain similar characteristics which often may confuse or lead people to think it is one of these.\n\nThe type of use case that foresight supports is incredibly specialized. That doesn&#x2019;t mean that the number of use cases is limited, but there is an element of creativity needed in order to extract value from such an analytic engine.\n\nDrools front loads the knowledge base by populating it before running rules. Foresight does the opposite; monitor a stream and remember protocol specific things for evaluation later.\n\nUsing the internal scheduler and by storing state derived from monitoring a near real time stream, workflow protocols can be built and managed. (ps02 saturation based on various peep, sat states, anti-coagulation, etc).\n\nTime and again, I have found value by amortizing the up front cost of a database query by tracking interesting values across time (as they occur) and later correlating them to provide new meaning.\n
- It is (mostly) left for external systems to evaluate whether calculated outcomes are bettering clinical care. Care must be taken to not generate too many user surfaced alerts, and to limit false positives or negatives.\n\nOutcome types may have placeholders for if they were clinically accepted, rejected, etc to assist with performing further analysis on the outcomes. Certainly more outcome types could be defined.\n\n(It is possible to write rules based upon foresight outcomes, so long as they are treated as events at some point).\n\nIterative development of modules is important. Communities and people will come up with use cases that engine designers never anticipated. I am always learning new and interesting ways in which someone has written rules on top of Foresight.\n\n
- EMR: Help2 (Tuxedo & Oracle, Knowledge Management), Carecast (Goldengate & SQLMX/MP)\nModels: MoM (Medical Object Model), CEO (Clinical Element Objects), GE/IDX Carecast Models, Relational Models.\n\n
- \n
- \n
- Time to bring the 2.0 code back into intermountain process and ultimately into production.\n\n
- courtesy of xkcd\n\n\n\n
- Oracle, JDBC, DSQL, DSS, LDAP\n - many missing abstractions\n\nDeployed on AIX, later moved to linux.\n
- - Data Drive Polling, wasn&#x2019;t the original design but was the fastest way to integrate and start getting data from existing IHC systems.\n - ASN.1 Translator by Joey Coyle\n - cdr.ejb\n - Impedance mismatch treating a DBMS table as a queue. High water mark / index / transaction locking issues. Scalability issue. (The more foresight engines there are, the more taxing the poll is for the DBMS). The faster foresight is (gets new hardware) the worse it beats up the database.\n\n - API Split into Generic Modules vs Medical Modules\n - Facilitated (via KAT/KRO) simple modifications that did not require a full test / release cycle.\n - attempt to enable IHC / Brent James vision.\n - Rule logging into the DBMS.\n - Rule state transitions not well tracked or defined.\n - patient property growth, per module\n - Rule defined types (anonymous types)\n - Rules often made direct calls to various databases rather than work with engine abstractions.\n - No easy way to test rule modules, or their associated configuration.\n\n - API leakage caused things such as long running cleanup jobs.\n
- Goals: Foresight always runs. Never needs restart.\n\nDriver, somewhat odd term. Naming is hard.\n\nUse Case: - Admin user wants to manually change (and make active) a new config file, but not restart FS.\n - Stuff that was changed with tools typically went into the DBMS.\n - can speculate as to why (translations were clinical context sensitive), but I don&#x2019;t remember all the details. Other developers cared about it & it was handy several times for troubleshooting.\n\nEach driver class had a set of functions:\n - start, stop, etc.\n\nArchitecture was implemented as a list, which had the effect of requiring configuration to be ordered. Service B couldn&#x2019;t depend on A unless A was defined first.\n\nAdditionally, several other intra service relationships were not easily tracked by using a simple list.\n\nTook effort to line up configuration in order to get correct shutdown behavior.\n\nDriver reset was all or nothing. Doing partial service resets was difficult. Moving away from Driver was hard, lots of internal services depended on it.\n\n- some needs developed for partial restart; (only some of the internal components).\n - data drive\n - time drive\n - process manager\n
- This includes DBMS specific code.\n - DBMS code was: - either purely owned by foresight\n - used to go after something specific in an EMR.\n\n\n
- Data at rest vs data in motion; handle both well.\n\nUsed jboss for a while, removed near the end.\n\n* = POC\n\nTrim the footprint & size down, stop paying Oracle / BEA for Weblogic.\n\n\n\n
- Functionally separate out how the engine gets data. This makes it easier to integrate against various EMR systems.\n\nRule API focused on lessons learned from 1.0. Things that caused cleanup jobs accounted for, and handled via correct API usage.\n\nRule state cache consistency issues gone w/o a cache. Some performance penalty, but rules that actually use this feature are in the minority.\n\nOutcomes can be saved to the FS database (or not), and can be routed to another service. Extensions (talked about alter) can pick those up and pass them to EMR systems that know more about the security model.\n\n\n
- HDD code system becomes a EMR specific binding, which can be added via extension (talked about later).\n\nBuilding a new service layer on top of a graph data structure made it easier to explicitly declare dependencies, implement partial restarts, dynamic services, and better more consistent behavior for starting and stopping.\n\nTypical start / stop uses a visitor pattern to carry out work as the graph edges are traversed.\n\nCode for windows has been scattered around. Some of the people in this room are likely the sole possessors of it now. All of it likely needs some work to decouple it from the shell and infrastructure it lived in before.\n\n\n\n\n
- Modules are where code specific to a particular clinical domain lives.\n - anti coagulation protocol that hints / suggests to clinical staff that warfarin should be increased or decreased.\n - pester someone until they come in for a visit.\n - etc\n\nExtensions are where EMR specific code would live.\n - specific databases\n - specific message brokers\n - specific data models (MOM, CEO, CEM, Archtypes, vMR, HL7)\n\nCore should remain universal.\n - Much of what was considered universal was something I decided.\n
- Modules can be independent of extensions, and just work against core.\n\nModules can also be tied to extensions.\n - A set of HL7 rules that depend on services provided by HL7 extensions.\n - Same for CEO, CEM, etc.\n\n
- Modules are where code specific to a particular clinical domain lives.\n - anti coagulation protocol that hints / suggests to clinical staff that warfarin should be increased or decreased.\n - pester someone until they come in for a visit.\n - etc\n\nExtensions are where EMR specific code would live.\n - specific databases\n - specific message brokers\n - specific data models (MOM, CEO, CEM, Archtypes, vMR, HL7)\n\nCore should remain universal.\n - Much of what was considered universal was something I decided.\n
- Core must support the other two abstractions. (extensions, rule modules and running system).\n\nResponds to real life clinical events as they occur.\n\nChange business logic easily at runtime.\n - Can hot swap configuration at runtime as well.\n\nTrack message state across time. (similar to a session, but the context is bound to a rule module / mutex token rather than a specific message, request, or user).\n\nSwapping DB backends allows for use case specific storage customization.\n\nExtensions are generally for specific EMR integrations. Provides hooks for integration with \nterminology and knowledge management systems.\n\n
- Core has it&#x2019;s own spring app context controlled by the service architecture. Core initiates a search and merge algorithm at boot time. Search uses java virtual machine arguments to locate child app contexts.\n\nhttp://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/context/ConfigurableWebApplicationContext.html\n\n
- Rule Modules can be added / removed at runtime.\n - can invoke each other, but need to be aware of the above fact.\n - engine acts as a top level exception trap\n - engine also will &#x2018;cancel&#x2019; events that timeout during execution.\n\nRules can be tested just like any other code.\n\nClient APIs: java, .net could be harvested from Admin / Alert Viewer code.\n
- These are part of foresight core until they are not.\n\nfs-io is a set of storage interfaces that core uses.\n\nfs-io_* are specific to storage backend. These are often added as extensions as well if they use spring, or define interfaces which are EMR specific.\n\n\n
- Also foresight core, more utility oriented.\n
- Contains class for consuming events from a message broker.\n\nUses a messaging abstraction that allows swapping of broker implementations.\n - activemq\n - rabbitmq\n\nModules is where qualibria specific modules could go.\n\nBoth projects serve as examples for how to build extensions and modules specific to an EMR.\n - did this in moxie, but carecast code was not moved with core. So, I only provided these as an example for someone that needed to create new instances of these types of projects.\n\n\n
- Specific maven project used to bundle foresight into a specific directory structure.\n - add fs-io_* into this if they could be used.\n - add extensions into this if they could be used.\n - a limited / fixed number of EMR systems exist in the world.\n (only about 30+ major care providers in the US)\n - don&#x2019;t add modules, those can just be added @ runtime\n\nTwo specific maven plugins required, one for jar, one for zip:\n - responsible for adding deps in lib, and correctly generating a manifest that:\n - allows java -jar to easily work from the directory that is unzipped.\n - minimal, seamless integration into pom.xml\n\n\n
- Uses standard (from c) getopt to parse options.\n\nForesight uses a TEMP_DIR variable to locate configuration, data. Allows for running multiple instances on the same machine easily. Defaults to $HOME/.foresight, can be moved using command line switches.\n\nForesight uses a web app context, must be specified on the command line using the -w argument.\n\nTCP_THREADS_OPT = set the number of jetty threads available to service requests.\n\nIf doing development, turn on java asserts.\n\nfs-server/src/main/java/com/gehc/ce/foresight/boot/BootStrap.java\n\nJetty Web App Contextd\nfs-server/src/main/java/com/gehc/ce/foresight/service/web/context/ContextLoader.java\n\nFind Spring Extensions\n/fs-server/src/main/java/com/gehc/ce/foresight/service/ConfigLoader.java\n
- app context file goes in jar file, not intended to be edited.\n\nfsconfig.xml goes in TEMP_DIR, can be modified and reloaded @ runtime.\n - placeholders to swap backend implementation using command line -e option.\n - not everything in here is intended for operations or service teams\n\n
- \n
- \n
- activemq, hornetq, openamqp, mrg, qpid, zeromq, rabbitmq\n
- cassandra, mongodb, voldemort, neo4j (graph), swift (openstack), riak\n
- \n
- \n