myZure™ Healthcare IT - TeleHealth & Contract Tracing
Multi-User Simultaneous Concurrent Users
CMS-1500 Health Insurance Claim Form
"Pro" Claim Entry - Data Validation
Contact Tracing, Geo-Location
Appointment Calendar "Outlook Style"
Twilio™ for Healthcare Telehealth
QuickBooks™ Online Interface
Cloud Data Access
Interacts with MS Office
Built-in Chromium Browser
Internet Web Communications TCP/IP
(BI) Business Intelligence Dashboard
"QBE" Query by Example
Audit Trail Log & Rollback
"Handwriting" Character Recognition
"One-Click" Data Copy
QR Codes and Images
Code Validation Tables
Appointments by Hour Chart
Send Data To Excel, XML, Email
Simple Fill-in-the-Blanks "FITB" Claim
Easy to Use - File Manager
Access Favorite Social Media & Others
Import Export Manager
Chromium Explorer/Browser, Editor
OddJob Advanced running of processes.
Contact Tracing feature collects accurate contact information for tracking
Pin Point Latitude & Longitude Accuracy
Twilio™ SMS (Simple Message Service)
When it comes to health, a notification or text message is more than just a message, it’s a reminder to patients of how to take care of themselves, and how healthcare providers help patients manage their care.
In the healthcare field, messaging, SMS, and chat have different engagement rules and regulations. It’s important to use an API that’s flexible enough to let you build the exact system you need.
With the high cost of healthcare, providers must keep costs as low as possible. API solutions like Twilio allow pay-as-you pricing that scale naturally as use grows.
What does the future of patient communication hold? As adoption of SMS continues to rise, new engagement models will reduce costs and personalize experiences faster. Thanks to technologies such as voice activation, AI, sentiment analysis, and bots, patients will be able to text simple questions and receive personalized answers right away.
Deliver A New Standard of Patient Engagement - Real-Time Video (HD)
The healthcare landscape is more dynamic than ever. Confidently navigate patient expectations, and rapidly deploy engagement and telehealth options with Twilio.
Improve patient access, eliminate frustrating wait times, and empower physicians and providers to use their time better. Healthcare is never one-size-fits-all; with Twilio, you have channel choices and the ability to rapidly and efficiently respond to the need at hand.
Expert System Knowledgebase
Healthcare as with any other profession is founded on the "expert knowledge" of professionals which it depends on. Having the right answer to the question in moments can mean the difference.
Often it's in the heads of key professionals and staff who could leave, become ill, etc.
myZure comes with Expert System that enables the capture of expert knowledge and have it available 24/7 for all staff and professionals
Inference Engine, Logging, and Audit Trail
Kept separate from the Knowledge Base so user has ultimate flexibility in creation of "Expert Knowledge" base
A log is kept of every session so that a user can check back on what their responses were and the Expert System will explain how it arrived at its decision.
Audit trail of questions and responses is also kept and is very useful when building the expert knowledge base.
Optional one-click importing – where all parameters are setup in advance by the developer
Update (replace) an existing record – as part of the de-dupe routines
Wizard type steps make importing very easy to understand
The user can match up fields by a Map by Name button (for similar labels) and then drag and drop. These Map Structures can be saved for future use.
Duplicate checking can be enabled by both the developer and the end-user with the option of adding replacing or skipping duplicates and saving them to a text file for later viewing/printing.
At runtime the user can “override” incoming text for a particular field with their own choice of text (or date).
For testing purposes a set number of records can be imported.
End user can set delimiter for ASCII import (defaults to comma)
Unattended and batch imports – using command line parameters
Records are added to your existing data file and if there is an Auto Number key the auto-number field will be incremented automatically.
Checks can be made by means of an EMBED point just before a record is added. For example you could check if a required field is blank.
For ASCII files there is the option to skip the header record (useful if this record contains just field names) and allow double quote marks.
Export to HTML, Delimited (comma, tab, pipe, semicolon)ASCII, Flat ASCII
Set Field Order for any export format and with Flat ASCII can also override the dictionary field length
HTML options: end user control over page and table attributes (font, color, width, cell spacing etc.) inclusion of user header/footer HTML (for example standard navigation bars) so the look and feel of their website can be maintained table fields can be given a URL link data can be output to one page or multiple pages. In the latter case Next/Previous links and page numbers are placed on each page generated.
The user can define which fields are included in the export file. So for example the user could exclude confidential data fields from being exported. These selections can be saved for future use.
For ASCII files there are options for header record double quotes and date format. Date fields are automatically detected by the templates.
Exclude fields from export – by both developer and end user
Create a new field on export – such as FirstName + MiddleName + LastName
Application Program Interface to:
CMS-1500 Claim Form
Process CMS-1500 Claims
Two Options for Claims Data Entry:
"FITB" Fill in the Blanks form entry
PRO Entry with interface to Patient data.
CMS-1500 Background Information
The 1500 Health Insurance Claim Form (1500 Claim Form) answers the needs of many health care payers. It is the basic paper claim form prescribed by many payers for claims submitted by physicians, other providers, and suppliers, and in some cases, for ambulance services.
ASLR also often referred to as DYNAMICBASE, modifies the header of an executable to indicate whether the application should be randomly rebased at load time by the OS.
ASLR is transparent to your application. With ASLR, the only difference is the OS will rebase the executable unconditionally, instead of doing it only when a base image conflict exists. ASLR is supported only on Windows Vista and later operating systems, it is ignored on older OS versions.
Why should you use ASLR?
On platforms without ASLR support (versions of Windows prior to Windows Vista), there is a well know exploit approach for an attacker to find and manipulate code that exists within its modules (DLLs and EXEs) when the modules have been loaded at predictable locations in the address space of the process.
Address space layout randomization (ASLR) randomizes the memory locations used by programs, making it much harder for an attacker to correctly guess the location of a given process, including the base of the executable and the positions of the stack, heap and libraries.
DEP - Data Execution Prevention
The purpose of DEP is to prevent attackers from being able to execute data as if it were code.
This stops an attack that tries to execute code from the stack, heap, and other non-code memory areas.
DEP prevents malware from writing code into data pages then executing it.
Summary - Malware Countermeasure
The combined use of DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) have proven to be effective against the types of exploits that are in use today.
DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not sufficient to prevent arbitrary code execution in most cases.
DEP is also needed to make ASLR (Address Space Layout Randomization) more effective.
Adding these two malware countermeasures to your applications is especially useful for applications that handle:
Protected Health Information (PHI)
Security - PROGRAM-LEVEL
myZure supports program-level-security to the application. It allows customer to control who can use the program, and what aspects of the program they can use.
We call this Program Access Control. The key goals here are flexibility (every end user has different policies) and usability (customers need to be able to manage their own security and not rely on a developer to do it for them.)
In addition large customers have different needs to small customers (such as Active Directory integration) and so Secwin is designed to be flexible, allowing customers to tailor the security to their needs.
A range of features, including password resets, self-sign-on, guest accounts and more make Secwin the last security tool to protect your system and organizations data access.
It also allows you to control which features in our program the customer has access to. We call this Licensing. The primary goal of licensing is to ensure that we the ISV get paid. Licensing is flexible and easy for both us and our customer, and online so that you can easily update clients license as their needs (or lack of payment for subscriptions) change.
Designed for both single-sale software and subscription services. It includes a web server app that is used as a licensing server, to make use of SecwinOnlineServer to host licenses for customers.
Secwin is designed to work on desktop, and web applications, and supports single-tenant or multi-tenant setups.
In today's world no program, or user, stands alone. Secwin is designed to integrate to a SendEmail or SendSMS function (or both).
These allow features like:
Second factor authentication
Self-sign-up accounts and so on.
Secwin feature also allows for online licensing features and Active Directory integration.
If unauthorized uses have access to the database, and they can tamper with fields (for example deleting them, or causing them to become invalid) or delete records, then certain Secwin features may no longer be effective.
If an unauthorized person does get access to the database, data inside it will not be exposed. Any data they damage can be restored from backups, and the data itself will not be compromised.
The user logs in using a user name and password. However individual customers have individual requirements that can vary enormously from one customer to another. In addition the platform being used (desktop or web) may have special requirements that need to be supported.
To make logins as powerful, safe, and as feature-rich as possible - while at the same time making them easy enough to setup and use by mere humans has been a challenge.
All facets of the login system can be controlled at runtime so each customer can configure it to their own needs and policies.
These features include;
No logins at all - Users can choose to make the system login-less.
Passwords are stored as Salted-Hashed values, not as encrypted text, in accordance with all current best practices.
Second Factor Authentication using SMS or Email with Customer Defined Policies. When to require the second factor is a crucial element here, with options including every time, only on new devices, or on a time-based system.
Active Directory support for those customers with an Active Directory server. This allows for password, or password-less logins against an Active Directory server, and also an optional In-Group setting on the server. This gives Active Directory Administrators complete control over who can use the program.
Guest Logins (with pre-defined guest accounts) can be added. These have a user name, but no password, and usually have limited program access rights.
Customer-defined password policies allow each customer to determine the password requirements for their users. Interesting options here include the prevention of password-reuse, and also the nonacceptance of passwords that are commonly used by people. (So no 1234 or password weak passwords.)
Customer-defined Lockout policies allow the user to determine when a user account will be locked (and for how long it will be locked) if multiple incorrect passwords are entered.
Password Resets via SMS or Email
Users can create new accounts (ie self sign-up) and be given default access rights.
Multi-tenant support with either unique-user or company/user logins.
All sensitive information in the data tables are stored encrypted and cannot be altered (or deciphered) by unauthorized programs.
Unencrypted fields are tamper resistant - editing them in an external program will make the data unusable.
Tables make use a of 3-secret system meaning that data can be bound to a specific program, specific table, or specific customer.
All secure information in the tables can be extended without changes to the file structure. This means that (for example) new security policies (and new settings) can be introduced and no file conversion is required.
The tables are declared in your dictionary, and can be extended with additional fields if you desire. (This would then necessitate a normal table-conversion)
User data is stored encrypted, in conformance with various privacy laws.