Jacob Morgan - The Future of Work

How many are closer to this model now than they were in 2013? 

 Our Collabosphere keynote speaker Jacob Morgan + Chess Media Group take a look at the future of work.

Jacob's latest for Forbes: http://www.forbes.com/…/j…/2013/09/10/the-evolution-of-work/

Jet Computer Support: Some of Our Specialties

Jet Computer Support has been helping businesses, non-profits, and government entities for more than 20 years. We offer professional services in computer systems, electronic health records and technology. Some of our specialties include:

·         Systems implementation	·         Data entry
·         Data warehouse	·         General support
·         Programming	·         Help desk
·         Project management	·         Documentation
·         Business Continuity and Disaster Recovery planning	·         IT department and staff management/supervision
·         Electronic health record: purchase, implementation, and modification	·         Data import and export for contract requirements
·         Development of management reports	·         Training

Business Types:
	Woman Owned Business
	Woman Owned Small Business
	WBE Certification – #W2F0024449

DUNS:	029866048
CAGE:	7KR01
EIN:	91-1697228

Super Script - Conditional Changes to DST (data elements) Values using uScript for Netsmart MIS/EHR

Super Script – Netsmart MIS/EHR Conditional Changes to Data (DST) Values

The Super Script that we developed and use regularly for Netsmart (previously CMHC) MIS/EHR allows changes to the Netsmart MIS database(s) when one or multiple data elements must be changed based on specific criteria.

Script behavior:

Ø  The super script is used to update both record and stand-alone DSTs (data elements) using conditional logic.

Ø  The script can make changes either to a list of registers or to all registers in a database.

Ø  The script produces two files in the print queue:  One file contains the logic used to determine when a change to the database should be made and the other shows changes that were made and to which registers.

Ø  Both stand-alone DSTs as well as record DSTs can be updated.

Ø  DSTs values can be copied from one database to another (databases must be linked with a DST containing a register ID).

Ø  When updating DSTs the script can link from one database to another so that changes can be coordinated between databases. This functionality is sometimes used to make changes to claims, ISNs, and events simultaneously.

The script can make multiple updates from one set of conditions, or multiple updates from multiple sets of conditions.  In other words, the script can update multiple DSTs (data elements) from one set of conditions, or multiple sets of DSTs (data elements) from multiple sets of conditions.  For example:

Multiple DSTs from one set of conditions:

For all clients:

If C.STATE = "OR" and C.ZIP = "97217" then set C.COUNTY to a value of "1" (Multnomah)

Multiple DSTs being updated from multiple sets of conditions:

For all clients:

If C.STATE = "OR" and C.ZIP = "97217" then set C.COUNTY to a value of "1"  (Multnomah)

If C.STATE = "WA" and C.ZIP = "98001" then set C.COUNTY to a value of "17" (King)

Use the superscript to:

Ø  Update database record layers based on multiple DST values within a record.

Ø  Coordinate updates between claims, ISNs, and events with the same changes at the same time.

Ø  Update stand-alone DSTs based on the specific values of other DSTs.

Ø  Simultaneously make multiple changes to data based on multiple conditions sets.

Ø  Delete record layers based on the DST values within the record.

Limitations:

Ø  The current super script cannot add DST layers. It can only change existing data or remove data.

Ø  The script only accesses one record layer per update. You cannot use the data in one record to determine if another separate record is to be updated.

Possible additional script features:

Ø  A feature can be added to allow for undoing DST changes after they are made.

Ø  Recode tables can be integrated into the script as a means of specifying the changes to be made.

Ø  A modification could be made to the script to allow for the adding of data layers. 

How We Solved It:

Customer issue:

A multi-county government entity needed to convert their legacy mental health Management Information System (MIS) from a HIPAA clearinghouse model paying their contracted agencies a capitated rate or cost based (i.e. not requiring HIPAA standard transactions), to a fee-for-service model using a browser based MIS interface and requiring HIPAA standard transactions from their contracted agencies.

How we solved it:

This was a huge undertaking that required much coordination, project management, attention to detail, with industry knowledge and expertise. In addition to creating scripts to import/export HIPAA standard transactions[1] that involved programming for complicated rules for data allowed/not allowed, we also created fully customized screens in their browser-based MIS that enforced entry edits to ensure accurate data. We were able to successfully complete all aspects of this project on time and within budget.

---

[1] HIPAA 837P Outpatient Claims, 270 Eligibility Inquiry (submission), 271 Eligibility Inquiry (results), 834 Eligibility from Payer, 820 Payments

Avoid Phishing

Thank you to Intermedia for this helpful article on Phishing.  I read their blog entry and wanted to pass this article along.  I have copied their main points below:

1. Be aware of email requests with high urgency that ask you to take quick action.  Phishers often prey on employee trust and will spoof executives to get you to comply with high urgency actions like wiring large amounts of money ASAP. Or in my case, losing my matching benefits if I didn’t immediately comply.  As a rule of thumb, if you are ever in doubt, double-check the request with the sender either by phone or by composing a new email—never reply to the email itself.
2. Never give sensitive personal or financial information over email.  Trusted parties will never ask you for personal or financial information through email (e.g., social security numbers, account numbers, credit card numbers, passwords, etc.). Be cautious of emails that ask you to call a phone number to update your account information as well.
3. If an offer seems too good to be true, it probably is.  Offers ofbig bonuses, large payments or gifts (e.g., win a free iPad) are ways attackers try to get inside your head. If the promise is “too good to be true,” do some research into the individual or company before taking action.
4. Think about whether you initiated the action.  Phishers will try to spoof well-known companies to have you reset your password, update your account or track a shipment. Always be suspicious of unsolicited email, if you didn’t prompt a password reset — don’t click the link.

I have been grateful that many Phishing scams seem very obvious.  This article describes a tricky scenario that wasn't so apparent and reminds each of us to be cautious and always alert.

First Agency to Meet Greater Columbia BHO Data Requirements

We at Jet Computer Support are happy to report we have helped a Greater Columbia contracted agency to become the first to meet new data requirements for Greater Columbia BHO.  Great job team!

IRMS File Extraction Script in the Netsmart MIS/EHR

IRMS File Extraction Script in the Netsmart MIS/EHR

Script behavior:

1)      All documents in the IRMS are exported as separate files.

2)      Documents are exported out of the IRMS in the same format in which they were imported (i.e., PDF files are extracted as PDF files, image files as image files, and HTML (eCET) files as HTML files).

3)      The script names the documents/files based on key information in either the DB13 document database or the DBX file which contains notes, treatment plans, and MISDesigner forms. This file name is used by the document import program to associate the document with a database record. The script can be modified to create custom file names based on customer specifications.

NOTE:  Due to peculiarities in the DBX file some customization will be needed before the script can be run on a customer’s server.

4)      The script is built for a gradual transition, meaning it tracks for itself which documents have been exported so staff can continue adding MIS documents to the IRMS without worry that the new documents will interfere with the file export process.

5)      The length of time the script needs to run is dependent on the number of documents in the IRMS. When there is a large volume of documents/files, the script could take 24+ hours to extract them all.

Script Limitations:

1)      Signatures in the MIS are not part of the document(s) in the IRMS. Instead, they are added to documents dynamically in the document viewer which is why they are not able to be included in the exported version of the document.

2)      The script currently cannot change files formats (e.g., an image file cannot be exptracted as or changed to a PDF file).

NOTE:  It is possible to convert files from one format to another by using a UNIX-based file conversion program within the script. However, this process brings its own complications and is not recommended.

Possible additional script features:

1)      An index file linking file names with fields is available via this script and may be necessary for some document import systems in order to associate the document with the new system’s EHR database.

2)      Text containing the names of the client/staff that signed the document can be added to HTML (eCET) documents. This is not the same as the encrypted signatures, but is simply lines of text that can be inserted into the document that denotes who signed it when it is viewed in the new system.