パスワードを忘れた? アカウント作成
13762877 story
バグ

夏時間のせいで医療記録が飛ぶ 92

ストーリー by hylom
海外では問題ないと言ったのは誰だ 部門より
あるAnonymous Coward曰く、

夏時間が導入されてから100年が経過した。しかし、今では多くの人々が毎年2回、時刻を調整するという行為に疑問を持っている。欧州委員会も今年の8月に夏時間の廃止を提案している。夏時間は第一次世界大戦中にドイツで石炭使用量を減らすことを目的に作られたが、もはや時代遅れのアイデアた。ある調査によると、夏時間の開始時に消費者支出は少し増加するものの、終了時には3.5%低下するという。

現代的な問題もある。病院で最も使用されているとされる電子健康記録ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず、トラブル時には時間を1時間戻すといった作業が強いられるという。しかも毎年繰り返し行われる。カリフォルニア州の集中治療室の看護師によると、夏時間変更時のトラブルで1時間分の電子記録保管が「なくなる」のだという。病院のスタッフは、手書きのチャートノートを作ることで対処しているという。

アメリカ医師会元会長のSteven Stack博士は、病院がこれらのシステムに何百万ドルも費やしていることを考慮すると、もはや容認できない事態だとしている(USA TODAYPBSONEWS HOURSlashdot)。

  • アイデアた。 (スコア:3, すばらしい洞察)

    by nemui4 (20313) on 2018年11月08日 7時58分 (#3512018) 日記

    #こういうのばかり目についてしまう。たぶん罠。

    現代的な問題もある。病院で最も使用されているとされる電子健康記録ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず、トラブル時には時間を1時間戻すといった作業が強いられるという。

    サマータイムがある現実を前にしてそれに対応しないソフトを使う非現実性にクラクラしてしまう。
    この手のシステム導入するときに先ず優先される仕様だと思うけど、アメリカだとそうではないんだ。
    #アメリカでの話だよね。

    そしてシステム側の改修はしないのか、できないのか。
    あるいはサマータイムに対応した別のソフトに乗り換えるという選択肢は考えられないのか。
    疑問渦巻く。

    病院のスタッフは、手書きのチャートノートを作ることで対処しているという。

    結局現場が一番しんどそう、そのソフトを使わざるを得ない事情はあるんだろうけど、なんだかじれったい。

    ここに返信
    • by Anonymous Coward on 2018年11月08日 8時24分 (#3512027)

      アリゾナ州向けのシステムを流用したに違いない

      > この手のシステム導入するときに先ず優先される仕様
      あちらからすれば一人の人がお亡くなりになるたびにコロコロかわる元号なんてものを
      使っているのになんで容易に変更できるようにしておかないの?って思っているかもね

      • by nemui4 (20313) on 2018年11月08日 8時52分 (#3512034) 日記

        改元前後に企画されたシステムなら、対応を仕様に盛り込むのはありそう。

        毎年必ずある予定と、不定期でン十年間が空く予定だと、コストを掛けてどっちに対応しておくのが得策か。
        #どっちもやれって

        • by Anonymous Coward

          崩御を見越して事前対応など不敬だからできなかった、なんて事情もありますよ。
          (今回は違うけど)

      • by Anonymous Coward

        人一人が亡くなることはコロコロ起きないだろ。

        それに亡くなる時期は不定期で、新元号の文字も画面上に表記する元号の個数も不定だから、
        定型処理ではない。仮に無限のパターンに対応できるように作れたとしても、対応コストも
        それ相応に高くつく。

        だから日本でも多くのシステムでは元号は使ってない。
        #お役所は知らん。

    • by Anonymous Coward

      リスクとコストの天秤だからサマータイムに自動対応する以外の手動でシステムの時間を修正するとか、システムの時間は直さずにアプリのスケジュールを一時間ずらすとか人の活動時間を一時間ずらすとかも方法としてはありかと

  • 米国ではハワイ、アリゾナとインディアナ州の一部はサマータイム未実施です。
    アリゾナ州のインディアン居留地ではサマータイムを実施しています。

    サマータイムを実施しているカリフォルニアの患者が隣接するアリゾナで受診したら
    結構ややこしいことになるかも知れません。
    ここに返信
  • by Anonymous Coward on 2018年11月08日 8時15分 (#3512021)

    > ソフトウェアシステム「Epic Systems」は夏時間に対応しておらず

    夏時間のせいで記録が飛ぶのではないでしょ。悪いのはソフトウエア。

    ここに返信
    • by Anonymous Coward on 2018年11月08日 8時54分 (#3512037)

      > 悪いのはソフトウエア。
      仕組みとして夏時間が施行されてしまっているならばそうでしょうね。

      今更あえてこんな不合理なことを導入する必要は全くないな、と思わされるエピソードですが。
      ましてや老害の自己満足のためにとかナンセンス。

    • by Anonymous Coward

      なぜこんなポンコツが最も使用されているのか。

    • by Anonymous Coward

      time()でタイムを、summertime()でサマータイムを扱えばいいと思うの

      • by Anonymous Coward

        問題は季節的に時間をずらすことだけじゃなくて、開始日も終了日もずらす時間も開始時・終了時の境界の時刻の扱いも、そもそも「夏時間」"summer time"という名称も、時代・地域によって全てバラバラで全くシステマティックではないということもある。

      • by Anonymous Coward

        どうやって呼び分けるんだ

      • by Anonymous Coward

        マジレスすると時刻取得関数フックしてサマータイムでない元の時刻返すようにしちゃうだけでいい。
        表示も含めてサマータイムにならないからその辺は注意必要だが。

        #日本用のシステムを日本鯖で海外向けにサービス展開するときはタイムゾーン修正面倒だからそれで運用してるw

      • by Anonymous Coward

        一方ロシアではtime()でunixタイムを使った

        #ロシア以外でもか

  • by Anonymous Coward on 2018年11月08日 8時59分 (#3512040)

    > ミスター・サマータイム
    > あれは遠い 夏の日の幻
    > ミスター・サマータイム気まぐれか
    > 何もかも失くした 私

    > ミスター・サマータイム
    > さがさないで あの頃のデータを
    > ミスター・サマータイム
    > あれは遠い 夏の日の幻

    夏時間の弊害は40年も前にすでに予言されていたのでふ

    ここに返信
  • by Anonymous Coward on 2018年11月08日 9時09分 (#3512046)

    どんな対応をしているのでしょうか。

    なにもしないと時間ごとのデータ集計とかおかしくなりますよね。

    ここに返信
    • by Anonymous Coward on 2018年11月08日 9時53分 (#3512084)

      米国在住の米国人で、ソフトウェア技術者をやってます。
      夏時間の他にタイムゾーンの時差も似たような問題を起こします。

      私のところでは、データベース等に記録する時間を全て UTC に統一し、
      表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
      データ集計等は全て UTC で行います。
      IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。

      • by Anonymous Coward

        > 夏時間の他にタイムゾーンの時差も似たような問題を起こします。

        そういえばあっちじゃ普通すぎて話題にも上らないけど、大陸横断したら普通にタイムゾーンが
        違って数時間ズレるんだっけ。グレハン旅行した時,到着時刻が現地時間で「午前二時」とか書いて
        あっても、自分の腕時計は出発側のタイムゾーンのままだったから、到着するのがあと10分なのか
        1時間10分なのかも分からなくて困った。

        日本国内じゃ、バスや鉄道で国内を移動してるだけなのに、
        「ここから隣のタイムゾーンだから腕時計1時間巻き戻さなくっちゃ」
        みたいなことは想像しにくい。そういうのは外国旅行の話だもの
        #さらにそこに夏時間のコンボ。うへえ。

      • by Anonymous Coward

        表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか?
        単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。

      • by Anonymous Coward

        データを記録するだけのソフトウェアならそういう運用もありかと思うが、
        毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、
        UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンから
        デイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい?

    • 時間情報はUTCで記録/処理して、現場で表示するときだけその場の時間帯に修正するとか?

      • by Anonymous Coward

        電子カルテの場合、1970年以前の治療記録を持つ年寄りのデータはUTCでは困る。
        (過去の紙データを電子化している場合だが。)

        • ・UTCはタイムゾーンの話で、1970年は関係ないのでは?
          ・POSIX Time の話だとしたら、Unix Epochからの経過秒数を負の数にすれば対応できそう

        • by Anonymous Coward

          現行の協定世界時の起点は確かに1972年1月1日だけどそれを起点にグレゴリオ歴をベースに過去に一日単位で戻していく分には問題ないだろう?
          さすがにもう天保暦の時代に生きていたひとの事は考慮しなくてもいいだろう。
          そういう古い紙カルテを電子化したデータで秒単位以下の制度が問題になることは実際にあり得るのか?

        • by Anonymous Coward

          カルテの保存義務期間は5年なので、まず問題にはなりませんよ。
          そんな古い紙カルテはまず残っていないので。

          #正確には診療終了後5年

          • by Anonymous Coward

            初診が1964年の持病があってここの先生に50年間以上ずっとお世話に、なんてあったらアウトじゃないの

    • by Anonymous Coward on 2018年11月08日 10時37分 (#3512109)

      夏時間の開始/終了とシフト時間がどうだったのか該当システムで後から確認するのは困難なケースが考えられるので、

      時刻の記録には、例えばUTCに加えて、その時刻が夏時間かどうか、夏時間の場合は何分シフトしているのかも分かるように
      同時に記録しておいた方が無難

    • by Anonymous Coward

      金融系のソフトは市場が開いてない週末にメンテして対応してるから問題ないが、
      医療系はどうなってるのか

      • by Anonymous Coward

        明け方に、縮退運用に切り替えてメンテするのが通例かと。

    • by Anonymous Coward

      内部的にはUTC管理で表示とかでローカルタイムが必要な時だけ設定しておいたタイムゾーンに従って変換というのはありますね。

    • by Anonymous Coward

      シンプルなのは内部的にはUTCで管理して、UI入出力だけ夏時間にする。
      ただ、毎朝N時みたいな現地時間に従属する項目は項目別に適切な対処が必要。
      夏時間中は夏時間分実施時刻をずらす(夏時間を無視する)なら入出力時に夏時間を換算するだけで済むけど……

      ていうかこのストーリーの事例でも、システムを夏時間のないタイムゾーン設定して夏時間中はユーザが読み替えればいいようにも思う。
      定時検診とかの時刻は非夏時間ベースのが良いだろうし……

  • by Anonymous Coward on 2018年11月08日 9時47分 (#3512074)

    導入を検討していた。

    ここに返信
    • by Anonymous Coward

      導入検討は終わって導入しないことになりましたけどニュースみないんですか?

  • by Anonymous Coward on 2018年11月08日 10時14分 (#3512095)

    サマータイムなんて表示上の話で世界標準時間があるのだからなぜサマータイムなんぞ考慮せねばならんのか(UTC)とでも書いておけば対応完了でいいと思うけど。

    ここに返信
    • ユーザーが日時を入力する箇所があればローカルタイム→UTCの変換も不可避なので、表示上だけでは済まない。
      ユーザーに「必ずUTCで入力」を強制できるなら別だけど。

      --
      うじゃうじゃ
      • by Anonymous Coward

        もうローカルタイムは廃止してすべてUTCでやればいいじゃん。
        そのうち、2:00(UTC)が昼前ということに慣れるよ。

        • by Anonymous Coward

          全てUTCで構わないけど、どうやって今のローカルタイム前提のソフトから
          移行するかも考えておかないとSEが死ぬる事になりかねんぞ。

        • by Anonymous Coward

          Swatch Beat「ワイの出番やな!」

        • by Anonymous Coward

          それは慣れるかもしれないけど、朝の9時に日付が変わるのは慣れるかなあ。
          日本の場合は始業時間になることが多いので、意外としっくりくるか?

          # 昼に日付が変わる地域とかだと「日」という概念自体が別物になる気がする。

    • by Anonymous Coward

      それは最も良くある勘違いです。
      表示を変えれば良いだけなら誰も苦労しません。
      時刻を見て動く自動処理や、集計処理で、切り替えのタイミングでのイレギュラーな動作を正しく(業務によって正しい扱いは変わる)実装する必要があります。
      1日が24時間だという前提で作られているプログラムや記録データも全てダメになります。
      システムに疎い人の身近なところでも、あなたが入力している勤怠記録がサマータイム切り替えを伴う深夜残業に対応して正しく計算出来るかを想像してみれば、如何に対応が容易ではないかがわかるでしょう。

  • by Anonymous Coward on 2018年11月08日 10時18分 (#3512097)

    夏時間を使うようになって1世紀経とうというのに、そんなソフトウェアを作る奴らはあほだし、
    現場で不都合が出ているのにいつまでたっても修正しないのも怠惰すぎると思ったが、
    いくらなんでもそこまであほとは信じがたい、対応不可能な理由が何かあるのか。

    採用するほうは、他が使っていてデータの相互運用などを考えると、不具合を呑み込んで使わざるを得ないという
    のもあるのかもしれないが。

    ここに返信
    • by Anonymous Coward

      君だってExcelの2つや3つ使うことあるだろ?
      それと同じ

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...