The uncommon cure for common data-sharing problems
IQware is a Health Care Information System (HCIS) that is designed to work cooperatively with existing health care IT systems. IQware helps all these systems work together and eliminates the need for error-prone, costly manual re-entry of critical health care and patient information. IQware can handle all common activities including admissions, EMR, pharmacy operations, tracking auditing and compliance verification.
IQware lets you KEEP your existing IT systems. Working with your
system, rather than being at odds with it, IQware prevents the
culture shock that often accompanies the typical “IT improvement”
in the health
care industry.
IQware is your paramount HCIS solution.
Information Technology (IT) systems in Health Care are a patchwork quilt of legacy platforms, organically-grown software and specialized applications. Managing these incompatible IT systems is error-prone, labor-intensive and very expensive. Scarce hospital and private practice resources are increasingly allocated toward “putting out fires” merely to keep systems running at the current level of functionality. No time or dollars are available for increasing capability, maintaining regulatory compliance and—most importantly—improving patient care. IQware directly addresses these issues.
Here are some of the top IT priorities named by hospital and health care executives,
and IQware addresses all of them:
Here are some of the top clinical applications desired by hospital and health care executives,
and IQware addresses them all:
Here are some of the biggest barriers to investment in information technology,
and IQware addresses them all:
The health care industry has attempted to build incentives, including financial rewards and expanded efforts to standardize record formats, nomenclature, and communication protocols to enhance interoperability, but most efforts have failed because the consequences of the actions taken were not thoroughly researched and considered. The unfortunate consequence: many health care professionals continue to view information technology as an administrative tool, used to handle rote business functions, rather than a powerful clinical assistant used to streamline workload, improve efficiency, and enhance patient care.
IQware Software Solutions Allow the Health Care Industry to View Technology as a Clinical Asset, not a Necessary Administrative Evil.
Just look at what IQware, currently instrumental in providing state-of-the-art systemic solutions for the pharmacy industry, is already doing for the health care industry:
As it has with the pharmacy industry, IQware has plans to provide state-of-the-art systemic solutions to address the needs of the broader health care industry as well, including:
Pursuant to the Medicare Modernization Act (MMA), sponsors of Medicare Part D are required to include Medication Therapy Management (MTM) systems designed to optimize therapeutic outcomes for targeted beneficiaries.
The intended use of these plans is to improve medication use and reduce adverse drug events, including adverse drug interactions. The MTM encounters are fee-for-service encounters, a cost that prescription drug providers are required by law to reimburse. To be provided primarily by pharmacists, an already over-burdened professional population, the services must be adequately tracked, regulated and reported. In an effort to ease the administrative burden on pharmacists while concomitantly increasing their ability to provide—and charge for—MTM patient services, the team at IQware has developed the first comprehensive, HIPAA-compliant health information delivery system for Medication Therapy Management (MTM) Plans.
To see our informational presentation
click here
To see the Main Issues Surrounding Compliance
click here
MUMPS (sometimes called "M") is a general purpose programming language that supports a native hierarchical data base facility. The language originated in the mid-60's at the Massachusetts General Hospital, and it became widely used in both clinical and commercial settings. ANSI, ISO (ISO/IEC 11756:1992) and DOD approved standards were developed for MUMPS, although several of these have lapsed.
MUMPS differed from other mini-computer based languages of the late 1960's by providing:
Syntactically, MUMPS is based on an earlier language named JOSS and has an appearance that is similar to early versions of Basic that were also based on JOSS.
MUMPS was originally written for the DEC family of mini-computers, including the very popular PDP-11 series. The operating systems supported included RT-11 (single-user), TSX-11 (multi-user), RSX11, RSX11-M, and RSTS/E. DEC-10 and DEC-20 systems also supported MUMPS applications for a number of hospitals.
Initially, the MUMPS’ structure was limited by the constraints imposed by the minicomputers and operating systems on which it was originally implemented. An early design goal for MUMPS was to provide multi-user, time-shared access despite the very limited memory and mainly single-user operating systems available at the time. Consequently, early implementations of MUMPS were mainly standalone, interpreter based, dedicated operating systems. In these implementations, each user was assigned a very small region of memory for both code and local data. Source code was loaded from external storage and stored in memory in source form. Since MUMPS programs were mainly interactive and dominantly data base access dependent, direct interpretation of source code did not introduce serious performance penalties. Typically, program partitions were less than 4,000 bytes, including all data, stacks, code and buffers thus allowing multiple time-shared partitions on even the smallest machines.
Because of early mini-computer memory and address space limitations, MUMPS applications usually consisted of many small, task-specific programs that were modular, compact, highly abbreviated, concise and focused on a limited objective. Program modules then, as now, were loaded frequently from a library. Applications typically consisted of a tree-like hierarchy of program modules that often corresponded to the structure of the underlying database in an early form of object-oriented programming style.
An excellent example of an early system structured this way can be found in the structure of the COSTAR System that employed well over a thousand tightly coupled and encapsulated separate code modules to service an ambulatory patient record data base. A more recent example is the widely used Veterans Administration Distribute Hospital Computer Program (DHCP) system, now known as Veterans Health Information Systems & Technology Architecture, which consists of several thousand MUMPS routines. Of course, DHCP now refers to the "Dynamic Host Configuration Protocol" which allows network devices to automatically "lease" a valid IP address from a server.
Initially, all MUMPS implementations were pure interpreters. As MUMPS evolved, various methods were developed to partly compile MUMPS code to intermediate representations, similar to Java byte codes or UCSD Pascal P code. However, due to indirection and the Xecute command, the interpretive nature of the language was always present. Indirection permits a MUMPS program to dynamically construct and execute MUMPS expressions and commands.
In 2000, development began on a compiler for MUMPS, written in C and C++ that translates MUMPS to C++. The compiler initially began as an interpreter implementation. It supports fast, flexible, multi-dimensional and hierarchical storage, retrieval and manipulation of data bases ranging in size up to 256 terabytes (TB).
IQware can share data with MUMPS applications by directly accessing the on-disk records created and used by the MUMPS applications. IQware can also interface with MUMPS applications by dynamically launching a MUMPS-coded “agent” to access the requested data records on an as-needed basis. A third way that IQware can connect to MUMPS applications is by dynamically copying MUMPS data records to its internal relational database. This lets modern structured applications and relational database tools be used on the data records. Note that this dynamic record transfer can be bi-directional, if desired. In this case, the MUMPS “agent” must be configured for record locking to prevent conflict issues. A sample deployment is shown below: