Thanks to Nandii Ramakrishna for tracking down the answers to the questions from members of the OCIS team. Please reply to this post if you have additional questions.
Q1 (Remi Parker): Could you please elaborate on ""OnmyWay"" functionality has an app? And assist Kiosk? I was wandering if the Kiosk always have to be complemented by ""AssstKiosk""?
A1: As a practical first step in our mobile strategy, we positioned OnMyWay as a web application and a mobile website. We will be able to package the application into a true mobile app with little effort. We welcome interested parties to contact us if this solution interests them.
Assist Kiosk and the Registration Kiosk are two distinct solutions serving two different needs, and don’t have inter-dependencies; one can exist without the other.
The primary functionality of the Registration Kiosk is to register/check-in a patient. The other functionalities it offers are: credit card payments for insurance co-payment, credit card purchase of discounted parking coupons, display public health announcements and diagnosis-specific messages.
Designed to be installed in waiting areas of hospitals or medical offices, the primary responsibility of the Assist Kiosk is to address a patient’s need while waiting to be seen: reduce the amount of time a patient spends in a waiting room, or stand in line to get their questions answered. It also affords them privacy by automatically giving them a unique number ID that is used by staff to call them in public waiting areas.
Q2 (Remi Parker): I guess the Kiosk registration and the Assist Kiosk is a different system helping with patient waiting experience? Is HL7/CPT is the standard used to check and validate the data within these two systems?
A2: The Registration Kiosk and Assist Kiosk are independent modular solutions that can be part of the Comprehensive Point-of-Care Patient Tracking System. The whole system is designed to streamline the workflow of a patient visit in an ambulatory setting: from requesting an appointment for a patient to transferring charges to a billing system. The ROI benefits of the system include: reduced patient wait time, increased patient satisfaction, money saved through increased productivity, patient throughput and billing reconciliation.
The system includes customized screens and user interfaces for all teams involved in an outpatient visit workflow: registrar, phlebotomist, pharmacist, nurse (primary and treatment) and physicians. The screens selectively integrate EMR, appointment schedule, pharmacy orders, lab results, vital signs, patient’s location, patient’s unique number ID used for calling a patient in public waiting areas, into an at-a-glance snapshot. The user interfaces provide billing entry forms for pharmacy, nurse and physician (utilizing CPT, statistical and HCPCS codes), medication administration documentation for nurses, vital signs entry for phlebotomists among other data entry capabilities.
The Registration Kiosk and Assist Kiosk needs patient appointment schedules in order to fulfil their primary responsibilities. They are both source “agnostic” as far as data is concerned. At JHH, the data was at first sourced from native appointment scheduling application, and later from data received from Epic via SIU and ADT HL7 message types.
Q3 (Remi Parker):Finally, as an EHR implementation manager, where and how do you compare these systems with Epic and VisTa?
A3: With the medical records of over half of the country's patients residing in Epic, the eponymous system has become the dominant EHR provider in the United States and is expanding its reach globally. Spanning across a similar range, VistA is the comprehensive EHR for the largest integrated health care system in the nation. So how can a (for lack of a better word) home-grown, organically-developed EHR compete in a space with a billion-dollar enterprise and an award-winning IT platform? By not competing at all! Rather our vision at OCIS is to exist alongside these successful implementations, supplementing that which Epic and VistA cannot provide or has yet not provided.
With 40 years at a leading Oncology center, the design and development of OCIS was highly optimized for clinical decision support and as well as patient-centric workflow. Many of our products--namely the Comprehensive Patient Tracking System and the Blood Order Management System--are complex applications that have evolved and been iteratively refined over time to become the most efficient yet robust software systems of their kind.
Q4 (Arun Kumar): In vista, we have everything as documented. Like in OCIS also, we have everything as documented?
A4: OCIS documentation is currently part of the JHH documentation library. As it transitions to CISpro, documentation of its products and technologies will be made available on its website.
Q5 (Arun Kumar): Can you please list out any websites for oncology documentation?
A5: It is currently only available on JHH intranet. As OCIS transitions to CISpro, the documentation will be available on its website.
Q6 (Arun Kumar): We will use global utilities, routine utilities to upload routines and globals. even we can use Kernal Installation Distribution to transfer the fileman files from GTMumps to Intersystems cache and from intersystems cache to GT Mumps. TEDIUM is also like as CPRS?
A6: Tedium shares similarities with FileMan. The OCIS Oncology EMR is similar to VistA CPRS/EHR.
Q7 (Arun Kumar): are you using any wearable technology?
A7: OCIS currently does not offer wearable technology. However it can support interactions with native clients on desktop, mobile and wearable devices through web APIs.
Q8 (Ramie Al Hamad): Is there a way of interchanging data between Tedium and FileMan?
A8: Interchanging data between Tedium and FileMan is possible but hasn’t been attempted except one time several decades ago which yielded good results. Our routine and global transfer utilities use modified versions of ISM transfer utilities, and also uses Tedium data and specification database to package the move. We are in process of using similar strategies to package the transfer of our software applications to GT.M.
Q9 (Ramie Al Hamad): The roadmap for having this application open source and on GT.M is 12 months which is very long period, can we start using the software as is and integrate it with VistA using HL7?
A9: Several OCIS applications can be acquired and used in a shorter time-frame if an institution were to invest in InterSystems Cache.
Q10 (Ramie Al Hamad): In VistA there is a module called OncoTrax which is a registry for cancer patients that can be used to extract different reports, is there something similar?
A10: OCIS has a module similar to OncoTrax which creates reporting to state and federal cancer registry. The system has not been moved to the web. This is on CISPro's work list.
Q11 (Ramie Al Hamad): Its apparent that the back-end of the oncology software is mumps, what is the front-end technology? Is it web or something else?
A11: The back-end of the OCIS, where the business logic resides, is cache database and Mumps routines generated by Tedium. The web front-end is standard web technology (HTML, CSS, JS, ...) served through InterSystems Cache Server Pages (CSP).
Q12 (Ramie Al Hamad): WHat is the license the software is going to be released under? Is it GPL or BSD-like?
A12: We are currently in the process of evaluating the license options for the products that will be offered by CISpro; we have not yet made a decision.
Q13 (Ramie Al Hamad): Are you providing web services (APIs)?
A13: OCIS currently does not provide APIs. However, an API layer has already been implemented to make APIs available for any chosen application.