| Contact Us | CHT | Mobile | Wechat | Weibo | Search:
Welcome Visitors | 登录 | 免费注册 | 忘记了密码 | 社交账号注册或登录

Home

News

Forums

Realty

大温餐馆点评

Car

Education

Yellow Page

Travel

印还掩盖新冠噩梦 全世界都要遭殃

QR Code
请用微信 扫一扫 扫描上面的二维码,然后点击页面右上角的 ... 图标,然后点击 发送给朋友分享到朋友圈,谢谢!
  当新冠疫情在美国以及其他以及其他一些国家因为疫苗接种而放缓时,印度(专题)却陷入了令人恐怖的疫情火海之中。对此,印度政府是如何反应的呢?《卫报》的新闻编辑安基塔·饶写道:“莫迪政府在挽救生命和挽回面子之间做选择,它选择了后者。”


  

  


  作者:安基塔·饶(Ankita Rao)

  几年前,在纳伦德拉·莫迪(Narendra Modi)上台后,我撰写了一份有关印度掩盖其疟疾死亡情况的调查报告。从部落奥里萨邦(Odisha)到新德里印度国家卫生部的旅行途中,我和我的同事看到成千上万的病例消失了:一些疟疾的死亡,首先在手写的本地卫生分类记录中被标记出来,但从未出现在中央政府的报告中;其他疟疾死亡病例神奇地转变为心脏病发作或发烧死亡。这种差异是巨大的:印度报告说那年有561人死于疟疾;而专家预测实际数字则高达20万。


  现在,随着新冠病毒席卷全国,绝望的印度人已经在Twitter上寻求氧气瓶或乞求一张医院的病床。政府对关键信息的隐瞒使危机更加恶化。在印度长期以来隐藏和低估疾病死亡的历史,以及最近抑制和压制新闻界的历史之间,莫迪政府使得有关印度新冠疫情的准确信息一直无法被找到。封锁这些信息只会伤害全国成百上千万的人。它还将阻碍全球在印度边境阻止新冠大流行以及该病毒的新变种的努力。

  印度和国外的流行病学家估计,该国官方报告的新冠死亡人数(在发稿时约为222000人)仅占真实死亡人数的一小部分。美国卫生计量与评估研究所所长估计,印度公布的数字仅占实际病例的3-4%。其他专家指出,孟买等城市的超额死亡总数证明,新冠死亡人数可能比政府公布的死亡人数多60%至70%。


  印度可能在篡改有关新冠死亡的记录数据,这是有着多种原因的。首先,公共卫生系统的彻底崩溃使得对在医院、诊所和在自己家里死去的数百万具尸体计数非常困难。尽管印度已成为世界上最大的经济体之一,但印度各州和联邦政府在医疗保健上的支出却并不乐观,投资不到其GDP的1%,是世界上医疗保健投资比例最低的国家之一。

  但是系统的崩溃还只是难题的一部分。印度政府的执政党吹捧它在大流行初期很成功地遏制了该病毒,并且从未放弃这种说法。4月,就在北方邦的露天火葬场在不停焚烧尸体的时候,其首席部长、莫迪的重要追随者Yogi Adityanath却声称一切都在控制之中,并一再拒绝宣布新的封锁措施,即使他本人也感染了新冠。

  这种否认的言论几乎发生在各个层面。就像印度对疟疾或肺结核采取的“视而不见”的方法一样,对新冠病毒的昏聩压制了“坏消息”,以提振该国的国际形象和执政党的国内地位。并非所有卫生系统陷入挣扎的国家都是这样做的。为了获得更多的人道主义援助,有的国家有时会夸大某种其他病毒造成的死亡。但是,在许多方面,低估疾病的危险性要大得多。莫迪政府在挽回面子和挽救生命之间做出了选择,它选择了大规模死亡。
不错的新闻,我要点赞     已经有 5 人参与评论了, 我也来说几句吧
Prev Page12Next Page
Note:
  • 新闻来源于其它媒体,内容不代表本站立场!
  • _VIEW_NEWS_FULL
    _RELATED_NEWS:
    _RELATED_NEWS_MORE:
    共有 5 人参与评论    (其它新闻评论)
    评论1 游客 [序.干.商.求] 2021-05-07 10:47
    最大的民主国家不可能这么下.三.烂!
    Prev Page1Next Page
    _POSTMYCOMMENT:
    Comment:
    Security Code:
    Please input the number which is shown on the following picture
    The Captcha image
    Terms & Conditions    Privacy Policy    Political ADs    Activities Agreement    Contact Us    Sitemap    

    加西网为北美中文网传媒集团旗下网站

    Page Generation: 0.0378 Seconds and 6 DB Queries in 0.0021 Seconds