すべての数字に理由がある。すべての理由が記録に残る。

病院とクリニックのための患者請求と収益サイクルの仕組みで、チャージの計上から帳簿の締めまでをひとつのシステムとして構築しています。チャージの計上、価格設定と税の適用、負担者の判定、保険と請求の処理、入金の受け付け、未収金の管理、現金の保管、元帳への転記、期間の締めを扱います。すべての数字に理由があり、すべての理由が記録に残ることを目指しています。

ひとつの計算エンジンが決定します。価格はサービス日付時点のバージョン管理された価格表から決まり、曖昧な一致は推測ではなくエラーとなり、税の設定がない場合は黙ってゼロ請求とせずチャージを止めます。すべての計算はバージョンと追跡情報を保持するため、後からでも計算過程を示せます。設定された段階を超える割引には、別の1人の承認が必要です。インドの GST に対応しており、CGST、SGST、IGST は役務提供地で決まります。VAT などの他の税制には、まだ対応していません。

請求書ができる前に、責任エンジンが患者、保険、法人、政府、その他の負担者ごとの按分を計算し、その上にパッケージが重なります。請求窓口にはチャージごとの結果が表示されます。その結果を上書きするには別の1人の承認が必要で、請求書には患者、保険、法人の負担分が並んで表示されます。

保険に関するやり取り全体を記録し追跡します。シミュレーター付きのバージョン管理されたプランと給付ルール、資格確認、変更や更新を含む事前承認、請求、査定、査定拒否、不服申し立て、支払者からの支払通知です。FHIR R4 の資格確認・請求アダプターは用意されていますが、支払者のエンドポイントと認証情報が設定されるまで休止状態です。X12 や各国のネットワークなど支払者固有のやり取りにはまだ対応していないため、現時点では、このモジュールは請求が置かれ処理される場所であり、保険者への直通回線ではありません。

まだできません。入金は、組織が有効にした現金、カード、銀行振込、小切手、保険精算などの方法ごとに記録され、各入金は処理、精算、充当、承認の状態を別々の事実として保持します。支払いリンク、オンラインチェックアウト、3-D Secure は未実装で、認証を受けた本番の決済ゲートウェイもありません。カード番号、セキュリティコード、トラックデータは保存されず、カード番号に見える自由入力の文字列は拒否されます。

保存された売掛金はありません。未払い額は照会のたびに取引の動きから導出され、過去の日付のレポートはその日をそのまま再現します。経過期間の区分は組織独自のものです。回収案件、支払約束、分割払い計画、紛争、貸倒処理はひとつの画面で扱い、貸倒処理は別々の人が申請、承認、実行します。静音時間を設けたバージョン管理の督促ポリシーが作業キューを動かします。督促状や明細書はキューに入れて画面に表示されますが、メール、SMS、患者ポータルでの配信はまだ実装されていません。

支払われた額、決済事業者が精算した額、銀行が入金した額を並べて表示し、差異は入金の修正ではなく、人が説明するものとして扱います。銀行明細は CSV ファイルで取り込み、ファイルは内容で識別されるため同じファイルが二度精算されることはなく、照合ルールはバージョン管理され、結果を再現するために再実行できます。その他の明細形式やリアルタイムの銀行フィードには、まだ対応していません。

はい、拠点ごとに選択できます。ドロアのない拠点はこれまでとまったく同じように動作します。ドロアは収納窓口に属し、レジ担当者はセッション単位で作業し、カウントはブラインドで行われ、2人の間で受け渡された現金は紛失ではなく受け渡し中と表示され、銀行への預入で一巡します。期待残高は手入力ではなく取引の動きから導出され、現金の差異は別の1人が判断する必要があります。

期間は6つの状態を経て、通常の請求、会計仕訳、税務仕訳、レポートの4つの独立したロックを持ちます。締めでは17項目の自動チェックを実行し、試算表が一致していること、保留中の仕訳がないこと、補助元帳が元帳と一致していること、現金の差異が判断済みであることなどを確認します。必須チェックは締めを止め、警告は確認が必要で、チェックリストは締めの開始時にコピーされるため、後からの編集で行われた締めが変わることはありません。締め済みの期間は一切受け付けません。

3つの方法があり、いずれも善意に頼らずデータベースが強制します。履歴は編集されません。誤りは元の行の隣にある調整行で訂正します。すべての監査イベントは書き込まれた時点でハッシュ化され、前のものに連なるチェックポイントに封印されるため、編集するとチェーンが壊れ、検証はボタンひとつです。そしてテナントの分離はすべてのテーブルで強制され、モジュールへのアクセスはリクエストごとに再確認され、失敗時は閉じる設計です。

このモジュールの一部は、意図的に2人を必要とします。返金、貸倒処理、責任按分の上書き、締めの例外、手入力の仕訳、再オープンされた期間、現金の差異は、同じ人が両方の役割を行おうとすると、画面だけでなくデータベースによって拒否され、どの設定でも解除できません。そのため、ユーザーが1人だけの環境ではこれらのワークフローをまったく完了できません。これは始める前に決める事柄であり、あとで驚くことではありません。

現時点では決定論的です。12の検知機能が Billing 自身の記録から、収益の漏れ、査定拒否のパターン、支払リスクなどを監視し、それぞれ記録から計算過程を示して算出されます。アシスタントは質問を既知の質問の固定リストのひとつに対応づけ、画面と同じコードで回答するため、言語モデルなしで動作し、その旨を画面上に表示します。収益の漏れは、Billing が自身の記録で証明できる範囲のみを対象とします。この層はどの財務テーブルにも書き込めず、ビルド内のテストがそれを検証します。

はい。通貨マスター、為替レートのポリシー、有効期間付きの拠点を持つ法人、複数の税務登録、国を有効にする前に有効化チェックを通過する必要がある国別プロファイルを備えています。為替レートは手入力で、レートフィードはありません。通貨をまたぐ入金、小数点以下3桁の通貨、拠点間の連結には、まだ対応していません。

そのように作られています。臨床モジュールはバージョン管理された契約に基づいて請求可能なイベントを発行し、他のモジュールは患者の財務情報のうち許可された範囲のみを参照でき、それぞれが権限を限定した独自の認証情報を持ちます。臨床モジュールはまだこれらのイベントを送信していないため、現時点ではチャージは請求窓口で入力します。自動取り込みも初期状態では無効で、無効の間に届いたイベントは、失われることも請求されることもなく保留されます。

これらのフレームワークが求める統制を支援するよう作られており、ISO/IEC 27001、SOC 1 および SOC 2、HIPAA、GDPR、PCI-DSS、PSD2 の強力な顧客認証、CCPA、CSA STAR を対象とした統制マトリクスが付属します。いずれについても、モジュールが認証済みであるとは説明していません。認証は組織が自ら取得するものであり、マトリクスはその監査を短くするためのものです。

Enterprise プラン1種類のみで、請求を行う拠点と法人の数に応じて組織ごとにお見積りします。上位の階層がないため、上位のために取っておく機能もありません。導入支援と、モジュールを開発しているチームへの直通の連絡手段が付きます。