This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Bulk Data Transfer Privacy and Security Concerns

From HL7Wiki
Jump to navigation Jump to search

Posted on September 20, 2017 by Grahame Grieve. Details below

  • Security WG Bulk Data Transfer Comments on Chat - Zulip and Grahame Grieve's responses (Thanks John for posting for use and the dialogue with Grahame):

John Moehrke: @Grahame Grieve The Security WG looked at the Bulk Data Access proposal, and we have some Privacy and Security "Considerations". We recognize that you are simply trying to address a technical need for a solution to Bulk Data Access, and you have been careful to indicate that you have not addressed Security. We would agree with the modularity of focusing on the access method without conflating Security/Privacy; but we also want to make sure that this Bulk Data Access has a Privacy and Security Considerations so that use of the method DOES consider these issues. The Security WG minutes contain these 'issues', we stayed away from declaring 'solutions' although we do think there are ready accessible solutions. We would like to be included on development to help address these issues. See http://wiki.hl7.org/index.php?title=October_3,_2017_Security_Conference_Call#Bulk_Data_Transfer_Access_Control_.26_AuthorizationQuestions:

  • John Moehrke: Generally we are not clear what kind of use-case would allow this level of access, especially with a PERMIT without exceptions. Given that we expect many exceptions, we are concerned that a mechanism is needed to recognize the exceptions and obligations. Second we would like to assure that audit logging be specified in a way that is actionable but not unnecessarly verbose.
  • John Moehrke: There was also discussion and support for a companion method for service to de-identify, such as I outline on my blog https://healthcaresecprivacy.blogspot.com/2017/09/fhir-and-bulk-de-identification.html
  • Grahame Grieve: in general, I expect that the API itself will be use for a variety of purposes of use
  • Grahame Grieve: in general, for all the uses, there will be consent/authorization/access control issues.
  • Grahame Grieve: as yet, we have had no requests for anything related to these to appear on the API itself.
  • Grahame Grieve: we did refer a number of policy issues back to ONC for clarification - these are US specific things
  • Grahame Grieve: I agree that there's a place for de-identification in the service, but as yet this is not required or asked for
  • Grahame Grieve: finally, audit logging is a policy question. We do't anywhere specify that audit logging is required, and nor should we in the base specification

implementers > Bulk Data Access Today

  • John Moehrke: I agree that many of these issues are not the issues we would address in a core specification. But we can put them in a "Security/Privacy Considerations" section so that those that are using the core capability are informed of some of the 'considerations' . This is minimally all we ask. This is what IETF, W3C, ISO, IHE, and DICOM are doing today. This is what our Security Risk Assessment Cookbook intended to drive to happen.
  • Grahame Grieve: do you think this is different to any other access that FHIR permits?
  • John Moehrke: Yes, for the above reasons...
  • John Moehrke: The use-cases that SMART focused on were targeting either Treatment (this patient, or any patient I have access to), or accesses by the Patient themselves. These are the use-case focus that has driven the development of the scope patterns today.
  • John Moehrke: Basically, the 'risk' -- 'impact' for bulk data access is 'everyone'; where a Provider or Patient access is more clearly one-patient-at-a-time.

Policy Material

HHS Regulations as Amended January 2013 Privacy of Individually Identifiable Health Information: Definition: Payment - § 164.501 Payment means: 1. The activities undertaken by: i. Except as prohibited under §164.502(a)(5)(i), a health plan to obtain premiums or to determine or fulfill its responsibility for coverage and provision of benefits under the health plan; or ii. A health care provider or health plan to obtain or provide reimbursement for the provision of health care; and 2. The activities in paragraph (1) of this definition relate to the individual to whom health care is provided and include, but are not limited to: i. Determinations of eligibility or coverage (including coordination of benefits or the determination of cost sharing amounts), and adjudication or subrogation of health benefit claims; ii. Risk adjusting amounts due based on enrollee health status and demographic characteristics; iii. Billing, claims management, collection activities, obtaining payment under a contract for reinsurance (including stop-loss insurance and excess of loss insurance), and related health care data processing; iv. Review of health care services with respect to medical necessity, coverage under a health plan, appropriateness of care, or justification of charges; v. Utilization review activities, including precertification and preauthorization of services, concurrent and retrospective review of services; and vi. Disclosure to consumer reporting agencies of any of the following protected health information relating to collection of premiums or reimbursement: A. Name and address; B. Date of birth; C. Social security number; D. Payment history; E. Account number; and F. Name and address of the health care provider and/or health plan. HHS Description and Commentary from the January 2013 Amendments Privacy of Individually Identifiable Health Information: Definition: Payment Proposed Rule The definition of “payment” in the Privacy Rule at § 164.501 includes activities, such as “determinations of eligibility or coverage” by a health plan, some of which may fall within the definition of “underwriting purposes.” To avoid any implication that a health plan would be permitted to use or disclose protected health information for “payment” purposes that are otherwise prohibited by the underwriting prohibition, we proposed to include a cross-reference in the definition of “payment” to the prohibition. Further, we believed the inclusion of such a cross-reference to be necessary to properly align the definition of “payment” in the Privacy Rule with the nondiscrimination provisions of GINA Title I and their implementing regulations. GINA provides a rule of construction at section 102(a)(2), which adds paragraph 2702(c)(3) of the PHSA, to make clear that health plans are not prohibited from obtaining and using the results of a genetic test in making determinations regarding payment, as such term is defined by the HIPAA Privacy Rule. Thus, the proposed exception would make clear that GINA’s rule of construction regarding payment does not allow a health plan to use the results of genetic tests for activities that would otherwise constitute “underwriting purposes,” such as for determinations of eligibility for benefits. Overview of Public Comments The Department received two comments on the proposed change to the definition of “payment,” one supporting the change and one indicating it is unnecessary. Final Rule For the reasons described above, the final rule adopts the proposed change to the definition of “payment.” HHS Description from Original Rulemaking Privacy of Individually Identifiable Health Information: Definition: Payment We proposed the term payment to mean: (1) The activities undertaken by or on behalf of a covered entity that is: (i) A health plan, or by a business partner on behalf of a health plan, to obtain premiums or to determine or fulfill its responsibility for coverage under the health plan and for provision of benefits under the health plan; or (ii) A health care provider or health plan, or a business partner on behalf of such provider or plan, to obtain reimbursement for the provision of health care. (2) Activities that constitute payment include: (i) Determinations of coverage, adjudication or subrogation of health benefit claims; (ii) Risk adjusting amounts due based on enrollee health status and demographic characteristics; (iii) Billing, claims management, and medical data processing; (iv) Review of health care services with respect to medical necessity, coverage under a health plan, appropriateness of care, or justification of charges; and (v) Utilization review activities, including precertification and preauthorization of services. In the final rule, we maintain the general approach of defining of payment: payment activities are described generally in the first clause of the definition, and specific examples are given in the second clause. Payment activities relate to the covered entity that maintains the protected health information (i.e., one covered entity may not disclose protected health information for the payment activities of a second covered entity). A covered entity may use or disclose only the protected health information about the individual to whom care was rendered, for its payment activities (e.g., a provider may disclose protected health information only about the patient to whom care was rendered in order to obtain payment for that care, or only the protected health information about persons enrolled in the particular health plan that seeks to audit the provider's records). We expand the proposed list to reflect many changes requested by commenters. We add eligibility determinations as an activity included in the definition of payment. We expand coverage determinations to include the coordination of benefits and the determination of a specific individual's cost sharing amounts. The rule deletes activities related to the improvement of methods of paying or coverage policies from this definition and instead includes them in the definition of health care operations. We add to the definition “collection activities.” We replace “medical data processing” activities with health care data processing related to billing, claims management, and collection activities. We add activities for the purpose of obtaining payment under a contract for reinsurance (including stop-loss and excess of loss insurance). Utilization review activities now include concurrent and retrospective review of services. In addition, we modify this definition to clarify that the activities described in section 1179 of the Act are included in the definition of “payment.” We add new subclause (vi) allowing covered entities to disclose to consumer reporting agencies an individual's name, address, date of birth, social security number and payment history, account number, as well as the name and address of the individual's health care provider and/or health plan, as appropriate. Covered entities may make disclosure of this protected health information to consumer reporting agencies for purposes related to collection of premiums or reimbursement. This allows reporting not just of missed payments and overdue debt but also of subsequent positive payment experience (e.g., to expunge the debt). We consider such positive payment experience to be “related to” collection of premiums or reimbursement. The remaining activities described in section 1179 are included in other language in this definition. For example, “authorizing, processing, clearing, settling, billing, transferring, reconciling or collecting, a payment for, or related to, health plan premiums or health care” are covered by paragraph (2)(iii) of the definition, which allows use and disclosure of protected health information for “billing, claims management, collection activities and related health care data processing.” “Claims management” also includes auditing payments, investigating and resolving payment disputes and responding to customer inquiries regarding payments. Disclosure of protected health information for compliance with civil or criminal subpoenas, or with other applicable laws, are covered under § 164.512 of this regulation. (See discussion above regarding the interaction between 1179 and this regulation.) We modify the proposed regulation text to clarify that payment includes activities undertaken to reimburse health care providers for treatment provided to individuals. Covered entities may disclose protected health information for payment purposes to any other entity, regardless of whether it is a covered entity. For example, a health care provider may disclose protected health information to a financial institution in order to cash a check or to a health care clearinghouse to initiate electronic transactions. However, if a covered entity engages another entity, such as a billing service or a financial institution, to conduct payment activities on its behalf, the other entity may meet the definition of 'business associate' under this rule. For example, an entity is acting as a business associate when it is operating the accounts receivable system on behalf of a health care provider. Similarly, payment includes disclosure of protected health information by a health care provider to an insurer that is not a 'health plan' as defined in this rule, to obtain payment. For example, protected health information may be disclosed to obtain reimbursement from a disability insurance carrier. We do not interpret the definition of “payment” to include activities that involve the disclosure of protected health information by a covered entity, including a covered health care provider, to a plan sponsor for the purpose of obtaining payment under a group health plan maintained by such plan sponsor, or for the purpose of obtaining payment from a health insurance issuer or HMO with respect to a group health plan maintained by such plan sponsor, unless the plan sponsor is performing plan administration pursuant to § 164.504(f). The Transactions Rule adopts standards for electronic health care transactions, including two for processing payments. We adopted the ASC X12N 835 transaction standard for "Health Care Payment and Remittance Advice" transactions between health plans and health care providers, and the ASC X12N 820 standard for “Health Plan Premium Payments” transactions between entities that arrange for the provision of health care or provide health care coverage payments and health plans. Under these two transactions, information to effect funds transfer is transmitted in a part of the transaction separable from the part containing any individually identifiable health information. We note that a covered entity may conduct the electronic funds transfer portion of the two payment standard transactions with a financial institution without restriction, because it contains no protected health information. The protected health information contained in the electronic remittance advice or the premium payment enrollee data portions of the transactions is not necessary either to conduct the funds transfer or to forward the transactions. Therefore, a covered entity may not disclose the protected health information to a financial institution for these purposes. A covered entity may transmit the portions of the transactions containing protected health information through a financial institution if the protected health information is encrypted so it can be read only by the intended recipient. In such cases no protected health information is disclosed and the financial institution is acting solely as a conduit for the individually identifiable data.

HHS Response to Comments Received from Original Rulemaking Privacy of Individually Identifiable Health Information: Definition: Payment Comment: One commenter urged that the Department not permit protected health information to be disclosed to a collection agency for collecting payment on a balance due on patient accounts. The commenter noted that, at best, such a disclosure would only require the patient's and/or insured's address and phone number. Response: We disagree. A collection agency may require additional protected health information to investigate and assess payment disputes for the covered entity. For example, the collection agency may need to know what services the covered entity rendered in order to resolve disputes about amounts due. The information necessary may vary, depending on the nature of the dispute. Therefore we do not specify the information that may be used or disclosed for collection activities. The commenter's concern may be addressed by the minimum necessary requirements in § 164.514. Under those provisions, when a covered entity determines that a collection agency only requires limited information for its activities, it must make reasonable efforts to limit disclosure to that information. Comment: A number of commenters supported retaining the expansive definition in the proposed rule so that current methods of administering the claims payment process would not be hindered by blocking access to protected health information. Response: We agree and retain the proposed overall approach to the definition. Comment: Some commenters argued that the definition of “payment' should be narrowly interpreted as applying only to the individual who is the subject of the information. Response: We agree with the commenter and modify the definition to clarify that payment activities relate to the individual to whom health care is provided. Comment: Another group of commenters asserted that the doctor-patient relationship was already being interfered with by the current practices of managed care. For example, it was argued that the definition expanded the power of government and other third party “payors,” turning them into controllers along with managed care companies. Others stated that activities provided for under the definition occur primarily to fulfill the administrative function of managed health plans and that an individual's privacy is lost when his or her individually identifiable health information is shared for administrative purposes. Response: Activities we include in the definition of payment reflect core functions through which health care and health insurance services are funded. It would not be appropriate for a rule about health information privacy to hinder mechanisms by which health care is delivered and financed. We do not through this rule require any health care provider to disclose protected health information to governmental or other third party payors for the activities listed in the payment definition. Rather, we allow these activities to occur, subject to and consistent with the requirements of this rule. Comment: Several commenters requested that we expand the definition to include “coordination of benefits” as a permissible activity. Response: We agree and modify the definition accordingly. Comment: A few commenters raised concerns that the use of “medical data processing” was too restrictive. It was suggested that a broader reference such as “health related” data processing would be more appropriate. Response: We agree and modify the definition accordingly. Comment: Some commenters suggested that the final rule needed to clarify that drug formulary administration activities are payment related activities. Response: While we agree that uses and disclosures of protected health information for drug formulary administration and development are common and important activities, we believe these activities are better described as health care operations and that these activities come within that definition. Comment: Commenters asked that the definition include calculation of prescription drug costs, drug discounts, and maximum allowable costs and copayments. Response: Calculations of drug costs, discounts, or copayments are payment activities if performed with respect to a specific individual and are health care operations if performed in the aggregate for a group of individuals. Comment: We were urged to specifically exclude “therapeutic substitution” from the definition. Response: We reject this suggestion. While we understand that there are policy concerns regarding therapeutic substitution, those policy concerns are not primarily about privacy and thus are not appropriately addressed in this regulation. Comment: A few commenters asked that patient assistance programs (PAPS) should be excluded from the definition of payment. Such programs are run by or on behalf of manufacturers and provide free or discounted medications to individuals who could not afford to purchase them. Commenters were concerned that including such activities in the definition of payment could harm these programs. For example, a university school of pharmacy may operate an outreach program and serve as a clearinghouse for information on various pharmaceutical manufacturer PAPS. Under the program state residents can submit a simple application to the program (including medication regimen and financial information), which is reviewed by program pharmacists who study the eligibility criteria and/or directly call the manufacturer's program personnel to help evaluate eligibility for particular PAPS. The program provides written guidance to the prescribing physicians that includes a suggested approach for helping their indigent patients obtain the medications that they need and enrollment information for particular PAPS. Response: We note that the concerns presented are not affected by definition of “payment.” The application of this rule to patient assistance programs activities will depend on how the individual programs operate and are affected primarily by the definition of treatment. Each of these programs function differently, so it is not possible to state a blanket rule for whether and how the rule affects such programs. Under the example provided, the physician who contacts the program on behalf of a patient is managing the patient's care. If the provider is also a covered entity, he or she would be permitted to make such a “treatment” disclosure of protected health information if a general consent had been obtained from the patient. Depending on the particular facts, the manufacturer, by providing the prescription drugs for an individual, could also be providing health care under this rule. Even so, however, the manufacturer may or may not be a covered entity, depending on whether or not it engages in any of the standard electronic transactions (See the definition of a covered entity). It also may be an indirect treatment provider, since it may be providing the product through another provider, not directly to the patient. In this example, the relevant disclosures of protected health information by any covered health care provider with a direct treatment relationship with the patient would be permitted subject to the general consent requirements of § 164.506. Whether and how this rule affects the school of pharmacy is equally dependent on the specific facts. For example, if the school merely provides a patient or a physician with the name of a manufacturer and a contact phone number, it would not be functioning as a health care provider and would not be subject to the rule. However, if the school is more involved in the care of the individual, its activities could come in within the definition of “health care provider” under this rule. Comment: Commenters pointed out that drugs may or may not be “covered” under a plan. Individuals, on the other hand, may or may not be “eligible” for benefits under a plan. The definition should incorporate both terms to clarify that determinations of both coverage and eligibility are payment activities. Response: We agree and modify the rule to include “eligibility”. Comment: Several commenters urged that “concurrent and retrospective review” were significant utilization review activities and should be incorporated. Response: We agree and modify the definition accordingly. Comment: Commenters noted that the proposed rule was not clear as to whether protected health information could be used to resolve disputes over coverage, including appeals or complaints regarding quality of care. Response: We modify the definition of payment to include resolution of payment and coverage disputes; the final definition of payment includes “the adjudication ... of health benefit claims.” The other examples provided by commenters, such as arranging, conducting, or assistance with primary and appellate level review of enrollee coverage appeals, also fall within the scope of adjudication of health benefits claims. Uses and disclosures of protected health information to resolve disputes over quality of care may be made under the definition of “health care operations” (see above). Comment: Some commenters suggested that if an activity falls within the scope of payment it should not be considered marketing. Commenters supported an approach that would bar such an activity from being construed as “marketing” even if performing that activity would result in financial gain to the covered entity. Response: We agree that the proposed rule did not clearly define 'marketing,' leaving commenters to be concerned about whether payment activities that result in financial gain might be considered marketing. In the final rule we add a definition of marketing and clarify when certain activities that would otherwise fall within that definition can be accomplished without authorization. We believe that these changes will clarify the distinction between marketing and payment and address the concerns raised by commenters. Comment: Commenters asserted that HHS should not include long-term care insurance within the definition of “health plan”. If they are included, the commenters argued that the definition of payment must be modified to reflect the activities necessary to support the payment of long-term care insurance claims. As proposed, commenters argued that the definition of payment would not permit long term care insurers to use and disclose protected health information without authorization to perform functions that are “compatible with and directly relate to...payment” of claims submitted under long term care policies. Response: Long-term care policies, except for nursing home fixed-indemnity policies, are defined as health plans by the statute (see definition of “health plan,” above). We disagree with the assertion that the definition of payment does not permit long term care insurers to undertake these necessary activities. Processing of premium payments, claims administration, and other activities suggested for inclusion by the commenters are covered by the definition. The rule permits protected health information to be used or disclosed by a health plan to determine or fulfill its responsibility for provision of benefits under the health plan. Comment: Some commenters argued that the definition needs to be expanded to include the functions of obtaining stop-loss and ceding reinsurance. Response: We agree that use and disclosure of protected health information for these activities should be permitted without authorization, but have included them under health care operation rather than payment. Comment: Commenters asked that the definition be modified to include collection of accounts receivable or outstanding accounts. Commenters raised concern that the proposed rule, without changes, might unintentionally prevent the flow of information between medical providers and debt collectors. Response: We agree that the proposed definition of payment did not explicitly provide for “collection activities” and that this oversight might have impeded a covered entity's debt collection efforts. We modify the regulatory text to add “collection activities.” Comment: The preamble should clarify that self-insured group health and workers' compensation plans are not covered entities or business partners. Response: The statutory definition of health plan does not include workers' compensation products. See the discussion of “health plan” under § 160.103 above. Comment: Certain commenters explained that third party administrators usually communicate with employees through Explanation of Benefit (EOB) reports on behalf of their dependents (including those who might not be minor children). Thus, the employee might be apprized of the medical encounters of his or her dependents but not of medical diagnoses unless there is an over-riding reason, such as a child suspected of drug abuse due to multiple prescriptions. The commenters urged that the current claim processing procedures be allowed to continue. Response: We agree. We interpret the definition of payment and, in particular the term 'claims management,' to include such disclosures of protected health information. Comment: One private company noted that pursuant to the proposed Transactions Rule standard for payment and remittance advice, the ASC X12N 835 can be used to make a payment, send a remittance advice, or make a payment and send remittance advice by a health care payor and a health care provider, either directly or through a designated financial institution. Because a remittance advice includes diagnostic or treatment information, several private companies and a few public agencies believed that the proposed Transactions Rule conflicted with the proposed privacy rule. Two health plans requested guidance as to whether, pursuant to the ASC X12N 835 implementation guide, remittance advice information is considered “required” or “situational.” They sought guidance on whether covered entities could include benefits information in payment of claims and transfer of remittance information. One commenter asserted that if the transmission of certain protected health information were prohibited, health plans may be required to strip remittance advice information from the ASC X12N 835 when making health care payments. It recommended modifying the proposed rule to allow covered entities to provide banks or financial institutions with the data specified in any transaction set mandated under the Transactions Rule for health care claims payment. Similarly, a private company and a state health data organization recommended broadening the scope of permissible disclosures pursuant to the banking section to include integrated claims processing information, as contained in the ASC X12N 835 and proposed for adoption in the proposed Transactions Rule; this transaction standard includes diagnostic and treatment information. The company argued that inclusion of diagnostic and treatment information in the data transmitted in claims processing was necessary for comprehensive and efficient integration in the provider's patient accounting system of data corresponding with payment that financial institutions credit to the provider's account. A state health data organization recommended applying these rules to financial institutions that process electronic remittance advice pursuant to the Transactions Rule. Response: The Transactions Rule was published August 17, 2000, after the issuance of the privacy proposed rule. As noted by the commenters, the ASC X12N 835 we adopted as the “Health Care Payment and Remittance Advice” standard in the Transactions Rule has two parts. They are the electronic funds transfer (EFT) and the electronic remittance advice (ERA). The EFT part is optional and is the mechanism that payors use to electronically instruct one financial institution to move money from one account to another at the same or at another financial institution. The EFT includes information about the payor, the payee, the amount, the payment method, and a reassociation trace number. Since the EFT is used to initiate the transfer of funds between the accounts of two organizations, typically a payor to a provider, it includes no individually identifiable health information, not even the names of the patients whose claims are being paid. The funds transfer information may also be transmitted manually (by check) or by a variety of other electronic means, including various formats of electronic transactions sent through a payment network, such as the Automated Clearing House (ACH) Network. The ERA, on the other hand, contains specific information about the patients and the medical procedures for which the money is being paid and is used to update the accounts receivable system of the provider. This information is always needed to complete a standard Health Care Payment and Remittance Advice transaction, but is never needed for the funds transfer activity of the financial institution. The only information the two parts of this transaction have in common is the reassociation trace number. Under the ASC X12N 835 standard, the ERA may be transmitted alone, directly from the health plan to the health care provider and the reassociation trace number is used by the provider to match the ERA information with a specific payment conducted in some other way (e.g., EFT or paper check). The standard also allows the EFT to be transmitted alone, directly to the financial institution that will initiate the payment. It also allows both parts to be transmitted together, even though the intended recipients of the two parts are different (the financial institution and the provider). For example, this would be done when the parties agree to use the ACH system to carry the ERA through the provider's bank to the provider when it is more efficient than sending the ERA separately through a different electronic medium. Similarly, the ASC X12N 820 standard for premium payments has two parts, an EFT part (identical to that of the 835) and a premium data part containing identity and health information about the individuals for whom health insurance premiums are being paid. The transmission of both parts of the standards are payment activities under this rule, and permitted subject to certain restrictions. Because a financial institution does not require the remittance advice or premium data parts to conduct funds transfers, disclosure of those parts by a covered entity to it (absent a business associate arrangement to use the information to conduct other activities) would be a violation of this rule. We note that additional requirements may be imposed by the final Security Rule. Under the proposed Security Rule, the ACH system and similar systems would have been considered "open networks" because transmissions flow unpredictably through and become available to member institutions who are not party to any business associate agreements (in a way similar to the internet). The proposed Security Rule would require any protected health information transferred through the ACH or similar system to be encrypted. Comment: A few commenters noted the Gramm-Leach-Bliley (GLB) Act (Pub.L. 106-102) allows financial holding companies to engage in a variety of business activities, such as insurance and securities, beyond traditional banking activities. Because the term “banking” may take on broader meaning in light of these changes, the commenter recommended modifying the proposed rule to state that disclosure of diagnostic and treatment information to banks along with payment information would constitute a violation of the rule. Specifically, the organization recommended clarifying in the final rule that the provisions included in the proposed section on banking and payment processes (proposed § 164.510(i)) govern payment processes only and that all activities of financial institutions that did not relate directly to payment processes must be conducted through business partner contracts. Furthermore, this group recommended clarifying that if financial institutions act as payors, they will be covered entities under the rule. Response: We recognize that implementation of the GLB Act will expand significantly the scope of activities in which financial holding companies engage. However, unless a financial institution also meets the definition of a “covered entity,” it cannot be a covered entity under this rule. We agree with the commenters that disclosure of diagnostic and specific treatment information to financial institutions for many banking and funds processing purposes may not be consistent with the minimum necessary requirements of this final rule. We also agree with the commenters that financial institutions are business associates if they receive protected health information when they engage in activities other than funds processing for covered entities. For example, if a health care provider contracts with a financial institution to conduct “back office” billing and accounts receivable activities, we require the provider to enter into a business associate contract with the institution. Comment: Two commenters expressed support for the proposed rule's approach to disclosure for banking and payment processes. On the other hand, many other commenters were opposed to disclosure of protected health information without authorization to banks. One commenter said that no financial institution should have individually identifiable health information for any reason, and it said there were technological means for separating identity from information necessary for financial transactions. Some commenters believed that implementation of the proposed rule's banking provisions could lead banks to deny loans on the basis of individuals' health information. Response: We seek to achieve a balance between protecting patient privacy and facilitating the efficient operation of the health care system. While we agree that financial institutions should not have access to extensive information about individuals' health, we recognize that even the minimal information required for processing of payments may effectively reveal a patient's health condition; for example, the fact that a person has written a check to a provider suggests that services were rendered to the person or a family member. Requiring authorization for disclosure of protected health information to a financial institution in order to process every payment transaction in the health care system would make it difficult, if not impossible, for the health care system to operate effectively. See also discussion of section 1179 of the Act above. Comment: Under the proposed rule, covered entities could have disclosed the following information without consent to financial institutions for the purpose of processing payments: (1) the account holder's name and address; (2) the payor or provider's name and address; (3) the amount of the charge for health services; (4) the date on which services were rendered; (5) the expiration date for the payment mechanism, if applicable (e.g., credit card expiration date); and (6) the individual's signature. The proposed rule solicited comments on whether additional data elements would be necessary to process payment transactions from patients to covered entities. One commenter believed that it was unnecessary to include this list in the final rule, because information that could have been disclosed under the proposed minimum necessary rule would have been sufficient to process banking and payment information. Another private company said that its extensive payment systems experience indicated that we should avoid attempts to enumerate a list of information allowed to be disclosed for banking and payment processing. Furthermore, the commenter said, the proposed rule's list of information allowed to be disclosed was not sufficient to perform the range of activities necessary for the operation of modern electronic payment systems. Finally, the commenter said, inclusion of specific data elements allowed to be disclosed for banking and payment processes rule would stifle innovation in continually evolving payment systems. Thus, the commenter recommended that in the final rule, we eliminate the minimum necessary requirement for banking and payment processing and that we do not include a list of specific types of information allowed to be disclosed for banking and payment processes. On the other hand, several other commenters supported applying the minimum necessary standard to covered entities' disclosures to financial institutions for payment processing. In addition, these groups said that because financial institutions are not covered entities under the proposed rule, they urged Congress to enact comprehensive privacy legislation to limit financial institutions' use and re-disclosure of the minimally necessary protected health information they could receive under the proposed rule. Several of these commenters said that, in light of the increased ability to manipulate data electronically, they were concerned that financial institutions could use the minimal protected health information they received for making financial decisions. For example, one of these commenters said that a financial institution could identify an individual who had paid for treatment of domestic violence injuries and subsequently could deny the individual a mortgage based on that information. Response: We agree with the commenters who were concerned that a finite list of information could hamper systems innovation, and we eliminate the proposed list of data items. However, we disagree with the commenters who argued that the requirement for minimum necessary disclosures not apply to disclosures to financial institution or for payment activities. They presented no persuasive reasons why these disclosures differ from others to which the standard applies, nor did they suggest alternative means of protecting individuals' privacy. Further, with elimination of the proposed list of items that may be disclosed, it will be necessary to rely on the minimum necessary disclosure requirement to ensure that disclosures for payment purposes do not include information unnecessary for that purposes. In practice, the following is the information that generally will be needed: the name and address of the individual; the name and address of the payor or provider; the amount of the charge for health services; the date on which health services were rendered; the expiration date for the payment mechanism, if applicable (i.e., credit card expiration date); the individual's signature; and relevant identification and account numbers. Comment: One commenter said that the minimum necessary standard would be impossible to implement with respect to information provided on its standard payment claim, which, it said, was used by pharmacies for concurrent drug utilization review and that was expected to be adopted by HHS as the national pharmacy payment claim. Two other commenters also recommended clarifying in the final rule that pharmacy benefit cards are not considered a type of “other payment card” pursuant to the rule's provisions governing payment processes. These commenters were concerned that if pharmacy benefit cards were covered by the rule's payment processing provisions, their payment claim, which they said was expected to be adopted by HHS as the national pharmacy payment claim, may have to be modified to comply with the minimum necessary standard that would have been required pursuant to proposed § 164.510(i) on banking and payment processes. One of these commenters noted that its payment claim facilitates concurrent drug utilization review, which was mandated by Congress pursuant to the Omnibus Budget Reconciliation Act of 1990 and which creates the real-time ability for pharmacies to gain access to information that may be necessary to meet requirements of this and similar state laws. The commenter said that information on its standard payment claim may include information that could be used to provide professional pharmacy services, such as compliance, disease management, and outcomes programs. The commenter opposed restricting such information by applying the minimum necessary standard. Response: We make an exception to the minimum necessary disclosure provision of this rule for the required and situational data elements of the standard transactions adopted in the Transactions Rule, because those elements were agreed to through the ANSI-accredited consensus development process. The minimum necessary requirements do apply to optional elements in such standard transactions, because industry consensus has not resulted in precise and unambiguous situation specific language to describe their usage. This is particularly relevant to the NCPDP standards for retail pharmacy transactions referenced by these commenters, in which the current standard leaves most fields optional. For this reason, we do not accept this suggestion. The term 'payment card' was intended to apply to a debit or credit card used to initiate payment transactions with a financial institution. We clarify that pharmacy benefit cards, as well as other health benefit cards, are used for identification of individual, plan, and benefits and do not qualify as "other payment cards." Comment: Two commenters asked the following questions regarding the banking provisions of the proposed rule: (1) Does the proposed regulation stipulate that disclosures to banks and financial institutions can occur only once a patient has presented a check or credit card to the provider, or pursuant to a standing authorization?; and (2) Does the proposed rule ban disclosure of diagnostic or other related detailed payment information to financial institutions? Response: We do not ban disclosure of diagnostic information to financial institutions, because some such information may be evident simply from the name of the payee (e.g., when payment is made to a substance abuse clinic). This type of disclosure, however, is permitted only when reasonably necessary for the transaction (see requirements for minimum necessary disclosure of protected health information, in § 164.502 and § 164.514). Similarly, we do not stipulate that such disclosure may be made only once a patient has presented a check or credit card, because some covered entities hire financial institutions to perform services such as management of accounts receivables and other back office functions. In providing such services to covered entities, the financial institution will need access to protected health information. (In this situation, the disclosure will typically be made under a business associate arrangement that includes provisions for protection of the information.) Comment: One commenter was concerned that the proposed rule's section on financial institutions, when considered in conjunction with the proposed definition of “protected health information,” could have been construed as making covered entities' disclosures of consumer payment history information to consumer reporting agencies subject to the rule. It noted that covered entities' reporting of payment history information to consumer reporting agencies was not explicitly covered by the proposed rule's provisions regarding disclosure of protected health information without authorization. It was also concerned that the proposed rule's minimum necessary standard could have been interpreted to prevent covered entities and their business partners from disclosing appropriate and complete information to consumer reporting agencies. As a result, it said, consumer reporting agencies might not be able to compile complete consumer reports, thus potentially creating an inaccurate picture of a consumer's credit history that could be used to make future credit decisions about the individual. Furthermore, this commenter said, the proposed rule could have been interpreted to apply to any information disclosed to consumer reporting agencies, thus creating the possibility for conflicts between the rule's requirements and those of the Fair Credit Reporting Act. They indicated that areas of potential overlap included: limits on subsequent disclosures; individual access rights; safeguards; and notice requirements. Response: We have added to the definition of “payment” disclosure of certain information to consumer reporting agencies. With respect to the remaining concerns, this rule does not apply to consumer reporting agencies if they are not covered entities. Comment: Several commenters recommended prohibiting disclosure of psychotherapy notes under this provision and under all of the sections governing disclosure without consent for national priority purposes. Response: We agree that psychotherapy notes should not be disclosed without authorization for payment purposes, and the final rule does not allow such disclosure. See the discussion under § 164.508.


#FHIR and Bulk Data Access Proposal

Posted on September 20, 2017 by Grahame Grieve.

ONC have asked the FHIR community to add new capabilities to the FHIR specification to increase support for API-based access and push of data for large number of patients in support of provider-based exchange, analytics and other value-based services.

The background to this requirement is that while FHIR allows for access to data from multiple patients at a time, the Argonaut implementations are generally constrained to a single patient access, and requires human mediated login on a regular basis. This is mainly because the use case on which the Argonaut community focused was patient portal access. If this work is going to be extended to provide support for API based access to a large number of patients in support of provider based exchange, the following questions (among others) need to be answered: •how does a business client (a backend service, not a human) get access to the service? How are authorizations handled? •How do the client and server agree about which patients are being accessed, and which data is available? •What format is the data made available in? •How is the request made on a RESTful API? •How would the client and server most efficiently ensure the client gets the data it asks for, without sending all data every time?

The last few questions are important because the data could be pretty large – potentially >100000000 resources, and we’ve been focused on highly granular exchanges so far. Our existing solutions don’t scale well.

In response to some of these problems, the SMART team had drafted an initial strawman proposal, which a group of us (FHIR editors, ONC staff, EHR & other vendors) met to discuss further late one night at the San Diego WGM last week. Discussion was – as expected – vigorous. Between us, we hammered out the following refined proposal:


Summary

This proposal describes a way of granting an application access to data on a set of patients. The application can request a copy of all pertinent (clinical) access to the patients in a single download. Note: We expect that this data will be pretty large.

Authorizing Access

Access to the data is granted by using the SMART backend services spec.

Note: We discussed this at length, but we didn’t see a need for Group/* or Launch/* kind of scopes – System/*.read will do fine. (or User/*.*, for interactive processes, though interactive processes are out of scope for this work). This means that a user cannot restrict Authorization down to just a group, but in this context, users will trust their agents.

Accessing Data

The application can do either of the following queries: 

GET [base]/Patient/$everything?start=[date-time]&_type=[type,type]
GET [base]/Group/[id]/$everything?start=[date-time]&_type=[type,type]

Notes: •The first query returns all data on all patients that the client’s account has access to, since the starting date time provided. •The second query provides access to all data on all patients in the nominated group. The point of this is that applications can request data on a subset of all their patients without needing a new access account provisioned (exactly how the Group resource is created/identified/defined/managed is out of scope for now – the question of whether we need to do sort this out has been referred to ONC for consideration). •The start date/time means only records since the nominated time. In the absence of the parameter, it means all data ever •The _type parameter is used to specify which resource types are part of the focal query – e.g. what kind of resources are returned in the main set. The _type parameter has no impact on which related resources are included) (e.g. practitioner details for clinical resources). In the absence of this parameter, all types are included. •The data that is available for return includes at least the CCDS (we referred the question of exactly what the data should cover back to the ONC) •The FHIR specification will be modified to allow Patient/$everything to cross patients, and to add $everything to Group •Group will be added as a compartment type in the base Specification

Asynchronous Query

Generally, this is expected to result in quite a lot of data. The client is expected to request this asynchronously, per rfc 7240. To do this, the client uses the Prefer header: Prefer: respond-async

When the server sees this return header, instead of generating the response, and then returning it, the server returns a 202 Accepted header, and a Content-Location at which the client can use to access the response.

The client then queries this content location using GET content-location (no prefixing). The response can be one of 3 outcomes: •a 202 Accepted that indicates that processing is still happening. This may have an “X-Progress header” that provides some indication of progress to the user (displayed as is to the user – no format restrictions but should be <100 characters in length). The client repeats this request periodically until it gets either a 200 or a 5xx •a 5xx Error that indicates that preparing the response has failed. The body is an OperationOutcome describing the error •a 200 OK with the response for the original request. This response has one or more Link: headers (see rfc 5988) that list the files that are available for download as a result of servicing the request. The response can also carry a X-Available-Until header to indicate when the response will no longer be available

Notes: •This asynchronous protocol will be added as a general feature to the FHIR spec for all calls. it will be up to server discretion when to support it. •The client can cancel a task or advise the server it’s ok to delete the outcome using DELETE [content-location] •Other than the 5xx response, these responses have no body, except when the accept content type is ‘text/html’, in which case the responses should have an HTML representation of the content in the header (e.g. a redirect, an error, or a list of files to download) (it’s up to server discretion to decide whether to support text/html – typically, the reference/test servers do, and the production servers don’t) •Link Headers can have one or more links in them, per rfc 5988 •Todo: decide whether to add ‘supports asynchronous’ flag to the CapabilityStatement resource

Format of returned data

If the client uses the Accept type if application/fhir+json or application/fhir+xml, the response will be a bundle in the specified format. Alternatively, the client can use the type application/fhir+ndjson. In this case: •The response is a set of files in ndjson format (see http://ndjson.org/). •Each file contains only resources of a single type. •There can be more than one file for each resource type. •Bundles are broken up at Bundle.entry.resource – e.g. a bundle is split on Entries so the the bundle json file will contain the bundle without the entry resource, and the resources are found (by id) in the type specific resource files (todo: how does that work for history?)

The nd-json files are split up by resource type to facilitate processing by generic software that reads nd-json into storage services such as Hadoop.

Notes: •the content type application/fhir+ndjson will be documented in the base spec •We may need to do some registration work to make +ndjson legal •We spent some time discussing formats such as Apache Avro and Parquet – these have considerable performance benefits over nd-json but are much harder to produce and consume. Clients and servers are welcome to do content type negotiation to support Parquet/ORC/etc, but for now, only nd-json is required. We’ll monitor implementation experience to see how it goes

Follow up Requests

Having made the initial request, applications should store and retain the data, and then only retrieve subsequent changes. this is done by providing a _start time on the request.

Notes: •Todo: Is _start the right parameter (probably need _lastUpdated, or a new one)? •Todo: where does the marker time (to go into the start/date of the next follow up request) go? •clients should be prepared to receive resources that change on the boundary more than once (still todo)

Subscriptions

The ONC request included “push of data”. It became clear, when discussing this, that server side push is hard for servers. Given that this applications can perform these queries regularly/as needed, we didn’t believe that push (e.g. based on subscriptions) was needed, and we have not described how to orchestrate a push based on these semantics at this time


Prototyping

It’s time to test out this proposal and see how it actually works. With that in mind, we’ll work to prototype this API on the reference servers, and then we’ll hold a connectathon on this API at the New Orleans HL7 meeting in January. Given this is an ONC request, we’ll be working with ONC to find participants in the connectathon, but we’ll be asking the Argonaut vendors to have a prototype available for this connectathon.

Also, I’ll be creating FHIR change proposals for community review for all the changes anticipated in this write up. I guess we’ll also be talking about an updated Argonaut implementation guide at some stage.



Like this:



Categories: Community, FHIR, Implementation


Gender Participation in the #FHIR Community


Question: #FHIR Documents and Composition


9 Comments Grahame Grieve 

September 20, 2017 at 2:05 am

gForge tasks 13919 – 13923

Reply Alexander Henket 

September 20, 2017 at 7:23 am

Thank you for this very clearly outlined piece. It’s good to see a proposed, useful solution for something that was lingering in our realms too.

I do worry sometimes about all the ‘server discretions’. As a specifier/architect we increasingly need to worry about infrastructural interoperability an ask ourselves which of those server discretions need to be supported at a minimum to guarantee basic interoperability while keeping a window open for innovation.

Reply Grahame Grieve 

September 20, 2017 at 10:04 pm

I expect that will tighten up, and that it will get profiled for realms and projects as well. In addition, it’s potentially onerous. I ended up implementing it down inside the REST stack, so I can do it for any call at all – but it doesn’t make sense for most simple things, so I’ve made a rule that it can only be used for search, history, and operations

Reply Niquola 

September 23, 2017 at 3:18 am

I’m going to present some related ideas in Amsterdam

Reply

Shahid N. Shah 

September 24, 2017 at 7:49 pm

Hi Grahame, this is a great first step for multi-record access to FHIR resources, thank you for putting it together. I was curious if you considered either oData or GraphQL as part of your research for the proposal (I didn’t see either mentioned but I’m sure you already know of their existence).

GraphQL especially is a great opportunity to use an industry-consensus batch querying language in place of something we might create special just for FHIR. Given that some folks in the FHIR community have already built some GraphQL to FHIR bridges I don’t think it would take too long to work that in. I look forward to hearing what you think.

Reply Grahame Grieve 

September 25, 2017 at 1:54 pm

We have already added a page around graphQL- see http://build.fhir.org/graphql.html – though I think we’ll have to take that out for IP reasons (we’re waiting to see if Facebook cares to resolve them or not). But adding graphql to the bulk data picture is potentially troublesome – while it has undeniable usefulness, it also presents some real challenges around scalability for the engineering provision side – and that was a subject that caused passionate discussions when we were scoping this out. OTOH, we didn’t consider oData at all. I’ve looked at it before (and we’ve adopted ideas from it), but it’s resolute squareness has always been a challenge for us

Reply Shahid Shah 

September 29, 2017 at 4:20 pm

Thanks, Grahame — Facebook has resolved the IP issues around GraphQL. Could you elaborate what you mean by GraphQL “also presents some real challenges around scalability for the engineering provision side”. If there’s a conversation where that took place I’d love to take look or if you have a summary of the issue that’s good too. For almost all our digital health work we’re moving to a GraphQL-first, REST/FHIR APIs-second, approach and I’d love to hear where some pitfalls may arise.

Reply Grahame Grieve 

October 4, 2017 at 1:49 am

I saw the graphQL IP issues update, and need to get around to updating the text in the graphQL page in regard to that

With regard to using graphQL, I don’t think there’s any written discussion though we could have on on chat.fhir.org. The issues that arise for graphQL in this context are two-fold:

  • the code to produce resources is canned and reproducible. GraphQL requires an interpreter which hasn’t been done by the existing EMR vendors, and so it’s extra work on top of producing resources.
  • there’s a certain amount of work to do to process the outcomes into a bulk data store. The vendors had a strong preference for seeing the ETL step done at this point, rather then before – and graphQL is effectively an ETL. More generally, having a very regular output from the bulk data query means that you get more re-use at your ETL tool level. Of course, you could argue that the converse is true: applying graphQL during the bulk data extract could make the ETL step simpler… that’s a value decision.

Perhaps the best way to resolve this is for me to package up the java graphQL processor I wrote so it can easily be run against the bulk data output as a step in an ETL pipeline? then you get fully powered graphQL without having to ask each vendor to do it

Reply 

 	John Moehrke 	

September 27, 2017 at 2:12 pm

Really need to understand the Problem you are trying to solve. No question this is a Solution, but it is hard to evaluate fitness of this solution without the Problem defined.

Also, See my proposal on #FHIR Bulk De-Identification https://healthcaresecprivacy.blogspot.com/2017/09/fhir-and-bulk-de-identification.html

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Bulk_Data_Transfer_Privacy_and_Security_Concerns&oldid=147582"