With the US government, though, it isn't simply a matter of the government deciding that "all clinics/doctors/hospitals/etc. shall do X, and thus it shall be". Because, if the government MANDATED that all clinics/doctors/hospitals/whatever shall do X, then the government would as a side-effect have to figure out how to ENABLE this mandate to work. Which they can't do right now, because so much of the data in the system is of proprietary origin (drug IDs, care plan information, etc.) By using a carrot-and-stick approach, then they can assert that these requirements are not MANDATES, they're merely "suggestions" that end-users can theoretically determine if they really want to meet -- even if failing to meet the criteria would place the end-user organization under a punitive competitive disadvantage. So, by not being mandates per se, then the government doesn't need to enable/fund/whatever the required effort. So now the end-users get to run around and try to figure out how to meet these requirements on their own, to determine which commercial medical records they feel will be viable in a high-change environment, and to try to pay for all of this technology (software costs of which can easily approach or exceed $5000/year/licensed user, not to mention additional hardware and environmental/logistical requirements), all while attempting to adhere to more stringent HIPAA privacy rules and the upcoming Red Flag reporting requirements. A cakewalk, really.
What we say here in our corner of the medical IT world: "Medicare uses the carrot-and-stick approach. First, they beat you with a stick. And if that doesn't work, they beat you with a carrot."
I feel your pain. We are a closely-held corporation (it's for-profit, but the docs own the place so they set the priorities), and we're now looking at commercial EMR software costs in the neighborhood of $12,000/physician to license a system, $2400/physician annual maintenance, plus all of the necessary hardware, etc. The hardware cost is a gimme (obviously), as is the implementation effort, but paying a couple million for software plus 400k/year maintenance stings a bit. Especially when you consider that our current home-brewed EMR is working well enough for us to want to limp along for another 5-7 years while letting the commercial EMR scene shake out a bit, but since our EMR misses a few CCHIT checkboxes, it won't qualify for any federal funding (or avoid the upcoming penalties) that HITECH offers. So, after planning for and funding a 10-year commitment to our current EMR, we're looking at being forced to drop it 4-5 years in just to avoid penalties that didn't exist 3 months ago. Bah.
Healthcare is dominated by application vendors who each make their own megaplatform for healthcare records. Cerner, Meditech, Siemens, et al. are all trying to keep as much of their system closed as possible, and aren't particularly interested in opening it up to third party systems. They don't particularly want open interfaces, their goal is to keep their customer locked in as much as possible.
So the healthcare IT companies get what they want, i.e. a bigger push for electronic records, selling the software they already have.
In my experience, you are right on-target with your assertions.
In fact, it seems that the "Health Information Technology for Economic and Clinical Health" or HITECH Act (PDF warning) leaves as many questions unanswered as it answers. What we do know: We involved in healthcare have the opportunity to qualify for incentive pay based on "meaningful use" of a "qualified" electronic healtcare record. Unfortunately, what "meaningful use" is, or what "qualifies" an EHR system is conveniently not addressed by the bill. We ASSUME that "qualification" means "certification under specs provided by the Certification Commission for Healthcare Information Technology (CCHIT)"...and that SEEMS to be a fair assumption.
So, what does "certification" under CCHIT consist of? Basically, it seems to be likened to a laundry-list of requirements that are best described as "what the megaplatforms already do". Funny how that works out, until you start looking at the CCHIT decision-makers, e.g. Siemens and NextGen have members on the CCHIT Commission. Allscripts has a member who is a Trustee. And guess what? The Siemens, NextGen and Allscripts products all passed the CCHIT certification without requiring major rework. And other large vendors (e.g. GE, Epic) have representation and input to the CCHIT decision making process. And to add to the pain of trying to avoid one of the "big systems", the CCHIT certification requirements can be punitive for small or one-off vendors...certification costs are start at $35,000 (PDF warning), retesting requires additional payment, and 2-year recertification is mandatory. Not a big problem for a megacorp, but crushing to a small outfit that has written a non-commercial EMR.
What is truly galling, though, is a myopic refusal to realize that yes, there is life outside of a monolithic EMR. Example: In the CCHIT requirements for clinical testing, there are requirements that lay out in annoying detail how e.g. Lab tests must be ordered, tracked, commented upon, and displayed directly in the EMR itself. There is no recognition that there is any other way to accomplish this outside of the EMR. However, for decades -- long before we moved our health records to electronic format -- we used our Practice Management (scheduling, billing, etc.) system to order Lab, to check for duplicate orders, to ensure that referrals exist when required, to enforce insurance eligibility requirements, etc. NONE of which qualifies for ANYTHING under the CCHIT rules -- under those rules, your EMR must do the order, the tracking, the duplicate checking, etc. So - in order to make our EMR comply with these CCHIT requirements, we would have to pull these activities out of our Scheduling system, and force them into an EMR system which does not, and can not, handle all of the insurance- and billing-driven requirements that our Practice Management system easily fulfills. Patient satisfaction, and ultimately Quality, will be negatively impacted by such a move. But we have little choice but to do so under these CCHIT "requirements" if we are to qualify for any of the HITECH incentives (or more to the point -- avoid the penalties that kick in later in the project).
Another thing that gripes me is the way that this inc
To my limited knowledge, that program is legitmately delivered in a LiveUpdate package.
The topics are deleted because it appears that somebody is abusing this system and some legitimate posts may be the collateral damage associated with dealing with this abuse.
To my limited knowledge, that program is legitmately delivered in a LiveUpdate package.
The topics are deleted because it appears that somebody is abusing this system and some legitimate posts may be the collateral damage associated with dealing with this abuse.
S MYNODE=^SOMEGLOBAL(INDEX1,INDEX2)
S MYVAR=$P(MYNODE,"^",1)
S MYVAR=MYVAR+" BET YOU THOUGHT THIS WAS GOING TO BE MATH, DIDN'T YOU?"
S $P(MYNODE,"^",1)=MYVAR
S ^SOMEGLOBAL(INDEX1,INDEX2)=MYNODE
Wow...we never opened OR closed a file, but the next time I reference ^SOMEGLOBAL referenced by INDEX1, INDEX2, darned if the first up-arrow delimited piece of the returned value doesn't have the string "BET YOU THOUGHT..." appended to it. MUMPS (err...ummm...Cache...) must be a really advanced language if it's already doing this "Phantom" stuff already.
(In reference to the above: Slashdot really needs a "sarcasm" tag...)
I don't ever come close to that on my charter account, but I would hope that if I did hit the cap, instead of cutting me off, Charter would simply drop me down to 256kb/s. Painful, but still usable.
Ahhh...but they can't make money CHARGING you for that, can they?
It's not just the format that kills you...it's the dataset, too.
Fat lot of good it does for the government to list a set of specs, when at the same time they don't list a means for actually encoding the content of those specs. Something simple, like drugs in a drug database, can cause all sorts of havoc when you realize that the only freely-available standardized coding scheme (NDC) doesn't so much identify drugs as it does specify an exact drug, manufacturer, package type, and quantity. In other words, aspirin isn't aspirin, it's "Easprin Tablets, 975mg, tablets, 100-count, bottle, oral, NDC 10802-9757-*1". Yes, that's a correct spelling of "Easprin", and that's an "asterisk 1", just to make things interesting. Not quite the same as (somehow) identifying that the patient is taking "aspirin".
Now, there are multiple PROPRIETARY databases out there to identify these drugs, but fat lot of good it does to try to communicate those identifiers to someone else if they don't use the exact-same PROPRIETARY database that you do. Or if the wording of the drug description in THEIR proprietary database doesn't exactly match the wording description in the one that you're using. Or whatever.
In fact, some companies (SureScripts being one) have acknowledged the shortcoming by asking providers to provide a "representative NDC" in order to identify the med that you're trying to communicate in an e-script. So, you write a script for "generic drug foo", but you send a "representative NDC" that specifies drug "bar", which is an equivalent of "foo", and which has a specific NDC. The pharmacy fills the script using the "representative NDC" to help them determine which actual packaged drug (and therefore which NDC) they are going to dispense--let's call that "meh". Then, when they eventually ask for a refill, they ask for a refill of "meh", which you sent as "bar", when what you really wanted to give the patient was simply "foo". Confused yet?
So, it's not simply a matter of defining a data exchange format...we still have to figure out how to commonly define what "it" is that we're actually exchanging in the first place.
Add in the difficulties in trying to determine what "problems" a patient may actually have (is one diagnosis of hypertension indicative of an ongoing problem? Was it secondary to another acute condition? Was it a mistake?), the dilemma of possible mis-use of the information by employers, insurance companies, or even government agencies, and the somewhat-fundamental problem of needing some way to globally identify the patient in the first place (by law we can't use SSN--and heck, in a college town, many of the students/patients don't even HAVE a Social Security Number), a national heathcare ID number does not yet exist, and even if it DID exist there would be a huge bureaucracy around securing this number and the information that it points to...
Nope, just having an agreed-upon format for sending records back&forth doesn't really solve the entire problem. It's a valid first step, agreed, but once the format has been loosely defined, determining what goes in the fields of those formats...THAT is when things can get "interesting".
I certainly agree. Having results returned, sequestered as they are in an area with a colored background along with a label that (very deceptively) states that these are "Sponsored Links", most certainly gives the user no indication that these URLs are in any way special.
Given taxi meters and electricity meters both have tamper seals, you would have thought that these would have visible tamper seals as well. If in doubt you could even have two tamper seals: one from Diebold and another from the voting commission, in order to ensure that both parties are satisfied with the state of the machine..
Hmmm...so what happens when someone DOES tamper with a "tamper seals", then? Are all the votes in the machine immediately suspect? Why or why not?
I mean...how long would it take a non-majority-party voter who isn't happy with the way that the voting in his/her precinct is going to decide to cause trouble by doing a little "non-violent protest" when alone in the booth?
For wanting to go in together with Yahoo, this seems like the wrong start for a good relationship.
1. Offer to "partner" with successful company.
2. Cut legs out from under "partner". Absorb all of "partner's" customers.
3. ???
4. Profit. Maybe - or maybe not. It doesn't matter. All that matters is that a non-Microsoft company which was once making money off of computers now isn't.
Hmmm...is this a copy-and-paste directly from the man's email?
"...To be fair, though, you can't expect a bunch of gamers to understand the satire if they think that Jonathon Swift, the author of 'A Modest Proposal,' is the name of a new Nike running shoe..."
...If so, he may be right, then. I'm pretty sure that most uf us that do know actually think that Jonathan Swift wrote "A Modest Proposal". And, for all I know, maybe there really *are* running shoes by that name?
320,000 accounts on a single iSeries? Child's play. I doubt that IBM is only on "one box" though, given the wide-ranging network that Big Blue maintains.
1 million total users at 99.9% uptime as per the original request? Not exactly "child's play", but honestly, not much harder
Domino on iSeries does seem to be a reasonable option for a deployment of this size, especially given the rather generous uptime allocation that is being offered..."3 nines" being EXTREMELY generous for an iSeries shop (you'd even be able to schedule monthly downtme on purpose and still meet this uptime goal.)
I do note that IBM has benchmarked Domino on a 16-way Power5-based iseries at a 33ms response time for 175,000 concurrent users (details here: http://www-03.ibm.com/servers/eserver/iseries/domi no/scalerecord.html)...and given the limited usage pattern of POP3 (yuck!), a properly-deployed solution should be able to meet the published needs with just one server. AND provide backup. AND enable the user to restore an individual mail store, mail box, or object on-demand. If high-availability or higher performance is necessary, 2 servers could be deployed in several different configurations (mirrors, clusters, HA failover, etc.).
And if the moans of "Outlook-only users" get to be too much of a problem, IBM offers a "connector" that can offer MAPI access to Domino's mail store.
Hell yes, I'm an iSeries fanboy. Those machines have proven themselves to be reliable, capable, economical systems over the long haul. Now, while (due to price) I wouldn't suggest deploying an iSeries to be a simple file, print, web, or small-database server, true...but when you need to move freight and *lots* of it, but you don't want to spend hours every week in operating and administering the system, it's hard to beat the venerable System/38 ne AS/400 ne iSeries systems.
Video and audio recordings of BPL interference in the Americas, Europe, Asia, etc.
It's not just the HAMs fighting this...many emergency response teams still rely on older, lower-frequency, long-range communication networks (instead of the relatively short-range digital networks of municipal locales), and the interference to those services is as disruptive to their systems as this "noise" is to Amateur Radio.
That's quite a stretch, CowboyNeal, somehow turning "This Account Has Been Suspended / Please contact the billing/support department as soon as possible." into "HardOCP Wins BIG against Infinium Labs". Maybe I don't have the right one-time encryption pad?
It's not pining, it's passed on. This webserver is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late webserver. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to an IP address, it would be pushing up the daisies. It's rung down the curtain and joined the choir invisible. This is an ex-webserver.
Slashdot Mirror
What we say here in our corner of the medical IT world: "Medicare uses the carrot-and-stick approach. First, they beat you with a stick. And if that doesn't work, they beat you with a carrot."
OK, here's one to refresh your memory.
No, they haven't changed that much.
I feel your pain. We are a closely-held corporation (it's for-profit, but the docs own the place so they set the priorities), and we're now looking at commercial EMR software costs in the neighborhood of $12,000/physician to license a system, $2400/physician annual maintenance, plus all of the necessary hardware, etc. The hardware cost is a gimme (obviously), as is the implementation effort, but paying a couple million for software plus 400k/year maintenance stings a bit. Especially when you consider that our current home-brewed EMR is working well enough for us to want to limp along for another 5-7 years while letting the commercial EMR scene shake out a bit, but since our EMR misses a few CCHIT checkboxes, it won't qualify for any federal funding (or avoid the upcoming penalties) that HITECH offers. So, after planning for and funding a 10-year commitment to our current EMR, we're looking at being forced to drop it 4-5 years in just to avoid penalties that didn't exist 3 months ago. Bah.
In my experience, you are right on-target with your assertions. In fact, it seems that the "Health Information Technology for Economic and Clinical Health" or HITECH Act (PDF warning) leaves as many questions unanswered as it answers. What we do know: We involved in healthcare have the opportunity to qualify for incentive pay based on "meaningful use" of a "qualified" electronic healtcare record. Unfortunately, what "meaningful use" is, or what "qualifies" an EHR system is conveniently not addressed by the bill. We ASSUME that "qualification" means "certification under specs provided by the Certification Commission for Healthcare Information Technology (CCHIT)"...and that SEEMS to be a fair assumption.
So, what does "certification" under CCHIT consist of? Basically, it seems to be likened to a laundry-list of requirements that are best described as "what the megaplatforms already do". Funny how that works out, until you start looking at the CCHIT decision-makers, e.g. Siemens and NextGen have members on the CCHIT Commission. Allscripts has a member who is a Trustee. And guess what? The Siemens, NextGen and Allscripts products all passed the CCHIT certification without requiring major rework. And other large vendors (e.g. GE, Epic) have representation and input to the CCHIT decision making process. And to add to the pain of trying to avoid one of the "big systems", the CCHIT certification requirements can be punitive for small or one-off vendors...certification costs are start at $35,000 (PDF warning), retesting requires additional payment, and 2-year recertification is mandatory. Not a big problem for a megacorp, but crushing to a small outfit that has written a non-commercial EMR.
What is truly galling, though, is a myopic refusal to realize that yes, there is life outside of a monolithic EMR. Example: In the CCHIT requirements for clinical testing, there are requirements that lay out in annoying detail how e.g. Lab tests must be ordered, tracked, commented upon, and displayed directly in the EMR itself. There is no recognition that there is any other way to accomplish this outside of the EMR. However, for decades -- long before we moved our health records to electronic format -- we used our Practice Management (scheduling, billing, etc.) system to order Lab, to check for duplicate orders, to ensure that referrals exist when required, to enforce insurance eligibility requirements, etc. NONE of which qualifies for ANYTHING under the CCHIT rules -- under those rules, your EMR must do the order, the tracking, the duplicate checking, etc. So - in order to make our EMR comply with these CCHIT requirements, we would have to pull these activities out of our Scheduling system, and force them into an EMR system which does not, and can not, handle all of the insurance- and billing-driven requirements that our Practice Management system easily fulfills. Patient satisfaction, and ultimately Quality, will be negatively impacted by such a move. But we have little choice but to do so under these CCHIT "requirements" if we are to qualify for any of the HITECH incentives (or more to the point -- avoid the penalties that kick in later in the project).
Another thing that gripes me is the way that this inc
And now it's back up. Seems to be missing a few threads, though...funny, that.
Hmmm...and now attempts to view the Norton forums either fail, or serve a "down for maintenance" screen. How...convenient.
Sounds like MUMPS (err..ummm...Cache?) to me....
S MYNODE=^SOMEGLOBAL(INDEX1,INDEX2)
S MYVAR=$P(MYNODE,"^",1)
S MYVAR=MYVAR+" BET YOU THOUGHT THIS WAS GOING TO BE MATH, DIDN'T YOU?"
S $P(MYNODE,"^",1)=MYVAR
S ^SOMEGLOBAL(INDEX1,INDEX2)=MYNODE
Wow...we never opened OR closed a file, but the next time I reference ^SOMEGLOBAL referenced by INDEX1, INDEX2, darned if the first up-arrow delimited piece of the returned value doesn't have the string "BET YOU THOUGHT..." appended to it. MUMPS (err...ummm...Cache...) must be a really advanced language if it's already doing this "Phantom" stuff already.
(In reference to the above: Slashdot really needs a "sarcasm" tag...)
I don't ever come close to that on my charter account, but I would hope that if I did hit the cap, instead of cutting me off, Charter would simply drop me down to 256kb/s. Painful, but still usable.
Ahhh...but they can't make money CHARGING you for that, can they?
It's not just the format that kills you...it's the dataset, too.
Fat lot of good it does for the government to list a set of specs, when at the same time they don't list a means for actually encoding the content of those specs. Something simple, like drugs in a drug database, can cause all sorts of havoc when you realize that the only freely-available standardized coding scheme (NDC) doesn't so much identify drugs as it does specify an exact drug, manufacturer, package type, and quantity. In other words, aspirin isn't aspirin, it's "Easprin Tablets, 975mg, tablets, 100-count, bottle, oral, NDC 10802-9757-*1". Yes, that's a correct spelling of "Easprin", and that's an "asterisk 1", just to make things interesting. Not quite the same as (somehow) identifying that the patient is taking "aspirin".
Now, there are multiple PROPRIETARY databases out there to identify these drugs, but fat lot of good it does to try to communicate those identifiers to someone else if they don't use the exact-same PROPRIETARY database that you do. Or if the wording of the drug description in THEIR proprietary database doesn't exactly match the wording description in the one that you're using. Or whatever.
In fact, some companies (SureScripts being one) have acknowledged the shortcoming by asking providers to provide a "representative NDC" in order to identify the med that you're trying to communicate in an e-script. So, you write a script for "generic drug foo", but you send a "representative NDC" that specifies drug "bar", which is an equivalent of "foo", and which has a specific NDC. The pharmacy fills the script using the "representative NDC" to help them determine which actual packaged drug (and therefore which NDC) they are going to dispense--let's call that "meh". Then, when they eventually ask for a refill, they ask for a refill of "meh", which you sent as "bar", when what you really wanted to give the patient was simply "foo". Confused yet?
So, it's not simply a matter of defining a data exchange format...we still have to figure out how to commonly define what "it" is that we're actually exchanging in the first place.
Add in the difficulties in trying to determine what "problems" a patient may actually have (is one diagnosis of hypertension indicative of an ongoing problem? Was it secondary to another acute condition? Was it a mistake?), the dilemma of possible mis-use of the information by employers, insurance companies, or even government agencies, and the somewhat-fundamental problem of needing some way to globally identify the patient in the first place (by law we can't use SSN--and heck, in a college town, many of the students/patients don't even HAVE a Social Security Number), a national heathcare ID number does not yet exist, and even if it DID exist there would be a huge bureaucracy around securing this number and the information that it points to...
Nope, just having an agreed-upon format for sending records back&forth doesn't really solve the entire problem. It's a valid first step, agreed, but once the format has been loosely defined, determining what goes in the fields of those formats...THAT is when things can get "interesting".
Next thing you know, they'll sic their lawyers on folks selling "organizers".
We have a whole building full of Windows XP machines here using Active Directory. I won't say it's trouble-free, but...never mind.
I certainly agree. Having results returned, sequestered as they are in an area with a colored background along with a label that (very deceptively) states that these are "Sponsored Links", most certainly gives the user no indication that these URLs are in any way special.
Oblig link: Pregnancy Test
I mean...how long would it take a non-majority-party voter who isn't happy with the way that the voting in his/her precinct is going to decide to cause trouble by doing a little "non-violent protest" when alone in the booth?
"First" it was Nintendo?
Ahh...all the times we'd get together to "play Atari" forgotten...
1. Offer to "partner" with successful company.
2. Cut legs out from under "partner". Absorb all of "partner's" customers.
3. ???
4. Profit. Maybe - or maybe not. It doesn't matter. All that matters is that a non-Microsoft company which was once making money off of computers now isn't.
It's because you forgot to subtract the number of domain names that their registrants are already paying for, you fool! (grin)
1 million total users at 99.9% uptime as per the original request? Not exactly "child's play", but honestly, not much harder
Domino on iSeries does seem to be a reasonable option for a deployment of this size, especially given the rather generous uptime allocation that is being offered..."3 nines" being EXTREMELY generous for an iSeries shop (you'd even be able to schedule monthly downtme on purpose and still meet this uptime goal.)
I do note that IBM has benchmarked Domino on a 16-way Power5-based iseries at a 33ms response time for 175,000 concurrent users (details here: http://www-03.ibm.com/servers/eserver/iseries/domi no/scalerecord.html)...and given the limited usage pattern of POP3 (yuck!), a properly-deployed solution should be able to meet the published needs with just one server. AND provide backup. AND enable the user to restore an individual mail store, mail box, or object on-demand. If high-availability or higher performance is necessary, 2 servers could be deployed in several different configurations (mirrors, clusters, HA failover, etc.).
And if the moans of "Outlook-only users" get to be too much of a problem, IBM offers a "connector" that can offer MAPI access to Domino's mail store.
Hell yes, I'm an iSeries fanboy. Those machines have proven themselves to be reliable, capable, economical systems over the long haul. Now, while (due to price) I wouldn't suggest deploying an iSeries to be a simple file, print, web, or small-database server, true...but when you need to move freight and *lots* of it, but you don't want to spend hours every week in operating and administering the system, it's hard to beat the venerable System/38 ne AS/400 ne iSeries systems.
http://www.arrl.org/tis/info/HTML/plc/aud-vid.html
Video and audio recordings of BPL interference in the Americas, Europe, Asia, etc.
It's not just the HAMs fighting this...many emergency response teams still rely on older, lower-frequency, long-range communication networks (instead of the relatively short-range digital networks of municipal locales), and the interference to those services is as disruptive to their systems as this "noise" is to Amateur Radio.
That's quite a stretch, CowboyNeal, somehow turning "This Account Has Been Suspended / Please contact the billing/support department as soon as possible." into "HardOCP Wins BIG against Infinium Labs". Maybe I don't have the right one-time encryption pad?
It's not pining, it's passed on. This webserver is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late webserver. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to an IP address, it would be pushing up the daisies. It's rung down the curtain and joined the choir invisible. This is an ex-webserver.
Most folks are 70% correct, at least 30% of the time.