低リスクの出生前健康記録のためのウェブベースのプラットフォームで、デジタルケア管理と医療専門家とのユーザビリティ検証を統合しています

サマリー

本研究は、低リスクの出生前相談記録をデジタル化するためのウェブベースのアプリケーションの開発とユーザビリティ検証を詳述しています。このツールは、臨床情報の文書化を最適化し、産科計算を自動化し、母体ケアの継続性を高めるために開発され、手作業記録管理の制約に対応しています。

要約

出生前記録の質と完全性は、効果的な母体および胎児ケアを確保するために極めて重要です。しかし、妊娠前相談の記録に印刷されたハンドブックを従来の使用すると、不完全な記録、判読困難、物理的な損傷や紛失のリスクなど重大な制約が生じます。これらの制約は、ケアの継続性や臨床情報の信頼性を損なう可能性があります。これらの問題を緩和するために、本研究では、出生前相談記録をデジタル化・最適化するためのウェブベースのアプリケーションの開発と予備的なユーザビリティ評価を提示します。このプロトコルの目標は、出生前データの記録、相談、管理のための構造的かつ効率的なデジタルシステムを提供し、自動産科計算と可視化ツールを統合して臨床意思決定を支援することです。システムの要件は、産前ケアの文書化および健康情報システムのベストプラクティスの文献に基づく分析を通じて特定されました。提案されたソリューションは、日常的な臨床ワークフローへの統合を促進するため、ユーザビリティとアクセシビリティ基準に準拠したレスポンシブなウェブアプリケーションとして実装されました。ユーザビリティ評価には、印刷されたハンドブックの使用経験のある医療専門家が参加しました。定量データはシステムユーザビリティスケール(SUS)を用いて収集され、定性的知見は半構造化インタビューを通じて得られました。アプリケーションは平均SUSスコア77.50を獲得し、良好な使いやすさと受理性を示しています。参加者は、このシステムが臨床実践に関連していること、エラーを減らす可能性、そして妊娠前ケアの継続性と質を高める可能性を強調しました。これらの調査結果は、提案されたプロトコルが、デジタル記録を出生前医療専門家の運用ニーズに効果的に整合させることに有望であることを示しています。このシステムは平均システムユーザビリティスケールスコア77.5を獲得し、業界の閾値68を超え、評価された専門家の間で良好なユーザビリティ受容を示しました。これらの発見は、提案されたプラットフォームが出生前健康記録のデジタル化において実現可能でユーザーにとって受け入れ可能なアプローチであることを示唆しています。

概要

ブラジルでは、産前ケアは母子の福祉を促進するための重要な公衆衛生政策^です。適切な出生前フォローアップは、検査や予防接種などの臨床的行動、患者の社会的・^{感情的ニーズ}への支援など、複数のケアの側面を含みます。この文脈において、妊婦健康記録は妊娠中の臨床データを記録・監視するための公式文書として機能^します。

その重要性にもかかわらず、印刷版の健康記録には手書きの記載が誤りや不完全、判読不能、書類の紛失^{や損傷に関する}問題など、重大な制約があります。これらの欠陥は医療従事者に管理業務の負担をかけ、ケアの継続性を妨げています。出生前データの質の低さは患者の安全性や情報に基づく意思決定に悪影響を及ぼし、最終的には一次医療の効果を低下させます。過去の研究では、妊娠前ケアの質と新生児アウトカムの直接的な関連が示されており、不十分な追跡調査が早産および低出生体重と相関していることが示されています⁵。

世界的に見て、世界保健機関(WHO)は、母子保健におけるデジタルトランスフォーメーションが持続可能な開発目標(SDGs)の達成に向けた戦略的優先事項であると強調しています。SDG3はすべての^6.7の健康な生活を確保し、幸福を促進することを目的としています。WHOのデジタルヘルス戦略2020–2025は、医療サービスの調整、データ品質、継続性を向上させるために相互運用可能なデジタルシステムの導入を提唱しています。いくつかの国では、電子母体保健記録が成功裏に導入され、データ駆動型の意思決定、合併症の早期発見、プライマリケアと専門医療の統合が強化されています^8,9。

これらの技術の導入は、世界的な努力にもかかわらず低・中所得国で依然として高い母体および新生児死亡率の削減に寄与しています。デジタルツールはリアルタイムのデータ共有、高リスク妊娠の自動アラート、標準化された報告を可能にし、妊婦ケアの質と安全性向上に不可欠です。さらに、ユーザー中心の設計とユーザビリティの検証は、健康情報システムの採用と長期的な持続可能性を確保するための重要な要素として認識されています^10,11。

これらの世界的かつ国内的な課題を踏まえ、臨床情報管理を最適化するための技術システムの開発はますます重要になっています。これらのツールは、医療従事者が手作業で記録管理を行う作業から解放され、直接的な患者ケアに集中できるようにすることを目指しています^。本研究は、妊娠中の女性の健康記録をデジタル化するためのウェブベースのソフトウェアプロトタイプの開発と予備的なユーザビリティ評価を提示します。これは特に低リスク妊娠向けに設計されています。このシステムは、クリーンアーキテクチャ¹³ とユーザー中心設計アプローチ¹⁴に従い、臨床データの整理とアクセシビリティに重点を置いて開発されました。目的は、医療専門家と共に実施されたユーザビリティテストの結果を提示し、患者の受け入れ、相談ワークフロー、個別のフォローアッププロセスを検証することです。

著者の知る限り、これはドメイン駆動型で臨床的に根拠のあるソフトウェアアーキテクチャを、低リスクの妊婦ケア環境におけるブラジル妊婦の健康記録のデジタル化に特化した構造化されたユーザビリティ評価プロトコルを組み合わせた最初の研究の一つです。この研究の主な貢献には、低リスク妊娠の妊婦の健康記録をデジタル化し、プライマリヘルスケア環境における臨床データの管理、アクセス性、信頼性を向上させるウェブベースの産前ケアシステムの開発が含まれます。さらに、この研究では医療専門家を対象に実施された予備的なユーザビリティ評価も行われており、その結果、システムがワークフローの効率化、文書ミスの減少、そしてより患者中心でデータ駆動型の母体ケアを支援できることが示唆されています。

プロトコル

この研究では、医療専門家がソフトウェアのプロトタイプに対して専門的な意見を提供するユーザビリティ評価を含みました。参加者から個人的、臨床的、または特定可能なデータは収集されず、セッション中に使用されたすべての患者記録は架空のものでした。この研究は参加者にリスクをもたらさず、機密データも収集されなかったため、正式な倫理委員会の審査対象外とみなされました。すべての参加者には研究の目的が説明され、参加前に口頭での同意が提供されました。

本研究で提案された方法論的ウェブインターフェースは、提案されたツールベースの出生前ケアアプリケーションの設計、開発、評価の再現性を確保するよう構成されています。プロセスは、要件分析¹⁵、プロトタイピング、システムアーキテクチャの定義、実装、ユーザビリティ評価を含む連続的なフェーズに組織されました。この構造が提案され、妊婦前ケアの記録や臨床意思決定の最適化を支援する、堅牢でユーザー志向かつ文脈認識型のデジタルツールの開発が可能となりました( 図1参照)。

図1:本研究で採用された5つの連続フェーズを示す開発プロセスモデル。 (1) 要件分析:文献レビューおよびドメイン専門家との共同設計セッション;(2) 低忠実度ワイヤーフレーム検証を含むプロトタイピング;(3) ドメイン駆動設計および六角形建築の原則に基づくアーキテクチャ定義;(4) フロントエンド、バックエンド、データベース開発をカバーする実装;および(5) システムユーザビリティスケールと声に出して考えるプロトコルを用いて5人の医療専門家を対象に実施するユーザビリティテスト。 この図の拡大版はこちらをクリックしてご覧ください。

システム要件
システム要件フェーズは、提案された出生前ケアアプリケーションの開発に不可欠な機能的および運用上のニーズを特定することを目的としていました。要件誘導プロセスは、構造化された文献レビューと、一次産前ケアの産科看護スペシャリストとの共同設計セッションを組み合わせたものでした。レビューはSciELO、PubMed/MEDLINE、Scopusで行われ、検索文字列を組み合わせて実施されました:(「出生前ケア」または「産前ケア」)および「デジタルヘルス」または「電子カルテ」または「健康情報システム」および「ユーザビリティ」または「ユーザー中心設計」といった検索クエリです。出生前記録や健康情報システムのユーザビリティ評価のためのデジタルツールを調査した英語およびポルトガル語で発表された研究も検討されました。文献レビューは、紙ベースの健康記録における限界の特定と、デジタル化すべき臨床パラメータの確立に役立ちました。共同設計セッションでは、構造化されたインタビューと低忠実度の共同プロトタイピングが含まれ、ドメイン専門家が実装前にデータ入力の論理的な順序と各システム機能の臨床的関連性を検証しました。このプロセスの中心的な成果は、開発チームと臨床専門家の間で共通語彙として普及する言語の確立であり、「患者入院」「妊娠周数」「子宮の高さ」「胎児心拍数」といったドメイン固有の用語がユーザーインターフェースとシステムのドメインモデルの両方に一貫して反映されるようにしました。このアプローチにより、臨床要件と実装されたソリューションとのギャップが縮まり、2つのコアモジュールが検証されました。

この制度の目的上、低リスク妊娠はブラジル保健省のガイドライン(ポルトガル語で Cadernos de Atenção Básica) に従って定義されています。2012年第32号)は、既往症の母体疾患(例:高血圧、糖尿病、自己免疫疾患)がなく、産前フォローアップ中に産科合併症が生じない妊娠であり、診察時に胎児の異常が確認されていないものとして認められました。高リスクと分類された患者はこのシステムの範囲外であり、専門の母体・胎児ケアに紹介されるべきです。

調査結果に基づき、(i) 協議モジュールと (ii) フォローアップモジュールの2つの主要なモジュールが設けられました。各モジュールは実際の臨床ルーチンを反映するよう設計されており、患者ケア中の直感的なナビゲーションと効率的なデータ入力を促進しています。この相談モジュールは、典型的な妊娠前相談プロセスに沿ったいくつかの主要なユースケースを含んでいます。患者入院機能は、新たに患者さんの氏名、国民健康カード(CNS)番号、最終月経日(LMP)を入力することで登録できるようにします。フィールド仕様、フォーマット要件、検証ルールは、クライアントレベルとサーバーレベルの両方で適用されていることが表 1に詳述されています。データの整合性を確保するため、システムはCNS識別子に基づく重複エントリを自動的に防止します。「コンサルテーション開始」機能により、医療従事者はすでに登録済みの患者に対して新しいコンサルテーションを開始し、ユーザーをコンサルテーションインターフェースにリダイレクトします。

フィールド	フォーマット	検証ルール	例
患者名	自由テキスト	最低3キャラクター;アルファベット文字とスペースのみ。	「マリア・ダ・シルヴァ」
CNS(全国) 健康保険証)	15 数値 数字	Luhnベースのアルゴリズムで検証;患者ごとに独自のものでなければなりません。	“70000000 0000001”
LMP日程	DD/MM/YYYY	将来の日付であってはならず、42週間以内に該当していなければなりません 現在の日付より先に。	“01/01/2026”

表1:患者入院現場の仕様、フォーマット要件、検証ルール。 フィールドは人口統計学的、識別、臨床登録要件に基づいて整理されており、標準化された患者のオンボーディングと出生前入院時のデータ一貫性を確保しています。

相談のワークフローは、効率的な妊婦前ケア管理を支援するために、順序的かつ構造化されたプロセスに従っています。まず、医療従事者はメインの患者リストにアクセスし、検索機能を使って名前またはCNS番号で対象患者を特定します。患者を選んだ後、「相談開始」をクリックして相談を開始します。この段階で、システムは選択した患者に紐づいた新しい診察記録を作成し、利用者を診察インターフェースへリダイレクトします。このインターフェースは身体検査、検査室検査、超音波、要約の4つのセクションに分かれています。

身体検査段階では、体重、身長、血圧、報告された訴状などの一般的な臨床パラメータ、さらに子宮の高さや胎児心拍数などの産科パラメータも記録します。このシステムは体格指数(BMI)と妊娠周数を自動で計算・表示し、臨床判断を支援します。検査セクションでは、トリメスター単位の検査結果を対応する入力コントロールで登録でき、完了済みと保留中の検査は視覚的に区別され、出生前プロトコルのモニタリングを容易にしています。

利用可能な場合は、超音波情報も相談に組み込まれることがあります。専門家は超音波登録エリアにアクセスし、報告書を含む対応するフォームに記入できます。すべての関連情報が入力された後、提出機能を通じて協議が完了します。システムは必要な項目を検証し、プロセスが成功すれば患者をフォローアップ画面にリダイレクトします。

フォローアップ画面では、体格指数や子宮高の傾向チャート、過去の診察の時系列リストを含む患者の臨床歴をまとめて表示します。この構造により、妊婦前ケア全体を通じて母体の健康を継続的にモニタリングすることが可能になります。

相談ワークフロー内では、臨床および診断データの記録を支援するための特定の機能が実装されました。身体検査セクションでは、標準化された臨床測定プロトコルに従い、一般および産科のパラメータを記録することが可能です。体重はキログラム(許容範囲:30〜200kg)と身長(許容範囲:1.00〜2.50m)で記録され、BMIは体重(kg)÷身長² (^m2)で自動的に計算されます。血圧は、患者が座った状態で標準的な血圧計測を行った後、収縮期/拡張期値(例:120/80 mmHg)としてmmHg単位で記録されます。子宮の高さ(子宮底高度)は、患者が背側デキュービトゥス(許容範囲:16〜40 cm、妊娠週数依存)で、恥骨結合から子宮底までセンチメートル単位で測定されます。胎児の心拍数は1分間に1拍数で記録されます(正常範囲:110〜160 bpm)。追加の項目には胎児の提示(頭部/逆子/横位)や、浮腫または外腫の表示が含まれる場合が含まれます。

検査インターフェースでは、トリメスター単位の検査結果の登録が可能で、完了済みおよび保留中の検査を示す視覚的な表示で重複を防いでいます。このシステムは、 表2に詳述された妊娠三度ごとの標準的な出生前検査の記録をサポートします。超音波モジュールはオプションで、超音波検査データが利用可能になった際に作動します。項目には、検査日(DD/MM/YYYY)、LMPに基づく検査時の妊娠週数(週)、超音波バイオメトリによる妊娠週数(週)、推定胎児体重(グラム)、胎盤位置(前方/後方/子宮底側/外側)、羊水評価が含まれます。LMPに基づく推定と超音波に基づく妊娠週数の不一致は、推定予定日修正に関する臨床判断を支援するために記録に残されています。試験日を除くすべての科目は任意です。

試験	1位 トリメスター	第2位 トリメスター	第3回 トリメスター
ABO/Rh	必須	–	–
空腹時血糖測定	必須	–	–
経口ブドウ糖耐性検査	必須	–	–
梅毒 — 迅速検査	必須	–	–
VDRL	必須	–	–
間接クームズ検定	必須	–	–
HIV/アンチHIV	必須	繰り返す	–
B型肝炎(HBsAg)	必須	繰り返す	–
トキソプラズマ症	必須	繰り返す	繰り返す
ヘモグロビン/ヘマトクリット	必須	繰り返す	繰り返す
尿検査(EAS)	必須	繰り返す	繰り返す
尿培養	必須	繰り返す	繰り返す

表2:システムが支援する標準的な産前検査(妊娠三ヶ月別に整理)。検査は推奨される産前フォローアップ期間に基づいてグループ化され、プロトコルの遵守を支援し、母体健康の縦断的モニタリングを促進します。

最後に、エンドコンサルテーション機能により、すべての記録されたデータを統合・保存し、専門家を患者のフォローアップ画面に自動的にリダイレクトします。そこでは患者の健康情報の統合された要約が利用可能です。フォローアップレポートは、臨床歴、検査結果、体格指数(BMI)や子宮高などの主要パラメータのグラフ的傾向を統合的に示し、継続的かつデータに基づく母体ケアを支えています。

システムは患者入院時に入力された最後の月経(LMP)日から3つの主要な産科パラメータを自動的に計算します。妊娠週数(GA)は、現在の日付とLMPの日数差を7で割ったものとして計算されます:GA = (現在の日付−LMP) / 7。推定予定日(EDD)は、LMPに280日(40週間)を加えることで得られます:EDD = LMP + 280日。体格指数(BMI)は、身体検査時に記録された体重(kg)と身長(m)から計算されます。

(1)

これらの計算はデータ入力時に自動的に行われ、手作業の計算を省き、転記エラーを減らします。

技術とシステムアーキテクチャ
このシステムはクライアント–サーバーアーキテクチャに従って開発され、ウェブインターフェースベースのフロントエンドがRESTful API¹⁷を通じてバックエンドサービスと相互作用します。このアプローチにより、モジュール性、スケーラビリティ、相互運用性が可能となり、将来的に他の医療情報システムと統合・拡張が可能となります。 図2 は、主な主体である 患者、 診察、 診察、 超音波といった主体と、それぞれの関連性を示すアプリケーションのエンティティ–関係(ER)図を示しています。患者エンティティはモデルの中核として機能し、複数の診察に関連する個人および識別データを維持します。各診察記録には一連の検査や任意の超音波エントリーが関連付けられており、母体健康パラメータの詳細な縦断的追跡が可能です。この関係構造により、臨床データの一貫した整理が可能となり、統合されたフォローアップレポートの作成を支援し、包括的かつ継続的な産前ケア管理を促進します。各エンティティはUUIDのプライマリキーを使用し、専用の deletedAt .フィールドを通じてソフト削除を実装することで、データのトレーサビリティを永久に削除せずに実現しています。主な制約には、患者エンティティ内のCNSフィールドがデータベースレベルで一意として強制され、重複患者登録を防ぐこと、診察のバイタルサイン(体重、身長、子宮高)は臨床的な正確さを保つために小数点で保存されています。また、超音波エンティティは完全に任意であり、識別子によって患者とリンクされ、必須の外部鍵制約はありません。すべてのフィールドタイプと制約を含む完全なスキーマ定義は、公開リポジトリで公開リポジトリに https://github.com/caderneta-digital-da-gestante/api で公開されています。

図2:システムデータベースのエンティティ・リレーションシップ(ER)図。 主に4つのエンティティが存在します:患者(中枢神経系番号やLMP日を含む識別および産科ベースラインデータを保存)、コンサルテーション(各患者受診にリンク)、診察(各相談に関連する三期間の検査結果)、および超音波(各コンサルテーションにリンクされた任意の超音波データ)。1人の患者は複数の相談を行うことがあります。各診察は複数の診察と0件または1件の超音波記録に関連付けられている場合があります。 この図の拡大版はこちらをクリックしてご覧ください。

バックエンドはNode.jsをランタイム環境として用い、ルートやHTTPリクエストの効率的な管理のためのExpress.jsフレームワークを組み合わせて実装されました。データの永続化は、堅牢性とACID原則への準致性が評価されたPostgreSQLリレーショナルデータベース管理システムを通じて処理されました。データベースアクセスを容易にし型安全性を確保するために、Prisma ORMライブラリが採用され、アプリケーションロジックとデータ^{レイヤー18}間の効率的かつ保守可能な相互作用が可能になりました。

フロントエンドはReactとNext.jsフレームワークを組み合わせて構築され、高速でレスポンシブ、検索エンジン最適化されたウェブインターフェースを提供しました。ユーザー操作とフォーム処理は、状態管理にはReact Hook Form、スキーマベースの検証にはZodを用いて実装され、データの一貫性を確保し入力エラーを削減しました。クライアント側のデータ取得とキャッシュはTanStack Queryによって管理され、最適化されたパフォーマンスとバックエンドとのリアルタイムデータ同期が可能となりました。

バージョン管理とデプロイには、プロジェクトはgitとGitHubを利用し、従来のコミット標準に従って明確で追跡可能な開発履歴を維持しました。展開はコンテナ化方式で行われました。前提条件は、Docker 27.x、Vercelアカウント(フロントエンド)、Renderアカウント(バックエンドとデータベース)です。バックエンドには、2つの環境変数を持つ.envファイルが必要です:DATABASE_URL(Renderが提供するPostgreSQL接続文字列)とDIRECT_URL(Prisma移行用の直接接続URL)です。バックエンドを展開するには、dockerイメージをdocker build -t cdg-api. で構築し、Startコマンドnode dist/index.jsとAPI_PORT環境変数を設定してウェブサービスとしてRenderにプッシュします。フロントエンドはVercelダッシュボードを通じてgitHubリポジトリを接続することでVercelにデプロイされます。NEXT_PUBLIC_API_URL環境変数はRenderバックエンドURLに設定されなければなりません。データベースの移行は、最初のデプロイ時にprismaのmigrate deployを通じて適用されます。

データセキュリティとプライバシーに関しては、現行のプロトタイプはエンドユーザー認証を実装しておらず、初期段階の性質を反映しています。患者データはRenderのクラウドインフラストラクチャ上でホストされるPostgreSQLデータベースに保存され、データベースへのアクセスはソースコードに公開されていない環境レベルの認証情報によって制限されます。このユーザビリティ研究の目的上、テストセッション中に使用されたすべての患者記録は架空のものであり、実際の患者データは収集・処理されませんでした。認証およびアクセス制御は、将来の本番対応バージョンの要件として特定されており、ブラジル一般データ保護法(LGPD — 法律第13.709号/2018)に基づくコンプライアンス評価も含まれています。

このシステムはクライアント側とサーバー側の両方の検証を実装しています。フロントエンドでは、React HookフォームとZodスキーマが、必要なフィールドが空または誤ったフォーマットの場合にフォームの提出を防ぎ、インラインエラーメッセージを表示します。バックエンドでは、すべての受信リクエストはドメイン層に到達する前にZodスキーマを解析・検証されます。無効な入力は、影響を受けたフィールドとメッセージを示す構造化エラー応答とともにHTTP 400を返します。ドメインレベルの検証は値オブジェクトを通じて強制されます。CNSフィールドは長さ、数字のみフォーマット、チェックサムアルゴリズム(1〜2桁から始まる恒久CNSと7〜9桁から始まる暫定CNSの両方)で検証されます。重複したCNSエントリは、一意制約によってデータベースレベルで拒否されます。ドメインエラーが発生した場合、APIは説明的なエラーメッセージとともにHTTP 400を返します。成功した操作はHTTP 201(作成)またはHTTP 200(取得)を返します。

ユーザビリティテスト
システムのユーザビリティ評価は、ユーザー満足度と全体的な^{ユーザビリティ}の定量的指標を得るために実施^{されました。}代表的なシナリオやタスクは、妊婦の身体的健康記録に基づく典型的な活動に基づいて設計され、検査が実際の臨床ワークフローを反映していることを確実に^{しました。}

評価は表 3に記載された完全な妊娠前相談ワークフローをカバーする8つのタスクで構成されていました。

任務	参加者への指導	成功基準
1	患者Xの相談はどのように始めますか?	リストまたは検索バーで患者を検索し→「相談開始」をクリックしてください。
2	患者Xの身体検査および産科検査データを入力するにはどのような手順を踏みますか?	身体検査タブにアクセスし→必要な項目を入力し→「次へ」をクリックするか、別のタブに移動します。
3	相談時に検査室検査を追加し、入力したデータを検証するにはどのような手順を踏みますか?	試験タブにアクセスし→試験および学期の「+」をクリックし、フォームを記入→→保存→表示をクリックしてください。
4	超音波検査の結果を記録するにはどのような手順を踏みますか?	超音波タブにアクセスし→「超音波検査を受け取る」をクリックしてフォーム→記入してください。
5	協議を最終決定するためにどのようなステップを踏みますか?	フォームが有効であるか確認→送信をクリックしてください。
6	患者Yの栄養状態の進行や子宮成長曲線をどのように監視しますか?	メイン→ページに戻って患者Yを見つけ→「Caderneta」をクリックしてInfoタブにアクセスし→カルテを閲覧→
7	患者Yの検査がすでに完了しているものを教えてもらえますか?	患者のYのカデルネタにアクセスし→検査タブに移動します。
8	患者Yはこれまでに何回の診察を受けており、その詳細を確認できますか?	相談タブに移動し→「詳細を見る」をクリックしてください。

表3:ユーザビリティ評価タスクと成功基準。 タスクは、患者の検索、相談ワークフロー、データ入力、フォローアップレビューなど、システムの中核機能を評価するように構成されており、成功するためのあらかじめ定義された基準が設定されています。

スノーボールサンプリングで合計5名の医療専門家が募集されました。これは、利用可能性、妊娠前ケア現場での印刷された女性の健康記録の既往実務経験、要件誘導段階に関わる専門家または既に募集された参加者からの紹介の3つの基準に基づいて行われました。正式な人口統計調査は実施されませんでした。構造化された人口統計データの収集は本研究の限界であり、今後の評価の目標とされています。このサンプルサイズは形成的ユーザビリティ研究の確立されたガイドラインと一致しており、5人の参加者でインターフェースにおける最も重要なユーザビリティ問題を特定するのに十分であること^{を示しています。}この数値は統計的一般化には制限がありますが、この予備評価の探索的性質には適しています。テストセッションでは、参加者はウェブアプリケーションを探索し、あらかじめ定められたタスクを声に出して考えながら実行するよう招かれました。セッションの前に、参加者はシステムとは無関係のウォームアップ演習を通じて、思いを出して考える技術を簡単に紹介されました。彼らは評価者の助けを求めることなく、課題の間ずっと自分の考え、行動、困難を絶えず口に出すよう指示されました。タスク実行中に修正フィードバックは提供されませんでした。訓練を受けた観察者が、^{各課題ごとに}観察された困難、ためらい、口頭コメントを記録した構造化されたフィールドノートを記録しました。

各セッション終了時に、参加者はブラジルポルトガル語でSUSアンケートに回答しました。標準的なSUS項目は、例えば「システム」への一般的な参照を「妊婦のデータ登録および相談」「低リスク産前フォローアップ」など、臨床ワークフローに関する具体的な参照に置き換えるなど、文脈に応じて適応されました。これらの適応は、元のスコアリング構造を維持しつつ、ターゲットユーザーグループへの関連性を高めました。SUSは5点リッカート尺度(1=強く反対、5=強く同意)で評価された10の文で構成され、肯定的と否定的な項目を交互に表現しています。スコアは標準的な方法で計算されました。奇数番号の項目では、寄与はスケール位置から1(R − 1)を除いたもので、偶数番号の項目では、寄与は5からスケール位置(5−R)を引いたものです。すべての貢献の合計に2.5を掛け、0から100までの最終スコアが出ます。スコア68を超えると平均以上の使いやすさ²⁴を示します。さらに、システムの強みや改善点に関する質的フィードバックを集めるための2つのオープンエンド質問も実施されました。回答はテーマ分析を用いて分析されました。参加者の回答や思考観察の繰り返しのテーマを2人の研究者が独立してコーディングし、カテゴリーにまとめました。意見の不一致は議論を通じて解決されました。得られたカテゴリー、統合ケアの概要、専門医と患者との関係、ケアの継続性、接続依存性、エクスポート機能の欠如、ユーザーサポートニーズは参加者の回答から帰納的に導き出され、定性的結果表に示されています。

ユーザビリティのセッションはリモートで実施されました。各参加者は、自分のデバイスとデフォルトのウェブブラウザを使って公開されているURLを通じてシステムにアクセスしました。ハードウェア仕様、オペレーティングシステム、ブラウザのバージョンは管理も記録もされていませんでした。これは実際の使用状況を反映していますが、デバイス間のパフォーマンスばらつきがインタラクション体験に影響を与えた可能性があるため、制約となっています。今後の評価では、使いやすさの問題をハードウェアや接続性の変数から分離するために、テスト環境を標準化する必要があります。

結果

結果セクションでは、標準化された尺度からの定量的指標や医療専門家からの質的フィードバックを含むユーザビリティ評価の結果を提示します。この分析は、ウェブベースの妊婦前ケアアプリケーションの効果、効率性、ユーザーの受け入れ度を評価することに焦点を当てています。プロトタイプのユーザビリティ評価では、全体のシステムユーザビリティスケール(SUS)スコアは77.5で、一般的に挙げられる68の基準を上回りました。これは満足のいくユーザビリティを示しています。SUSスコアは正規分布(Shapiro-Wilk検定:W = 0.9076、p = 0.4532)で、平均は77.50、標準偏差は9.35で、 表4に記載されています。受理性の尺度では、ほとんどの参加者から 受理可能 と評価されました。さらに、ネットプロモータースコア(NPS)評価では、5人中3人がこのアプリケーションを プロモーターとして分類しており、システムを好意的に推奨する傾向を示しました。これらの結果は、デジタルツールが妊婦ケアにおけるユーザーインタラ...

ディスカッション

デジタル妊娠記録のプロトタイプは平均SUSスコア77.5(SD = 9.35)を記録し、確立されたベンチマークに基づく許容されるユーザビリティを示しました。この結果は、ドメイン駆動設計の原則^25,26と六角形アーキテクチャ¹³の組み合わせが、システムを実際の臨床ワークフローと密接に整合させることで、認識された使いやすさに良い寄与を強いていることを示唆しています。効率性とエラー防止の高いスコアは、システムが臨床タスクの完了を効果的に支援し、出生前ケアの文脈で重要な入力エラーを最小限に抑えていることを示しています。ブラジルのプライマリヘルスケアで既に使われているデジタルツールと比較して、このシステムは優れた使いやすさを示しました。e-SUSテリトリーシステムは55.3、市民電子健康記録(PEC)はSUSスケールで60.1を記録し、いずれも一般的に受け入れられている68の閾値を下回りました。CDGプロトタイプのス...

材料

この記事で使用された材料の一覧

名前	会社	カタログ番号	コメント
Axios	Axios Contributors	1.8.4	N/A
バックエンドリポジトリ	著者	N/A	N/A
Docker	Docker, Inc.	27.x	N/A
Express.js	OpenJS Foundation	5.1.0	N/A
フロントエンドリポジトリ	著者	N/A	N/A
Next.js	Vercel	15.2.4	N/A
Node.js	OpenJS Foundation	22.x	N/A
PostgreSQL	PostgreSQL Global Dev. Group	15.x	N/A
Prisma ORM	Prisma Data, Inc.	6.5.0	N/A
React	Meta Platforms, Inc.	19.0.0	N/A
React Hook Form	react-hook-form Contributors	7.55.0	N/A
Recharts	recharts Contributors	2.15.3	N/A
Render	Render Services, Inc.	N/A	N/A
TanStack Query	TanStack	5.74.4	N/A
TypeScript	Microsoft	5.8.2	N/A
Vercel	Vercel, Inc.	N/A	N/A
Zod	Colin McDonnell	3.24.2	N/A