dbMotion

dbMotion
Private
Industry Healthcare
Founded 2001
Headquarters Pittsburgh, Pennsylvania
Products dbMotion
Revenue Privately held
Number of employees
 130
Website http://www.dbmotion.com/

dbMotion is a vendor of health Interoperability solutions for connected healthcare that enable healthcare organizations to meaningfully integrate and leverage their information assets.

Overview

dbMotion facilitates interoperability and health information exchange (HIE) for health information networks and integrated healthcare delivery systems. The service-oriented architecture (SOA) based dbMotionTM Solution gives caregivers and information systems secure access to an integrated patient record composed from a patient's medical data maintained at facilities that are otherwise unconnected or have no common technology through which to share data, without requiring the replacement of existing information systems. dbMotion can interoperate with multiple different vendor products[1] and the architecture’s modularity allows for multiple approaches to sharing medical information e.g. centralized, distributed/federated or any hybrid format.

dbMotion can dovetail the clinical vocabulary, or semantics, from disparate systems from different vendors, together, making it possible to view all medication orders across ICU, med/surg, and ambulatory environments, for example, on a single screen.[2] The use of interoperability can enhance efficiency and improve quality of care.[3]

dbMotion has been implemented at UPMC,[4] UMass,[5] Clalit, University Health System, Fraser Health, MidMichigan Health, Scripps Health as well as other hospitals and medical networks.

History

dbMotion was founded in 1996 within Ness Technologies's business intelligence solutions unit, which developed the dbMotion product as an innovative healthcare software solution. In 2004 dbMotion was established as an independent company with support from various venture capital investments. In January 2007, Ness Technologies announced the sale of its ownership interest in dbMotion for $6 million to its other shareholders. University of Pittsburgh Medical Center (UPMC), one of the company's first customers, also acquired a stake in the company.[6]

In March 2013, Allscripts Healthcare Solutions acquired dbMotion for $235 million.[7]

As of 2016, despite the fact that the software has been in the marketplace for 10 years, they don't handle the switch from Daylight Savings Time to Standard Time without manual intervention by their customers. Inbound HL7 messages are filed based upon the value in MSH.07 which is a date and time stamp from the originating system. The inability to handle messages out of date/time sequence causes the messages to fail. Their recommendation is for the customer to do manual intervention at 1 a.m. on Sunday morning. "To minimize risk of failed messages during the DST time change, some precautions can be taken during/before the time change. Regardless of precautions taken, the DAT(DataAnalysisTool) should be used to check for failed messages that occurred during the time change 'critical hour' (1AM DT - 2AM ST), and failed messages should be regenerated from the source after the time change has occurred." [8]

Ownership of responsibility for handling the Daylight Savings Time switch, especially in the fall when an hour is repeated on a local clock located at the message sender, is continuously debated between being the senders of the data being sent to the HIE (a patient/clinical system), or the receiver (the data aggregator / HIE, in this case dbMotion). It seems more reasonable to expect that the sender of messages would include a "DST offset" that when applied to the supplied message time-stamp would yield a UTC time causing no risk of message time overlap. If a message sender fails to provide a full description of the time-stamp allowing translation to UTC, then the recipient (the HIE, in this case dbMotion) needs to make some educated guesses as to the UTC time to be applied to messages that arrive during the hour that is repeated on a local clock located at the message sender. This situation happens once a year, however when the situation remains unhandled in code, significantly manual intervention by interface engineers is required to keep messages that were generated during this "fall back" hour flowing correctly.

References

External links

This article is issued from Wikipedia - version of the 11/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.