A Conceptual Model to Share Resources and Align Goals: Building Blockchain Application to Support Care Continuity Outside a Hospital
Notice bibliographique
Résumé
The increased use of advanced technologies by consumers and hospitals is moving care closer to patients, and the challenge is one of how patient data can be shared with external care providers and patients. To support care continuity, patient data include both clinical data used by external care providers and non-clinical data used by social care providers. Care coordination of a patient outside a hospital requires peer-to-peer connectivity among a number of these clinical and social care providers, using a digital platform that aligns their goals and assigns their resource sharing responsibilities. With no single entity supporting such care coordination, most hospitals currently distribute this responsibility to several of its provider partners and patients. Such a division of responsibility with no real time feedback leads to discontinuous resource sharing, localized data analysis, and challenges in tailoring care to improve health outcomes. The goal of this paper is to propose a blockchain architecture model that uses a number of constructs for creating and assigning ownership to patient data so it can support peer-to-peer resource sharing and uses smart contracts to support goal alignment. Using two blockchain applications implemented in Hyperledger and illustrating their potential representation using the constructs in multi-chain, we develop a conceptual model for developing blockchain applications in general to support continuity of care. The generalizability of this model is illustrated by applying these constructs to four additional healthcare applications. Finally, we conclude the paper with a discussion of the limitations and directions for future research.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,000 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».