Terms and Conditions

Last updated Tuesday, April 19, 2016


We have made the documentation of open.epic materials including Epic’s support of the FHIR Specification (referred to as the “Materials”) available to you for your development and testing. The Materials are provided to you as-is with no other warranties expressed or implied. You may use the Materials as long as you follow these rules:
     
  1. This website has the most up-to-date documentation, so while you can keep copies of the Materials for yourself, do not distribute them. Instead, link others to the Materials hosted on open.epic.
  2. You own what you develop using the Materials. Epic owns the Materials, as well as any improvements to or derivatives of the Materials, such as enhancements to our testing tools or documentation. We want to encourage a vibrant developer environment, so if you suggest a way to improve the Materials and we use your suggestion, it may become part of the Materials for anyone to use without any obligation or notice to you.
  3. You’re responsible for your products and how they connect to our community members’ software. You’re also responsible for complying with all applicable laws, including not infringing on Epic’s or others’ intellectual property rights. Some interfaces listed on open.epic may require a customer to license additional functionality or build additional workflows, so help our mutual customers avoid surprises by always working closely with them and us. Please follow the FHIR App Development Guidelines when using the Materials to build an App submitted via open.epic.
  4. If you want to use open.epic, Epic's name, or Epic's logo to advertise your product, do so in accordance with our open.epic branding guidelines
  5.  

Developer Terms of Use

Last updated Saturday, December 10, 2016


open.epic App registration is available to you to submit FHIR API-based patient-facing Apps for use at healthcare organizations using Epic (referred to as “Community Members”). Apps submitted to open.epic will be able to connect to U.S.-based Community Members that are using the Epic 2017 release and have chosen to enable APIs for this purpose. Apps that use any other APIs, have other users such as providers, or are developed for a particular Community Member will follow a different process and different terms may apply. You may use open.epic documentation of Epic’s support of FHIR APIs (referred to as the “Materials”) to develop Apps and submit them to open.epic as long as you follow these rules

  1. You agree to indemnify, hold harmless and defend Epic, its subsidiaries, and Community Members and their affiliates, and all of the employees, officers, directors, contractors and other personnel of any of them from and against any claim arising out of or relating to, directly or indirectly, you, any of your Apps, or any use of any of your Apps.
  2. Epic will issue a unique client identifier for each App you submit to keep track of which Apps use Epic’s FHIR APIs. Epic or a Community Member might need to suspend or revoke an App’s client identifier if there are issues, concerns, or things are otherwise not going well with one of your Apps. If this happens, your App will not be able to communicate with Community Member systems until the concern is resolved and the suspended client identifier is restored. Contact Epic or the Community Member in question to work on resolving the problem that led to the App’s client identifier being suspended. Because it is possible that your app will be suspended, you will clearly inform users of your app that it might not always be available to them and that they should not rely on it in an emergency.
  3. Direct access to Epic’s software is not required to develop or test your products. Testing can be done via the open.epic sandbox, or by working with a Community Member to test against a particular system. Your receipt of the Materials does not give you permission to access Epic’s software, and does not give you permission to access a Community Member’s Epic system. Your access to Epic’s software can only be granted by Epic.
  4. You and Apps you submit on open.epic must follow the open.epic FHIR App Development Guidelines, including documenting compliance to the ONC Certification Criteria .

Developer Guidelines

As an App developer, you are obligated to be familiar with principles for responsible healthcare App development and usage. As part of those responsibilities, you and Apps you submit to open.epic must follow all of the below guidelines. If you or your Apps fail to follow these guidelines or misbehave in any other way, Epic or Community Members may take action on your App, including notifying users of your App’s non-compliance, or suspending your App until the issue can be resolved. If you have reason to suspect your App is not following the guidelines or is misbehaving and would like Epic to suspend use of your App until the issue is resolved, you can contact us.

  1. Transparency. Your pricing and marketing materials must be clear and consistent. You and your App must provide to users and Community Members understandable financial and licensing terms that will apply to the use of your Apps(k)(1). All information you provide about yourself and your products must be accurate and truthful.
  2. Safety. Your App must be designed and implemented to not put patients or your users at risk of harm(g)(3). You may not use the Materials for any activities that could lead to death, personal injury, or damage to property. Your application must adhere to usability standards, specifically safety-enhanced design(g)(3) and accessibility-centered design(g)(5)
  3. Security. Your App must not pose a direct risk or otherwise increase the risk of a security breach in any system it connects to. Data exchange between your App and Epic’s APIs and between your App and any other third-party system must be secured with industry standard encryption while in transit(d)(9), and use authentication and authorization protocols(d)(1). Your App must secure all data on an end-user’s device(d)(7) (d)(8), and enforce inactivity time-outs(d)(5). You and your App must not introduce any code of a destructive nature into any system you or your App connect to. Your App’s client identifier is given to you for your use only for a single App. You agree to keep your App’s client identifier confidential, and will not disclose it to any third party, or use it for any other purpose. Epic will provide a log of the activity of your App at connected Community Member locations for their review.
  4. Privacy. Your App must provide clear and understandable consent for use and give users the ability to decline consent. Epic exclusively supports OAuth 2.0 as the mechanism for authenticating access to patient data, and your App must not circumvent the display of any authentication or consent mechanisms from Epic or Community Members. You will provide and follow a privacy policy for your App that clearly, accurately, and truthfully describes to your users what data your App collects, and how you use and share this data. Your App must not access, use, or disclose protected health information (PHI) or other confidential information in violation of any law or in any manner other than that which the owner of the information has given its informed consent.
  5. Sharing. You may not share the data collected by your App with any third party without the explicit consent of the user of the App and the patient whose data is being shared, and without notifying the Community Member where the data originated. When sharing data, document what was shared, when, with whom, and for what purpose, and provide your users access to that documentation upon request(d)(3) (d)(11). Your App must provide the means for a user to export, transfer, or remove his or her data from application(b)(6).
  6. Reliability.Your App must be properly tested and must be stable, predictable, and not negatively impact clinical operations or patient safety for users or Community Members. Development of your App must be documented and managed in a Quality Management System (QMS)(g)(4) and complaints and defects reported about your App must be managed in a complaint tracking system(n). If you identify a patient-safety, security, data breach, or privacy issue with one of your Apps, you must follow your documented complaint process to notify all users(n), and proactively contact Epic to disable your App’s usage at Community Member sites until you resolve the issue.
  7. Efficiency. Your App is not permitted to generate excessive load on a user’s systems or a Community Member’s systems, or to cause other systems to behave inaccurately or unexpectedly.
  8. Data Integrity. You and Your Apps must not corrupt or otherwise cause material inconsistencies in any data used by your Apps(d)(2).
  9. Verifiability. Epic or Community Members may inspect or test your App to verify your compliance with these guidelines and the FHIR API Terms of Use.
  10. Reciprocity. You will provide FHIR API-based Access(g)(7) (g)(8) (g)(9) to any data you and your App collect or derive to your users on the same terms as provided in these Development Guidelines.

Required ONC Certification Criteria

To ensure minimum standards for safe and effective healthcare software, you and your Apps must meet the below list of ONC certification criteria.

For each App you submit, you must provide one of the following for Epic, Community Members, and users to review:

  • Public documentation that your App has been certified to the below specified ONC criteria.
  • Public documentation of equivalent functionality in lieu of formal certification.
  • Public documentation describing why specific criteria aren’t applicable for your App.

Epic or Community Members may review documentation supplied by you at any time to ensure you meet these criteria. If documentation you supply is missing or inaccurate, Epic or Community Members may take action on your App, including notifying users of your App’s non-compliance, or suspending your App until the issue can be resolved.

45 CFR 170.315 (b)(6) (Data Portability): "A user can configure the technology to create export summaries using the Continuity of Care Document document template."

45 CFR 170.315 (d)(1) (Access Control): "Verify against a unique identifier(s) (e.g., username or number) that a user seeking access to electronic health information is the one claimed; and [...] establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided"

45 CFR 170.315 (d)(2) (Auditable Events): "The health IT records actions pertaining to electronic health information [...] when health IT is in use; changes to user privileges when health IT is in use; and records the date and time [each action occurs]. [...] The health IT records the audit log status [...] when the audit log status is changed and records the date and time each action occurs. [...] The health IT records the information [...] when the encryption status of locally stored electronic health information on end-user devices is changed and records the date and time each action occurs.

45 CFR 170.315 (d)(3) (Audit Reports): "Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data."

45 CFR 170.315 (d)(5) (Access Timeouts): "Automatically stop user access to health information after a predetermined period of inactivity. [...] Require user authentication in order to resume or regain the access that was stopped."

45 CFR 170.315 (d)(7) (End-Device Encryption): "Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of the technology on those devices stops [or] technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops."

45 CFR 170.315 (d)(8) (Data Integrity): "Verify [...] upon receipt of electronically exchanged health information that such information has not been altered."

45 CFR 170.315 (d)(9) (Trusted Connection): "Health IT needs to provide a level of trusted connection using either 1) encrypted and integrity message protection or 2) a trusted connection for transport."

45 CFR 170.315 (d)(11) (Accounting Disclosures): "Record disclosures made for treatment, payment, and health care operations."

45 CFR 170.315 (g)(3) (Safety-Enhanced Design): "User-centered design processes must be applied to each capability technology."

45 CFR 170.315 (g)(4) (Quality Management System): "For each capability that a technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation, and maintenance of that capability must be identified."

45 CFR 170.315 (g)(5) (Accessible Design): "The use of a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of that capability must be identified."

45 CFR 170.315 (g)(7) (Patient Selection): " The technology must be able to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient’s data."

45 CFR 170.315 (g)(8) (API Access): "Respond to requests for patient data (based on an ID or other token) for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in a computable format."

45 CFR 170.315 (g)(9) (CDA Access): "Respond to requests for patient data (based on an ID or other token) for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted [...] following the CCD document template."

45 CFR 170.523 (k)(1) (Pricing Transparency): "Any additional types of costs that an EP, EH, or CAH would pay to implement the Complete EHR's or EHR Module's capabilities in order to attempt to meet meaningful use objectives and measures."

45 CFR 170.523 (n) (Complaint Process): "Submit a list of complaints received to the National Coordinator on a quarterly basis each calendar year that includes the number of complaints received, the nature/substance of each complaint, and the type of complainant for each complaint."

Additional Proposed Suspension Criteria

In the future, ONC certification intends to also determine whether HIT modules are:

  • Contributing to a patient’s health information being unsecured and unprotected in violation of applicable law;
  • increasing medical errors;
  • decreasing the detection, prevention, and management of chronic diseases;
  • worsening the identification and response to public health threats and emergencies; leading to inappropriate care;
  • worsening health care outcomes;
  • or undermining a more effective marketplace, greater competition, greater systems analysis, and increased consumer choice.
See Federal Register Vol. 81, No. 41, pg 11064 (3)

You will want to be mindful of these goals as you develop your App.