夏時間のせいで医療記録が飛ぶ 92
ストーリー by hylom
海外では問題ないと言ったのは誰だ 部門より
海外では問題ないと言ったのは誰だ 部門より
あるAnonymous Coward曰く、
夏時間が導入されてから100年が経過した。しかし、今では多くの人々が毎年2回、時刻を調整するという行為に疑問を持っている。欧州委員会も今年の8月に夏時間の廃止を提案している。夏時間は第一次世界大戦中にドイツで石炭使用量を減らすことを目的に作られたが、もはや時代遅れのアイデアた。ある調査によると、夏時間の開始時に消費者支出は少し増加するものの、終了時には3.5％低下するという。
現代的な問題もある。病院で最も使用されているとされる電子健康記録ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず、トラブル時には時間を1時間戻すといった作業が強いられるという。しかも毎年繰り返し行われる。カリフォルニア州の集中治療室の看護師によると、夏時間変更時のトラブルで1時間分の電子記録保管が「なくなる」のだという。病院のスタッフは、手書きのチャートノートを作ることで対処しているという。
アメリカ医師会元会長のSteven Stack博士は、病院がこれらのシステムに何百万ドルも費やしていることを考慮すると、もはや容認できない事態だとしている（USA TODAY、PBSONEWS HOUR、Slashdot）。
アイデアた。 (スコア:3, すばらしい洞察)
#こういうのばかり目についてしまう。たぶん罠。
現代的な問題もある。病院で最も使用されているとされる電子健康記録ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず、トラブル時には時間を1時間戻すといった作業が強いられるという。
サマータイムがある現実を前にしてそれに対応しないソフトを使う非現実性にクラクラしてしまう。
この手のシステム導入するときに先ず優先される仕様だと思うけど、アメリカだとそうではないんだ。
#アメリカでの話だよね。
そしてシステム側の改修はしないのか、できないのか。
あるいはサマータイムに対応した別のソフトに乗り換えるという選択肢は考えられないのか。
疑問渦巻く。
病院のスタッフは、手書きのチャートノートを作ることで対処しているという。
結局現場が一番しんどそう、そのソフトを使わざるを得ない事情はあるんだろうけど、なんだかじれったい。
Re:アイデアた。 (スコア:1)
アリゾナ州向けのシステムを流用したに違いない
> この手のシステム導入するときに先ず優先される仕様
あちらからすれば一人の人がお亡くなりになるたびにコロコロかわる元号なんてものを
使っているのになんで容易に変更できるようにしておかないの？って思っているかもね
Re:アイデアた。 (スコア:1)
改元前後に企画されたシステムなら、対応を仕様に盛り込むのはありそう。
毎年必ずある予定と、不定期でン十年間が空く予定だと、コストを掛けてどっちに対応しておくのが得策か。
#どっちもやれって
Re: (スコア:0)
崩御を見越して事前対応など不敬だからできなかった、なんて事情もありますよ。
（今回は違うけど）
Re: (スコア:0)
人一人が亡くなることはコロコロ起きないだろ。
それに亡くなる時期は不定期で、新元号の文字も画面上に表記する元号の個数も不定だから、
定型処理ではない。仮に無限のパターンに対応できるように作れたとしても、対応コストも
それ相応に高くつく。
だから日本でも多くのシステムでは元号は使ってない。
＃お役所は知らん。
Re: (スコア:0)
リスクとコストの天秤だからサマータイムに自動対応する以外の手動でシステムの時間を修正するとか、システムの時間は直さずにアプリのスケジュールを一時間ずらすとか人の活動時間を一時間ずらすとかも方法としてはありかと
Re:アイデアた。 (スコア:1)
編集側にもコメント側にもTypoがあるのを飲み込んでネタにして楽しんでる側面もありますね。
サマータイムを実施していないところもあるから (スコア:2)
アリゾナ州のインディアン居留地ではサマータイムを実施しています。
サマータイムを実施しているカリフォルニアの患者が隣接するアリゾナで受診したら
結構ややこしいことになるかも知れません。
Re:サマータイムを実施していないところもあるから (スコア:1)
そもそも、カリフォルニア州とアリゾナ州でタイムゾーンが違い、一時間差がありますよね。
サマータイム実施時には、カリフォルニア州が一時間進めるので、結果的に両州一緒になります。
#ああ、ややこしい。
責任転嫁 (スコア:1)
> ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず
夏時間のせいで記録が飛ぶのではないでしょ。悪いのはソフトウエア。
Re:責任転嫁 (スコア:1)
> 悪いのはソフトウエア。
仕組みとして夏時間が施行されてしまっているならばそうでしょうね。
今更あえてこんな不合理なことを導入する必要は全くないな、と思わされるエピソードですが。
ましてや老害の自己満足のためにとかナンセンス。
Re: (スコア:0)
なぜこんなポンコツが最も使用されているのか。
Re:責任転嫁 (スコア:2)
お金にならないから競合商品が出てこないんですかね。
Re: (スコア:0)
time()でタイムを、summertime()でサマータイムを扱えばいいと思うの
Re: (スコア:0)
問題は季節的に時間をずらすことだけじゃなくて、開始日も終了日もずらす時間も開始時・終了時の境界の時刻の扱いも、そもそも「夏時間」"summer time"という名称も、時代・地域によって全てバラバラで全くシステマティックではないということもある。
Re: (スコア:0)
どうやって呼び分けるんだ
Re: (スコア:0)
マジレスすると時刻取得関数フックしてサマータイムでない元の時刻返すようにしちゃうだけでいい。
表示も含めてサマータイムにならないからその辺は注意必要だが。
＃日本用のシステムを日本鯖で海外向けにサービス展開するときはタイムゾーン修正面倒だからそれで運用してるｗ
Re: (スコア:0)
一方ロシアではtime()でunixタイムを使った
#ロシア以外でもか
Mr.サマータイム (スコア:0)
> ミスター・サマータイム
> あれは遠い 夏の日の幻
> ミスター・サマータイム気まぐれか
> 何もかも失くした 私
> ミスター・サマータイム
> さがさないで あの頃のデータを
> ミスター・サマータイム
> あれは遠い 夏の日の幻
夏時間の弊害は40年も前にすでに予言されていたのでふ
Re:Mr.サマータイム (スコア:2)
＃これも弊害？
Re:Mr.サマータイム (スコア:1)
サマータイムなんて、どの国も廃止でいいと思う。
これのせいで、いろんなシステムに支障が出てる。
実際のところ、夏時間対応済みのソフトは (スコア:0)
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
Re:実際のところ、夏時間対応済みのソフトは (スコア:5, 興味深い)
米国在住の米国人で、ソフトウェア技術者をやってます。
夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、
表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
データ集計等は全て UTC で行います。
IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
Re: (スコア:0)
> 夏時間の他にタイムゾーンの時差も似たような問題を起こします。
そういえばあっちじゃ普通すぎて話題にも上らないけど、大陸横断したら普通にタイムゾーンが
違って数時間ズレるんだっけ。グレハン旅行した時，到着時刻が現地時間で「午前二時」とか書いて
あっても、自分の腕時計は出発側のタイムゾーンのままだったから、到着するのがあと10分なのか
1時間10分なのかも分からなくて困った。
日本国内じゃ、バスや鉄道で国内を移動してるだけなのに、
「ここから隣のタイムゾーンだから腕時計1時間巻き戻さなくっちゃ」
みたいなことは想像しにくい。そういうのは外国旅行の話だもの
＃さらにそこに夏時間のコンボ。うへえ。
Re: (スコア:0)
表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか？
単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。
Re: (スコア:0)
データを記録するだけのソフトウェアならそういう運用もありかと思うが、
毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、
UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンから
デイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい？
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。
単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね
# ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...
M-FalconSky (暑いか寒い)
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
なぜそう見下すような発言をするかね。
一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。
むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
時間情報はUTCで記録/処理して、現場で表示するときだけその場の時間帯に修正するとか？
Re: (スコア:0)
電子カルテの場合、1970年以前の治療記録を持つ年寄りのデータはUTCでは困る。
(過去の紙データを電子化している場合だが。)
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
・UTCはタイムゾーンの話で、1970年は関係ないのでは？
・POSIX Time の話だとしたら、Unix Epochからの経過秒数を負の数にすれば対応できそう
Re: (スコア:0)
現行の協定世界時の起点は確かに1972年1月1日だけどそれを起点にグレゴリオ歴をベースに過去に一日単位で戻していく分には問題ないだろう?
さすがにもう天保暦の時代に生きていたひとの事は考慮しなくてもいいだろう。
そういう古い紙カルテを電子化したデータで秒単位以下の制度が問題になることは実際にあり得るのか?
Re: (スコア:0)
カルテの保存義務期間は5年なので、まず問題にはなりませんよ。
そんな古い紙カルテはまず残っていないので。
#正確には診療終了後5年
Re: (スコア:0)
初診が1964年の持病があってここの先生に50年間以上ずっとお世話に、なんてあったらアウトじゃないの
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
夏時間の開始/終了とシフト時間がどうだったのか該当システムで後から確認するのは困難なケースが考えられるので、
時刻の記録には、例えばUTCに加えて、その時刻が夏時間かどうか、夏時間の場合は何分シフトしているのかも分かるように
同時に記録しておいた方が無難
Re: (スコア:0)
金融系のソフトは市場が開いてない週末にメンテして対応してるから問題ないが、
医療系はどうなってるのか
Re: (スコア:0)
明け方に、縮退運用に切り替えてメンテするのが通例かと。
Re: (スコア:0)
内部的にはUTC管理で表示とかでローカルタイムが必要な時だけ設定しておいたタイムゾーンに従って変換というのはありますね。
Re: (スコア:0)
シンプルなのは内部的にはUTCで管理して、UI入出力だけ夏時間にする。
ただ、毎朝N時みたいな現地時間に従属する項目は項目別に適切な対処が必要。
夏時間中は夏時間分実施時刻をずらす(夏時間を無視する)なら入出力時に夏時間を換算するだけで済むけど……
ていうかこのストーリーの事例でも、システムを夏時間のないタイムゾーン設定して夏時間中はユーザが読み替えればいいようにも思う。
定時検診とかの時刻は非夏時間ベースのが良いだろうし……
そして日本は (スコア:0)
導入を検討していた。
Re: (スコア:0)
導入検討は終わって導入しないことになりましたけどニュースみないんですか？
標準時間で (スコア:0)
サマータイムなんて表示上の話で世界標準時間があるのだからなぜサマータイムなんぞ考慮せねばならんのか(UTC)とでも書いておけば対応完了でいいと思うけど。
Re:標準時間で (スコア:1)
ユーザーが日時を入力する箇所があればローカルタイム→UTCの変換も不可避なので、表示上だけでは済まない。
ユーザーに「必ずUTCで入力」を強制できるなら別だけど。
うじゃうじゃ
Re: (スコア:0)
もうローカルタイムは廃止してすべてUTCでやればいいじゃん。
そのうち、2:00(UTC)が昼前ということに慣れるよ。
Re: (スコア:0)
全てUTCで構わないけど、どうやって今のローカルタイム前提のソフトから
移行するかも考えておかないとSEが死ぬる事になりかねんぞ。
Re: (スコア:0)
Swatch Beat「ワイの出番やな！」
Re: (スコア:0)
それは慣れるかもしれないけど、朝の9時に日付が変わるのは慣れるかなあ。
日本の場合は始業時間になることが多いので、意外としっくりくるか？
# 昼に日付が変わる地域とかだと「日」という概念自体が別物になる気がする。
Re: (スコア:0)
それは最も良くある勘違いです。
表示を変えれば良いだけなら誰も苦労しません。
時刻を見て動く自動処理や、集計処理で、切り替えのタイミングでのイレギュラーな動作を正しく(業務によって正しい扱いは変わる)実装する必要があります。
1日が24時間だという前提で作られているプログラムや記録データも全てダメになります。
システムに疎い人の身近なところでも、あなたが入力している勤怠記録がサマータイム切り替えを伴う深夜残業に対応して正しく計算出来るかを想像してみれば、如何に対応が容易ではないかがわかるでしょう。
なんぼなんでも、ひどすぎる。 (スコア:0)
夏時間を使うようになって1世紀経とうというのに、そんなソフトウェアを作る奴らはあほだし、
現場で不都合が出ているのにいつまでたっても修正しないのも怠惰すぎると思ったが、
いくらなんでもそこまであほとは信じがたい、対応不可能な理由が何かあるのか。
採用するほうは、他が使っていてデータの相互運用などを考えると、不具合を呑み込んで使わざるを得ないという
のもあるのかもしれないが。
Re: (スコア:0)
君だってExcelの２つや３つ使うことあるだろ？
それと同じ