The analogy fails for media because people still want media, and still want media to be created by media creators (writers, musicians, filmmakers, artists, producers, etc.).
For some media, that is true. For, e.g., newspapers (dead tree, especially, but overall, as well, even including the internet forms) all the evidence is that people increasingly don't want them. That's what it means when people aren't willing to pay for something. Sure, its a trend over time, and, sure, even in the end it probably won't lead to total elimination; but cars didn't replace horses and horse-drawn carriages as the dominant mode of transportation immediately, and even today horses and horse-drawn carriages have a niche.
So, no, news and reporters are not on par with monks who copied documents thousands of years ago. They are reporting news, and there is still value in, and demand for, that.
Actually, for quite a long time, cost cutting trends led to "news" outlets doing less and less discovery of the news and more and more serving as an uncritical relay for press releases and statements from interested parties. In the online age, even as a whitewashing tool to provide credibility, mass "news" media outlets are less necessary in that role, and the advertisers who are the prime revenue stream for mass "news" media aren't interested in paying the cost for news gathering.
Specialized media with a narrower, more engaged audience do gather information more critically, but they have always been distinct from the mass media.
I don't expect newspapers to be available for free on the internet--at least I don't expect anything that resembles the sunday print edition of the NYT to be there for free. The problem is that there is no effective way to charge for them the way there is for physical newspapers.
Charging for most physical general-audience newspapers is mostly just a way of getting statistics on people who probably actually read a significant portion of the newspaper (on the theory that they must be doing so if they are paying for it) so that newspaper publishers can sell ads; it isn't the main revenue stream. On the internet, there are better and more direct ways of tracking whether ads get seen and whether they work, which means there isn't a whole lot of reason to charge the readers (who are, after all, the main product the newspaper is selling) in addition to the advertisers (who are, even for print newspapers, the main customer the paper is serving and its main source of revenue.)
Regardless of what the answer is to this question, I am wondering if HTML 5 can provide most of the functionality of Javascript without posing as much of a security risk.
Javascript is mostly used for dynamic features, obviously, and HTML5 relies on Javascript for those. Canvas, for instance, requires Javascript (or, I suppose, some other client-side language) to actually draw on it; you can't even present a static drawing with Canvas without Javascript (unlike, e.g., SVG.)
HTML5 does more to increase what you can do with Javascript than to increase what you can do without Javascript.
Amazon published a white paper about using their AWS platform with HIPAA compient applications: basic idea is to keep data encrypted until it is in memory, and encrypt it again before writing to persistent storage.
And unless that white paper was published after (and took into account) this year's HITECH Act and the subsequent Guidance under that act, its probably leaves out a lot of critical concerns. Before the HITECH Act and the Guidance, there were basically no concrete, specific requirements that had to be met for HIPAA security compliance; there were vague requirements to protect data at rest and in motion, for instance, but no real standards on what protection was adequate. The HITECH Act and the Guidance issued under the Act specified fairly particularly what must be done with PHI for it not to be considered "unsecured", as well as imposing notice requirements when PHI is exposed "unsecured" and expanding who is legally responsible for violations of HIPAA security standards.
The blame will go to the DOCTOR not their online data service.
Or not: under HIPAA, anyone that a covered entity contracts with to handle PHI must be covered by a Business Associate Agreement, and under the HITECH Act passed earlier this year, HIPAA security noncompliance sanctions, including civil and criminal penalties available under HIPAA, apply to parties under BAA's exactly as they do to the covered entities themselves.
HIPAA makes no distinction between a compliance consultant and an IT consultant.
HIPAA doesn't have anything more than tangential to do with consultants. If you are being paid as an IT consultant, its not your job (and, unless you have unusual expertise outside of your field, not something you are qualified to do) to advise your client on legal requirements, whether HIPAA or anything else.
That's the *whole point of the law that is HIPAA.*
No, actually, its not; first of all, what you propose with regard to IT consultants responsibilities with regard to privacy isn't even part of the HIPAA or its associate rules, and second of all, privacy and security aren't even the whole (or even main) point of HIPAA. The main point of the Health Insurance Portability and Accountability Act is to make healthcare delivery more efficient and improve access to healthcare by both imposing mandates regarding the transferrability of health insurance, promoting the use of electronic transactions rather than paper to perform insurance-related functions, and mandating that those electronic transactions be in standardized formats to promote interoperability. The HIPAA privacy and security rules are secondary to that primary purpose; the exist largely to mitigate the fear of decreased privacy associated with electronic records that were, at the time HIPAA was adopted, seen as major barriers to public support for the adoption of the data systems HIPAA hoped to encourage the use of to streamline the administrative side of healthcare (they apply beyond the electronic data systems, of course, but that's their motivation.) The privacy and security rules are important HIPAA mandates, but they aren't the whole point of HIPAA.
If you're getting paid to work on a project related to health care and patient information, HIPAA requires you to be aware of the implications of information transmission.
No, in fact, it doesn't. If you are a contractor to a HIPAA covered entity (which it is the entities, not your, job to discover) and if you may be exposed to PHI in the course of that activity, HIPAA does require the entity itself to put you under a business associate agreement (BAA) that binds you to the requirements that apply to the covered entity with regard to protection of PHI. Additionally, the recently-passed HITECH Act makes the security requirements with regard to PHI directly binding on a contractor under a BAA to a covered entity (so, if you are considering taking a job that would require a HIPAA BAA, you have an obligation to understand the requirements of HIPAA with regard to PHI so that you can apply them to your own handling of PHI.)
But, it is not your job to tell your client what rules HIPAA imposes on them, its their job to tell you that as it applies to the requirements for the systems you are building for them. Once they have done so, it is your job to use your technical expertise to explain to them the implications particular implementation options have with regard to those requirements.
Giving legal advice is one thing. Bringing attention to areas of your expertise that carry implications for HIPAA is another.
Yes, exactly. Telling them what HIPAA requires them to do is the first. Telling them how various options impact the requirements they have communicated to you, including any that are based in HIPAA is the second. My point is that an IT consultant's job is to do the second, not the first.
What happens when your data contains \r or \n characters?
\r or \n aren't problems with proper CSV; \r\n combinations define record breaks, and can be included in data fields by enclosing them in double quotes.
What happens if the data has commas in it, and the.csv was generated by something that doesn't add quotes?
Then you should use something that generates proper CSV (which means it either uses quotes properly or doesn't allow anything that needs quoting in data fields.)
What do you do if your data is more complicated than a simple table?
You use more than one CSV file in some appropriate wrapper.
It matters because as long as GNU/Linux isn't standardised, and can subtly change behaviour between releases, you don't have a stable platform to target.
Sure, but the absence of UNIX-certified Linux isn't the same as Linux not having a stable standard that can be targetted. It just means that the standard isn't the Unix standard: the standard for Linux is the Linux Standard Base (LSB). While the LSB does have newer releases, newer versions support all earlier versions, so any version of the LSB targetted is a stable target.
That document is from 2005. Additional (and more detailed) specifications for requirements for PHI to not be considered "unsecured" were specified in Guidance issued this year under the authority of the HITECH Act (part of the American Recovery and Reinvestment Act of 2009), which also extended HIPAA's existing (and the Act's new) security requirements to business associates of HIPAA covered entities and not just the covered entities themselves.
I'd stress to them that HIPAA PHI standards require the company -- AKA your bosses -- to be able to vouch for the security of the entire pipeline of information flow.
Unless you are being paid as a HIPAA compliance consultant rather than an IT consultant, its not your job to tell them what HIPAA requires and, chances are, you don't really know what your client's status is under HIPAA and what the specific obligations they have under the various HIPAA rules. You certainly should raise the issue, if you think HIPAA or some other domain-specific privacy law applies to them, that it is out there and they have the responsibility to be certain that the business requirements they give you reflect their obligations under that law at any others that may apply, but you also shouldn't pretend to be qualified to advise them on what those rules are unless you really are competent to do that. If you aren't your client's lawyer, you shouldn't be giving them legal advice.
If a patient sues a provider because information leaked somehow, and it is discovered that information was obtained through HIPAA negelgence, the doctor's next question will most certainly be "Would you like to make it a combo meal?"
Seriously, the courts will strip him naked.
Well, except that HIPAA doesn't create a private cause of action which would allow a patient to sue in the first place.
However HIPAA only applies to what is considered 'PHI' - data applicable to individual patients relating to their health.
Specifically, the privacy and security provisions of HIPAA (which aren't the only mandates under HIPAA) are addressed specifically to the protection of PHI.
As far as I know, NO ONE HAS SUCCESFULLY SUED FOR HIPAA VIOLATIONS.
Since HIPAA doesn't create a private cause of action for violations, only the federal government can enforce HIPAA rules generally (sometimes, under state laws, the fact that a disclosure is in violation of a federal law like HIPAA, or of a assurance or agreement mandated by HIPAA, may, with other factors, meet the standard for some private cause of action under state law, but the action won't be for a HIPAA violation, per se.) To date, AFAIK, none of the HIPAA complaints received by the Department of Health and Human Services' Office of Civil Rights (which enforces HIPAA) have resulted in monetary penalties being assessed, but most of them do result in OCR requiring business practice changes on the part of the entity against whom the complaint was lodged. A few do get referred to the Department of Justice for criminal prosecution, though I believe that, to date, no prosecutions have been made on HIPAA charges alone (sometimes HIPAA charges have been part of a broader criminal complaint.)
But they are allowed to send your information to third parties to help "manage your health" or "process billing" or "collect payments" or all sorts of things.
These third parties ARE NOT REQUIRED to follow HIPAA, as they are considered non-covered entities. . This means once your info goes to billing for processing, your privacy is based on contracts with your provider and social embarrassment.
There was a time when that was at least generally true (where a business associate of a HIPAA covered entity might not be liable the way a covered entity was if it was not itself a covered entity), however, the recently passed HITECH Act (part of the American Recovery and Reinvestment Act of 2009 [ARRA], Pub.L. 111-5) both added additional security requirements that apply to HIPAA covered entities and extended both the existing and new security requirements on HIPAA covered entities, including the civil and criminal penalties for violations, to apply to those entities' business associates to the same extent as to covered entities themselves. (see ARRA, Title XIII, Subtitle D, Sec. 13401; codified at 42 U.S.C. Sec. 17931.)
you can use google apps without google docs. HIPAA is fine with it.
Maybe, maybe not. The HITECH Act (which is really part of the recent federal stimulus law, the American REcovery and Reinvestment Act) and the Guidance issued under the HITECH Act requires that for HIPAA protected health information (PHI) to not be considered "unsecured", information in motion must be protected under appropriate FIPS 140-2 approved standards (for use of TLS, that's NIST Special Publication 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations), which (as well as restricting which of the avaialable cipher suites for TLS are acceptable--notably, not RC4) also provides for the use of client certificates for authentication and states that server implementations should not accept connections without them, rather than falling back on alternative authentication mechanisms like username/password. The HITECH Act requirements, and the specific standards referred to in the guidance, are rather new as specific mandates with regard to HIPPA PHI, and I am rather suspicious of anyone who, without presenting any analysis, simply says that HIPAA raises no problems with Google Apps being used for HIPAA PHI.
I provide IT services for medium-sized medical and law practices. Lately I have been getting a lot of feedback from doctors and lawyers who use gmail at home and believe that they can run a significant portion of their practice IT on Google Apps. From a support standpoint, I'd be happy to chuck mail/calendar service management into the bin and let them run with gmail, but for these businesses, there is significant legal liability associated with the confidentiality of their communications and records (e.g., HIPPA). For those with high-profile celebrity clients, simply telling them 'Google employees can read your stuff' will usually end the conversation right there. But for smaller practices, I often get a lot of pushback in the form of 'What's wrong with trusting Google?' and 'Google's not interested in our email/calendar.' Weighing what they see as a tiny legal risk against the promise of Free IT Stuff(TM) becomes increasingly lopsided given the clear functionality / usability / ubiquity that they experience when using Google at home. So my question to the Slashdot community is: Are they right?
Maybe they are, and maybe they aren't. But here's the thing: you are being paid as an IT consultant, not a legal adviser or a compliance consultant. You need to ask what their requirements for security, privacy, etc., are, and, if they ask about using Google Apps to meet those needs, you should give your professional advice as to whether that service meets the requirements they have articulated to you. But you probably aren't qualified to tell them what their requirements are under HIPAA (not HIPPA) requirements, or any of the myriad of other specialized, domain-specific, privacy laws and regulations, or even to tell them which of those laws and regulations apply to them, and, if you aren't, you shouldn't hold yourself out as someone who can answer those questions for them.
Her lawyer is supposed to tell her that her case is frivolous, because there's no reasonable argument that the liability is the school's, not hers.
First of all, RTFA: she doesn't have a lawyer.
Second of all, schools often make representations about the degree of job-placement effort they will provide graduates as inducements to get people to enroll. To the extent that such representations are untrue, there may be liability for fraud. To the extent that such representations are included in agreements that are binding, there may be breach of contract issues. Without knowledge of both the specific facts of the case beyond what is reported in TFA and the law applicable in the jurisdiction, you can't say what her lawyer (if she had had one) should have told her about what course of action would be most appropriate.
There is no universal "theoretical minimum". There are estimates of what the level of unemployment is below which "undesirable" level of inflation is likely in particular economies at particular points in time. (And, mostly, these are the products of both subjectivity and guesswork.)
0.8% unemployment? 2%? Really? I know that sounds great, but that's no more healthy than 15% unemployment. In fact, if you really had that low of an unemployment rate, the rate of inflation would be through the roof as employers paid increasingly ridiculous salaries to try to fill positions. Such a low unemployment rate simply means you're lacking an employable workforce. You want there to constantly be people in transition otherwise the economy has no where to grow. That's just ECON 101.
Er, no, its not. Yes, its a fairly basic widespread understanding in that, for any given economy, there is some level of unemployment below which, absent countervailing factors, small decreases in unemployment result in large increases in inflation. Its also an equally basic understanding that those levels are not constant over time, and are not constant between different economies, and that there are a number of potential countervailing factors.
Simply having a different typical modality of transition would have a big effect on the full-employment unemployment rate. If employers are more prone (either for social or regulatory reasons) to give actual prior notice rather than immediate termination (with or without severance compensation), that is going to reduce the amount of transitional unemployment for the same labor mobility. If the workweek is shorter and more leave is available, this can make employee-initiated transitions more likely while employed (as it is easier to conduct a search for a new job while still doing the old one), which will also reduce the amount of transitional unemployment for the same labor mobility. And, of course, if an economy under analysis is part of a free trade region with liberal rules on internal mobility and employment, or has immigration rules well-constructed for the purpose, or both, it can have access to large pools of "outside" labor which provide the wage control (and hence, inflation-limiting) effects of higher unemployment without actually having higher internal unemployment.
Although it sounds horrible, keeping up with legislation being put forth is more than a full time job.
Which is why, of course, members of Congress each tend to have more than one person assigned to do that job; look at any representative or Senator's staff listing at legistorm or any similar site, and note the number of staffers with titles like "Legislative Director", "Legislative Correspondent", "Legislative Aide", "Legislative Assistant", "Legislative Research Assistant", etc.
High-level decision makers in any field make decisions based on brief decision papers prepared by the analysts working for them, not in-depth personal reading of the details of every proposal.
contrary to popular opinion, the big difference between lobbyists and ordinary voters isn't money (although money matters), it is access to information on a timely basis.
No, the two big differences are: 1) Access to professional analysis on a timely basis, and 2) Having legislators feel that you, as a single lobbyist, represent a coherent focussed interest that has the kind of influence that makes a difference in their electoral prospects (money is a part of this, but not the whole thing.)
This project manages to address neither part of that.
If they had priced it at $699 and taken a loss for the first year everybody would have gotten one.
No, they wouldn't have. Because much of their marketing hype pointed to the weaknesses of the product, though it recast them as strengths. When they said "cities will be redesigned for this", what they meant is "cities will have to be redesigned for this to have any use for most people".
And nothing about the Segway makes it worth the cost of redesigning cities around it.
By definition, if I bought it, I own it, yes.
For some media, that is true. For, e.g., newspapers (dead tree, especially, but overall, as well, even including the internet forms) all the evidence is that people increasingly don't want them. That's what it means when people aren't willing to pay for something. Sure, its a trend over time, and, sure, even in the end it probably won't lead to total elimination; but cars didn't replace horses and horse-drawn carriages as the dominant mode of transportation immediately, and even today horses and horse-drawn carriages have a niche.
Actually, for quite a long time, cost cutting trends led to "news" outlets doing less and less discovery of the news and more and more serving as an uncritical relay for press releases and statements from interested parties. In the online age, even as a whitewashing tool to provide credibility, mass "news" media outlets are less necessary in that role, and the advertisers who are the prime revenue stream for mass "news" media aren't interested in paying the cost for news gathering.
Specialized media with a narrower, more engaged audience do gather information more critically, but they have always been distinct from the mass media.
Charging for most physical general-audience newspapers is mostly just a way of getting statistics on people who probably actually read a significant portion of the newspaper (on the theory that they must be doing so if they are paying for it) so that newspaper publishers can sell ads; it isn't the main revenue stream. On the internet, there are better and more direct ways of tracking whether ads get seen and whether they work, which means there isn't a whole lot of reason to charge the readers (who are, after all, the main product the newspaper is selling) in addition to the advertisers (who are, even for print newspapers, the main customer the paper is serving and its main source of revenue.)
Javascript is mostly used for dynamic features, obviously, and HTML5 relies on Javascript for those. Canvas, for instance, requires Javascript (or, I suppose, some other client-side language) to actually draw on it; you can't even present a static drawing with Canvas without Javascript (unlike, e.g., SVG.)
HTML5 does more to increase what you can do with Javascript than to increase what you can do without Javascript.
And unless that white paper was published after (and took into account) this year's HITECH Act and the subsequent Guidance under that act, its probably leaves out a lot of critical concerns. Before the HITECH Act and the Guidance, there were basically no concrete, specific requirements that had to be met for HIPAA security compliance; there were vague requirements to protect data at rest and in motion, for instance, but no real standards on what protection was adequate. The HITECH Act and the Guidance issued under the Act specified fairly particularly what must be done with PHI for it not to be considered "unsecured", as well as imposing notice requirements when PHI is exposed "unsecured" and expanding who is legally responsible for violations of HIPAA security standards.
Or not: under HIPAA, anyone that a covered entity contracts with to handle PHI must be covered by a Business Associate Agreement, and under the HITECH Act passed earlier this year, HIPAA security noncompliance sanctions, including civil and criminal penalties available under HIPAA, apply to parties under BAA's exactly as they do to the covered entities themselves.
HIPAA doesn't have anything more than tangential to do with consultants. If you are being paid as an IT consultant, its not your job (and, unless you have unusual expertise outside of your field, not something you are qualified to do) to advise your client on legal requirements, whether HIPAA or anything else.
No, actually, its not; first of all, what you propose with regard to IT consultants responsibilities with regard to privacy isn't even part of the HIPAA or its associate rules, and second of all, privacy and security aren't even the whole (or even main) point of HIPAA. The main point of the Health Insurance Portability and Accountability Act is to make healthcare delivery more efficient and improve access to healthcare by both imposing mandates regarding the transferrability of health insurance, promoting the use of electronic transactions rather than paper to perform insurance-related functions, and mandating that those electronic transactions be in standardized formats to promote interoperability. The HIPAA privacy and security rules are secondary to that primary purpose; the exist largely to mitigate the fear of decreased privacy associated with electronic records that were, at the time HIPAA was adopted, seen as major barriers to public support for the adoption of the data systems HIPAA hoped to encourage the use of to streamline the administrative side of healthcare (they apply beyond the electronic data systems, of course, but that's their motivation.) The privacy and security rules are important HIPAA mandates, but they aren't the whole point of HIPAA.
No, in fact, it doesn't. If you are a contractor to a HIPAA covered entity (which it is the entities, not your, job to discover) and if you may be exposed to PHI in the course of that activity, HIPAA does require the entity itself to put you under a business associate agreement (BAA) that binds you to the requirements that apply to the covered entity with regard to protection of PHI. Additionally, the recently-passed HITECH Act makes the security requirements with regard to PHI directly binding on a contractor under a BAA to a covered entity (so, if you are considering taking a job that would require a HIPAA BAA, you have an obligation to understand the requirements of HIPAA with regard to PHI so that you can apply them to your own handling of PHI.)
But, it is not your job to tell your client what rules HIPAA imposes on them, its their job to tell you that as it applies to the requirements for the systems you are building for them. Once they have done so, it is your job to use your technical expertise to explain to them the implications particular implementation options have with regard to those requirements.
Yes, exactly. Telling them what HIPAA requires them to do is the first. Telling them how various options impact the requirements they have communicated to you, including any that are based in HIPAA is the second. My point is that an IT consultant's job is to do the second, not the first.
\r or \n aren't problems with proper CSV; \r\n combinations define record breaks, and can be included in data fields by enclosing them in double quotes.
Then you should use something that generates proper CSV (which means it either uses quotes properly or doesn't allow anything that needs quoting in data fields.)
You use more than one CSV file in some appropriate wrapper.
Sure, but the absence of UNIX-certified Linux isn't the same as Linux not having a stable standard that can be targetted. It just means that the standard isn't the Unix standard: the standard for Linux is the Linux Standard Base (LSB). While the LSB does have newer releases, newer versions support all earlier versions, so any version of the LSB targetted is a stable target.
That document is from 2005. Additional (and more detailed) specifications for requirements for PHI to not be considered "unsecured" were specified in Guidance issued this year under the authority of the HITECH Act (part of the American Recovery and Reinvestment Act of 2009), which also extended HIPAA's existing (and the Act's new) security requirements to business associates of HIPAA covered entities and not just the covered entities themselves.
Unless you are being paid as a HIPAA compliance consultant rather than an IT consultant, its not your job to tell them what HIPAA requires and, chances are, you don't really know what your client's status is under HIPAA and what the specific obligations they have under the various HIPAA rules. You certainly should raise the issue, if you think HIPAA or some other domain-specific privacy law applies to them, that it is out there and they have the responsibility to be certain that the business requirements they give you reflect their obligations under that law at any others that may apply, but you also shouldn't pretend to be qualified to advise them on what those rules are unless you really are competent to do that. If you aren't your client's lawyer, you shouldn't be giving them legal advice.
Well, except that HIPAA doesn't create a private cause of action which would allow a patient to sue in the first place.
Specifically, the privacy and security provisions of HIPAA (which aren't the only mandates under HIPAA) are addressed specifically to the protection of PHI.
Since HIPAA doesn't create a private cause of action for violations, only the federal government can enforce HIPAA rules generally (sometimes, under state laws, the fact that a disclosure is in violation of a federal law like HIPAA, or of a assurance or agreement mandated by HIPAA, may, with other factors, meet the standard for some private cause of action under state law, but the action won't be for a HIPAA violation, per se.) To date, AFAIK, none of the HIPAA complaints received by the Department of Health and Human Services' Office of Civil Rights (which enforces HIPAA) have resulted in monetary penalties being assessed, but most of them do result in OCR requiring business practice changes on the part of the entity against whom the complaint was lodged. A few do get referred to the Department of Justice for criminal prosecution, though I believe that, to date, no prosecutions have been made on HIPAA charges alone (sometimes HIPAA charges have been part of a broader criminal complaint.)
There was a time when that was at least generally true (where a business associate of a HIPAA covered entity might not be liable the way a covered entity was if it was not itself a covered entity), however, the recently passed HITECH Act (part of the American Recovery and Reinvestment Act of 2009 [ARRA], Pub.L. 111-5) both added additional security requirements that apply to HIPAA covered entities and extended both the existing and new security requirements on HIPAA covered entities, including the civil and criminal penalties for violations, to apply to those entities' business associates to the same extent as to covered entities themselves. (see ARRA, Title XIII, Subtitle D, Sec. 13401; codified at 42 U.S.C. Sec. 17931.)
Maybe, maybe not. The HITECH Act (which is really part of the recent federal stimulus law, the American REcovery and Reinvestment Act) and the Guidance issued under the HITECH Act requires that for HIPAA protected health information (PHI) to not be considered "unsecured", information in motion must be protected under appropriate FIPS 140-2 approved standards (for use of TLS, that's NIST Special Publication 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations), which (as well as restricting which of the avaialable cipher suites for TLS are acceptable--notably, not RC4) also provides for the use of client certificates for authentication and states that server implementations should not accept connections without them, rather than falling back on alternative authentication mechanisms like username/password. The HITECH Act requirements, and the specific standards referred to in the guidance, are rather new as specific mandates with regard to HIPPA PHI, and I am rather suspicious of anyone who, without presenting any analysis, simply says that HIPAA raises no problems with Google Apps being used for HIPAA PHI.
Maybe they are, and maybe they aren't. But here's the thing: you are being paid as an IT consultant, not a legal adviser or a compliance consultant. You need to ask what their requirements for security, privacy, etc., are, and, if they ask about using Google Apps to meet those needs, you should give your professional advice as to whether that service meets the requirements they have articulated to you. But you probably aren't qualified to tell them what their requirements are under HIPAA (not HIPPA) requirements, or any of the myriad of other specialized, domain-specific, privacy laws and regulations, or even to tell them which of those laws and regulations apply to them, and, if you aren't, you shouldn't hold yourself out as someone who can answer those questions for them.
First of all, RTFA: she doesn't have a lawyer.
Second of all, schools often make representations about the degree of job-placement effort they will provide graduates as inducements to get people to enroll. To the extent that such representations are untrue, there may be liability for fraud. To the extent that such representations are included in agreements that are binding, there may be breach of contract issues. Without knowledge of both the specific facts of the case beyond what is reported in TFA and the law applicable in the jurisdiction, you can't say what her lawyer (if she had had one) should have told her about what course of action would be most appropriate.
There is no universal "theoretical minimum". There are estimates of what the level of unemployment is below which "undesirable" level of inflation is likely in particular economies at particular points in time. (And, mostly, these are the products of both subjectivity and guesswork.)
Er, no, its not. Yes, its a fairly basic widespread understanding in that, for any given economy, there is some level of unemployment below which, absent countervailing factors, small decreases in unemployment result in large increases in inflation. Its also an equally basic understanding that those levels are not constant over time, and are not constant between different economies, and that there are a number of potential countervailing factors.
Simply having a different typical modality of transition would have a big effect on the full-employment unemployment rate. If employers are more prone (either for social or regulatory reasons) to give actual prior notice rather than immediate termination (with or without severance compensation), that is going to reduce the amount of transitional unemployment for the same labor mobility. If the workweek is shorter and more leave is available, this can make employee-initiated transitions more likely while employed (as it is easier to conduct a search for a new job while still doing the old one), which will also reduce the amount of transitional unemployment for the same labor mobility. And, of course, if an economy under analysis is part of a free trade region with liberal rules on internal mobility and employment, or has immigration rules well-constructed for the purpose, or both, it can have access to large pools of "outside" labor which provide the wage control (and hence, inflation-limiting) effects of higher unemployment without actually having higher internal unemployment.
And why shouldn't spending on a new weapon system be included in a bill whose other provisions relate mostly to the arts?
"X shouldn't be done just like Y shouldn't be done" isn't really useful without a clear reason why Y is undesirable.
What agencies?
Which is why, of course, members of Congress each tend to have more than one person assigned to do that job; look at any representative or Senator's staff listing at legistorm or any similar site, and note the number of staffers with titles like "Legislative Director", "Legislative Correspondent", "Legislative Aide", "Legislative Assistant", "Legislative Research Assistant", etc.
High-level decision makers in any field make decisions based on brief decision papers prepared by the analysts working for them, not in-depth personal reading of the details of every proposal.
No, the two big differences are:
1) Access to professional analysis on a timely basis, and
2) Having legislators feel that you, as a single lobbyist, represent a coherent focussed interest that has the kind of influence that makes a difference in their electoral prospects (money is a part of this, but not the whole thing.)
This project manages to address neither part of that.
No, they wouldn't have. Because much of their marketing hype pointed to the weaknesses of the product, though it recast them as strengths. When they said "cities will be redesigned for this", what they meant is "cities will have to be redesigned for this to have any use for most people".
And nothing about the Segway makes it worth the cost of redesigning cities around it.
Patent issues are addressed directly by the GPLv2, in section 7.