Public Health Centers: Difference between revisions
Line 5: | Line 5: | ||
In context of the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA Trusted Exchange Framework and Common Agreement (TEFCA)], [https://rce.sequoiaproject.org/SEQUOIA Recognized Coordinating Entity] and health information exchanges, there is ongoing dialogue regarding the data sharing agreement, interoperability, electronica health records using FHIR formats. What’s needed is a plan for engaging vulnerable populations. | In context of the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA Trusted Exchange Framework and Common Agreement (TEFCA)], [https://rce.sequoiaproject.org/SEQUOIA Recognized Coordinating Entity] and health information exchanges, there is ongoing dialogue regarding the data sharing agreement, interoperability, electronica health records using FHIR formats. What’s needed is a plan for engaging vulnerable populations. | ||
The first challenge is Patient Matching which is a life or death as well as a medication fraud issue. The second challenge is the [https://www.healthit.gov/curesrule/ ONC’s Cures Act Final Rule] which makes clear that all Patient Health information needs to be available to patients. Since a large fraction (91%) of the US population at large as well as the vulnerable population have cell phones, this use case will focus on vulnerable patients that have access to a cell phone. The large majority of those are smart phones. When patient outcomes are considered, it may even be cost effective to provide the vulnerable patient with a smart phone. The Cures act explicitly notes that applications provided with smart phones need to be from certified developers and the TEFCA | The first challenge is Patient Matching which is a life or death as well as a medication fraud issue. The second challenge is the [https://www.healthit.gov/curesrule/ ONC’s Cures Act Final Rule] which makes clear that all Patient Health information needs to be available to patients. Since a large fraction (91%) of the US population at large as well as the vulnerable population have cell phones, this use case will focus on vulnerable patients that have access to a cell phone. The large majority of those are smart phones. When patient outcomes are considered, it may even be cost effective to provide the vulnerable patient with a smart phone. The Cures act explicitly notes that applications provided with smart phones need to be from certified developers and the TEFCA adds the requirement for NIST IAL2 and AAL2 (SP 800-63-3) Identity integrated with HIE’s and record locator services to ensure interoperability and patient safety. | ||
Today that is not a realistic or even an achievable goal for vulnerable populations. What is achievable is that our work group can start to put in place a trusted entity infrastructure for a CSP on-ramp coupled with a trust registry that is linked to a record locator service for the specific purpose of serving a vulnerable population with a user friendly app with core functionality content that is interoperable. And there is a way to incentivize user/patients to want to participate that can increase compliance, quality of life and generate a positive ROI. (The proposal being shared originated with IDESG and this team). | Today that is not a realistic or even an achievable goal for vulnerable populations. What is achievable is that our work group can start to put in place a trusted entity infrastructure for a CSP on-ramp coupled with a trust registry that is linked to a record locator service for the specific purpose of serving a vulnerable population with a user friendly app with core functionality content that is interoperable. And there is a way to incentivize user/patients to want to participate that can increase compliance, quality of life and generate a positive ROI. (The proposal being shared originated with IDESG and this team). |
Revision as of 19:44, 13 May 2020
Full Title
Public Health Centers as a Vulnerable Populations use case of the Identity Ecosystem Framework.
Context
In context of the Trusted Exchange Framework and Common Agreement (TEFCA), Recognized Coordinating Entity and health information exchanges, there is ongoing dialogue regarding the data sharing agreement, interoperability, electronica health records using FHIR formats. What’s needed is a plan for engaging vulnerable populations.
The first challenge is Patient Matching which is a life or death as well as a medication fraud issue. The second challenge is the ONC’s Cures Act Final Rule which makes clear that all Patient Health information needs to be available to patients. Since a large fraction (91%) of the US population at large as well as the vulnerable population have cell phones, this use case will focus on vulnerable patients that have access to a cell phone. The large majority of those are smart phones. When patient outcomes are considered, it may even be cost effective to provide the vulnerable patient with a smart phone. The Cures act explicitly notes that applications provided with smart phones need to be from certified developers and the TEFCA adds the requirement for NIST IAL2 and AAL2 (SP 800-63-3) Identity integrated with HIE’s and record locator services to ensure interoperability and patient safety.
Today that is not a realistic or even an achievable goal for vulnerable populations. What is achievable is that our work group can start to put in place a trusted entity infrastructure for a CSP on-ramp coupled with a trust registry that is linked to a record locator service for the specific purpose of serving a vulnerable population with a user friendly app with core functionality content that is interoperable. And there is a way to incentivize user/patients to want to participate that can increase compliance, quality of life and generate a positive ROI. (The proposal being shared originated with IDESG and this team). The trusted entity, a CSP, issues or registers subscriber authenticators and issues and verifies electronic credentials of subscribers including pseudonymous identity, different levels of assurance and identity, including federations.
Regarding the user/patient, their mobile phone/smartphone will be the medium of choice along with a medical facility health kiosk. Users will need a state driver’s license or a state issued ID card plus a Medicaid ID card #. Two factor authentication can be a SMS #, a biometric or a one-time password OTP. The process details will be shared at a later time.
A sister project to the above is the Identity Ecosystem Framework – Registry (IDEF-R) which was a work-effort under NSTIC-IDESG which was designed and partially built (2/3 complete) with funding from NIST. The members of that team are the same individuals now on the Kantara FIRE Work Group (Federated Identity Resilient Ecosystem) which I am Chair. The software is available for demonstration and has been demonstrated to the CARIN Alliance Identity Work Group of which I am a member.
References
- Design Principles/Goals for a Healthcare Identity Environment Architecture shared with the ONC in February 2020 in support of the Cures Act formalization. Signed by Dr. Thomas Sullivan, chair of the Healthcare Identity Assurance Work Group, and Jim Kragh, chair of the Federated Identifiers Work Group, of the Kantara Initiative.
- See the wiki page on the Phone as Health Care Credential as providing a large part of the US population with excellent patient matching.
- See the wiki page on Patient Choice as requiring a high level of protection for patient health information outside of HIPAA servers.