Patient Registration with Distributed Attributes: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
No edit summary
Line 23: Line 23:
## Driver's licence
## Driver's licence
## Payment card to be used for co-pays or other changes which may occur. (Cash may be possible, but is not considered here.)
## Payment card to be used for co-pays or other changes which may occur. (Cash may be possible, but is not considered here.)
# Different providers are unlikely to allow each other, or the patient, to write into their [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR], so it is expected that the patient will have multiple repositories, each with their own [https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier].
## Other providers will have an [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR] with its own [https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier] that they patient could potentially bring with them to gather existed [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR].
# Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
# Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
# The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.
# The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.

Revision as of 20:37, 27 April 2019

Full Title of Use Case

Patient at private care provider (PCP) on-boarding ceremony to create initial EHR.

Context

  • To provide good assurance that a patient data records are as accurate as possible and relate to a real live person.

Goal

  • The patient in the very near future has full capability to exercise their right to participate in the care plan and see who has access to their medical records.
  • Provide the two apis as described in the Health Care Profile.
  1. Trusted Identifiers for all providers, and perhaps patients as well.
  2. Consent experience that gives the patient rightful ownership of their data and where it is shared.

Actors

  1. Patient
  2. Provider of patient's general health care

Preconditions

  1. The patient has self-selected to become "known to the practice" where general health care is provided.
  2. A trust registry of providers exists (based on TEFCA) which the patient knows and trusts.
  3. The private care provider (PCP) presents the patient with a trusted identity which confirms that they subscribe to the privacy regulations of TEFCA.
  4. The PCP give the patient a list of documents to bring with them 30 minutes before the first appointment with the provider; for example:
    1. Health Insurance card
    2. Driver's licence
    3. Payment card to be used for co-pays or other changes which may occur. (Cash may be possible, but is not considered here.)
    4. Other providers will have an EHR with its own Medical Records Identifier that they patient could potentially bring with them to gather existed EHR.
  5. Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
  6. The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.

Optional Conditions

Scenarios

The goal of this scenario is to test the functionality of the APIs associated with patient trust of the providers and patient consent granting and recording.

Primary Scenario:

  1. Patient schedules an appointment with primary care physician and is authenticated at the front desk. (This might involve re-affirmation of the consent with the practice.)
  2. Patient sees the doctor, is reauthenticated (this reauth will be less onerous than that at the front desk) and explains symptoms.
  3. Doctor schedules a lab test for a sensitive condition (for example sexually transmitted disease) in order to test patient consent to share such information with referral.


Alternate Scenario:

  1. The patient can sign onto the various practices' web sites and preform the actions from the comfort of her living room. In this case electronic consents are appropriate.
  2. In this case the consent receipts will be renderable to the user in plain language that they can understand.

Results

Accepted Risks:

  1. Data transfers involved work within a framework of trust and mutual understand as to the patient's wishes with respect to care and privacy.

Post Condition:

  1. r.

Examples:

  1. tbd

Dependencies::

  1. Web Sites must be trusted before any user information is released.
  2. Trust federations can be used to help users make informed decisions.
  3. User consent and trust must begin with no user information transferred.
  4. Standards exist to collect needed attributes where-ever they may be.

Workflow Diagram

TK


References