Recommendation 1 : Add Principle 2D as: Every transaction over the TEFCA network, including bulk access, is to be accompanied by a contemporaneous email to each individual patient and a monthly statement delivered via email or post if there is activity in that month.
Make Patient-Directed Exchange the Baseline for a National API
Application Programming Interfaces (APIs) are the future of interoperability and mandated by law applicable to TEFCA. The scope of APIs is broad. An API can serve inside a single legal entity to connect one information system to another, it can provide access to one patient per transaction or to a batch of patients, it can connect under the direction of an authorized entity, or it can connect two parties directly on demand by the patient herself. We are familiar with patient-directed interoperability as the paper Release of Information Form submitted to hospital records departments. This fundamental patient right must be preserved and enhanced as we move from paper and Fax to APIs. Using a separate API for entity-directed vs. patient-directed exchange increases the attack surface, confuses patients, and increases cost. If separated, the patient-directed exchange API is likely to be less supported and less functional that the entity-directed API. Errors and security breaches in both APIs are likely to be harder to detect if the two APIs are separate.
Specify that the same API is to be used for both entity-directed and patient-directed exchange. Treat bulk transfers of multiple patients in one transaction as a special case of the API that is not patient-directed, but still notifies the individual patients involved. Ensure that the API does not require more paper-based or in-person processes for patient-directed exchange than are required for entity-directed exchange.
Recommendation 2 : Amend Principle 3A to specify that the same API is to be used for both entity-directed and patient-directed exchange.
Recommendation 3 : Amend Principle 5A to specify that the same API is to be used for both entity-directed and patient-directed exchange.
Recommendation 4 : Amend Principle 6A to clarify that the multiple patient record functionality does not reduce the responsibility to contemporaneously notify individual patients.
Recommendation 5 : Definition of Individual Access 2) is confusing. The API Task Force was clear that blocking of any patient-directed sharing other than one that endangers other patients is prohibited. For example, a patient directed-request to move information to a destination via plain, unsecured email or to a foreign country is acceptable under Applicable Law.
Separate Identity and Authorization Standards from Data Model Standards
Introducing interoperability into a system as large and diverse as healthcare is a tremendous challenge that the draft TEFCA clearly recognizes and seeks to address. Much of this regulation is, quite appropriately, devoted to standards. Some of the standards relate to how health records are encoded. Let’s call this the data model. Other standards relate to how access to a record is controlled. Let’s call this authorization. It is common practice for standards-dependent efforts such as SMART or Argonaut or TEFCA to combine both data model and authorization concerns because there is some overlap in their scope. For example, the data model includes demographic information that is critical to the discovery aspects of authorization around an encounter. Unfortunately, blending projects that seek to standardize the data model with those that seek to standardize the authorization model makes scaling interoperability much harder because it makes healthcare practices less able to benefit from large-scale authorization standards outside of the healthcare domain.
Identity, demographics, and authorization standards are not specific to healthcare. To achieve broad interoperability on a national scale, adopt the Postal Service model of separating what’s on the envelope (authorization) from what’s in the envelope (the data model) and manage the corresponding standards, policies, and practices separately.
We are especially mindful of the multiple portals problem that forces patients to manage consent separately by accessing every separate provider using different protocols and procedures. Just as TEFCA seeks to provide a single on-ramp for providers as End Users it should encourage and ideally offer a single on-ramp for individual patients by allowing the patient to specify their preferred UMA / HEART Authorization Server.
Recommendation 6 : Amend Principle 1A to encourage separation of authorization and data model standards.
Recommendation 7 : Reference Kantara UMA and the profile work of Health Relationship Trust (HEART) as components of ISA.
Recommendation 8 : Any QHIN, Participant, or End User that offers access to Individuals via an API, including the TEFCA-specified API, must allow the Individual to specify and delegate control to a standards-based authorization server of their choosing.
Be Clear About Creating a National Health Encounter Surveillance System
TEFCA is creating a national health encounter surveillance system under the control of the Federal Government. Regardless of the reasons why this might be desirable, the Federal Government needs to be clear that this is a new national agency that manages personal information on substantially everyone just like the IRS, TSA, and FBI. The draft TEFCA is very confusing in this respect. It is hard to draw an analogy to existing systems of identity. State drivers’ licenses are the only common example of a distributed identity system that allows for broadcast queries to some extent, but it is operated by government, founded on coercive biometric databases, and controversial when subject to federal policy like Real ID.
Recommendation 9 : State clearly in the introduction of the proposed regulation that it is national in scope and subject to federal government policy. State also that the system is identity-based, and that a person can have zero, one, or multiple identities in the system.
Recommendation 10 : Definition of Broadcast Query to make clear that it is a national in scope and may include encounters outside of HIPAA Covered Entities.
Recommendation 11 : Definition of Recognized Coordinating Entity (RCE) to make clear that it is controlled by the federal government and subject to the policies of the federal government.
Recommendation 12 : In section 3.3, describe how patients can choose to be tracked, identity-matched, and notified of a match, in a voluntary and non-coercive way.
Recommendation 13 : In section 6.2.4, describe how patients identified only as “known to the practice” under HIPAA or receiving an anonymous service from a laboratory may voluntarily participate, without Identity Proofing in the national system.
If TEFCA is Voluntary, Explain How Patients Can Opt-Out
TEFCA is introduced as voluntary but the draft document is not clear about how a patient can avoid participation in the national surveillance system. Consider, for example, a 15 year old with a severe anxiety attack requiring mental health care. Will this patient be entered into the national system by the emergency department, the psychiatrist, the laboratory, the pharmacy, the insurance company, or all of the above? When this patient turns 18, will he or she have the ability to delete the record of this episode of care from the national system and the process to effect this deletion?
Define how the system is voluntary from the perspective of the patient and describe how a patient opts-out of having an encounter from being entered into system, how a patient is notified when an encounter is added to the system, and how an encounter is deleted from the system.
Recommendation 14 : Amend Principle 5B to replace the reference to Qualified HIN and replace it with a broad statement of participation in the national health encounter surveillance network.
Avoid Introduction of a Hidden Data Brokerage Layer
Current patient rights regulations tend to focus on the right of access to a service provider such as a HIPAA Covered Entity combined with a limit on the ability of Business Associates to aggregate information about an individual across multiple service providers. When a data aggregator or broker is introduced, as for example some state health information exchanges or the Surescripts network, these entities are not well-known to the patient and have no customer relationship with the patient. The result is that these intermediary data brokers are effectively hidden from the patient and not accountable to the patient.
By analogy, we are familiar with the national surveillance system of credit bureaus. Equifax, Experian, and TransUnion are limited in number to three so people can know of all of them, they are regulated to be accessible and responsive to people, and they are required to accept and redistribute comments from the individual. The credit surveillance system also has benefit of a unique person identifier, the Social Security Number, in order to reduce the number of errors that are propagated. Nonetheless, having to deal with three separate data brokers in cases such as identity theft to impose a credit freeze is a major hardship for the individual.
There is, however a major difference between credit surveillance and health surveillance. As individuals we access credit voluntarily but we are compelled to access health care by illness, accident, and misfortune. At a time of suffering and stress, US patients already have to worry about the scope of their insurance network, large unknowable out-of-pocket costs, the impact of their misfortune on employment, disability, and life insurance. These are all hidden consequences of seeking health care. It’s imperative that TEFCA not add another hidden layer to an already stressful system.
To the extent TEFCA envisions a layer of QHINs responsible for managing the location of encounters and consent to access personal information, it is critical that they be accessible and accountable directly to the individual at least as much as the hospitals and service providers are. To the extent TEFCA is establishing a single national data brokerage system like the TSA or the IRS, it is imperative that people know exactly who they are dealing with and how they are identified in the system. Decentralized, private-sector surveillance such as we have for advertising tracking is not appropriate for healthcare.
Recommendation 15 : In Section 7, Access, make RCE the single patient-facing entity, accountable for a consistent policy and a consistent patient identifier across all hospitals, labs, payers, and other service providers. To avoid coercion, allow patients to have multiple, separate RCE identifiers in order to voluntarily segment sensitive encounters from routine one
A National Health Encounter Surveillance System posted first on http://rehabitation.blogspot.com
No comments:
Post a Comment