Technical Frequently Asked Questions
- What documents should organizations review prior to implementing SCHIEx services?
- What are the responsibilities of the Site Administrator?
- Which service(s) does the user agreement requirement pertain to?
- If staff already sign an organizational privacy/security statement is it necessary to implement a user agreement too?
- Other than how to use the application/system, what type of staff training is required by the policy?
- Is there any special patient consent required for DIRECT messaging?
- Which service(s) does the patient notice policy requirement pertain to?
- Do you have an example for a patient notice?
- How do I execute the technical component of the Exchange opt-out?
- How do I get access to the opt-out tool and training?
- How long to I have to execute the opt out?
- If the patient wishes to opt out and my system can block a CCD/CCDA from being registered with SCHIEx, do I still need to opt the patient out using the web tool?
- Who do I contact If I have additional questions about SCHIEx policies and procedures?
- To satisfy HIPAA requirements, is there an audit log entry created when a patient’s information is provided through the Exchange to a Participant?
- What happens if a patient is sent by a Participant via a patient identity feed and the patient does not match up with any other patient known to the Exchange?
- What parameters does the patient matching depend on?
- What is the timeline for the on-ramping process?
- Is VPN required to access SCHIEx?
- Are there any bandwidth requirements for participating in SCHIEx?
- Are you (SCHIEx) creating an end-user Training Manual?
- How does opt out work?
- What will happen if demographic information is entered for the wrong patient or a similar error occurs at the Participant location, but is later corrected by the Participant?
- How does document replacement work in a Participant’s XDS/b Document Repository?
- Will physicians be required to log into another system/separate application?
- What if we discover issues related to the connectivity process? What are our options?
What documents should organizations review prior to implementing SCHIEx services?
SCHIEx Participation Agreement
SCHIEx Policies and Procedures
What are the responsibilities of the Site Administrator?
- Serves as your organization’s point of contact for questions about access or use of SCHIEx
- Schedules SCHIEx training and executes user agreements for SCHIEx users on your staff
- Manages role-based access to SCHIEx services and termination of users who no longer need access
- Enforces policies for logins and passwords
- Monitors access and use of SCHIEx
- Serves as your organization’s official point of contact for all SCHIEx technical communications
Which service(s) does the user agreement requirement pertain to?
This requirement pertains to all SCHIEx services.
If staff already sign an organizational privacy/security statement is it necessary to implement a user agreement too?
No, if staff already sign any document that addresses the type of information included in the sample user agreement, then it isn’t necessary to sign one specific to SCHIEx.
Other than how to use the application/system, what type of staff training is required by the policy?
At a minimum staff should receive basic information about SCHIEx, its permitted purposes, and any specific requirements or policies related to the service being implemented.
Is there any special patient consent required for DIRECT messaging?
No, however you should continue to follow whatever consent procedures your organization has in place now for sharing patient health information. DIRECT is another method to send the information.
Which service(s) does the patient notice policy requirement pertain to?
This requirement pertains to SCHIEx Query Based Exchange.
Do you have an example for a patient notice?
Yes, it and other resources and suggested best practices are located on the Provider – Resources page of the website.
How do I execute the technical component of the Exchange opt-out?
SCHIEx provides a web tool to opt patients out or cancel a previous opt-out.
How do I get access to the opt-out tool and training?
Your site administrator can contact SCHIEx to schedule this.
How long to I have to execute the opt out?
This varies with workflow, but you should try to implement it as soon after the patient request as possible. If you have a central team that will be executing the opt-out, you may want to include a timeframe in your patient notice, particularly if it will not occur the same day.
If the patient wishes to opt out and my system can block a CCD/CCDA from being registered with SCHIEx, do I still need to opt the patient out using the web tool?
Yes, this is the current policy.
Who do I contact If I have additional questions about SCHIEx policies and procedures?
Email info@schiex.org with your specific question, and we will direct you to the staff member who will be most helpful in your situation.
To satisfy HIPAA requirements, is there an audit log entry created when a patient’s information is provided through the Exchange to a Participant?
Yes. All PHI transmissions are logged to the audit log in that the exchange tracks that a document related to a specific patient was sent to a specific Participant. The log will track that a document was transmitted, but will have no record of the specific PHI contained in the document.
The receiving system is then responsible to maintain a more granular record of the end user that had access to that document and the PHI. The analogy is that of a fax that is transmitted. SCHIEx can track that a fax was sent from point A to point B, but once the fax arrives at point B, who has access to the document becomes the responsibility of point B, the receiving party.
Please also see related question located on page 5 of the “Responsiveness Summary Regarding Public Comments Received on the SCHIEx Governance Documents” under the “SCHIEx Policy Manual” tab on the “For Providers” page.
What happens if a patient is sent by a Participant via a patient identity feed and the patient does not match up with any other patient known to the Exchange?
The patient (Patient X) is still accepted by the PIX manager and registered, but the record is not linked to any others at that point in time. The participating site that sent that patient record can still register clinical documents for that patient (Patient X).
Should a site try to register documents for a patient for which a patient identify feed was not originally sent, or a case where the identity feed failed, an unknown patient error response is sent by the Exchange (in compliance to the standards) so the site is aware of the failure to register the document.
What parameters does the patient matching depend on?
Patients from various sources are linked based on demographic attributes such as first and last name, date of birth, gender, Social Security number, etc. The SCHIEx record locator service protects an individual’s privacy and security concerns by using “blindfolded” record linking. Under this blindfolded approach, the likeness or similarity of patient demographics are used to match a patient’s medical records from different providers, not the patient’s actual demographic information.
What is the timeline for the on-ramping process?
The actual time it takes the provider to technically prepare for connectivity is highly variable and depends on many factors such as whether there is already support for IHE profiles within the provider EMR; whether it requires an upgrade; whether there is just one system or multiple that have to be integrated before connecting, etc. Once Step1, the basic NIST testing and interface testing (which simply confirm whether the edge systems are standards conformant), is complete for a system, we should be able to move through the rest of the process quickly. While there will be variables such as the number of providers seeking on-ramping within a given time period, we will process applications on a first-come-first-served basis. We anticipate the technical process taking four elapsed weeks after the NIST sandbox testing is completed. The time taken to execute legal agreements and other policy requirements will vary, depending on the organization.
Is VPN required to access SCHIEx?
No. SCHIEx is built using open technology standards that fully comply with the specifications established by the NHIN and IHE. SCHIEx implements standards like the IHE Audit Trail and Node Authentication Integration (ATNA) profile that enable secure health information exchange over the Internet. The exchange uses bi-directional certificate-based node authentication for connections to and from each participant. TLS is used to secure communication between SCHIEx and the participant.
Are there any bandwidth requirements for participating in SCHIEx?
While we have no minimum requirements for a connection to SCHIEx, the recommendation, at this point, is a connection with at least a 512Kbps download speed.
Are you (SCHIEx) creating an end-user Training Manual?
The advantage of SCHIEx is that the end user has access to a more complete patient record. SCHIEx provides Participants with the standards-based “highway” to securely transport/share documents in a federated peer-to-peer model. The receiving systems (i.e. the Participant’s EMRs connecting to the exchange and pulling down patient information) are responsible for deciding the best way to disseminate/present that information to the end user. We expect that this workflow will vary depending on the Participant and expect that the EMR vendors at each individual facility will provide this specific training.
How does opt out work?
Once an opt out is executed by any Participant using either the Web-based tool provided in the SCHIEx Production Package or the Basic Patient Privacy Consent (BPPC) profile, the SCHIEx Xds.b Registry will no longer respond to any queries for information related to the patient.
What will happen if demographic information is entered for the wrong patient or a similar error occurs at the Participant location, but is later corrected by the Participant?
When a participant updates demographic information via a Patient Identity feed with the A08 (update) option, the external record data is refreshed. So, if an error occurs and is later corrected, it will be corrected for the other SCHIEx Participants when they do a PIX query. All modifications are date/time stamped.
How does document replacement work in a Participant’s XDS.b Document Repository?
Previous documents in a Participant’s XDS.b will be deprecated and replaced with current documents as specified in IHE XDS. However, the previous ones are never actually deleted from the repository.
Will physicians be required to log into another system/separate application?
It depends on the system that is onboarding to SCHIEx and what it plans to do with the information it receives from the exchange. In general, it is expected that the connecting system will seamlessly integrate the additional patient information obtained from the exchange in to a report viewer or other clinical data viewers already available as part of their existing portfolio. Please discuss with your EMR vendors what this workflow and integration will look like in the application.
What if we discover issues related to the connectivity process? What are our options?
We encourage you to reach out to SCHIEx by describing your issue or just requesting a technical call. The SCHIEx team will work with you to understand your specific issue and will be able to advise you regarding next steps.