You always wondered why, but then you were never in the healthcare industry or work at an exec level to know how the tech systems work at a typical hospital…
Here’s a quick education into the healthcare disaster!
When you go into the hospital, a chart is written up based on your comments and the doctors evaluation and actions (draw blood, tap your knee, whatever). This chart is then translated into a series of medical codes so they know how to charge them to you or your insurance. The charts are evaluated by a series of medical “coders”, no, they don’t know C# or Java or JavaScript, they just match the words to “codes” (ICD9/ICD10).
Each chart is “coded” to a specific set of codes. The codes are then sent off to the billing system. The billing system will match the codes to the patients insurance (or lack thereof) such that the base charge rate is multiplied times a discount (or again, a lack thereof) or “forced” charge amount for that particular insurance contract (Blue Cross, Medicaid, Medicare, etc).
Most insurance companies want a “discount” on your particular services\codes. They can negotiate or force (depending how big they are) just about anything for a set of codes.
The crazy part about this is that the base rate that the hospital charges (the “charge master” database system) is pretty much a let’s run a sql query against the database and increase everything by 7% EVERY YEAR (or some rate adjustment, possibly matching inflation or exec\board discretion).
You should be saying…”wait what”?
Yup, every year, a non-qualified individual will increase the pricing of stuff because the execs tell them too. Remember the movie “Independence Day” when the jewish guy says something about the price of the hammer…yeah…$400 for a hammer.
Aka, $20 for a bandaid!
Why? Because the charge master simply gets incremented by a percentage every year in a blanket fashion!
Ok…so the charge master is broken. Yup. That’s where the government comes in. Obama actually kicked some serious ass with this. He forced certain codes to be charged at a base rate that is run by the government (and you have to follow them for any ACA insurance policies). If you send in a bill with a code that has a price over the base, REJECTED! It forced everyone to reevaluate their charge masters (at least for government stuff).
I applaud him for that.
But…here’s the kicker. The “coders” that “code” your chart. Those people are instructed to interpret the words in such a way that they can set the chart to match the most expensive codes! Even though those codes may not even really match! It’s up to the patient and the insurance company to do a review of the worded chart to see if the codes have been applied appropriately!
This review happens very rarely.
Now that I know how this works, believe me…every time I go into the doctor’s office I ask for my chart and the codes that were sent for it. I actually got $250 back for this last visit!
What else happens? Oh, execs and doctors are “spiffed” for overdoses of various items. Example, you get bit by a snake and need the anti-venom, guess what, you only need one dose…but how many do you actually get? Anywhere from 1-5 doses! Each dose (back in the day) can be up to $20K each. Where does the money go? The doc, the hospital and the execs get a kickback! What?!?! Yup…there is shadiness that occurs for all kinds of things.
And that is your 10 min run down of how corrupt the medical system in America is and why we don’t have universal health care, everyone has a different charge master that no one can agree to the price of anything!
Enjoy!
Chris
SharePoint eDiscovery OR Records Management, but not both!
NOTE: This blog post is context sensitive to the current state (9/2017) of on-premises SharePoint 2013 and 2016 environments and has no relation to any new evolving data labeling or retention in Office 365. It has come to my attention some very significant features will be announced at Ignite around filling the traditional Records Management feature gaps.
Stay tuned for a post on why you should upgrade/migrate to the latest and greatest!
You see many blog posts by many of my peers. SharePoint eDiscovery is great, Records Management is good (yeah, only good if not bad). But what you rarely hear is the truth of the matter.
Just like in the highlander series…”there can be only one”. As new features are added to any product, they will start to collide. The collisions are becoming more frequent and the regression tests more infinite.
That all being said, if you only had one to choose from, eDiscovery or Records Management. Which one would you choose?
eDiscovery is pretty awesome when taken as a single entity. The ability to find and lock down (aka Hold) items across Exchange and SharePoint for the purposes of litigation for example.
Records Management (again as a single entity) is great in that you can enforce the users to not be able to make modifications to declared records. Albeit, only in the sense that they live in the records center or you have enabled the “In-place records management” feature in a site.
So why can you only have one? Hmm, let’s get to the meat of it shall we?
eDiscovery holds are great in that they allow you to target content such that it does not get modified. It does this through the somewhat well known Preservation Hold Library. That’s all fine and dandy, but the reality that most people don’t get is that when you add a “site” as a source and then create the hold, it holds the entire site by default. Admins (not end users) can get around this by enabling the “hidden” feature of Query based preservation. But when you do this, it adds an entirely new issue of performance to the whole conversation, but we’ll leave that out here.
Ok, so where does the choice come in?
Well, if you want to put a hold on your entire SharePoint Farm, you have to select all the sites in your sources for the eDiscovery case. Its doable, painful, but doable. So what does that do? It of course will make it such that any time a user modifies a document, it will go into preservation hold.
Ok, so what happens when you need to archive a document to the records center? You aren’t destroying it…you aren’t modifying it (per se), you are following basic procedures to create a record. Well, unfortunately my friends, the reality is that you will get an ugly error that the document has in fact moved to the records center, but that a link could not be created:
This is so very bad. You now have a document sitting in the records center, but yet it is also sitting in the source site. What happens is you send it again, which is of course what a user will try to do! Yup, another version is created and unless you have versioning turned on, you get the crazy FileName_ZUOXUDF filename. The original document will sit there…forever…or…until the hold is lifted and then of course, the data owner may have left the company and whala…a orphaned record that no one really knows what to do with!
Ouch.
SharePoint has never truly been a records management platform (content organizer and rules are a complete failure).
Because of this, it’s the reason four different companies formed (RecordPoint, RecordLion, Gimmal, Collabware) to solve the problems that SharePoint has had for quite some time. I’ll skip the inadequacies of those products for now, but likely you’ll get my full opinion on them later in life…
This particular instance of features colliding though…it really pushes organizations over the proverbial limit of understanding and patience.
In reality, the way things should go is…are you sending something to a trusted records center? Yes? Ok cool…I’ll let that action occur because I know its going to someplace good and monitored and approved.
Not…fail no matter what cuz one feature overrides another!
Pick one…but only one.
Chris
Do you trust O365’s trust of others?
So I’m renewing my CISSP and will be making a push into the security space pretty hard in the next few months. Part of that will be doing things like in this post.
I am deep into identity and auth flows and have been doing a ton with ADFS/OAuth with Intune etc.
A few days ago it hit me that a person has the ability to modify the claims that ADFS sends to O365. That got me to thinking…
What will happen if O365 does its realm redirect where a user logs in as one person yet the claim for the UPN is different than the original? Will it work and if so, what are the ramifications of it?
So, here’s my general thinking of what I want to do (didn’t end up being how to do…keep reading):
- Setup ADFS and a federated domain in O365 (chrisgivens.com)
- Modify the O365 ADFS claims to be someone\something other than what the actual login implied.
- IE…I login as chris@chrisgivens.com, but the claim that is sent back is actually spoof@chrisgivens.com
- Share a site with spoof@chrisgivens.com
- See if it all works…
So…first part. ADFS. When you setup the O365 relay it adds in its own claims rules so that it gets what it is expecting. The general set of claims that get sent are:
- http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
- http://schemas.xmlsoap.org/claims/UPN
- http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
In addition to the other basic claims as seen here:
Ok, cool. So here’s my goal. Set it such that no matter who logs in, the identity and claims that get sent to O365 are really someone else! That requires a bit of claim manipulation. Here’s an example:
See what I’m doing? I’m setting the email to be something else other than the original value from the auth’d AD user! I do this for all the email claim fields. The though is that Azure AD will utilize the email\UPN as its “source of truth” for who the user is. Ok, great. So let’s try it out!
Going to the faithful login.microsoftonline.com, I enter in a set of credentials for my federated domain, and get redirected to ADFS. I log in to ADFS page, and the first go around, I got this error:
After removing competing claim rules and re-trying the login, this is the beauty you end up:
It worked…kinda. Notice that id. That is what I though was the valid ObjectGUID. Nope, its a bit different than that. So how the heck do I view the claims that ADFS is sending?
Well, good luck with that with the out of box logging of ADFS. You can attempt to follow this post to turn on all the verbose logging, but its only helpful for resolving the competing claims issue or the fact I did not have the SAML Consumer setup on the replying party.
So, what do you do? You swing over to Auth0.com and you setup your ADFS with them, then you can use all their cool debugging tools to see what is actually coming across! Awesome…
So, after looking at the logs and seeing the original claim rule applied, I see that the ObjectGUID is base64 encoded. So I copy it and paste it into my claim rule.
Ok, let’s try this again…I sign on, type a username and password, ADFS does its thing, I get redirected back to the site, and whala…I’m in as the other user! Holy shizer balls, it worked…
It wasn’t what I though would happen being that I had to find the ObjectGUID and that is what Azure AD goes off of, not the email claims.
So what does this mean? It means whoever has access to ADFS for the remote federated domain, can open up the ADSI edit tool, find the ObjectGUID for a user (or even use basic powershell such as “Get-ADUser username -Properties ObjectGUID | Select *”), paste in some rules and BAM…they are in as that user in the O365 application layer.
They do NOT have to be a domain admin to query Active Directory for ObjectGUID, nor do you have to be a domain admin to manage ADFS. You can simply be an ADFS Admin.
This is significant in that unlike a domain admin, when a domain admin changes a password or an AD object, the AD object changes are very likely audited and red flags thrown!
In my experience, a change to ADFS claim rules is very rarely audited and monitored and if it is, it is unlikely to throw up any major red flags. Any ADFS admin can make a change and login at any time and bam, you can be anyone, anytime. This leads to…log your ADFS 510 events:
Hope you trust whoever is running the target federated auth server (no matter what it is). Or that you trust whoever you are sharing things with if they are doing federation and not Azure AD directly!
I think it would be nice to be able to set in the configuration settings that I don’t want to allow my users to share data with a domain that has federation enabled and that it must be managed by Azure AD! Maybe even be able to set it at a very specific level such as Site/Web.
Free SharePoint Apps for Everyone!
Have had this in my back pocket for a while. I just checked to see if it still works and sure enough…it does. You can see I tore deep into the SP App Store design with this 4 year old post. What I didn’t show was how one can get the app packages for free and by pass paying for the apps.
This only works with Apps that have a “trial”. Ones that you have to pay for will not be open to this hack as you would have to buy them first. But technically once you have bought it, you can use this same hack to then go post their app package on the internet.
How does it work you ask? If you read through the steps of the post referenced above, one of the back end abstracted parts is to download the app package such that it can be deployed to the target web. The app package will not be put into the database and is required to be downloaded each and every time you request it. In the App Mgmt database you will find the RawXMLEntitlementToken.
This is generated when you click through the Microsoft billing portion of the app install. All apps (Free, Trial, Paid) have to run through this in order to get the token. Once you have this token, you can use it to download the app package by simply pasting this into your browser window:
https://store.office.com/appinstall/unauthenticated?cmu=en-US&clienttoken=%3cr%20v%3d%221%22%3e%3ct%20aid%3d%22WA103532495%22%20pid%3d%22%7b1d39b4be%2D60e0%2D45d3%2D9084%2D186800df12e2%7d%22%20cid%3d%225B0427C7B8C9F259%22%20did%3d%22%7b4AA4B65C%2D9085%2D41B7%2DBC31%2D4553E50D3AAA%7d%22%20ts%3d%220%22%20sl%3d%22true%22%20et%3d%22Free%22%20ad%3d%222013%2D10%2D05T01%3a32%3a24Z%22%20sd%3d%222013%2D10%2D05%22%20te%3d%222018%2D05%2D31T22%3a44%3a03Z%22%20ss%3d%220%22%20%2f%3e%3cd%3e0o9KoXMWV%2bOazF2J02jVoMDkzptamrbN9%2fIZw0m09V8%3d%3c%2fd%3e%3c%2fr%3e&ret=0&build=15.0.4763.1000&av=OSU150&origin=EC101785291&corr={96ae724f-5d59-49b3-8fcd-79191c3e1728}
This will download the .cab file for the target app. Once you have this, you don’t need to pay for the App when the trial expires. Just install it to your app catalog or directly into the site.
Enjoy!
Chris