Solutions

Rapid Deployment – Lower Long-Term Cost

Through our Channel Partners, Unityware delivers disparate systems integration products and services.  Our core product is the Virtual Logic Server (VLS).  The VLS is the Unityware code on a dedicated server within the network that makes the connections and keeps them functioning properly, even if individual systems make changes.  The VLS is an anamorphic logic engine with synthetic intelligence that allows it to perform in ways you’ve only dreamed about.

You can read a case study about Unityware’s previous patented technology here.

Quite simply, Unityware can unify all the disparate computer systems within a hospital.   We are anxious to prove this to you.   Please contact us and we can arrange a very quick Proof of Concept (POC) around your specific needs.

Field Test Scenarios

Purpose:

Provide guidance to hospitals when looking for proof implementations. Tasks need to be brief enough to afford hospital personal adequate time in which to explain the objectives to Unityware implementation people. Proof projects need also be large enough to prove the effect of Unityware’s technology.

Example implementations
  • Virtual Data Warehouse
    Connect to all major hospital information system databases throughout the enterprise (test systems only) and generate either an actual global data warehouse or a virtual one.  Provide real-time direct access to a single view of a given patient and related procedures.
  • Data Anomaly Detection
    Perform data integrity comparisons on patent description data across Hospital & Clinical Information Systems.  Develop a new database into which discovered anomalies are posted with system recommended repairs (where possible) for human intervention.

Possible scenarios to be used as guides when evaluating an initial test implementation.

  • Two or more databases need to become updated where the data source does not contain enough information to complete the task. The information can be assembled by querying a table in yet another database, and possibly using that data to query another to complete the data set. Data that can not completed is inserted into a local “can’t post” table.
  • Databases A, B and C need to become synchronized where the result is updated back to all three.  Rules for handling inconsistent overlaps of data is provided by the hospital.
  • A number of databases need to be scanned for a given patient using an assured common key to compile a complete picture of a given patent.  The process output could be a new database containing tables for indexing back to the source data (in detail) and another to hold summary patent data.  Hospital to define what to do with missing records (i.e. assume that the patient did not receive the service or place in a table for human followup).
  • Scan a given table in database A and apply an algorithm to determine the action to take on the data which may include no-action, look-up from or update to tables in other databases B or C or could selectively update the source table and mark the updated table rows with a date and time.

Minimum requirements (as defined by Unityware’s current level of technology completion).

  • Any and all data that may be accessed, in any form, is on a test system safely away from any production data.
  • Databases must have an available Java driver (JDBC).
  • Access to the database and tables including appropriate permissions must be granted.
  • A set of user id and passwords needed to gain access (can be unique to this test provided it is assigned adequate permissions) need be supplied.
  • Detail of data movement from one field to another and rules to do so (this need only be as detailed as the criteria defining success dictates, e.g. if completion requirements are satisfied by our guess of where the data moves from and to) – in any event unaccessible data and/or missing data is automatically considered “complete” for evaluating the resultant test case implementation.

The implementation examples and scenarios listed above, are meant only as guides, as such, do not reflect limitations of the technology.  Other proof implementation ideas can be considered, as can combinations from the examples and scenarios.