What has been found, though, is that flu vaccinations reduces loss work time from staff from contracting the flu (when the vaccines guessed right on what strain to produce). However, studies also show that proper hygiene measures by the staff also have the same effectiveness (ie. latex gloves, sanitizing hands, etc.).
Based on the data, it appears that the mandatory flu vaccine has more to do with the business side of the hospital than with the patient care.
Given that hospitals do not have an infinite pool of on-demand skilled replacement labor for patient care positions, "reduces lost work time from staff contracting the flu" has a fairly direct impact on patient care.
And it really doesn't matter that hygiene measures, considered in isolation, have similar effectiveness to vaccination because hygiene measures and vaccination aren't mutually exclusive options (in fact, I think you'll find that hospitals tend to mandate proper hygiene measures for patient care workers in addition to mandating flu vaccinations for those workers.)
Actually, social sciences are concerned with two questions, only one of which is scientific. The scientific question is: How do societies work. The non-scientific question is: How should societies work.
Actually, no. Social sciences are concerned with various aspects of the first question. The second question is a philosophical question which is outside the scope of the social sciences in the same way as the question "what should we do with the world's supply of fissionables" is outside the scope of nuclear physics.
Obviously, individual social scientists may be concerned with the second question and, moreover, once you determine a particular set of goals with regard to the second question, social science can provide insight as to the particular steps which are most likely to acheive the desired goals, just as once you have the performance requirements for an aircraft, materials science can provide insight as to what materials are most appropriate to build it out of given the requirements.
I don't think Kuhn was really thinking in terms of social sciences in his book. He was thinking of traditional science which is about using the scientific method of testing hypothesis with experiments. Depending on how you define "social science" I don't think there is a lot of objective experimentation going on.
Social sciences are pretty much exactly like other science; it doesn't have as much room for experiments confined to laboratories as some of the physical sciences, relying on other controls (e.g., statistical controls), but the mechanisms used here are pretty much the same as are used in physical sciences to study phenomenon that because of scale or conditions can't conveniently be studied in a lab.
They also often concern subjects where there is somewhat greater tendency to misrepresentation of profit-serving PR and ideological/religious doctrines as "science" in the popular media, but that's not unique to the social sciences (its notably seen in biology, cosmology, and climatology. )
Which is irrelevant from a legal perspective. If you don't protect your copyright (intellectual property), then you lose it. It can legally become public domain then -- not that such a thing has ever happened in our twisted and convoluted legal system, but in principle it could.
Well, no, it couldn't. Some forms of intellectual property have some kind of protect-it-or-lose-it rules (trademarks and patents both have rules that fall under that broad umbrella), but copyright doesn't. Copyright is automatic on creation and for the full duration that applies based on the form of creation, whether or not you actively protect it.
Can you point me to the part of HITECH that requires FIPS certification
It doesn't. What it does (at Section 13402) is require the Secretary of HHS to publish guidance on appropriate methods of securing data, and specifies that PHI not secured by technology consistent with the most-current issued guidance is considered "unsecured", and specifies a number of things that have to be done if "unsecured" PHI is exposed.
The guidance HHS has issued under the HITECH Act requires that encryption methods for data in motion be consistent with FIPS 140-2 (not that systems be certified under FIPS 140-2) in order for the data not to be considered "unsecured", and specifies other requirements for data at rest.
because the NIST checklist [nist.gov] still has the standard HIPAA style policy driven directives, not prescribed technical solutions. (section 164.312(a)(2)(iv))
All those still apply (and that reference not a section of HITECH -- or even HIPAA -- its the section of Title 45 of the Code of Federal Regulations for one piece of the regulations issued under HIPAA making up the Security Rule.)
Any large hospital would have fought this out in court and prevailed.
You mean, like the $1 million settlement Massachussetts General made in 2011 for HIPAA violations?
Banks, State Agencies, Military, Doctors and Clinics all over the country have data losses all the time, but
nobody gets fined.
Banks aren't covered by HIPAA. Most doctors and clinics are small-entities, and this case was noted as being the first significant penalty for a small entity under HIPAA. Cignet -- a big insurer -- paid a $4.3 million fine for HIPAA violations.
This exactly, much like SarbOx it's mostly a minimum framework for organizations to write their own policies (in fact HIPPA doesn't specify ANY technologies, only policies).
First, its HIPAA, not HIPPA.
Second, the "no technologies, only policies" statement used to be true, but hasn't been really true since the HITECH Act and related guidance/regulation modified the HIPAA Security Rule; there are specific technical requirements for data to be considered "secured". Its not required to actually meet those requirements, but there are consequences if unsecured data (that is, not secured by technology meeting the specified standards) is exposed to unauthorized parties.
Yet, HIPAA doesn't mandate the use of any specific technology, at all. FIPS is not mandated for use for HIPAA, the AC is dead wrong.
The HITECH Act, under which the guidance referred to was issued, specifies that the guidance issued under the act controls whether data is considered "secured" or "unsecured"; the various penalties and breach notification requirements in HIPAA apply to breaches of unsecured PHI. So, the guidance specifying particular methods is a mandate as to which methods of securing data must be used, at a minimum, to avoid triggering various consequences.
Its true that you can ignore that guidance as to particular methods and, if you never expose data (even encrypted data, if its not encrypted by one of the specified mechanims) to an authorized party even accidentally, never trigger the consequences under HIPAA.
Where in HIPAA does it state FIPS complaint encryption?
It doesn't say it in HIPAA (which is a statute). It says it in the guidance issued by HHS under the HITECH Act which sets standards for whether data is considered "unsecured" or "secured" under the HIPAA Security Rule (a regulation adopted to implemented HIPAA under the regulatory authority granted to the HHS by HIPAA).
And the "consistent with FIPS 140-2" is for data in motion, not data at rest, so it doesn't actually apply here; the data at rest standard is NIST SP 800-111.
See 72 FR 19006, 19009-19010.
There are exactly zero FIPS 140-2 software encryption products, as this level requires hardware.
HIPAA doesn't require a FIPS 140-2 validated product, it requires that, for data in motion, the encryption method is consistent with FIPS 140-2, and it specifically includes anything consistent with NIST SPs 800-52, 800-77, and 800-113.
For data at rest -- which what the issue is here with, e.g., Full Disk Encryption -- FIPS 140-2 isn't even discussed; the requirement is that the method be consistent with NIST SP 800-111.
FIPS 140-2 to be more specific. There are plenty of free options.
Are there? Last time I looked into FIPS 140, it was the case that only certain software versions were validated by NIST, and none of the validated incarnations were either free-beer or free-libre.
Well, first off, FIPS 140-2 is only specified as part of the requirement for data to be considered "secured" for data in motion under HIPAA (not data at rest, which is where FDE comes into play.)
Second, where FIPS 140-2 is relevant (data in motion) the HIPAA rule certainly accepts FIPS 140-2 validated systems, but what it requires is merely that the encryption method be consistent with FIPS 140-2, not that the system be FIPS 140-2 validated.
More specific, but not necessarily accurate. FIPS 140-2 is the requirement for data "in motion" (being transmitted via some communication channel.)
The requirements for encryption to be sufficient to not leave the data covered by it "unsecured" under HIPAA are methods consistent with NIST Special Publication 800–111, Guide to Storage Encryption Technologies for End User Devices.
If it worked, we wouldn't be reading this article. The data was lost despite government regulation. I don't care that the government made 50k off the deal.
The $50K isn't the important part of the deal, the important part is the corrective action plan. (TFA isn't particularly good, but see here.)
if i recall correctly from the hipaa rules, it isnt the hospice that is required to pay the fine, im pretty sure it is the employees responsible.
Both covered entities and individuals working in them can face criminal charges for certain HIPAA violations (which can include fines and jail time), there are also civil fines against covered entities possible for a wider range of violations. TFA clearly indicates that this is a fine as part of negotiated settlement between the government and the hospice, and that the hospice itself is paying the fine, though a better article is here.
Encryption is slow. If you have ever did healthcare data, there is just so much data that encryption can add hours to your tasks.
Yeah, I work with plenty of healthcare data, and every computer in my organization uses full-disk encryption, plus all our communications channels that handle healthcare data moving to or from the outside world are also encrypted. The encryption doesn't add noticeable time to tasks.
The reason that taxes are high in other nations is that there's a ratchet effect where it's easy for the government to raise taxes and increase spending, but forces within the government will fight against any attempt to reduce either of them, or to keep them low. So in the long run, taxes (and spending) just keep going up and up and up.
While the distribution of taxes between different particular federal taxes has varied considerably, overall US federal taxes have fluctuated between just over 20% and just under 15% of GDP in the period since 1945. It has not followed your description of "keep going up and up and up".
I mean, why should the United States of America resort to legal loopholes ?
The legal loophole may be necessary because Congress has both required the President to spend money by way of appropriation and failed to either raise taxes or raise the debt limit to provide the funds, but has given the Treasury carte blanche to mint unlimited platinum coinage.
How long do you think America can keep spending the money it doesn't have?
Pretty much forever, certainly its not a problem (but for things like self-imposed rules like the debt limit) right now, as evidence by the very low cost of government borrowing.
I mean, even if America get the minting of quadrillion-dollar plutonium ingot going, the world doesn't have to "buy" it.
The world is more than willing to buy US debt. The platinum coin loophole is about minting a coin to deposit with the Federal Reserve; no one would have to buy it.
All of us balance our own checkbook at the end of every single month, and try our best to live within our means.
Americans, as individuals, have combined about $1 trillion in delinquent (not total) debt last I saw figures (middle of last year, IIRC.) The government is much better at keeping its debts to the level at which it could pay -- at least, so far. Admittedly, those trying to force a debt-ceiling crisis are doing their best to change that.
That's so wrong. Imagine you are on the other end of this process, trying to use that code. You'll never be certain which combination of features exist and are supported and which have either been deleted or not implemented.
Just-in-Time development does not mean that the current state of the system isn't communicated to users, and nothing in GPs description implied that.
Doesn't evidence have to be credible to be accepted in a US court?
No, it needs to be legally admissible.
Credibility is assessed by the jury or court (depending on the type of proceeding) after the evidence has been accepted.
(Some assessment of probative value -- which relates to credibility -- may be made by the court in determining admissibility if there is a challenge to admissibility on some grounds, because probative value is a factor which weighs against certain bases for inadmissibility.)
Sometimes you need to leave a line like that in the code - else some programmer in 5 years time may attempt to put some more code in that does the same thing; being completely unaware of why that was taken out previously.
If the final code has something that is likely to look like a code smell to someone unfamiliar with why it is that way but which has a good reason -- whether as a result of deleting code or not -- it may be valuable to put a comment explaining the reasoning so that someone coming to the code has the value of whatever process got to the end result.
But that's not so much a comment about deleting the code (or adding, or whatever change made it the way it is -- and heck, it could be even the first version of the code, because the original programmer might have realized the right way), which is the process of how it got to be the way it is, as it is a comment about the current logic of the implementation.
No I feel you should comment it out for one version, or one iteration.
But that provides -- literally -- no value.
The problem with deleting code is that you lose functionality and information.
You lose exactly the same functionality as you do when commenting it out, and you lose no information at all if you are using version control, so neither of these concerns is a valid reason to prefer commenting-out over deleting.
Yes yes we have this ideal world where unit tests will ensure that the code only does what it is supposed to.
Unit tests aren't relevant here. The relevance is that deleting code from source files doesn't delete it from version control history, so if for some reason you need to recover the code, its still there.
Code that needs to be completely rewritten is crap code.
Not necessarily. "There is a better way to do it" doesn't mean the code is crap code, but sometimes the better way requires a complete rewrite.
And, of course, deleting code doesn't mean rewriting code. Sometimes, requirements have changed such that previously-required functionality is no longer required, and you aren't "rewriting" the code that provides that functionality, you are simply removing it.
Crap code is code that does many things, but quite a bit of it incorrectly.
Again, no. Even code that needs rewritten because it is of exceptionally poor quality can be of poor quality for reasons other than mixing concerns.
It also is hard to get a grip on because of its complexity.
That may be true of some crap code, but even where the code is hard to get a grip on because of its complexity, it doesn't mean the requirements are (even if they were for the author of the crap code, which may just have been because the requirements were unclearly or incorrectly specified at the time the original code was written, and they may be clearly specified now.)
Thus when you rewrite you are trying to simplify, and restructure.
Possibly.
And because you don't have a handle of the original code you are going to introduce bugs in the new code.
Having a handle on the old code isn't relevant to introducing bugs. Having a handle on the current requirements is, and old code that is "crap code" that "does quite a bit... incorrectly" is not likely to be the best resource in understanding those requirements.
These bugs are new cases that you have not thought about and thus need thinking about. They are not critical bugs since the rewritten code is easy to understand and easy to fix. BUT these bugs need to be cross referenced with the original code. You need to see if these bugs are bugs, or actually the correct answer.
The crap code that does things wrong isn't going to tell you if things are bugs or the correct answer, the requirements will tell you that. The crap code is, at most, going to tell you if the bugs were there before (of course, you can do the same thing by attempting to reproduce the bugs on the old build, and, in fact, if the problem is, as you suggest, that the old code is hard to understand -- and even if it is not -- the best way to tell if the bug is introduced with the code change or consistent with the prior behavior is to test with the old build, since that's a direct confirmation of the behavior, rather than what it appears from the code that the behavior would be.)
They wanted him for questioning, which is not extraditable by itself.
It is when your name is Julian Assange
Extradition isn't a matter of common universal norms, its a matter of particular treaties between particular countries, and the extradition treaty between the US and Belize is, surprisingly enough, not the one that governed Sweden seeking the extradition of Julian Assange from the UK.
.. and after posting this to his blog, he has a rather strong argument that he would be the victim of political persecution if sent back
After posting this, there's certainly a number of additional crimes in Belize (including a variety of frauds and acts of bribery that would seem to fall squarely within the scope of the extradition treaty) for which he has provided evidence -- in the form of a public admission -- against himself. As well as, I suspect, a number of violations of US law which have extraterritorial application.
And since he has accused the US government of being in league with Belize in the posts, I doubt he was won much leverage with the US authorities with the posting.
explain how he sidestepped a murder charge from a soverign nation
He didn't. He is a person of interested wanted for questioning, not a charged criminal. If he was a charged criminal, fleeing to the US wouldn't help, as the US has an extradition treaty with Belize that provides for the extradition of criminals charged with any of a wide array of crimes, including, naturally, as #1 on the list, murder.
There is nothing about this entire series of unfortunate events that shouldnt warrant immediate extradition to Belize
You mean, other than the fact that Belize hasn't criminally charged him with anything, much less anything subject to the extradition treaty with the US?
Unfortunately Mr McAfee wasnt found accused of these crimes in say, the Soviet Union or China
Or, for that matter, anywhere else. Because he hasn't actually been charged with any crimes, anywhere.
Slashdot Mirror
Given that hospitals do not have an infinite pool of on-demand skilled replacement labor for patient care positions, "reduces lost work time from staff contracting the flu" has a fairly direct impact on patient care.
And it really doesn't matter that hygiene measures, considered in isolation, have similar effectiveness to vaccination because hygiene measures and vaccination aren't mutually exclusive options (in fact, I think you'll find that hospitals tend to mandate proper hygiene measures for patient care workers in addition to mandating flu vaccinations for those workers.)
Actually, no. Social sciences are concerned with various aspects of the first question. The second question is a philosophical question which is outside the scope of the social sciences in the same way as the question "what should we do with the world's supply of fissionables" is outside the scope of nuclear physics.
Obviously, individual social scientists may be concerned with the second question and, moreover, once you determine a particular set of goals with regard to the second question, social science can provide insight as to the particular steps which are most likely to acheive the desired goals, just as once you have the performance requirements for an aircraft, materials science can provide insight as to what materials are most appropriate to build it out of given the requirements.
Its more an Agile or Lean approach than an Open Source one; its development methodology, not licensing structure, that is involved.
Social sciences are pretty much exactly like other science; it doesn't have as much room for experiments confined to laboratories as some of the physical sciences, relying on other controls (e.g., statistical controls), but the mechanisms used here are pretty much the same as are used in physical sciences to study phenomenon that because of scale or conditions can't conveniently be studied in a lab.
They also often concern subjects where there is somewhat greater tendency to misrepresentation of profit-serving PR and ideological/religious doctrines as "science" in the popular media, but that's not unique to the social sciences (its notably seen in biology, cosmology, and climatology. )
Well, no, it couldn't. Some forms of intellectual property have some kind of protect-it-or-lose-it rules (trademarks and patents both have rules that fall under that broad umbrella), but copyright doesn't. Copyright is automatic on creation and for the full duration that applies based on the form of creation, whether or not you actively protect it.
It doesn't. What it does (at Section 13402) is require the Secretary of HHS to publish guidance on appropriate methods of securing data, and specifies that PHI not secured by technology consistent with the most-current issued guidance is considered "unsecured", and specifies a number of things that have to be done if "unsecured" PHI is exposed. The guidance HHS has issued under the HITECH Act requires that encryption methods for data in motion be consistent with FIPS 140-2 (not that systems be certified under FIPS 140-2) in order for the data not to be considered "unsecured", and specifies other requirements for data at rest.
All those still apply (and that reference not a section of HITECH -- or even HIPAA -- its the section of Title 45 of the Code of Federal Regulations for one piece of the regulations issued under HIPAA making up the Security Rule.)
You mean, like the $1 million settlement Massachussetts General made in 2011 for HIPAA violations?
Banks aren't covered by HIPAA. Most doctors and clinics are small-entities, and this case was noted as being the first significant penalty for a small entity under HIPAA. Cignet -- a big insurer -- paid a $4.3 million fine for HIPAA violations.
First, its HIPAA, not HIPPA. Second, the "no technologies, only policies" statement used to be true, but hasn't been really true since the HITECH Act and related guidance/regulation modified the HIPAA Security Rule; there are specific technical requirements for data to be considered "secured". Its not required to actually meet those requirements, but there are consequences if unsecured data (that is, not secured by technology meeting the specified standards) is exposed to unauthorized parties.
The HITECH Act, under which the guidance referred to was issued, specifies that the guidance issued under the act controls whether data is considered "secured" or "unsecured"; the various penalties and breach notification requirements in HIPAA apply to breaches of unsecured PHI. So, the guidance specifying particular methods is a mandate as to which methods of securing data must be used, at a minimum, to avoid triggering various consequences. Its true that you can ignore that guidance as to particular methods and, if you never expose data (even encrypted data, if its not encrypted by one of the specified mechanims) to an authorized party even accidentally, never trigger the consequences under HIPAA.
It doesn't say it in HIPAA (which is a statute). It says it in the guidance issued by HHS under the HITECH Act which sets standards for whether data is considered "unsecured" or "secured" under the HIPAA Security Rule (a regulation adopted to implemented HIPAA under the regulatory authority granted to the HHS by HIPAA). And the "consistent with FIPS 140-2" is for data in motion, not data at rest, so it doesn't actually apply here; the data at rest standard is NIST SP 800-111. See 72 FR 19006, 19009-19010.
HIPAA doesn't require a FIPS 140-2 validated product, it requires that, for data in motion, the encryption method is consistent with FIPS 140-2, and it specifically includes anything consistent with NIST SPs 800-52, 800-77, and 800-113. For data at rest -- which what the issue is here with, e.g., Full Disk Encryption -- FIPS 140-2 isn't even discussed; the requirement is that the method be consistent with NIST SP 800-111.
Well, first off, FIPS 140-2 is only specified as part of the requirement for data to be considered "secured" for data in motion under HIPAA (not data at rest, which is where FDE comes into play.) Second, where FIPS 140-2 is relevant (data in motion) the HIPAA rule certainly accepts FIPS 140-2 validated systems, but what it requires is merely that the encryption method be consistent with FIPS 140-2, not that the system be FIPS 140-2 validated.
More specific, but not necessarily accurate. FIPS 140-2 is the requirement for data "in motion" (being transmitted via some communication channel.) The requirements for encryption to be sufficient to not leave the data covered by it "unsecured" under HIPAA are methods consistent with NIST Special Publication 800–111, Guide to Storage Encryption Technologies for End User Devices.
The $50K isn't the important part of the deal, the important part is the corrective action plan. (TFA isn't particularly good, but see here.)
Both covered entities and individuals working in them can face criminal charges for certain HIPAA violations (which can include fines and jail time), there are also civil fines against covered entities possible for a wider range of violations. TFA clearly indicates that this is a fine as part of negotiated settlement between the government and the hospice, and that the hospice itself is paying the fine, though a better article is here.
Yeah, I work with plenty of healthcare data, and every computer in my organization uses full-disk encryption, plus all our communications channels that handle healthcare data moving to or from the outside world are also encrypted. The encryption doesn't add noticeable time to tasks.
While the distribution of taxes between different particular federal taxes has varied considerably, overall US federal taxes have fluctuated between just over 20% and just under 15% of GDP in the period since 1945. It has not followed your description of "keep going up and up and up".
The legal loophole may be necessary because Congress has both required the President to spend money by way of appropriation and failed to either raise taxes or raise the debt limit to provide the funds, but has given the Treasury carte blanche to mint unlimited platinum coinage.
Pretty much forever, certainly its not a problem (but for things like self-imposed rules like the debt limit) right now, as evidence by the very low cost of government borrowing.
The world is more than willing to buy US debt. The platinum coin loophole is about minting a coin to deposit with the Federal Reserve; no one would have to buy it.
Americans, as individuals, have combined about $1 trillion in delinquent (not total) debt last I saw figures (middle of last year, IIRC.) The government is much better at keeping its debts to the level at which it could pay -- at least, so far. Admittedly, those trying to force a debt-ceiling crisis are doing their best to change that.
Just-in-Time development does not mean that the current state of the system isn't communicated to users, and nothing in GPs description implied that.
No, it needs to be legally admissible. Credibility is assessed by the jury or court (depending on the type of proceeding) after the evidence has been accepted. (Some assessment of probative value -- which relates to credibility -- may be made by the court in determining admissibility if there is a challenge to admissibility on some grounds, because probative value is a factor which weighs against certain bases for inadmissibility.)
If the final code has something that is likely to look like a code smell to someone unfamiliar with why it is that way but which has a good reason -- whether as a result of deleting code or not -- it may be valuable to put a comment explaining the reasoning so that someone coming to the code has the value of whatever process got to the end result.
But that's not so much a comment about deleting the code (or adding, or whatever change made it the way it is -- and heck, it could be even the first version of the code, because the original programmer might have realized the right way), which is the process of how it got to be the way it is, as it is a comment about the current logic of the implementation.
But that provides -- literally -- no value.
You lose exactly the same functionality as you do when commenting it out, and you lose no information at all if you are using version control, so neither of these concerns is a valid reason to prefer commenting-out over deleting.
Unit tests aren't relevant here. The relevance is that deleting code from source files doesn't delete it from version control history, so if for some reason you need to recover the code, its still there.
Not necessarily. "There is a better way to do it" doesn't mean the code is crap code, but sometimes the better way requires a complete rewrite. And, of course, deleting code doesn't mean rewriting code. Sometimes, requirements have changed such that previously-required functionality is no longer required, and you aren't "rewriting" the code that provides that functionality, you are simply removing it.
Again, no. Even code that needs rewritten because it is of exceptionally poor quality can be of poor quality for reasons other than mixing concerns.
That may be true of some crap code, but even where the code is hard to get a grip on because of its complexity, it doesn't mean the requirements are (even if they were for the author of the crap code, which may just have been because the requirements were unclearly or incorrectly specified at the time the original code was written, and they may be clearly specified now.)
Possibly.
Having a handle on the old code isn't relevant to introducing bugs. Having a handle on the current requirements is, and old code that is "crap code" that "does quite a bit ... incorrectly" is not likely to be the best resource in understanding those requirements.
The crap code that does things wrong isn't going to tell you if things are bugs or the correct answer, the requirements will tell you that. The crap code is, at most, going to tell you if the bugs were there before (of course, you can do the same thing by attempting to reproduce the bugs on the old build, and, in fact, if the problem is, as you suggest, that the old code is hard to understand -- and even if it is not -- the best way to tell if the bug is introduced with the code change or consistent with the prior behavior is to test with the old build, since that's a direct confirmation of the behavior, rather than what it appears from the code that the behavior would be.)
Extradition isn't a matter of common universal norms, its a matter of particular treaties between particular countries, and the extradition treaty between the US and Belize is, surprisingly enough, not the one that governed Sweden seeking the extradition of Julian Assange from the UK.
After posting this, there's certainly a number of additional crimes in Belize (including a variety of frauds and acts of bribery that would seem to fall squarely within the scope of the extradition treaty) for which he has provided evidence -- in the form of a public admission -- against himself. As well as, I suspect, a number of violations of US law which have extraterritorial application. And since he has accused the US government of being in league with Belize in the posts, I doubt he was won much leverage with the US authorities with the posting.
He didn't. He is a person of interested wanted for questioning, not a charged criminal. If he was a charged criminal, fleeing to the US wouldn't help, as the US has an extradition treaty with Belize that provides for the extradition of criminals charged with any of a wide array of crimes, including, naturally, as #1 on the list, murder.
You mean, other than the fact that Belize hasn't criminally charged him with anything, much less anything subject to the extradition treaty with the US?
Or, for that matter, anywhere else. Because he hasn't actually been charged with any crimes, anywhere.