レンサ球菌の分類法はいろいろあるが、古典的な分類法は血液寒天培地上の溶血の有無によってβ(はっきり溶血)、 α(少し溶血)、γ(溶血なし)に分類される。一般的には溶血が強いほど病原性も強い。 全般的に薬剤感受性が高い。基本的にはペニシリン系がよく効く。
病原性が強い。特にA群連鎖球菌(注3)は強毒菌。咽頭炎の起炎菌として有名だが、 蜂窩織炎などの軟部組織感染症の起炎菌としても重要。 稀であるが劇症の軟部組織感染症である壊死性筋膜炎の原因ともなる。 B群連鎖球菌は古典的には婦人科領域の感染症や新生児の感染症(注4)の起炎菌として重要であるが,近年は成人の菌血症や心内膜炎, 軟部組織感染症などの起因菌としても認識されてきている。病原性が強いが薬剤感受性は高い。ペニシリンが常に有効。耐性菌はいない。
肺炎球菌とそれ以外にまず分けられる。この両者は見た目も性質も異なる。
病原性は強い。名前の通り肺炎の起炎菌として最も頻度が高い。肺炎だけでなく成人の髄膜炎の起炎菌としても最も頻度が高い。 副鼻腔炎、中耳炎の起炎菌としても重要。βラクタム剤に対する薬剤感受性は基本的には高い(注5)。 近年、ペニシリン耐性菌が問題になっているが髄膜炎以外ではあまり問題にならない(注6)。 また、肺炎でも血中濃度が上がりにくい経口βラクタム薬で治療する場合は問題になることがある。
口腔内の常在菌である。薬剤感受性は良好で、基本的にはペニシリンが有効(注7)。 亜急性感染性心内膜炎の起炎菌として重要。血液培養から検出されたら心内膜炎の検索は必須。 全般的に病原性は高くないが、中に膿瘍形成しやすく、肺化膿症や脳膿瘍の原因菌になるものもいる(注8)。
腸球菌は腸内の常在菌なので、腹腔内感染症や複雑性尿路感染症の起炎菌になりうるが実際に起炎菌であることは多くない。 感染性心内膜炎の起因菌として重要。 腸球菌には感受性試験の結果や添付文書の記載の如何によらずセフェム系は全く効かないので注意。 起炎菌としての頻度が高いEnterococcus faecalisはペニシリンが有効なことが多い。E. faeciumはペニシリン耐性菌が多い。 感受性試験の結果によらず腸球菌に対して臨床的に有効であるのはABPC(ABPC/SBTも可),PIPC(PIPC/TAZも可),IPM/CS, VCMのみであるのでこれらのうちで感受性のあるものを選択する(ABPCが理想的)。 ただしこれらの薬剤も腸球菌に対しては静菌的にしか作用しないので重症菌血症や心内膜炎などに対してはアミノグリコシドを併用することが推奨される。
最初の報告でどこまで分かるのか? まず、血液培養検体のグラム染色の菌の形態や配列のパターンによってブドウ球菌かレンサ球菌か、 そしてレンサ球菌ならば肺炎球菌かそれ以外のレンサ球菌かがある程度分かる。
黄色ブドウ球菌とCNSは見た目では区別できない。そして、当然であるが薬剤感受性も分からないのでMRSAかどうかも分からない。 培養結果がでるまではVCMでの治療が最も確実である。 CNSは皮膚の常在菌なので、2セット中1セットのみの場合はコンタミネーションの可能性を考える。
血液培養でも溶血の有無はある程度分かるが、厳密に菌を特定することは不可能。コンタミネーションの可能性は低い。 連鎖球菌菌血症の場合、常に感染性心内膜炎を疑う。多くの場合は菌名と感受性判明まではVCMを使用することになる。
And the whole problem hinges on the little tiny decision of what IE8 should do
when it encounters a page that claims to support ���standards���, but has probably
only been tested against IE7.
What the hell is a standard?
Don���t they have standards in all kinds of engineering endeavors? (Yes.)
Don���t they usually work? (Mmmm���..)
Why are ���web standards��� so frigging messed up? (It���s not just Microsoft���s
fault. It���s your fault too. And Jon Postel���s (1943-1998). I���ll explain that
later.)
There is no solution. Each solution is terribly wrong. Eric Bangeman at ars
technica writes, ���The IE team has to walk a fine line between tight support
for W3C standards and making sure sites coded for earlier versions of IE still
display correctly.��� This is incorrect. It���s not a fine line. It���s a line of
negative width. There is no place to walk. They are damned if they do and
damned if they don���t.
-- Joel Spolsky
-- "Martian Headsets" ( http://www.joelonsoftware.com/items/2008/03/17.html )
The very first version of Microsoft Word for Windows was considered a "death
march" project. It took forever. It kept slipping. The whole team was working
ridiculous hours, the project was delayed again, and again, and again, and the
stress was incredible. When the dang thing finally shipped, years late,
Microsoft sent the whole team off to Cancun for a vacation, then sat down for
some serious soul-searching.
What they realized was that the project managers had been so insistent on
keeping to the "schedule" that programmers simply rushed through the coding
process, writing extremely bad code, because the bug fixing phase was not a
part of the formal schedule. There was no attempt to keep the bug-count down.
Quite the opposite. The story goes that one programmer, who had to write the
code to calculate the height of a line of text, simply wrote "return 12;" and
waited for the bug report to come in about how his function is not always
correct. The schedule was merely a checklist of features waiting to be turned
into bugs. In the post-mortem, this was referred to as "infinite defects
methodology".
To correct the problem, Microsoft universally adopted something called a "zero
defects methodology". Many of the programmers in the company giggled, since it
sounded like management thought they could reduce the bug count by executive
fiat. Actually, "zero defects" meant that at any given time, the highest
priority is to eliminate bugs before writing any new code.
-- Joel Spolsky
-- "The Joel Test: 12 Steps to Better Code" ( http://www.joelonsoftware.com/articles/fog0000000043.html )