In 2013 I moved down to Saint Petersburg, FL to turn around what I thought was a Food Manufacturing and Home Delivered Meal company. Now make no mistake, it was absolutely that. But 2 months after I started that turn around, a surprising question rose to the surface: Is this actually a healthcare company?

The short answer: yes.

Now you may be asking yourself, how can one not know the business they are actually in? It seems to be a more prevalent point of confusion in healthcare, but it is also true in other businesses as well. Remember the famous line from McDonald's founder Ray Kroc, "Ladies and gentlemen, I'm not in the hamburger business. My business is real estate."

Recently I was talking with an accomplished executive in the home care industry. For those uninitiated, historically there is a nuanced difference between "home care" and the "home health." Home health provides professional medical assistance, usually in the form of skilled nursing. Whereas home care usually provides non-medical services (i.e. cleaning, bathing, cooking, etc...).

A further distinction, if I could quote an "A Place for Mom" article, is "that home health is generally covered by Medicare or private insurance while home care isn't."

Therein lies the problem. This is becoming less and less true by the second. Many home care services are being provided for, particularly by Medicare, but also Medicaid and Group/Commercial Insurance. Maybe you have seen the ominous toned Joe Nameth commercials.

Nevertheless, home care is healthcare. And because of that, there are troves of dollars awaiting the right forward thinking home care businesses. But it comes with a catch: those companies are going to need to function like healthcare providers. They can keep fighting it and miss out on opportunities, or they can embrace it, ahead of their peers, and thrive.

Jumping back to the conversation with the home care executive. He said, "[y]ou still have a number of home care agencies that argue because they are 'non-medical' that HIPAA does not apply to them. That argument is falling flat. In fact, last month I responded to an RFP that asked about HITRUST certification. I give it 3 years and it will be an expectation."

Let's assume his three year timeline is correct. Take it from someone who was three years ahead of the curve in our jaunt into home delivered meals being a filed benefit with Medicare, you want to solve this ahead of time or else you will find yourself incredibly flat footed.

In 2016 we entered into a Medicare Advantage program in South Florida. It was not a filed benefit at the time (an article for another day), but we wouldn't have won that contract if we told them we could become a healthcare provider. We won that contract because we were a healthcare provider. The next year they filled meals as a benefit. And the following year other payors followed suit. And that is when the revenue started pouring in.

All of this was enabled because we did the hard work of preparing ourselves to be a true healthcare business in 2014. If we missed that then, the revenue wouldn't have come in 2017.

If you are on the outskirts of healthcare, and you find yourself asking the same question, "am I really a healthcare company?" We would love to talk to you.

In the early 90s, the Gartner Group first coined the term ERP as the next evolution of software for manufacturing companies. Before this, a manufacturing company might have a separate accounting, purchasing, inventory, bill of material, and production system. What ERP did then, and continues to do now, is combine all these systems into one in order to achieve data entry efficiency and accuracy.

This was a necessity for manufacturing. They have very challenging margins. They need every ounce of efficiency to survive as a business. And for the past 30 years, they have been streamlining their operations with ERP systems. One could argue this past March this was on full display when the global supply chain had havoc wrecked upon it because manufacturing processes (and inventories) were so lean they could not handle the disruption of the Coronavirus (e.g. toilet paper). Manufacturing has become pros at just in time production because they have to.

Healthcare does not suffer the same perils that manufacturing does. They have very decent margins and a seemingly endless checkbook from the federal government. Therefore the answer to just about every healthcare operation problem: throw bodies at the problem.

But not only is this a wasteful approach to the problem, leaving billions in unrealized profits to the business and savings to the consumer, it is a fleeting approach to the problem. Make no mistake, the day of reckoning is coming for healthcare companies where like every other industry in the history of the world, margins will be compressed.

But even before then, the quality of life and missed opportunities most healthcare companies experience due to a non-integrative data set is a problem. They have separate scheduling, records, billing, fleet management, and accounting systems. In a lot of ways, they are stuck in the 80s. The consumer and taxpayer pay for that lack of efficiency. It's why medical billing is so dysfunctional. It is why health insurance data sets are so inaccurate. And all that comes to a head with the healthcare provider. To which that provider, in addition to having to provide all that, also has a hard time really understanding in real time the profitability (or lack thereof) of their business.

So what is a Healthcare ERP? It sets out to fix this. It does this by either 1) combining all business functions into one integrated, HIPAA compliant healthcare system, or 2) it fills in the gap where an accounting system leaves off by integrating through APIs or database connections. In the later example, you may have two separate systems, but they speak to each other in a way that is fast and accurate. Thus requiring no double entry of data. When the ERP system gets done with the scheduling, service and claims, it then passes the data off to accounting seamlessly.

Seamless. Does that sound like your healthcare operation? Probably not. And because of that you have too many people, too many headaches, too many missed opportunities, and too little understanding of your business.

Vy Healthcare ERP solves that problem. Reach out, we'd love to discuss.

When serving payors (insurance companies) there appears to be two types of customers in their eyes. Those where filing claims is all the information they need, and those where they expect troves of data from their vendor.

From my experience, when it comes to data, payors do not seem to require doctor's offices, hospitals, and pharmacies to do anything more than file claims. Of course, they make them jump through all kinds of other hoops to get authorizations, but their data expectations are fairly minimal.

However, for all other vendors that are not in those categories, and particularly for national providers, and especially particularly in Medicare Advantage, this is not the case.

When I began working with a Medicare Advantage payor for the first time I got some advice from a 25-year veteran of payors. She said, "they will report you to death if you let them." Boy was she right.

What she meant by that is that if you fall into their category of vendors where they expect you to provide them data beyond claims, the requests will never stop coming. Part of this advice served as justification in standing our ground when saying no. But part of this advice was to be ready for them to say, too bad. Like all things in healthcare. Everything is a negotiation. And that includes reports and data.

Just because you'll lose some of those battles does not mean you need to hire 10 analysts and devolve into a full time data shop.

There are two parts to fulfilling these data needs. 1) Actually generating the data, and 2) delivering the data. Simple enough? Not quite.

The first takes the most time no matter what you do. You have to be able to provide data to them on the services you provide, and this is important, that ties to the claims/invoices you submit to them. This can be a lot more complicated than it sounds. Likely your accounting system is not the same as your PHI system. Most accounting systems cannot handle PHI security that is required by HIPAA. So you usually have a separate system. And usually, when left to their own devices, these systems do not talk well to each other and rarely tie naturally. This is a recipe for disaster. We'll talk about that specifically on a later date.

But when it comes to the second phase, this is where you can make up some time in two ways: portals and automated tasks. Vy Healthcare ERP handles both of these seamlessly.

Payors love portals. They can go in and get all their data however they want. Some Payors will have one person responsible for the entire national operation. Other Payors will have a handful of people across different business units. Still others have hundreds or thousands of caseworkers that need access to the data. A Portal solves all those different scenarios in one unified methodology.

The other option of course is automating the delivery of this data. This really helps cut down on the number of people. Most payors want monthly data at the exact same time each month. Some want it emailed. Some want it sFTP-ed. It doesn't matter. All can be simply scheduled.

With Vy Healthcare ERP, adding a portal and automation does not necessarily require a reinvention of all your systems and data. If your systems are meeting most of your needs, keep it. You can use Vy Healthcare ERP to sit on top of those systems and deliver the data you need. Of course, if you are struggling to get your accounting system and PHI system to tie, Vy Technology ERP can help with that issue as well.

Does your ERP or EHR solution allow for portal access to your customers? If it doesn't, you are over-staffed and missing out on efficiencies. We'd love to chat with you on how you can decrease your staff needs and increase your quality of service (and quality of life).

From time to time I like to highlight some of the more unique things we do with our ERP. The cool thing about our system is that it has a great foundation for just about any business, but it also remains highly flexible to add features rapidly.

Previously we discussed a WhatsApp implementation that enables communication between the ERP system and WhatsApp users - including automated bot response and data capture.

Today though we venture off of healthcare a bit to show a cool feature built for one of our non-Healthcare partners. M Cultivo aims to cultivate next-generation farmers that are mostly in the coffee industry. They are doing some really cool stuff and fixing a very big problem in the world. They have taken the Vy ERP framework foundation to deploy an inventory system, messaging platform, pricing index, and CRM.

When receiving coffee from farmers into the inventory system, M Cultivo sends a receipt via text message, WhatsApp, and/or email. But one of their customers had a more traditional request: a physical printed receipt. Makes sense. But the bigger issue? Their customer's harvest season was already under way and they needed this feature. Quickly. Like, yesterday quickly.

Thanks to Amazon Prime, we received next business day an Epson TM-T20ii printer. A very short time after that we proved the concept. Within a week or so, the customer in Costa Rica had received their printer. And voila. Receipts printed at a Coffee Mill in Costa Rica.

This is just one example of how Vy Technology and our ERP system can create some really cool solutions... fast. Got a unique problem you are trying to solve? Reach out, we'd love to brainstorm with you. It probably can be done quicker and more cost effectively than you think.

"The dirty little secret of cloud spend is that the bill never really goes down," says J.R. Storment, executive director of the FinOps Foundation.

This quote was found in a recent ZDNet article espousing the newly created IT career of FinOps. The reason for this newly created career? Because, expanding on Storment's quote a bit, if the costs never really go down, then it gets expensive real fast.

As you know, I am a fan of either cloud and on-premise setups. This can sometimes be referred to as a "hybrid." However, that is usually the reference given when someone runs in the cloud and on-premise, not necessarily the cloud or on-premise. To choose between the cloud or on-premise, one must take into account all one's realities.

One of those major realities is cost. So let's take a look at that with a bit more detail with a real simplified example. Say you need a fairly powerful web server and database (LAMP Stack) for your internal, web-based ERP operation.

• Dell R70 with 2.3 Ghz 16 core / 32 virtual with 64 GB of RAM and 2.0 TB of RAID 10 Data: $5,900
• 20 GB up/down Enterprise Fiber Internet with SIP Phones: $5,000 per month
• Watchguard Firewall: $5,500
• Cisco 48-Port Switch: $600

While of course depreciation schedules will have you divide this by four, the true cost of ownership should be divided by seven. The on-premise solution comes to $1,714.28 per year in capital, and $60,000 per year in bandwidth. So you might say that the total on-premise operation for this server is $61,714.28. Of course, add a Network/Server admin into the equation for an all-in payroll cost of $90,000 and that brings your on-premise total to $151,714.28 per year. Pretty pricey right?

But here's the thing. You likely have a Network/Server admin on staff anyways. You likely are using that person for tier 2/3 IT support and projects. Truthfully, if that is all you are using them for, you aren't getting your money's worth.

The other pricey element: your enterprise fiber line. The issue is that you likely have chosen your internet for download speeds and SLA factors. To host a server, your primary concern is upload. And while residential service has an imbalance in download/upload speed that favors download, enterprise is usually equal. Thus your upload is there, you just aren't using it. It is in a sense: free. Also, assuming the majority of your employees are in one location, the internet is irrelevant to an on-premise solution because all the traffic would be on your internal network.

Both of these bring us to an important point: if you can't remove the position or the service by moving to the cloud, then don't charge it to on-premise.

So after that, we are down to a $1,714.28 annual charge for on-premise. How does that stack up against the cloud solution?

• Reserved c5a.8xlarge EC2 Instance: $7,319
• 2.0 TB of EBS: $2,400
• I am not going to calculate AWS bandwidth charge, it likely isn't significant enough to matter, but if you know your actual annual total bandwidth you can add $1.08 per GB

This brings your annual cloud charges to $9,719 on the low end.

But say you have 10 servers you need. Yes, you probably don't need them all to be c5a.8xlarges, and maybe you rightsize the EC2s a bit. But even if you cut your EC2 charge in half, the difference is still $4,000 per server. Times 10. That's $40,000 more per year with the cloud than on-premise.

So there you have it. Now you know why Jeff Bezos is making so much money. On-premise has to be the way to go, right? Not exactly.

The other major factor one must consider is availability. While an AWS outage is not unheard of, I would never argue that if your largest primary concern is uptime outside of your local network, then no on-premise will hold a candle to AWS uptime. It just won't. And if you have a highly decentralized workforce, that's all the more reason to focus on availability.

So the general conclusion is that if availability is the most important thing, go with the cloud. Otherwise, on-premise is likely the way to go assuming you have strong enough technology management to manage it.

As an example, in another life, I ran an on-premise web solution with an IT staff of 3 and had no downtime in 6 years of operation for a very important web-based ERP system except a 36 hour period where a telephone pole caught on fire and took down our Verizon Fiber line. That was it. Now, to some, even one 36-hour period of downtime in 6 years would be a problem. For our operation, it wasn't. It was acceptable. That was still a 99.93% uptime. Also, most of our employees were located on the main campus and still had access to the system on our local network. In one way, we would have been more reliant on our fiber line with the cloud than on-premise. And those types of outages will never show up in a cloud SLA.

Cost and availability aren't the only two factors one needs to consider, but they are certainly the two most important. If you answer those honestly, you are probably 90% to your answer.

Whether you land in the cloud or on-premise, Vy Healthcare ERP is here to help. It can be installed on your on-premise solution, on your cloud solution, or hosted in our cloud solution. We are here to help you focus on what you need to focus on the most: running your business.

Many years ago (before Apple's second surge) I would sit around and listen to technology minded individuals have very passionate arguments about which was better: Microsoft, Mac, or Linux. I was always perplexed by this conversation and found myself uniquely agnostic to the whole conversation. When I would reluctantly get dragged into them I would say, "you know, I think they all have their strengths and weaknesses and I like using each of them where they best excel." The only thing they would all agree on: they all hated my answer.

Fast forward to this decade and I find myself again in a unique position. This time it is the new-age old battle: should healthcare software that has PHI and needs to be HIPAA compliant be in the cloud or on-premise?

One thing is for sure, healthcare and banking are the two industries that are most behind in the cloud revolution. This isn't by happenstance. It is because they are the two most regulated industries. And regulation brings confusion. And confusion brings status quo.

The result? You can talk to many within healthcare that will passionately defend that the cloud is not acceptable for healthcare. Some will go so far (wrongly) to say that not only is it not acceptable, it isn't legal.

To the latter point, that is just flat out wrong. HHS actually released a fairly clear and comprehensive (for once?) guidance detailing how cloud computing can be done under the terms of HIPAA. This should be mandatory reading for anyone entering this conversation.

So you then probably think I am a fan of cloud hosting over on-premise? Not quite.

In fact, most of our implementations of Vy Healthcare ERP are on-premise. One thing we pride ourselves on is that the platform can be run in the cloud or on-premise. I am sure there are others out there like us, but I know of no others that enable this versatility. When we run it on the cloud, we use AWS GovCloud. When we run it on-premise, we work with great internal IT teams to ensure security and uptime.

That is one of the beauties of using web languages as software development: it can be used cost effectively anywhere you can spin up a web server. And a web server doesn't care if it is cloud hosted or on-premise. It functions through a web browser regardless.

What I think is more important is to take you, the customer, into consideration before deciding between the cloud or on-premise. What are your needs? What is your internal server and network infrastructure like? How complex are your internal integration points? What are your uptime needs? How competent is your internal IT team? These are all important questions.

But what is not an important question: does HHS force on-premise to be HIPAA compliant. That answer is flat out no.

One last tip if you are going the cloud route. While not required per se, it certainly makes things easier to use AWS GovCloud. Can you be HIPAA compliant without using AWS GovCloud: yes. Is it harder to do so: yes. Why? For starters, it may violate your IT Policy. But even if it doesn't, it is likely that sooner or later you will get into DFAR-like questions from customers. These are the questions that are concerned with offshoring and who has access to your code, data, and network. And while you can certainly still be HIPAA compliant while offshoring data and code, it also will certainly increase your risk assessment workload and security scanning. For what little AWS GovCloud costs over regular AWS, it just isn't worth the headache.

The important thing is to ensure your system is secure. We'd love to talk to you about how Vy Healthcare ERP can do just that for your organization.

As we come to our 7th and final article in the HITRUST Certification series, we come to the last question: Is HITRUST Certification really necessary?

Truthfully.

No.

"What?!? You just spent 6 other articles espousing what it takes to go through HITRUST Certification and now you tell me it was all a waste of time?" Not exactly, but more on that in a second.

If you do some light research on the topic, you will find there are quite a few objections to the Certification. The most thoughtful in my opinion is Kamal Govindaswamy's in his three separate write-ups.

He does a better job detailing all this than I ever could. They are worth the read. But the TL/DR version of his articles is that HITRUST Certification is:

• antiquated
• too complex to be beneficial
• extremely costly and those funds should be used for actual security
• isn't really an industry standard beyond the 5 companies that created the Alliance.

And you know what? He is absolutely, 100% correct.

I would never advise anyone to start with HITRUST Certification. Truthfully, I would never advise anyone to start with any certification. The starting point should always be get the right Technology Executive, get the right team and structure, and get the right systems in place that are incredibly secure and enable growth. Only years later should certification enter the conversation.

So why spend this much time on this topic?

The first time I went through the HITRUST Certification process, our assessor asked us right off the bat: "Why are you doing this?"

My honest response: "Because one customer is making us, another is implying they will make us, and those two contracts alone are worth [insert 8-figure number]."

His last response: "You are jumping to the hardest and most complex one. Jumping from no certifications (i.e. ISO 27001 or NIST) to HITRUST will be difficult."

Now especially after reading Kamal's article, don't mistake "hardest and most complex" with best. But here's the truth: when you work in healthcare, there are a lot of things that are forced on you that you may not agree with or may not even think are beneficial. Honestly, your opinion doesn't really matter.

This is not a position I am usually comfortable with. This is certainly not a position I advocate. But it is a position I recognize as a reality. That reality usually drives one of two common mistakes from the Technology Executive.

They ignore it. Usually at the peril of future contracts or less lucrative ones. This is what I call the "Defensive IT Executive" response. If one takes this they should be prepared to either work for a non-growing company or be looking for another job. Both situations are unacceptable.

Or, they go all in. And I mean all in. This is what I call the "Industry Reputation Executive" response. This individual is usually more worried about their industry reputation than the health and effectiveness of the organization. This is the person who thinks HITRUST Certification should be the largest priority of the entire organization and everything is viewed through that lens. This is dangerous because your costs will skyrocket and your innovation will grind to a halt.

The way to avoid this mistake. Strategically use demands like HITRUST Certification when contractually appropriate to further growth, but at the same time do so in the most cost effective and least organization altering way possible.

As we have said throughout this series, if you find yourself having to go through HITRUST Certification, or something like it, it certainly helps to be on a platform that has gone through it before. We'd love to chat about this, give you an unbiased and fair interpretation of your situation, offer some advice, and discuss how Vy Healthcare ERP can help you no matter what your healthcare needs are.

You have achieved HITRUST Certification. Great! But now the real hard part comes: adhering to your new policy. Do not underestimate the importance of this.

HITRUST Certification follows a validated assessment every two years with an interim assessment in between. While much of your initial certification may have been improving policy and fixing gaps, the recertification process will be validating that you are continuing to do what you said you would do all along.

A lot of your new IT Policy will have tasks that require a certain frequency of completion. Daily, weekly, monthly, quarterly, and annually. For example, you may have a daily infrastructure checklist for a Network/Server Admin. You may also require Penetration Testing annually. Or you may need to Patch Servers monthly. You will probably have 25 to 35 tasks that will need to be completed regularly. Much more, it will need to be documented that you completed them per your policy.

One of our Apps within Healthcare ERP is what is called "Scheduled Task." While not exclusively for HITRUST Certification, it certainly helps as it does just about everything you need to make sure all tasks are getting completed on time and documented.

All tasks are assigned a title, control number, a responsibility, an escalation hierarchy, frequency, and start date. The automation then takes it from there based on start date and frequency. It takes the standing task and creates a specific assigned task with a due date and emails it to the assigned party. This specific task has a place for notes and a place for uploaded documentation. If tasks are not completed by the assigned party by the due date, the first chain of escalation is alerted via email. If after 15 days it still isn't done, the second layer of escalation is notified. And if still not complete a month after the due date, the third layer of escalation is notified.

Whether you use our Schedule Task app or not, you need a game plan on how you plan on adhering to your policy. I promise if this isn't given serious thought you will find yourself during your next assessment with either a lot of gaps which risk losing certification or a lot of work to prove you have adhered to your policy. Neither is a good scenario to be in.

We would love to talk to you about how you can maintain your HITRUST Certification, save time, and possibly prevent the need for a whole IT position.

If the first question when first considering HITRUST Certification is how much will this cost, the second question is how long will it take? It's a valid question. Any project you take on should always be prepared to quickly and concisely answer how much and how long?

The important thing to remember when it comes to timeline is this: decide you are going to do it and do it. I was discussing with a fairly accomplished healthcare CIO the other day and he said in two separate operations, "we started the certification but couldn't get it finished." This kind of surprised me, but it is a good reminder whether it is HITRUST or other projects, accomplishing complicated projects requires commitment and focus. If you don't have that in this project (or any project), you might as well not start.

Similar to how much, how long will depend on where your organization finds itself. Everyone's experience will vary, but this article aims to give you an idea of a good baseline. Start to finish, the first time I did HITRUST it took 18 months. There were three parts:

1. Research
2. Execution
3. Waiting

Research

The first 6 months are just research and fact finding. You could greatly expedite that process by reading this blog series. This stage also was a bit longer due budget year expense timing. Honestly, this phase could take as little as 1 month. The important thing that must happen in this phase is finding the right HITRUST External Assessor. To be clear, that is not us. We are not a certified assessor. Like security testing, we don't desire to become one. It isn't what we do. We build highly secure systems. We don't certify them. Technically you could do this yourself. But also, like security testing, you shouldn't. It will go smoother, and probably be cheaper, to go the route of an external assessor. Use the link above, find a few, interview them, decide on a scope and timeline with them, and pick one.

Execution

This is the section where the most amount of work and time is spent. Think of this as 7 months. Less if you have a robust IT Policy. More if you don't have any controls in place. Assuming you are committed and focused. This is the stage where the men and women are separated from the boys and girls.

As we stated before, we had no real formal IT Policy but we were set up pretty well by our guiding Pillars of HIPAA. Your mileage may vary. The execution phase will include a few sub-steps

1. Submission of Information Request List to External Assessor (all the details of your operation)
2. Field Work by External Assessor (think of it like an preliminary Audit)
3. Answer MyCSF Questionnaire (similar to a Risk Assessment)
4. Fill in the Gaps from MyCSF Results
5. External Assessor performs Field Work (like a final audit)
6. Submit Final Report to HITRUST

By far the most amount of time is spent in task #4. All other tasks are usually just about a week's worth of work give or take. But #4 takes a lot of time. This is where your "starting" point matters. You have to get any identified gaps corrected. If you have no controls in place and a lot of gaps, it will take a lot of time. If you have a fairly robust IT Policy and good controls in place, this will be a lot easier.

If you do not have a robust IT Policy, it is step #4 where you will develop your new IT Policy. If you have questions about that, be sure to check out our article on writing a good IT Policy.

Waiting

You may be told that you will receive a response by HITRUST within 6 weeks. At this point you become HITRUST Certified. The problem? This stage in actuality takes many months. The first time I went through this it took 5 months and that was only after applying some pressure on getting a response.

There you have it. Your mileage may vary, but that is a good estimate. If you are committed and HITRUST isn't backed up you could probably do it in 6 to 9 months. Likely it will take more like a year to 18 months. But again, only if one is committed.

As we have said before, if the time comes to go through HITRUST it helps to go through it with a platform that has gone through it before. We'd love to talk to you about that and other Healthcare software needs.

I have mentioned before (and will continue to) that HITRUST Certification didn't secure the system itself; rather, it codified and proved out the existing security apparatus. However, one could argue that it made the system more secure through the security testing needed throughout the certification.

When it comes to security testing, a lot of technical terms may be flying around that may be unfamiliar, they were for me too, and it's easy to become confused. You may even start to feel like Woody in the famous Woody & Buzz 'Everywhere' Meme with a mixture of confusion, exasperation, and fear.

In this post we will demystify those terms and outline different security testing methodologies and how it could be applicable to your business.

But first, let's talk about the negative in security testing. Cost. There's no way around it, it's going to cost you time and money to do effective testing. You could save some money by testing internally, but if you are reading this post and learning something from it, you should hire a specialist. Even if you came to Vy and said "we'd like you to do this testing for us," we'd decline. Testing isn't our speciality and it's probably not yours. It will be more cost-effective (time, money, risk, etc) in the long run to hire a professional with experience.

Back to the topic at hand.

Below are the four types of security "testing" that were required for HITRUST Certification:

• Penetration Testing
• DAST (Dynamic Application Security Testing)
• SAST (Static Application Security Testing
• Risk Assessment

Let's demystify them...

Penetration Testing

The first type of testing you likely will come across, and in my opinion, the most valuable, is Penetration Testing. Penetration Testing will likely be required annually. Penetration Testing is when a live human, hopefully one who is experienced, will actively try and hack your software. They will do this by using the same tools and practices that real hackers use. This can be completed in two ways:

• Black Box - when the tester does not know the inner workings of your system or have special access.
• White Box - when you give special access/knowledge to the tester that someone outside your organization wouldn't have.

If you are only going to do one form of testing, then you should do White Box Penetration Testing. However, if you do DAST as well, then I am usually a fan of Black Box Penetration Testing. This is because it gives you a real clear idea of real world threats without confusing the hypothetical.

DAST

DAST stands for Dynamic Application Security Testing. This is similar to Penetration Testing with two key differences:

1. It's automated and handled at a higher frequency (say quarterly),
2. It gives access to your system and vulnerabilities found here are usually true vulnerabilities.

However, DAST does not actually test the code, only the application layer. These are not code scans.

SAST

SAST stands for Static Application Security Testing. This is a code scan. Full disclosure, I'm not a big fan of SAST for small operations. I have yet to find a good SAST application unless you are using a well known framework (which I'm against for other reasons), and/or using built-in functions only. I've run into a lot of problems surfacing helpful vulnerabilities because the system wasn't using a framework like Cake or CodeIgniter, it was built with a custom data cleanser, and its security was integrated via the operating system setup. Now you can't ignore SAST if you want your system to be open sourced or don't have control over what system your code resides. But the vast majority of you reading probably aren't concerned with that. Unfortunately, the end result of SAST can be a lot of false positives to wade through. Because of this, I would highly recommend using the same company for SAST that you use for DAST and Penetration Testing. This way they can easily validate which findings are false positives and which need attention.

Risk Assessments

Risk Assessments aren't traditionally technology related, but rather they come more often out of the insurance industry. That being said, they seem to be a favorite tool amongst everyone in InfoSec. Risk Assessments usually take the form of 100-300 question Excel document. Because you could answer these questions any way you want, think of it more of a test of your IT Policy (and its implementation) than of any actual security test. Note, I am not saying you should lie on these assessments. If you have a security issue and use the Risk Assessment as a defense, but you lied on them, that will be extremely bad. But that being said, no actual, meaningful testing usually accompanies this, and it's only as helpful as the effort you put into it.

All four forms of testing will output reports that will rank vulnerabilities that usually follow the CVSS Scoring method (Critical, High, Medium and Low). Unless proven a false positive, Critical and High should be addressed immediately and if possible, you should run the testing again after fixing the vulnerability, for your documentation.

There you have it. Hopefully that brings a bit of clarity. If you're going through HITRUST certification, it helps going through it with a proven system that's been there before. If that's the case, we'd love to talk more with you.

"So how was the HITRUST Conference?" I asked the Network/Server Admin I tasked with the initial HITRUST requirement fact finding.

"They expressed a lot of doubt that we were going to be able to do this with an IT staff of 3," he replied.

"Doesn't surprise me, but we are going to do it." And you know what? We did it. In 7 months!

While the context of this article may be within the completion of HITRUST Certification, the question is really a much larger question. It's a question I get a lot. How big does my IT department need to be?

Every company will of course be different, but the answer for a small, medium sized enterprise should likely be smaller than it currently is. But it takes three things to accomplish this.

1. The right Technology Executive that cares about the P&L
2. The right hires and structure of the team
3. The right system

Let's take a look at each of these.

Technology Executive

A lot of Technology Executives are not true Executives. They were great technology people who got promoted along the way, but they do not have a P&L mindset, nor do they really care about using technology in a way that actually does what technology should do: reduce headcount while not sacrificing growth. They often care more about their respect and standing within the broader IT Community than the high performance of your P&L. Throw in a singular focus area within IT (i.e. Infrastructure, but no experience on Security or Development) and you have a recipe for an inefficient and costly IT Department.

Right team. Right structure.

After that, keeping an IT Department small and efficient requires the right team members. Most companies could get away with a Network/Server Admin with Security experience, a Full Stack Developer, and Help Desk Technician. As your company's needs grow, you can easily expand out from here. In Healthcare that might mean splitting the Network/Server Admin duties by creating an InfoSec position. After that, split the Full Stack developer duties by creating a Database Administrator. Or probably vice versa outside of Healthcare. Add HelpDesk Technicians as support tickets grow (but only after benchmarking the number of reasonable tickets completed in a day). Too often though expanding the positions is done way too early and for the wrong reasons (i.e. compensating for underperforming team members, structure or leadership).

Right System

This one is the easiest to overlook. Your system setup dramatically impacts your ability to stay small, efficient, secure and nimble. Are your systems fully integrated or are they all decentralized? Think about it just at one layer: for every system you have, there are separate usernames and passwords. For every set of usernames and passwords, there are that many password reset requests to help desk. If you expand out from there, you realize there are more databases to maintain and backup. There are more security scans to be done. There are more security holes to patch and or be concerned about. There is a higher likelihood of outsourcing, which presents its own costs, inefficiencies, and insecurity. In short, the system(s) you implement will make or break the performance of your IT Department and your company as a whole.

Vy Technology is a big proponent of integrated, simplified systems. There is an immense amount of value in having one or two total systems. Anything else should (and can) be integrated with an API.

Only when all three align can you have an efficient, nimble, and high quality technology operation that is not only secure, but cost effective. If you have a feeling yours may not be, reach out to us. We'd love to discuss how you can save money and improve security.

If you are looking to embark on HITRUST Certification, you'll be spending a lot of time on your IT Policy. This is arguably the most important part of the HITRUST Certification (whether it should be the most important part is a topic for another day).

This might be a boring post, I find it tedious too, but if you're serious about HITRUST Certification, this will save you a ton of fits and starts and complete the objective at hand: certification.

Disclaimer: I am not a fan of policies in general. This stems from a college course when the professor brought in an attorney who said two things that changed the way I looked at policies.

1. Policies are defined to assign blame not to set forth documenting SOPs.
2. On that note, be careful what you put into a policy because if you're not adherent to it in totality, it can be used against you when defending yourself. Truthfully, it would almost be better to not have, than be caught not adhering to your policy

For those reasons, I delayed a full fledged IT Policy.

If you go for your HITRUST Certification, no amount of kicking and screaming will prevent policy documentation. Get on board, or don't do the certification. And if you're going to create a policy document, you better do it well and adhere to it or it will create more harm than good.

For us this meant moving from a 1 page, 13-bullet point document (that did a phenomenal job of protecting our data), to a 105-page document that created a slightly better job of protecting our data.

Those 105 pages were not easy to craft either. Recently, I had a conversation with an accomplished CIO in healthcare, and he was curious where we got our IT Policy document. My response, "I composed it. From scratch." This impressed him as he had tried to do HITRUST Certification twice in the past and never got it accomplished, even with the assistance of a purchased IT Policy template.

Make no mistake, it's not easy writing a HITRUST Compliant IT Policy.

That being said, let's talk about the structure which will considerably help in crafting this document.

Typically, your HITRUST Certification is based on a framework. For us, it was NIST. This framework will define the Domains your controls will derive from. Then with your MyCSF tool (part of what you pay for), it will determine the HITRUST Controls that are required for your certification. All of these controls are then put into a versioned module that lists all requirements. These requirement master list references are prefixed with HIT and sequentially numbered to the totality of your certification. We referred to these as HITs. And for us, there were 281 of them.

From there, these HIT references are required to have 1) a documented Policy statement and 2) a Process defined. Your assessor must agree these exist AND must agree the process fulfilled the policy.

Here is my best advice for structuring your IT Policy:

1. Start with the high level Domains. These should be the "sections" of your IT Policy. Have them match exactly as they are in the HITRUST Module. Start with "01 Information Protection Program" then go on to "02 Endpoint Protection" etc...
2. From there organize each sub-section by the HITRUST CSF Control. These sub-sections are named like "00.a Information Management Program" and "02.a Roles and Responsibilities"
3. From there have two main bodies within the sub-section: Policy & Process
   
   
   • Policy: here is where you write the policy statements. After each policy statement (which could be multiple statements) put the HIT number in parenthesis after it. This will help you and your assessor make sure all your HITs are covered.
   • Process: for each process you then spell out exactly how you will achieve the necessary policy statement. You should have as many processes as that take. Each process should have a Responsible Party where it defines who will do this process. Use definitions (i.e. titles), not names. It should also have Applicable Tools and Description of Implementation.

Make sure you have a table of contents for all this, and be sure to use definitions. Both of these will save you a lot of time using and updating the document in the future.

If you want to see a sample of this, shoot us an email or fill our the contact form.

Now with that out of the way, the really hard part: adhering to it.

It goes a long way in getting HITRUST Certified by ensuring your system has gone through it before. If you'd like help with this process, don't hesitate to reach out to us.

Picking up on the theme from a few days ago, let's tell another story about a time I went head to head with an MCO and lost: HITRUST Certification.

You might be beginning to think all I did was lose these arguments. I won more than I lost, but like a lot of things in life, the losses are where real interesting things were learned.

In 2018 an MCO we were working with required us to get HITRUST Certification. At that point in time we weren't under any certification (SOC-2, ISO, etc...). I didn't really know where to start. Future articles will be written to provide other lessons learned from this process, but let's start with the first question I asked but could find very little answers on: how much will HITRUST Certification cost?

You'd think that answer would be readily available and easy to answer. Neither is true. Initial costs are tough to answer because it depends on where you are starting from. Ongoing costs will fluctuate every other year depending on whether you are doing a validated assessment or interim assessment.

One disclaimer. This is just from my experience. Size of company, complexity, and overall IT technical competency may vary. Also it should be noted that this is with no offshore outsourcing and very little (almost none) domestic outsourcing with all network, hardware, and software on premise and not in the cloud.

So let's break this down.

If you are starting from scratch with no other certifications, then I'd say you should budget around $150,000 for initial launch. This cost breaks down like this:

• Actual Certification Costs: $50,000
• Increased Testing, Risk Assessments & Controls: $90,000
• Hardware Updating: $10,000

Now if you are already doing Penetration Testing, DAST Testing, and Outside Third Party Risk Assessments, then you can knock off $50,000. Likewise, if you have relatively new firewalls (capable of NIDS), then you probably don't have to spend the $10,000 on upgrading your hardware.

So that's the initial cost, what about the ongoing? Well that depends which year it is. HITRUST does a full recertification every 2 years. In the interim years they do - you guessed it - an interim assessment. Other than that, your ongoing costs are the same. You should expect to pay between $80,000 (interim) and $120,000 (full) per year just to stay HITRUST Certified. This again covers reoccurring requirements like Third Party Risk Assessments, Penetration Testing, and DAST testing. So if that is already in your budget, subtract that out.

This of course doesn't include salaries of IT employees. We didn't need to add any employees to our operation to achieve certification, so I am not including them here in the cost. That being said, we only had three members on our IT team, which we were told from the start was going to be a real hindrance to get certified (more on that in a future post).

So there you have it. Budget about $150,000 for initial certification, and about $100,000 every year thereafter.

One last point. No one in this process is looking to achieve certification in the most cost effective way. The state of healthcare and healthcare technology is to just throw more and more money at any problem. That has always rubbed me the wrong way. This can be made all the worse if your own internal team does not have a "P&L mindset" when it comes to something like this.

If you have any questions about achieving HITRUST Certification spending the least amount of money in the shortest amount of time, we'd love to hear from you.

Most of us would probably agree that the roll out of the COVID19 vaccine has been anything but stellar. The large task of developing a vaccine in a lot of ways went smoother and more efficient than the logistical handling of actually distributing the vaccine. However, what caught my attention in a CNBC article about why Walgreens and CVS were selected as the primary distribution channel for Assisted Living Facilities was the role IT played in the decision.

"[Walgreens and CVS] have been doing this for a while," Paul Mango, deputy chief of staff for policy at HHS said. "They have demonstrated the ability from an IT perspective, from a training and personnel perspective, from an asset perspective."

Now let's not read too much into the statement, but that being said, not only was "IT perspective" in the list, but it was listed first. Why? Because technology is what makes or breaks a smooth operation in healthcare.

Of course, this isn't a surprise to anybody who works in healthcare. I have had the opportunity to work with over 50 different MCOs directly and when you work with that many insurance companies you definitely get a sense of the vast chasm between the well ran healthcare technology operations and the poorly ran healthcare technology operations.

Ultimately though this isn't about CVS, Walgreens, or any insurance company. This is about you and your operations? Why? Because technology plays an important role for two reasons:

1. You can benefit greatly within the healthcare industry by being a market leader with a well run technology operation yourself
2. If you have any scale at all within healthcare, you will one day be faced with the challenge compensating for your customers technology inadequacies.

Flip back to a previous article as an example of just how sometimes you need a technology solution to overcome your customers own internal inadequacies.

The challenge of course is for your operation to be like Walgreens and CVS and not like the countless others out there using technology just barely enough to get by. If you want to start using technology to thrive, we would love to help with that.

In 2018 I spent an exceedingly large amount of time arguing with managed care attorneys. I was representing a healthcare company that didn't fit traditional classifications, and in turn, "lively discussions" around traditional security requirements were occurring constantly.

In one particular call, we discussed their requirement for an around the clock, eyes on glass SIEM solution before our $5-million contract could start. This requirement was overkill for the operation, and it was my job to convince them.

Eventually, they backed off the need of around the clock, eyes on glass, but they still insisted for a traditional SIEM solution. Their recommendation was for us to use a company called SolarWinds.

I had concerns for TWO main reasons:

• We already built top tiered solutions for security monitoring
• More importantly, I wasn't (and still not) fully comfortable adding additional parties where someone else has control and there is no visibility into their security practices

Their response: "SolarWinds is used by DOD, FBI and almost all Fortune 500 companies, I promise you their security is better than yours."

Recognizing I had to bend on this particular requirement, I agreed. However, I wanted to be on the record noting that I didn't believe SolarWinds solution was better, but more importantly point out that they ARE a bigger target, which made me uncomfortable giving them access to our network and data.

Fast forward to 2020 and SolarWinds is now the source of what in my opinion will be seen as the largest security breach to date. Having Microsoft Source code stolen is hugely problematic in so many ways I'd need a whole other blog post (or ten) to detail. Then came the US Government agencies breached. And the more time and info we uncover, the worse it gets.

This is reminiscent of this summer's SonarQube hack of the FBI (also reminiscent for me because due to other discussions I had with a different set of MCO attorneys over SAST testing requirements and their suggestion to use SonarQube).

This topic will probably be controversial for certain vested interests, so let's get a disclaimer out the way. If you are a Fortune 500 company, a large government agency, or if part of an "IT security company" this post isn't for you. This post will be beneficial for healthcare companies that are not hospitals/doctors offices/pharmacies, generating $50-$200 million in revenue.
Disclaimer out of the way, onto the real controversial statement.

The current unfashionable practice of "security through obscurity" (when combined with other key security measures) is prudent and needs to make a comeback.

If you're still reading you are probably: 1) vehemently opposed to that statement and looking for a pitch fork, 2) you agree with me (very unlikely), or 3) you have no idea what I'm talking about.

So for third group, security through obscurity is the past belief that there was security in no one knowing your source code and your technology apparatus.

For the pitchfork folks, before we go too far, I am not saying that "security through obscurity" should be the only security measure. But rather we increasingly find that attack vectors come through adding services (yes, even security services) to one's network, and maybe as serious IT professionals we should consider limiting the amount of entities on our network for the sake of security. This principal applies doubly to small and medium sized companies.

Blindly adding services on top of one another is like adding more entrances to the White House without ensuring additional security precautions. In short, you're asking for trouble.

You need a solution that thinks through the most cost-effective (emphasis on effective) method of security. You need a solution that will look at your company's entire landscape and make the best decisions to keep your data safe. You need a solution that doesn't just regurgitate industry jargon like "standards" and "best practices" especially since every business is different and has their own specific needs. With these ideals in mind, Vy can not only ensure an effective tailored security solution but we can usually implement at a lower total cost. Truly a win-win.

Maybe your operation needs an incredibly well hardened software that has limited attack vectors. If that is the case, Vy would love to have a conversation with you.

Thinking of selling your company in the near future? Great. It's an amazing time of your life. A lifetime of hard work culminating into a single event. Similar to a wedding, only this is the end of the journey not the beginning, you need to broach important subjects to ensure you are making the best possible decision. For marriage that might be discussing with your spouse the want for children, where you're going to live, and values of importance. In business there are many issues as well, but one that often gets overlooked, and can make or break the big day, is data asymmetry.

You've likely never heard of data asymmetry, and you're not alone. But if you don't familiarize yourself, you could be leaving 10s, or even 100s, of millions of dollars on the table.

The private equity or publicly traded companies behind large scale purchases are highly sophisticated. They have scores of Ivy League MBAs that spend their time analyzing data with the sole purpose of estimating your company's worth five years in the future, and how they can justify "discounting" your company's valuation in their offer.

When a seller cannot compete with this intense data analysis, that's when data asymmetry occurs. Put another way, data asymmetry is when you know your business is worth more than the offers suggest, but you have no way of demonstrating why they are wrong.

It's a frustrating place to be, and quite frankly, it occurs more often than not. Private equity is banking on the idea that you can't demonstrate the full value of your business, and in return, their offers reflect that assumption.

You may be asking yourself, "but won't my investment banker help me through this?" Not exactly. Even if you go the investment banking route, think of the investment banker as a real estate agent. By that, I mean two things:

1. Expediency of the sale is more important than final price. This is due to the cost-loss analysis, i.e. how much money do they stand to make on pushing for the best price vs. how much they stand to lose if the deal falls through.
2. They are handcuffed with the data you give them.

Of course, investment bankers will clean it up, format it, and present the best possible view. But they can only work with what you have given them. And in a lot of cases it is not enough.

When I first went through this process I was shocked at just how little value the investment banker brought to the data side of the transaction. Still, they were worth their fee, just for their relationships in the industry alone, and that they knew what questions to get answered. But if you think they are able to take your raw data and present the case for the highest valuation, think again.

It is critical that data analyses occur before you hire an investment banker, or start talks with private equity firms. Truly, the time to think about/implement is one to three years before the sale.

I saw this first hand. My journey into increasing a company's valuations, via technology and data advancements, began when I was brought on board to increase a company who had recently received mid 8-figure valuation. Some might say, great, I'll take it. But the owners of this company had their sights set on a low 9-figure. But without changes that wasn't going to happen.

Those changes were simple to outline (data asymmetry and an inability to grow into sophisticated markets), but took expertise to solve.

Private Equity knew this and appropriately discounted their offers.

The owners, however, were smart enough to recognize the problem, implement a solution, and then bring the business back to the sellers.

In three years we were able to fix their data/technology systems which enabled:

1. a more efficient operation (EBITDA improvement)
2. entering more sophisticated markets (top line growth); and
3. output sophisticated data when buyers came knocking

In the end, they were able to get an offer 3x higher compared to their original offer. 3 TIMES!! They earned their low 9-figures and then some.

If the above problem sounds familiar to you, and you'd like to hear more, feel free to contact us. We love solving data/technology problems and helping businesses prove their value.

Also, we promise to keep your intentions confidential, and NEVER sell your information.

We completed a really fun project this past week for a client of ours involving our ERP and WhatsApp integration.

To WhatsApp's credit, they do not want to become a spamming engine for the entire globe. Because of this, navigating their API process is quite complicated. The API itself is super simple. But how to get approved, how templates are approved, and how templates are used for initiation make for a complicated integration. We are glad we are on the other side of that now and have the understanding of how all that works.

But it got us thinking about another area we are highly versed in: HIPAA compliance.

WhatsApp is great because it is end-to-end encrypted by design (which text messaging is not). So does that make it HIPAA compliant? As Steve Adler's great write-up in HIPAAJournal.com points out, no, not as it is traditionally used.

He's right, except for one thing. He assumes the only way to use WhatsApp is from phone to phone.

As Mr. Adler points out there are three issues that prevent WhatsApp from being HIPAA compliant on the surface: Access Controls, Audit Controls, and Termination Controls. Let's look at why these are problems for phone to phone messaging, but not within an application like Vy Healthcare ERP to Phone.

Access Controls

If you use WhatsApp phone to phone, you lose ability to control who can install that account onto a phone. Thus you have no access controls and that is a big HIPAA no no. But if you never install the application on a phone, this isn't an issue. If your WhatsApp messaging is built into your Healthcare ERP, and it does the sending, you have the same level of access controls as the rest of your application.

Audit Controls

Likewise, if you just use WhatsApp phone to phone, you have no ability to keep an audit trail of conversations. However, the very nature of integrating the WhatsApp API into your Healthcare ERP, will produce the same audit trail of communication as you do with any other method of compliant communication. We'd argue you actually get better audit controls because of the verified feedback you get from WhatsApp on the status of the message (i.e. you know whether it was delivered and not read or delivered and read).

Termination Controls

Lastly, termination controls are achieved just like the rest of your Healthcare ERP termination process. Unlike in a phone to phone situation, where if you remove the app from the phone it removes the data, all the historical data is saved, access is terminated, and everyone goes on with their life.

BAA

I do agree with Mr. Adler's assertion that a BAA is not necessary because by the nature of how WhatsApp built their platform and the underlying technology, the data never gets stored on their servers and the data is always end to end encrypted with keys WhatsApp doesn't have. If someone tells you that you need a BAA for WhatsApp, then you better get one with the United States Postal Service because a lot more PII is available to every letter carrier in this country than WhatsApp has available to them. That being said, you may have to sign a BAA with a third-party if you use them as your API gateway, but that is usually a pretty straight forward process, and certainly not a reason to not use WhatsApp.

Tools like WhatsApp coming together in Healthcare is exciting. So even though it isn't HIPAA compliant out of the box (or phone), it can be a solution if implemented correctly. If you have questions or ideas on how you want to implement it, feel free to reach out to us.

It may be because there is nothing on TV. It may just be general curiosity. Either way, I find myself consuming a bit more news than normal in these interesting times we currently find ourselves in. Much of that news is to be expected. Airlines in trouble. Oil plummeting. Stimulus packages created and then poorly managed. But then I came across something I wasn't expecting. The dire need for COBOL programmers.

The backstory is this. Due to the rise in unemployment, and a flood of unemployment claims, the antiquated system that utilizes a programming language few people know anymore is creating significant issues processing claims. So there is this urgent call for COBOL Programmers. But few under the age of 60 know how to program in COBOL. Why? Because COBOL came onto the scenes in the 1960s and hasn't really been taught since the 1980s.

But before we jump on the obvious lack of foresight New Jersey and Kansas have had, it is important to understand that what most tech companies don't understand about non-tech companies is that you rarely get the benefit of being an early adopter in an established, profitable, well-run organization.

That being said however, what non-tech companies don't understand is that they have to have a game plan to deal with their aging systems and processes. Credit can be given for not always being up on the latest and greatest because the latest and greatest is not actually the greatest for established companies, but they don't get a pass on waiting 50 years to update their system either.

You have to find a balance.

While the old saying goes, never waste a good crisis, it is by far more preferable to modernize before a crisis hits.

One of our customers recently capitalized on that. They are one of the few businesses that have stable growth in the good times, but have very rapid growth when things are bad. In theory, their main competition could do the same. But their main competition can't because they aren't set up for that. So while our customer can pivot on a dime - even remotely - and integrate insurance companies' systems into their system, and then their system into UPS's system, their competition is left with a very small piece of the pie. We are talking tens of millions of dollars left on the table.

But it wasn't in the crisis that enabled them to do that. It was 7 years before that when they realized their RPG-based (similar to COBOL) system was stuck in the 80s and it was time to modernize.

Times are tough now and they likely will be tough for a while. And whether it is helping your team work easier remotely, or cutting costs, or simply because the time to advance is when your competition is flat footed: now (yes even now) is the time to modernize. It's probably cheaper and easier than you might think.

Be better situated for the good times. Be better prepared for the bad times. And stay safe out there.

When I was a boy my dad would ask, like most fathers, "how was school?" I'd mentioned something along the lines of "well I had a math test today."

Then my dad would ask, "well how do you think you did on it?"

And I would answer, as if it was the most obvious answer to his question, by informing him that I finished faster than everyone else in the class.

Looking a little perplexed by that answer, he would then follow up with, "ok, but how do you think you scored on that test." And I would respond along the lines of, "yeah, that was a given. I got an A on it."

In my mind the fact I got an A, wasn't what set me apart. The part that set me apart was the fact that I finished before everybody.

To be very clear, I am not saying I was the smartest person in the class. But I was an "A" student in a gifted program. So let's say I was in the top 5%, but I was not in the top 1%.

This didn't really bother me then and it definitely doesn't bother me now. Answering my dad so naturally that I finished first, spoke more about what I eventually learned about myself: which is that I have a zeal for efficiency.

This is something very unique in technology. That is why I want to build our company on this value.

You can find companies that can do relatively the same thing as us. But you'd be hard-pressed to find one that can do it as fast as us. Likewise, you may be able to find companies who can move as fast as we can, but the quality and security of what they do is not up to par.

In college I had a professor, who is still a great mentor and friend, named Dick Pritchard. He would say in completely different context from business, "you can have something good, fast, and cheap, but you have to pick two out of three. You can't have all three." For the first 10 years of my professional career I always liked to think that I was the anomaly. You can have all three with me. Eventually over time I became less and less cheap.

While we might not be cheap in the strictest definition, we are the greatest value. Because in business time is money. First in a billable sense meaning that if you can do something in 10 hours that others will do in 40 hours, it doesn't matter if you charge twice as much because you still saved them half. But there is also opportunity costs. If something takes two years to implement that could be implemented in 6 months, there is a significant amount of missed opportunity in the 18 months lost.

So at our core: we are high quality technology innovation in the shortest amount of time. We have a zeal for efficiency.

If there is one thing I am most grateful in this life is that I have had amazing mentors at all stages. There were three in high school. Two in college. Four after college. But there is one mentor that I have had throughout all the stages. Charlie Paparelli.

It is not an understatement to say I would not be the person I am today without Charlie. He is my Uncle. He is a very successful businessman. But when he realized that the life of success he was pursuing was pulling him away from family and instilling some bad habits, he had the strength to become someone completely different. A better person.

When everyone else in my life was just impressed I was a 4th grader with a job, he wasn't. That wasn't good enough. I still remember sitting in my dad's office and him teaching me (at 4th grade mind you) how to sell more newspaper subscriptions and the value of recurring revenue. I mean, who does that?

If you are going to be around Charlie you got to be ready to improve.

As a kid I don't remember him being an alcoholic. I just remember him being my Uncle Charlie. Right as I became of age and started knowing things is when he turned his life around. He's now as passionate about reaching this world for Jesus as he is a savvy businessman.

I remember a lot of his sayings throughout the years. One of which was when I was 13 or 14, I was up in my cousin's David bedroom, and he gave me this classic Charlie look. If you know Charlie you know that look. It's a look that means something - whether asked for or not - is coming. I love that look. He said, "Andy, if you are not learning you're dying." I am sure there were many supporting points to this statement that followed. I don't remember those. But I always remember that saying.

Unlike Allen Hunt's value, Charlie's value is one I naturally gravitate to. I like learning new things. I like experiencing new things. I get a little bored once I have become "good enough" at something. I think a lot of time when we get in trouble in life is when we basically come to the point where we say "yep I have learned that" and then try to coast it on in.

Charlie gets overcoming this temptation better than anyone I have ever known. It is rooted in the saying, "if we are not learning we are dying."

Be someone who is constantly trying to learn new things. Be someone who is trying to be better today than you were yesterday. Be someone who does not feel that it is up to anyone else to train, equip and develop you. Go out and find the answer and then do something with those answers.

We are dying if we are not learning.

Thank you, Charlie Paparelli. We will strive to be like you.

Church was not part of my childhood. I started going in Middle School without my family and eventually became a Christian. In that time, I got to know a man named Dr. Jeff Justice.

Dr. Justice was amazing. He was a great father, a great husband, and very active in our church.

The first time I met Dr. Justice he was teaching a Sunday School class when I was still new to this whole thing. He gave a simple quiz - one of the questions was along the lines of what is Matthew, Mark, Luke and John - which anyone who has been going to church would answer easily those are the Gospels. But I didn't know that. I didn't really know anything about what was in the Bible.

Since I didn't know any of the answers to the quiz, it was a quick quiz for me. So I turned in the quiz with no answers. I wouldn't say he called me out, but I think he thought I was being a punk middle schooler not wanting to do the quiz. Not realizing that I had just started coming to church and knew nothing, he kind of teased me a bit for it.

I love that story.

Beyond that though, the one thing that struck me about Dr. Justice was how well he was respected outside of church. It's hard to describe unless you live in a community like Fort Wayne, IN, but everyone within the Medical/Legal/Business community kind of knows everybody. It's big enough to be something of substance. But also, small enough that most people know each other.

Often my church was a topic of conversation with people outside of my church and I would eventually talk about people inside there and when I would get to Dr. Justice people would stop and say how much they liked him and respected him. How much the nurses liked working with him. How much his patients liked him.

That wasn't always the case with other doctors.

Dr. Justice modeled what it was like to be a great father and husband, but also what it looked like to be a Christian out in the marketplace. Respected first for his marketplace impact, but also for a character that forces the question, "what else is there to this man?" Why is he different?

I am not naive to the idea that this core value is probably the most controversial for a business. Partially for reasons that might be warranted. But also for reasons that aren't.

We are glad that you are here regardless of who you are and what you believe. My life was impacted deeply by Dr. Justice and I want us to have that same impact in our marketplace. I would be remised if I didn't establish the same foundation Dr. Justice modeled for me. One that loves, that respects, that gives, that rests, and that creates a positive family environment.

Thank you, Dr. Jeff Justice. I will strive to be like you.

It has been a joy living in four very distinct places in my life. The first 18 years in Indiana. 4 in Los Angeles. 8 in Atlanta. And going on 7 in St. Petersburg, FL. More than living in these places, it has been a privilege working with some amazing people.

Starting my own company was always on my radar. Because of that, I maintained a list of people that are first and foremost great people, but also excel at some area that my future company may need.

One of those was Gina Donnelly Theising.

She was the Associate Director of Chapel Programs at Azusa Pacific University. She was so good at what a lot of people aren't good at: office administration. She did that relatively unsexy job with such joy and love that just permeated through the entire office contagiously.

The timing to start my own company was very much a struggle for me. I'd say I really wrestled with it for about two years. The time came in June of 2019 when I finally accepted it was time to leave the best job I ever had and start Vy Technology.

Like every year, I was planning on spending the 4th of July with my family up at the lake in Coldwater, Michigan. So I said, "I think I know where I stand on this, but I am going to take that week just to clear my head before I do what I need to do."

In the middle of that week I got a message that Gina died at 47 years old in an ATV accident.

This world can be tough sometimes. Good things happen to bad people. Bad things happen to good people. That's a conversation for another day. If this were a just and fair world, probably everyone reading this blog should have gone before Gina. She just loved everyone. She saw the value in everyone.

When I went to her funeral a few weeks later, I was awe struck how many people were there. I thought I knew the people who knew her. If I were to guess, the large Catholic Church in Simi Valley, CA had about 100 pews. They were all full. But the people I knew maybe took up 5 of those pews. It was then I realized just how big of an impact she had. That was all because of how much she loved.

She was always the first one there for anything. She would sign up for the marathon you wanted to run. She'd go hiking if you wanted to go hiking. She had a zeal for life and that zeal always involved others.

I am sure she had her selfish moments. Though from the outside that was not evident. She just loved and valued people the way God loved and valued people. We want to be a culture where we value all people the way Gina valued all people.

Thank you, Gina Donnelly Theising. We will strive to be like you.

My grandfather Ray Neslund was an astonishing man. He spent most of his childhood on a very poor side of Chicago. His parents were first generation immigrants from Sweden. There are parts of his childhood that he wouldn't share. You can just tell that things were not good.

One of the things we do know is that he lied about his age to join the Merchant Marines. At 17 years old he traversed the Atlantic dodging German U-boats. Even back then, 17 year olds wouldn't volunteer for that type of operation if things were good at home.

He never went to college. He came back after serving in the Merchant Marines, served a short time in the Army, and then after some time he started the Manpower franchise for Denver, Colorado.

It wasn't until I co-led a massive FEMA emergency meal operation in 2017 that I learned a nuance of Grandpa's business. Within that project, we had to employ 700 temporary employees. Even though we employed temps every day in our normal operation, there is something to be said about needing 700 temps as quickly as we needed them.

We had a very small break between Hurricane Irma production and Hurricane Maria production. In that small amount of time, another executive and I debriefed and we said that most went fairly well, but one thing that needed to change was how we checked in temps. In a matter of two days and a budget of $40, I developed a digital check-in system that could most easily be described as an airline boarding process. This took the temp check in process down from 2 hours to 15 minutes, and from requiring 10 people to 2.

Later I was sharing this story with a family member who said, "your Grandfather would have loved to have seen that." I was a bit surprised because I was always under the impression that his business employed more office temps than blue collar temps.

My uncle said "ohh no, he made his name in Denver with blue collar temps because he created a niche where he would pay them the same day they worked. This enabled him to get the best temp employees in the Denver market."

Grandpa of course did very well in business (with no formal education). He had built a lot of profit and margin for himself and his family. But he also built a lot of margin for his customers and his employees.

At that time credit cards weren't as accessible as they are today - especially to this population. Being able to pay the same day extended a lot of lifestyle margin to his employees. I also know full well that a lot of margin is extended to a company (his customers) that used temporary employees either by impacting profitability or flexibility or adaptability. You are enabling a lot of margin for that company too.

That is what we intend to do. We pursue margin for our employees, our customers, and our owners.

Thank you, Ray Neslund. We will strive to be like you.

In 2005, my first job out of college was being a Videographer for a church in Alpharetta, Georgia. That is where I met Allen Hunt. He was the Senior Pastor of that church.

Unbeknownst to me when I graduated on a Saturday and packed up and moved from Los Angeles to Atlanta by Tuesday, was that Allen Hunt would become (and continues to be) a huge influence in my life.

I also didn't know at the time that he was starting a talk radio show aimed at talking about faith in the mainstream (not on Christian radio).

I spent the next six years working side by side with Allen. The show started as a side project of our church and eventually we struck out on our own: just the two of us.

It is where I learned a lot about running technology for an operation because we had no budget and a lot of needs. I was responsible for everything - from the networking to the website design, database management, CRM, graphic design, satellite uplinks, audio editing. You name it, everything.

But while I self-taught myself a lot about tech during my time with Allen, I also learned a lot about life from him. Looking back, it would be amazing if everyone spent the first six years of their professional journey with someone like Allen.

Allen would have this saying that there is a "difference in being right and doing right."

I always loved that. Not because I was particularly good at it. I like being right. If you know me for more than five minutes you know I like being right. I grew up in what I would call a multi-generational, extended-legal family. In three generations I can count seven lawyers and one politician. And that doesn't even count the two intense businessmen. It breeds into you the ability to think creatively and stand your ground. Which has its benefits some times.

But this was added as one of our core values partially because I am not good at it and I need the reminder, but also because - no pun intended - he's right. It is better to do right than be right.

Sometimes that means swallowing your tongue. Sometimes that means doing the right thing regardless of whether or not someone is right to have asked of it. Sometimes it means just having empathy.

It also makes a lot of sense given our industry. There is something about being in Technology and being in Healthcare that makes this all the more important. There are a lot of egos. There is a lot of dysfunction. A lot of times it just takes someone stopping and asking the question, what is the right thing to do, and then doing it.

We probably will not be successful at this at all times. But we strive to be.

Thank you, Allen Hunt. We will do our best to be like you.

My Grandfather - Bill Borgmann (#6) - played football for University of Michigan back in 1934. He was good buddies with fellow teammate Gerald Ford (#48). Grandpa went on to be a Lawyer. Gerald Ford went on to be President.

One of their teammates was Willis Ward (#61). Ward was a black football player 15 years before Jackie Robinson played Major League Baseball.

When the University of Michigan was to play Georgia Tech, Tech refused to take the field if Ward played. The story goes that when the players found out about this they contemplated refusing to play. Now I don't know if it was truly the "Rudy-esque" moment that President Ford's campaign made it out to be. There seems to be some dispute about that.

But what I do know is that they did take the field without Ward. Early in the game one of the Tech players made a snide comment to my Grandfather and President Ford that I can only assume used the N-word. As the story goes, my Grandfather and President Ford hit that guy so hard on the next play it took him out of the game via a stretcher.

Even 40 years later, you can still see the pride and joy in Ward's retelling.


Grandpa never told me that story. It would be 7 years after he died when I first heard it. I love that story for a lot of reasons. One of which is because I believe it speaks to a familial belief that this world should be a meritocracy.

This is one of the reasons I love sports so much (it certainly isn't because I am good at them). Ultimately at the end of the day, sports do not care about anything other than how well you play, how well you help your teammates, and how well your teammates help you.

Within that meritocracy there are phenomenal players and there are great players - you don't make it to the team if you aren't great - but compensation and tenure is solely based on how well you perform. Tom Brady is not compensated the same as Edelman, and Edelman is not compensated the same as the backup lineman. That doesn't devalue the backup lineman. Our value in this world should not be based on our position or earnings.

But business should be a meritocracy. Your value within a company should not be based on whether you are male or female, young or old, Republican or Democrat, educated or uneducated, straight or gay, Christian, Jewish, Muslim or non-religious, Black, White, Latino or Asian, or anything else. The only thing that matters in a business is how well you perform for your team.

Tech companies in particular are not notorious for being good at this. Sure, their Executives write books on the concept, but their cultures do not reflect this. Vy Technology will strive in all things to be a meritocracy.

Thank you, Bill Borgmann. We will do our best to be like you.

We have a customer that is growing very fast in the Healthcare space. Two years ago their Member database was around 200,000 members. After 2020 Annual Enrollment Period settled, they are now over 5 million members. This growth is a very good problem to have.

One of the features of Vy Healthcare ERP is something called "IntelliSearch." This feature enables a quick and easy ability to find members when names are not always the same or when it is not obvious which MCO they are with (something that can be more difficult than you'd think - but this is a topic for another day).

The problem with IntelliSearch is that while it makes it very user friendly for Call Center agents, it is way more taxing on the server, especially as that database grows.

Another feature of Vy Healthcare ERP is that we process discharge/authorization files as soon as they come in from the MCO. This is of course great for the MCO, our customer, and ultimately the member getting served, but it is also pretty taxing to be processing through thousands of discharges and comparing it to millions of Members in the middle of the day.

So when average page load times went from 1.2 seconds to 7 seconds in January, something needed to be done and needed to be done fast.

It was initially proposed that we need to remove IntelliSearch and that file processing should be moved to an overnight job because that is where the problem lies.

The problem with this is that it would severely impact usability and also provide worse customer service.

And therein lies the problem. For those outside of technology (looking at you CEOs and CFOs), all "tech people" seem the same. But there are a lot of different types of technology people. In a perfect world you have:

• Developers
• Database Administrators
• Server Admins
• Network Admins
• Security Specialists
• Project Managers
• And of course, an Executive over all of them that understands all of this

If you have an appetite for all that, Vy Technology may not be for you (that's at least a $1 million in payroll right there). Even if you can afford it though, finding and retaining is a whole other issue. So what most small and medium sized businesses do is they hire a single Network/Server Admin type, put them in an IT Director position, and turn to them to make big picture decisions. If you found that diamond in the rough that can wear all those hats and you can keep them happy, great! But if you don't have that, you can't leave operational business decisions up to the wrong type of technology person.

In the end, we went with a replicated database solution that processed the searching in one database, the discharge files in another database, and left the master database free to do everything else (at no additional cost, no operational impact, little work for the internal IT department, and in a matter of two days).

This absolutely was more work. Did it "ruin a weekend," yes. Was it the easy way out, no. But there is no doubt this was the right move to make for the business. And putting the business over the IT department is what good businesses (and IT departments) do.

One of our core values at Vy Technology is that We Know the Difference in Being Right and Doing Right. What we mean by that is, being right is important, but doing right is far more important. When those conflict, choose doing right.

Even though most of our core values reflect what I naturally gravitate to in business, this, in full disclosure, is not one I naturally gravitate to. Out of all our values, this is one that I personally struggle with the most. I think a lot of technology personalities struggle with this. It's why it's important it's there.

Living out this value of course can manifest itself in many ways. One recent way was looking at helping a customer of ours come up with a solution because their customer didn't have the ability to provide consistently formatted data.

This story may get a little complicated so I will go ahead and call our customer Good Food Company and I will name their customer Homestead Insurance Company (neither are their real names).

A standard need for Good Food is being able to process hospital discharge files. This usually entails processing through the discharge file, comparing MemberIDs to a previously loaded eligibility file, and then proceeding on if a match is found.

This match is important because after the member has been served, the reporting needs kick in and there is a lot of metadata associated to that member from the eligibility file that needs to be reported back to Homestead.

The problem lies however in the fact that you would think the MemberIDs in the discharge file would be in the same format as the MemberIDs in the eligibility file. For most MCOs, that is the case. But for Homestead, that wasn't the case.

Now we could have rightly held firm and said, you need to get your two files to match. We would be right saying that. But that isn't necessarily doing right given the situation.

Why? Because we know that Homestead will take months to get this resolved. We know that Good Food will be missing out on revenue while Homestead sorts through that. And most importantly, we know that Homestead's members will be missing out on a benefit they very desperately need when they are at their most vulnerable.

So how does a "doing right" versus "being right" mindset solve this issue? Simple. Vy Technology proposed and then wrote an algorithm that tries 896 different combinations of MemberIDs to find a match.

So if a MemberID is 123456789-01 in a discharge file, then we try 12345678901, and 123456789*01, and 00012345678901, and 123456789, and 892 more variations. The computational impact on the server is measured in milliseconds. The coding effort was measured in 2 to 3 hours. Good Food is happy, Homestead is happy, and Homestead's members are happy.

These are the types of issues you find when doing business in healthcare. And this is the type of creative problem solving you get with Vy Technology.

On a recent visit to my alma mater, I sat in on a Machine Learning class.

It was fascinating. Being in the room with 20 or so students talking about a technology trend I have little real world experience with was a thrill.

But as thrilling as it was, and as talented and intelligent as those students were, I left the class with the words of my father in my head. He'd always say, "No one ever asked for my law school GPA two years after I graduated." The strong point that made to me as a child was that school is important, but the real world will be different.

Put another way: the theoretical is great, but the rubber meets the road in the practical.

15 years removed from the classroom, away from the field I originally studied, and after hiring many people in the technology field (and interviewing even more), I find his professional philosophy to be truer than ever.

Technology is full of incredibly smart people. No doubt about it. However, what those in technology miss too often that impacts particularly small and medium-sized, non-technology companies is a business first, technology second mindset.

If that doesn't quite resonate, simpler put: if an organization is struggling to get out of spreadsheets, machine learning is likely not the solution.

Now in full disclosure, and to his credit, the Professor made this point to his class. I believe his exact words were, "if you can solve a problem with out machine learning, you probably should." But what that Professor understood is very often missed by businesses vetting technology providers. And when missed, it becomes a big part of their frustration down the road.

Instead, those vetting technology providers should ask themselves, is this a Technology first or a Business first solution?

• Technology first asks, what is the latest and greatest?
  Business first asks, with out sacrificing the objective, how can we make this the least disruptive to our workforce?
• Technology first asks, what is everyone in the industry doing?
  Business first asks, what does this particular business need?
• Technology first asks, what will garner the most respect of my peers?
  Business first asks, what will make the largest impact to this company's goals?

Sometimes these answers are the same. Usually they are not.

There is something great about being cutting edge, no doubt about it. But if it is incredibly expensive, it is incredibly disruptive, it takes longer than expected, and ultimately doesn't produce the desired results, there is no value in it. And providing more service value than you take in payment is the foundation of all great businesses.

When I first started developing HIPAA compliant software I had been developing custom software for 9 years. But I had never had to develop a HIPAA compliant solution. Like a lot things in life I figured, no biggie, I'll do some research and figure this out.

Boy was I in for a surprise how nebulous the law is and how wide the varieties of interpretations were.

What came out of all that research turned out to be our guiding principles.
Something I came to call the Pillars of HIPAA. It serves as a pretty decent introduction into the basics of securing HIPAA data.

Eight of these were developed pretty early on. Five more were added over the course of the next six years.

When we went for HITRUST Certification, we were positioned pretty well with just these pillars. Yes, the Certification required us to codify a more formal IT Policy. And in no way am I saying these pillars are the equivalent of HITRUST Certification. But I do believe the 105-page IT Policy that ensued doesn't do that much more than these 13 pillars below did to secure data in a HIPAA compliant system.

1. Encryption in Transit - all data is encrypted and transferred using a 128-bit SSL secure connection.
2. All access is controlled by an individual username and password for every employee.
3. Every page view and action is logged - including date, time and IP address.
4. PHI is always hidden unless an employee purposely chooses to see it, in which case a special entry is logged.
5. All PHI is stored in the database in an encryption at rest state - i.e. a social security number of XXX-XX-XXXX would be encrypted and stored as WhvNDTdXAPJYzWajhkXegzfX...
6. All PHI (which is already encrypted) is stored in a separate table from other identifying information. As an example, names and addresses are stored in a separate location than Social Security numbers and Medicaid IDs.
7. Permissions for all employees are set on an individual level using the Principle of Least Privilege - access to information is reviewed and granted on an individual level.
8. All member related data is not accessible outside of our internal network without the use of 2-Form Authentication via Google Authenticator and a proprietary key. This conforms to algorithms specified in RFC 6238 and RFC 4226.
9. All reports are generated with minimal information needed.
10. The server can only be accessed via SSH/SCP - since FTP connections are unencrypted, they are not allowed on the server - SSH/SCP is more secure than FTP and SFTP.
11. SSH/SCP access is only granted via security keys (no passwords) - thus preventing brute force attack attempts - this method is much more secure than a traditional username and password method.
12. Our firewall only opens the following ports: 80/HTTP, 443/HTTPS, 22/SSH to the outside
13. All versions of Linux, PHP, Apache and MySQL are long term stable (Ubuntu 18.04.x LTS / PHP 7.2.x / Apache 2.4.x / MySQL 5.7.x).

After going through HITRUST Certification for one of our Customer's systems, I would add the following four as well.

14. Force logoff system after 15 minutes of inactivity
15. Include warning messages on all systems (Web or SSH sessions) that informs an individual they are entering a system with PHI and their actions are monitored
16. Implement a DLP solution for Email that includes the ability to send secure
17. Implement annual third party penetration testing and risk assessment