Comments by ARCHIE Posted on January 29, 2008

Page #	Line #	Comments/Criticisms	Suggested Alternatives
		There should be a public Q&A session similar to the Heal 5 Grant session to discuss this final document. There are many questions and areas needing clarification. The paper is still a very high level, in order to truly evaluate the impact we need to think in the terms of implementation details and how the policy affects our vendors and our practices.
15	1-13	Question: Explain the difference between Peer-to-Peer, Custodial-CDR and the Owner-CDR - particularly the difference between Owner and Custodial? What decides that a RHIO owns data? Is it how they use the data? Is it the existance of a business agreement? What do you describe as "ownership rights".	Proposed interpretation is: Peer-toPeer is the pure federated model where clinical patient dat is not retained in central data repository (CDR). Only patient identification and metadata is stored in a CDR where providers can search for relevant patient data. for level 1 usage. Custodial-CDR is the centralized data repository model where all data (identifying and clinical) is stored in a centralized location. The data is not owned by the RHIO but is hosted by the RHIO for access by RHIO participants for level 1 usage. Custodial CDRs could also include some Hybrid-Federated models that store some clinical data centrally. Owner CDR models are centralized data repositories where all data (identifying and clinical) is stored in a centralized location. The data is owned by the RHIO such that it can be used in any way the RHIO wishes and is not limited to level 1 usage. These CDRs can be level 2 RHIOs or central data warehouses/data marts created from the data provided to the RHIO.
19	21-26	Question: "All RHIOs must ensure that the health info service providers with whom they contract for HIE software and services and the participants of the RHIOs comply with minimum protocols, stds, and services of the new consent policies and procedures". How far reaching is the RHIOs liability with regard to it's participants compliance. Who gets sanctioned for breech of security and what are the sanctions?	Proposed Interpretation: "RHIOS must ensure that their business agreements clearly state that each business associate must meet and comply with the minimum protocols, standards, and services of the new consent policies and procedures. Business associates will be responsible to the RHIO to participate in audits by the RHIO to ensure compliance and is responsible for its own acts of non-compliance."
20	36	Question: If a provider belongs to multiple organizations do they have to get consent at each org, or is consent attached to the provider? Also, if a hospital gets consent from a patient, do all attending MDs at that hospital have consent?	Proposed Solution: Once a provider received consent from any organization (including hospitals), then he has full consent at all organizations that he belongs to.
20	29-32	Question: There seems to be a twist in the direction of the consent. What I understood in our previous meetings was that we asking patients to consent to share their clinical data with the RHIO in an all or nothing manner ("patient opt in") implying that a patient would sign a single consent form and then their data was made all available to all members of the RHIO. Now I am reading that the patient does not have to consent to sharing (or uploading) their data, but each provider organization must get consent from the patient in order to view the data. This seems to be a fairly dramatic change in direction. This has a huge impact on the software vendors to be able to track which physician/organization has access to which patient's data and for what period of time. It is perhaps more importantly a huge impactt on the small to mid-size practices to manage the consent in a timely enough manner to make it useful to the provider and could be a significant deterrant to participation of these providers. This is especially true in rural areas and smaller urban/suburban areas that typically have smaller practices.	Proposed Change: Suggestions: 1 - On the consent form allow the state consent form allow the consumers to specify "all providers" and "all practices". Additionally, allow the RHIO to distribute and manage the form to the consumers. 2. Also, allow consumers to specify the list of their regular or favorite providers and/or practices (including the hospitals). 3. Once a provider has been allowed acces at one practice, also allow his access at all practices that he belongs to. Finally, this will be a fairly significant change for the software vendors to implement, the state must allow a significant period of time for compliance so that the cost of this change can be absorbed by the vendors.
21	11-12	Question: There is a requirement for additional functionality to be added to the 'break glass"option which is to track whether the provider had been previously denied access. Consent must be indicated as: no preference indicated by patient; access allowed; access denied and time stamped. All data must also be timestamped so that the systems know who can view what data for what periods of time. What if we prevent an MD from accessing info in the ER because a patient has denied access to the local hospital and there is an adverse outcome - who gets sued? Who gets sanctioned for breach of security - the RHIO, the provider, the hospital?	Proposed Change: There should be a contingency to the break glass denial in that a provider should have the liberty to view a patients info under life-theatening conditions and where the patient is unconscious. Otherwise, we are not allowing the patient to change his consent to save his life! Flexibility needs to be built into the policy to ensure optimal patient safety and care.
21	21-23	Question: Uploading data to the CDR. The definition of the Owner vs Custodial is critical. We need more clarification on the difference here. We need each source to determine if the patient data can be uploaded based on whether the individual patient has given a HIPAA consent. This requirement is extremely difficult to implement - you are asking that each sending system have the ability to track which patients have consented to having their data shared. How many HIS and practice managment systems would this affect for those systems that are owner CDRs? I don't think you would ever get compliance that is affordable or it would ever be a high enough priority to ever be implemented.	Proposed Change: Allow systems to upload the data but either block it from upload on the receiving system or not use it or access until the HIPAA consent is received. This would affect only the RHIO software where we have a much better chance of getting software changes. Assuming that the "Owner CDRs" are systems that use the data outside of Level 1 use then you could block the upload of data. If the Owner CDR is a separate data warehouse that was created from uploaded data is already in the possession of the RHIO and the RHIO would have to block it from being sent to the data warehouse.
22 23	13-43 12-13	Question: What is the implication for a level 1 RHIO that begins to share data with a level 2 RHIO (under Heal 5). Will all patients who consented under level 1 now need to re-consent under level 2? We need more clarification with details and examples of Level1 and Level 2 RHIOs. Include "what it is" and "what it is not" for each level.
23	34-37	Question: More clarification is needed on these statements: In one sentence, it says the RHIOS may offer consumers the ability to screen sensitive information from the RHIO…. And the very next sentence indicates that clinicians must be allowed to withhold information from the RHIO. Theoretically, this is a noble goal to give consumers complete control over their information. The implementation of such an option is quite different. For clinicians to withhold information indicates that their must be a mechanism in the sending data system to flag data as not to be sent. The ability for source systems to build this functionality into their products is most likely not on any development plan nor on a priority list for these companies. This level of requirement is for an advanced system and seems better placed further out in the RHIO requirements. Otherwise, it is becoming far to difficult to get our RHIOS up and running.	Proposed Change: RHIO systems, on the other hand, would be the more likely place where data could be marked as private or possibly deleted once a consumer and physician have decided to "withhold" that data. However, withholding specific data from the medical record could make the value of the RHIO much less and not worth the effort on the part of the stakeholders and the subscribers. Again, this a very advanced requirement for a system in such a stage of infancy. Software vendors have not yet proven to themselves that this is a viable market to be in.... I suggest we table this requirement until a much later date (5 years out).
20	43-46	Question: This statement seems to conflict with the above (page 23 lines 34-37). Here it says Providers *may* seek consent prior to disclosure of sensitive info. Above it says, Clinicians *must* have the discretion to withhold information from the exchange.	Proposed Change: same as above.
24	40-44	Question: Does the revocation of consent mean that the RHIO must timestamp data so that the participant can continue to access that data they previously viewed but not view future data. This is a fairly advanced requirement for the infant stages of RHIO systems.	Proposed Change: Suggest that once a patient has revoked consent then none of their data is available to that provider. If the provider has an EMR and the data has been sent via CCR/CDR then they will have access to that data for their records for the specified time period. If the provider does not have an EMR with an interface then the provider would have to request that information from either the RHIO or the data source; or print copies for their internal charts. This is also an advanced requirement and should be delayed. Allow the RHIO systems to get up and running with the basics then introduce the timestamp access to data.
23	39-42	Question: This statement no longer makes sense in this shift to having each provider organization get consent from the patient. This seems to be a left-over statement from the type of consent that was discussed in the committee meetings where patients gave a single consent for all RHIO members to access data. Now that the patients control what providers get consent...why have the "must" statement in their at all. It becomes a superfluous requirement.	Proposed Change: Remove this or make it an optional requirement.
25	25-37	Question: The ability to provide access either electronically or hardcopy will be function of the RHIO software. Providing copies of full medical records at this point will be difficult. It is critical that the RHIOS can set their own policies for cost and timeliness without expectations.	Proposed Change: Allow a generous definition for timeliness. Most RHIOs are operating with a very small staff and very very small budget… the feature needs to down played as a function of the RHIO until it is offered in a Consumer web portal.
29	17-25	Question: Managing payer access by patient consent is another area of development for the RHIO software vendors and in the interest of patient centered care it should be a secondary requrement. Let's get is working for the patients and the providers and then bring in the payors. I agree that requiring the payer to obtain consent on a patient by patient basis is much more palatable then giving them full access as part of the consent form. Having payer access may be a very strong deterrent to consumers.
30	15-21	Question: What is the general period for compliance? Or, are you expecting to reach an agreement with each individual RHIO?	Proposed Change: Allow the compliance period to extend 18 months from the date of the paper finalization.
		Question: How do we handle electronic referrals and consultations? Many RHIO software systems have an electronic capability for referrals and consultations. If a physician shares patient info in a consult mode and the provider has not seen the patient before, then the consulting practice would need to seek consent from the patient. The cumbersoneness of this workflow would most likely deter providers from using a system that is meant to improve the workflow.	Proposed Change: Allow a consult and/or referral from a physician to give automatic consent to the consulting provider unless the provider has been specifically blocked from viewing the information via the RHIO.
		Statement: Medication history from services such as RxHub and SureScripts provides medication prescriptions written by all providers. A provider that has consent to view a patients information should automatically have access to all medication history. Do not limit the Rx viewing to only scripts written by the provider. Do not force a consent from the patient for RxHub or SureScripts. Having a farily complete medication history is one of the biggest advantages of a RHIO from a providers prespective. Restricting this will seriously devalue the RHIO.
		Statement: Providers that are cc'd on results (lab, radiology, reports, etc) should automatically receive consent to view this data in the RHIO. The cc'd provider should not have to seek consent from the patient to view the information.