--- name: drchrono description: "\n\n# APPLICATION PROGRAMMING INTERFACE LICENSE TERMS AND CONDITIONS\n

EverHealth Solutions Inc. doing business as DrChrono.\n(“Company”) requires developers (“Developer”) accessing the Company’s database\nthrough any of the standard application programming interface\n(“API”), including Fast Healthcare Interoperability Resources\n(“FHIR”) APIs and Proprietary APIs, to accept and adhere to these\nterms and conditions (the \"Agreement\"). By accessing or using\nCompany’s API, Developer agrees to be bound by this Agreement.\nCompany may update this Agreement from time to time and Developer\nwill have 30 days to reject the updated terms by providing written\nnotice to Company. If Developer continues to use or receive the\nservices following such period, the updated Agreement will be\ndeemed accepted.

Definitions\n
1. “FHIR APIs\" are standardized APIs developed by HL7\nInternational to promote healthcare data interoperability.
2. \"Proprietary APIs\" are custom-built interfaces. These APIs are\ntailored to the unique needs of the platform but may not follow\nindustry-wide standards.
\n
Developer Account.\n
To access Company’s APIs, Developer will be required to register\nby establishing a developer account and provide certain information\nsuch as contact information (e.g., name, address, telephone number\nand e-mail address), demographic information (e.g., zip code,\norganization and/or role), or, if applicable, billing information\n(e.g., credit or debit card numbers). Any registration information\nDeveloper gives to Company will always be accurate and up to date\nand Developer will inform Company promptly of any updates. If\nCompany assigns Developer credentials, Developer must use them with\nthe applicable APIs. Developer will not misrepresent or mask its\nidentity when using the APIs or developer account.
\n
License.\n
1. License Grant. During the term of this Agreement, and subject\nto the terms and conditions set forth herein, Company hereby grants\nto Developer a limited, non-exclusive, non-transferrable,\nnon-sublicensable, revocable license to access and use the API to:\n(A) integrate the Developer’s technology (“Technology”) with the\nElectronic Health Record (“EHR”), test, read/write data, and deploy\nthe API and the data; (B) access and use a dedicated test\nenvironment of the EHR (the, “Environment”) for the purposes of\ntesting the API; (C) use the documentation and specifications for\nthe API (“Documentation,” and collectively with the API, EHR and\nthe Environment, the “Services”) for the purpose of fulfilling\nDeveloper’s rights and obligations hereunder; and (D) make\navailable and use the API and data through the Technology on behalf\nof Developer’s customers (“Customers”). Company may change, modify,\nimprove, upgrade, suspend, or discontinue any aspect of the API or\nService at any time without notice, including the availability of\nthe API. Company may also impose limits on certain features or\nrestrict Developer’s access to parts or all of the API or the\nService (including limiting the number of Developer’s API Calls)\nwithout notice or liability
2. Restrictions. Developer will not: (a) resell, lease, encumber,\nsublicense, distribute, publish, transmit, transfer, assign or\nprovide such access or use to any third party in any medium\nwhatsoever, except for as described in Section 1.1 above; (b)\ndevise specifications from, reverse engineer, reverse compile,\ndisassemble, or create derivative works based on the Services; (c)\napply systems to extract or modify information in the Services\nusing technology or method such as those commonly referred to as\n“web scraping,” “data scraping,” or “screen scraping”; (d)\nknowingly input or post through or to the Services any content that\nis illegal, threatening, harmful, lewd, offensive, or defamatory or\nthat infringes the intellectual property rights, privacy rights or\nrights of publicity of others, (e) transmit through or store data\non the Services that is regulated by the PCI Data Standards (f)\ninput or transmit through or to the Services any virus, worm,\nTrojan Horse, or other mechanism that could damage or impair the\noperation of the Services or grant unauthorized access thereto; (g)\nuse or access the Services for purposes of monitoring the\navailability, performance or functionality of the Services or for\nany other benchmarking or competitive purposes; or (h) cause,\nassist, allow or permit any third party (including an end-user) to\ndo any of the foregoing; (i) use the Services to compete with\nCompany in any way; or (j) permit any third party to use or access\nthe Services other than Customers, or Developer’s direct employees\nor agents who are acting on Developer’s behalf.
3. Maintenance. Developer agrees that Company may update, correct\nor modify the Services as Company deems necessary from time to\ntime. All such updates, corrections and modifications will be\nconsidered part of the Services for purposes of this\nAgreement.
4. Applicable Laws. Developer’s access to and use of the Services\nis subject to all applicable international, federal, state and\nlocal laws and regulations. Developer may not use the Services or\nany data in violation of or to violate any law, rule or regulation.\nEnsuring Developer’s use of the Services is compliant with\napplicable laws is the responsibility of Developer.
5. Suspension of API. Company has the right to immediately suspend\nthe API, including sandbox access and API applications(a) in order\nto prevent damage to or degradation of the Services or unauthorized\nor non-compliant use or (b) for operational reasons such as repair,\nmaintenance, or improvement or because of any emergency, or (c) if,\nfollowing notice from Company, Developer has failed to pay any\namounts due and owing. In the case of (a) or (b) Company will give\nDeveloper prior notice if reasonable and will ensure that the API\nis restored as soon as possible after the event giving rise to\nsuspension has been resolved to Company’ reasonable\nsatisfaction.
\n
Ownership.\n
1. Company. Company’s intellectual property, including without\nlimitation the EHR, the API and the Documentation, its trademarks\nand copyrights, and any modification thereof, are and will remain\nthe exclusive property of Company and its licensors. No licenses or\nrights are granted to Developer except for the limited rights\nexpressly granted in this Agreement.
2. Developer. developer’s intellectual property, including without\nlimitation the Technology, the design and architecture of the\nintegration of the Technology with the EHR via the API, or with any\nother electronic health records system, or equivalent medical\npatient and scheduling software, the source code and any text or\nbinary executable representation of that source code which enables\nintegration of the Technology with the Company EHR, its trademarks\nand copyrights and any modification thereof, are and will remain\nthe exclusive property of Developer and its licensors. No licenses\nor rights are granted to Company except for the limited rights\nexpressly granted in this Agreement.
3. Feedback. Developer agrees that advice, feedback, criticism, or\ncomments provided to Company related to the EHR, the API and the\nDocumentation are given to Company and may be used by Company\nfreely and without restriction and will not enable Developer to\nclaim any interest, ownership or royalty in Company’ intellectual\nproperty. Likewise, Company agrees that advice, feedback,\ncriticism, or comments provided to Developer related to the\nTechnology are given to Developer and may be used by Developer\nfreely and without restriction and will not enable Company to claim\nany interest, ownership or royalty in Developer’s intellectual\nproperty.
\n
Fees/Payment Terms.\n
1. Fees. Company may charge a fee for Developer’s use of the\nServices and/or for support related to Developer’s use of the\nServices. For details about these fees, please contact the Company\nat api@drchrono.com.
2. Payment Terms. The fees\nset forth in Section 5.1 (“Fees”) are due and payable by the\nLicensee within 30 days of receipt of an invoice from the Company.\nAny amounts past due will be subject to a monthly charge of 1.5% or\nthe maximum rate permitted by law, whichever is less. In the event\nthat any amounts are not paid when due, the Licensee agrees to pay\nall reasonable costs of collection. All fees are payable in United\nStates Dollars and are non-refundable.
3. Taxes. The fees outlined\nabove do not include any local, state, federal, or foreign taxes,\nlevies, or duties of any nature, including value-added tax, sales\ntax, use tax, or withholding taxes (“Taxes”). The Licensee is\nresponsible for paying all Taxes for which it is liable under this\nsection. The Company may invoice taxes to the Licensee, and the\nLicensee will pay such taxes unless it provides a valid tax\nexemption certificate from the appropriate taxing authority.
4. Exemption for Patient API\nAccess. At the Company's sole discretion, these fees will\nnot apply to API access related to patient access use case. The\nCompany may determine, based on the specific nature of the access,\nthat fees for patient-facing API interactions are waived or treated\ndifferently.
\n
Marketing. Neither party will make any public\nstatements or press releases without the prior written approval of\nthe other party which may be withheld in the approving party’s sole\ndiscretion. Developer may include Company’ name and EHR in its\npublished list of supported EHR integrations and partnerships for\nthe purposes of Developer sales and marketing of the Technology.\nDeveloper acknowledges that the Company’s trademarks are owned\nsolely and exclusively by Company and agrees to use the Company’s\ntrademarks only in the form and manner as prescribed by Company.\nAll use of the Company’s trademark shall inure to the benefit of the Company.\nDeveloper shall defend, indemnify, and hold harmless Company and\nits affiliates in connection with any third party claims or actions arising out of\nDeveloper’s unauthorized use of the Company trademarks. Company may\nterminate Developer’s right to use Company trademarks under this\nsection (either in part or whole) immediately on notice, with or\nwithout cause. Such termination shall not terminate or otherwise\naffect this Agreement. Moreover, this permission shall terminate\nimmediately upon termination or expiration of this Agreement. Upon\ntermination or expiration of this Agreement, Company shall\nimmediately stop using the Company trademarks.
Confidentiality.\n
1. Confidential Information. “Confidential Information” means any\ninformation disclosed by one party to the other whether orally or\nin writing that is designated as confidential or that reasonably\nshould be understood by the receiving party to be confidential,\nnotwithstanding the failure of the disclosing party to designate it\nas such. Confidential Information may include information that is\nproprietary to a third party and is disclosed by one party to\nanother pursuant to this Agreement. The Services, all features and\nfunctions thereof and related pricing and product plans will be the\nConfidential Information of Company.
2. Non-Disclosure. Each party agrees to maintain the\nconfidentiality of the other party’s Confidential Information with\nthe same security and measures it uses to protect its own\nConfidential Information of a similar nature (but in no event less\nthan reasonable security and measures) and not to use such\nConfidential Information except as necessary to perform its\nobligations or exercise its rights under this Agreement. The\nreceiving party may disclose Confidential Information of the\ndisclosing party to those employees, officers, directors, agents,\naffiliates, consultants, users, and suppliers who need to know such\nConfidential Information for the purpose of carrying out the\nactivities contemplated by this Agreement and who have agreed to\nconfidentiality provisions that are no less restrictive than the\nrequirements herein. Such party will be responsible for any\nimproper use or disclosure of the disclosing party’s Confidential\nInformation by any such party. Except as expressly permitted by\nthis Section, the receiving party will not disclose or facilitate\nthe disclosure of Confidential Information of the disclosing party\nto any third party. The restrictions in this Section shall continue\nuntil such time as the information is covered by an exclusion set\nforth below.
3. Exclusions. The receiving party will have no obligation under\nthis Section with respect to information provided by the disclosing\nparty that: (a) is or becomes generally available to the public\nother than as a result of a breach of this Agreement by the\nreceiving party, (b) is or becomes available to the receiving party\nfrom a source other than the disclosing party, provided that such\nsource is not known to the receiving party to be bound by an\nobligation of confidentiality to the disclosing party with respect\nto such information, (c) was in the receiving party’s possession\nprior to disclosure by the disclosing party, or (d) is\nindependently developed by the receiving party without reference to\nthe Confidential Information. Further either party may disclose\nConfidential Information (i) as required by any court or other\ngovernmental body or as otherwise required by law, or (ii) as\nnecessary for the enforcement of this Agreement or its rights\nhereunder.
\n
Compliance with Laws.\n
1. PHI. “PHI” means “protected health information” as that\nterm is used in the Health Insurance Portability and Accountability\nAct of 1996 as associated regulations as may be amended from time\nto time (“HIPAA”). Neither Party is the business associate of the\nother. If a Party requires PHI from the other to perform its\nobligations hereunder, and to the extent that the operation of any\nInterface capability as to any mutual client involves the use or\ndisclosure of PHI by the other Party, each Party requesting or\nreceiving such PHI agrees to: (a) obtain the written\nauthorization of the client of all such uses and disclosures of\ninformation of that client and that client’s patients;\n(b) enter into an agreement with the client that complies with\nthe applicable business associate provisions required by HIPAA\nprior to obtaining any PHI and requires that any patient consent\nthat may be required by law for such uses and disclosures is\nobtained by the client; and (c) adopt and enforce appropriate\nphysical, administrative, and technical measures to maintain\nprivacy and security of such information in accordance with HIPAA\nand Applicable Law. Any PHI of a client unintentionally or\nincidentally disclosed to the other Party shall be held in\nconfidence by the other Party in accordance with Applicable Law.\nEach Party will take reasonable steps to limit its request or\nrequirement from the other Party of any client’s PHI to the minimum\namount necessary to accomplish the intended purpose of requests\nfor, and uses and disclosures of, such PHI in accordance with\n45 C.F.R. 502(b)(1), and as authorized under HIPAA.
2. Personal Information. “Personal Information” means any\ninformation that a party collects, receives, or obtains, from or on\nbehalf of Customers that does or can identify a specific individual\nor by or from which a specific individual may be identified,\ncontacted, or located, such as the individual’s name; address;\nsocial security number; driver’s license number or state-issued\nidentification card number; and any other information relating to\nan identified or identifiable individual, or may otherwise\nconstitute personally identifiable information under any applicable\nlaw. Each party acknowledges and agrees that, in the course\nof performance of this Agreement, it may receive or have access to\nPersonal Information. Each party shall comply with the terms and\nconditions set forth in this Agreement in its collection, receipt,\ntransmission, storage, disposal, use, and disclosure of such\nPersonal Information and be responsible for the unauthorized\ncollection, receipt, transmission, access, storage, disposal, use,\nand disclosure of Personal Information under its control or in its\npossession.
3. Data Transmissions. In connection with any transfer of\nPersonal Information or PHI between them in the operation of the\nAPI, each party: (i) will transfer such Personal Information\nor PHI only through use of a dedicated connection to which they are\nthe only authorized parties or such other method of communication,\nsuch as encrypted communication, between them as offers an\nequivalent level of security and authentication of the recipient;\n(ii) will not permit any third party to use any such\nconnection to the extent that such use is within that party’s\ncontrol, except as permitted herein; and (iii) will take\nadequate and reasonable steps to ensure that access to that\nPersonal Information and PHI at each facility that party has or on\neach system utilized by such party or its subcontractors is limited\nto authorized personnel of that party. Each party will take\nreasonable care to ensure that data transmissions between them in\nthe operation of the API that contain any Personal Information or\nPHI are timely, complete, and accurate, and each party will take\nreasonable steps to retransmit any such data transmission to the\nother party upon discovery that the original transmission has been\nlost in transmission or is corrupted. If either party receives data\nfrom the other and is informed or believes that such data was not\nintended for it, the receiving party will notify the sender,\npromptly take effective steps to return such data, or at the\ndirection of the other party immediately and permanently delete\nsuch data from its systems.
4. Compliance with Laws. Each party represents that its\ncollection, access, use, storage, disposal, and disclosure of\nPersonal Information and PHI does and will comply with all\napplicable law. Without limiting the parties’ obligations in the\npreceding sentence, each party shall implement administrative,\nphysical, and technical safeguards to protect Personal Information\nand PHI that are no less rigorous than generally accepted industry\nstandards, including, but not limited to, with respect to\nimplementation, client service, payment security, functionality,\nease of use, and the creation, access, storage, destruction, or\nexchange of Personal Information and PHI. If, in the course of\nperformance of this Agreement, a party has access to or will\ncollect, access, use, store, process, dispose of or disclose\ncredit, debit, or other payment cardholder information, that party\nshall at all times remain in compliance with the Payment Card\nIndustry Data Security Standard (“PCI DSS”) requirements, including\nremaining aware at all times of changes to the PCI DSS and promptly\nimplementing all procedures and practices as may be necessary to\nremain in compliance with the PCI DSS, in each case, at such\nparty’s sole cost and expense.
5. Anti-Fraud and Abuse Law Compliance. By entering into this\nAgreement, the parties specifically intend that no part of any\nconsideration paid hereunder is a prohibited payment for the\nrecommending or arranging for the referral of business or the\nordering of items or services; nor are the payments intended to\ninduce illegal referrals of business. If any part of this Agreement\nis determined to violate an applicable law, the parties agree to\nnegotiate in good faith revisions to the provision or provisions\nthat are in violation. If the parties are unable to agree to new or\nmodified terms as required to bring the entire Agreement into\ncompliance with such applicable law within 30 days, either party\nmay terminate this Agreement on no less than 30 days prior written\nnotice to the other party or sooner if required by any applicable\nlaw.
6. No Exclusion. If a\nparty becomes debarred, excluded, suspended, or otherwise\ndetermined to be ineligible to participate in federal health care\nprograms, that party shall provide notice thereof to the other\nparty. Upon receipt of such notice, this Agreement shall\nautomatically terminate without further action or notice.
\n
Disclaimer. COMPANY DOES NOT WARRANT THAT THE\nSERVICES WILL BE ERROR-FREE OR UNINTERRUPTED, THAT COMPANY WILL\nCORRECT ALL ERRORS OR THAT THE SERVICES WILL MEET DEVELOPER’S\nREQUIREMENTS OR EXPECTATIONS. COMPANY IS NOT RESPONSIBLE FOR ANY\nISSUES RELATED TO THE PERFORMANCE, OPERATIONS OR SECURITY OF THE\nSERVICES THAT ARISE FROM DEVELOPER’S TECHNOLOGY OR THIRD PARTY\nAPPLICATIONS OR SERVICES PROVIDED BY THIRD PARTIES. COMPANY\nEXPRESSLY DISCLAIMS (TO THE GREATEST EXTENT PERMISSIBLE UNDER\nAPPLICABLE LAW) ALL OTHER WARRANTIES EXPRESS, IMPLIED, STATUTORY OR\nOTHERWISE, RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT,\nINCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,\nTITLE, OR FITNESS FOR A PARTICULAR PURPOSE.
Limitation of Liability. IN NO EVENT WILL\nCOMPANY OR ITS AFFILIATES BE LIABLE FOR ANY INDIRECT,\nCONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR EXEMPLARY DAMAGES,\nOF ANY KIND OR NATURE ARISING OUT OF THIS AGREEMENT OR THE\nSERVICES, INCLUDING WITHOUT LIMITATION, ANY COST TO COVER\nPROCUREMENT OF SUBSTITUTE GOODS OR SERVICES (WHICH THE PARTIES\nAGREE WILL NOT BE CONSIDERED DIRECT DAMAGES), OR ANY LOSS OF\nREVENUE, PROFITS, SALES, DATA, DATA USE, GOOD WILL, OR REPUTATION.\nCOMPANY’ MAXIMUM LIABILITY ARISING OUT OF OR RELATED TO THE\nSERVICES OR THIS AGREEMENT WILL BE LIMITED TO THE AMOUNT OF FEES\nDEVELOPER HAS PAID TO COMPANY IN THE 3 MONTHS PRIOR TO THE EVENT(S)\nGIVING RISE TO SUCH LIABILITY. THE LIMITATIONS SET FORTH IN THIS\nSECTION APPLY REGARDLESS OF THE LEGAL THEORY ON WHICH A CLAIM IS\nBROUGHT, EVEN IF COMPANY HAS BEEN NOTIFIED OF THE POSSIBILITY OF\nDAMAGE OR IF SUCH DAMAGE COULD HAVE BEEN REASONABLY FORESEEN AND\nNOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE OF ANY EXCLUSIVE\nREMEDY PROVIDED IN THIS AGREEMENT.
Indemnity.\n
1. By Company. Company will indemnify and hold Developer, its\naffiliates and each of its and its affiliates’ employees,\ncontractors, directors, suppliers and representatives harmless\nagainst any action brought against Developer by a third party to\nthe extent such action is based on a claim that the unmodified\nServices as used in accordance with this Agreement infringe a\ncopyright, patent, trademark or misappropriate a trade secret of\nsuch third party or other proprietary right enforceable in the\ncountry in which Company has authorized Developer to use the\nServices. Should the Services become, or in Company’ opinion be\nlikely to become, the subject of any infringement claim, Company\nmay, at its option: (a) procure for Developer, at Company’ expense,\nthe right to continue using the Services, (b) modify, at Company’\nexpense, the Services so that it becomes non-infringing but remains\nfunctionally equivalent, or (c) terminate Developer’s right to use\nthe Services and refund to Developer any unused pre-paid fees for\nsuch Services. Company will have no liability for any claim of\nintellectual property infringement that is based on (i) the use or\ncombination of the Services with any products, services, data or\nother materials not provided by Company, provided such infringement\nwould not have arisen but for such combination, (ii) the use of\nother than a current, unaltered version of the Service, (iii)\nspecifications or designed provided by Developer, or (iv) any\nunauthorized modification of the Services.
2. By Developer. Developer agrees to defend and indemnify Company\nand its affiliates from and against any legal action, demand, suit,\nor proceeding brought against Company or its affiliates by a third\nparty arising out of or related to Developer’s use of the\nServices.
3. Indemnification Procedures. Each party’s indemnification\nobligations are subject to conditions that the indemnified party\nmust: (a) notify the indemnifying party promptly in writing of such\nclaim; (b) permit the indemnifying party to have sole control of\nthe defense, compromise, or settlement of such claim, including any\nappeals, provided, that the indemnifying party will not settle any\nclaim in a manner that adversely affect the rights of the\nindemnified party without the indemnified party’s prior written\nconsent; and (c) fully cooperate with the indemnifying party at the\nindemnifying party’s expense in the defense or settlement of such\nclaim.
4. Disclaimer. This Section states the entire liability of\nCompany, and Developer’s sole and exclusive remedy, with respect to\nthe infringement of any intellectual property rights by the\nService.
\n
Term and Termination.\n
1. Term. This Agreement will be effective as of the Developer’s\ninitial creation of a developer’s account or access of the APIs\n(“Effective Date”) and remain in effect until terminated by either\nparty as permitted by this Agreement. The initial term will be for\none year, thereafter, this Agreement will automatically renew for\nsuccessive one-year periods, unless cancelled by either party in\naccordance with this Agreement.
2. Termination. Either party may terminate this Agreement for any\nreason or no reason by providing at least 90 days’ prior written\nnotice. Either party may terminate this Agreement immediately for a\nbreach by the other party of any of its material terms, if the\nbreaching party has failed to cure such breach (if curable) within\n30 days of receipt of written notice from the non-breaching party\ndescribing the breach. Either party may terminate this Agreement\nwithout notice if the other party becomes insolvent, makes or has\nmade an assignment for the benefit of creditors, is the subject of\nproceedings in voluntary or involuntary bankruptcy instituted on\nbehalf of or against such party (except for involuntary\nbankruptcies which are dismissed within 60 days), or has a receiver\nor trustee appointed for substantially all of its property.
3. Effects of Termination. Upon the expiration or termination of\nthis Agreement for any reason, (a) Developer will immediately cease\nusing the Services for any of Developer’s Customers who have not\nyet executed a contract with Developer for the deployment of\nTechnology dependent on the Services, (b) upon request, each party\nwill return or destroy all Confidential Information of the other\nparty, provided, that each party may retain one copy of the\nConfidential information of the other party as necessary to comply\nwith applicable law or its records retention or archival policies\nor practices (and such retained Confidential Information will\nremain subject the non-disclosure obligations in this Agreement)\nand (c) any unpaid, undisputed amounts due through termination will\nbecome immediately due and payable and (d) for those Customers who\nare in contract with Developer, and who have deployed and are using\nthe Technology in conjunction with the Services, Developer shall\ncease using the Services for, with and on behalf of those Customers\nwithin a 90 day period from the date of termination, during which\nCustomers have the opportunity to remove business and technical\ndependencies and migrate away from the Technology (“Wind-Down”).\nThis Wind-Down period may be extended by mutual, written agreement\nof the parties.
4. Survival. Any provisions of this Agreement that expressly, or\nby implication, are intended to survive its termination or\nexpiration will survive and continue to bind the parties, including\nwithout limitation provisions relating to confidentiality,\nrepresentations and warranties, indemnification, limitations on\nliability, intellectual property, and Developer’s payment\nobligations under this Agreement.
\n
Assignment. Developer may not assign or\ntransfer this Agreement or any of its rights or obligations\nhereunder in whole or in part without the prior written consent of\nCompany. Subject to the foregoing, this Agreement will inure to the\nbenefit of, be binding upon, and be enforceable against, each of\nthe parties hereto and their respective successors and\nassigns.
Attorney’s Fees. In the event any proceeding\nor lawsuit is brought in connection with this Agreement, the\nprevailing party in such proceeding will be entitled to receive its\nreasonable costs, expert witness and attorneys’ fees.
Relationship of the Parties. This Agreement\ndoes not create any joint venture, partnership, agency, or\nemployment relationship between the parties.
No Third-Party Beneficiaries. This Agreement\nis being entered into for the sole benefit of the parties hereto,\nand nothing herein, express or implied, is intended to or will\nconfer upon any other person or entity any legal or equitable\nright, benefit or remedy of any nature whatsoever.
Equitable Remedies. Each party acknowledges\nand agrees that (a) a breach or threatened breach by such party may\ngive rise to irreparable harm to the other party for which monetary\ndamages may not be an adequate remedy; and (b) if a breach or\nthreatened breach by such party occurs, the other party will in\naddition to any and all other rights and remedies that may be\navailable to such other party at law, at equity or otherwise in\nrespect of such breach, be entitled to seek equitable relief that\nmay be available from a court of competent jurisdiction, without\nany requirement to post a bond or other security.
Force Majeure. Neither party will be liable\nunder this Agreement for any failure or delay in the performance of\nits obligations (except for the payment of money) on account of\nstrikes, shortages, riots, insurrections, fires, flood, storm,\nexplosions, acts of God, war, governmental action, pandemics,\nearthquakes, material shortages, or any other cause that is beyond\nthe reasonable control of such party.
Export Compliance. Developer must comply with\nUnited States, foreign and international laws and regulations,\nincluding without limitation, the United States Export\nAdministration Regulations and the United States Office of Foreign\nAsset Control regulations, and other anti-boycott and import\nregulations. Such export laws govern use of the Services including\ntechnical data and any deliverables provided under this Agreement\nand Developer agrees to comply with all such laws and regulations\n(including “deemed export” and “deemed re-export” regulations).\nDeveloper is responsible for ensuring that no data, information,\nsoftware programs and/or materials resulting from the Services (or\ndirect product thereof) will be exported directly or indirectly in\nviolation of these laws. Developer will indemnify Company for any\nviolation by Developer of any applicable export controls or\neconomic sanctions laws and regulations.
Governing Law, Jurisdiction and Venue. This\nAgreement will be governed by and construed in all respects in\naccordance with the laws of the State of Delaware, without regard\nto its conflicts of laws principles. Each party hereby consents to\nthe exclusive venue and jurisdiction of the courts of Indiana. THE\nPARTIES FURTHER AGREE, TO THE EXTENT PERMITTED BY APPLICABLE LAW,\nTO WAIVE ANY RIGHT TO TRIAL BY JURY WITH RESPECT TO ANY CLAIM,\nCOUNTERCLAIM OR ACTION ARISING FROM THE TERMS OF THIS\nAGREEMENT.
Severability, Waiver and Amendment. If any\nprovision of this Agreement is held by a court of competent\njurisdiction to be unenforceable or invalid, such provision will be\nchanged and interpreted as to best accomplish the objectives of the\noriginal provision to the fullest extent permitted by law, and the\nremaining provisions will remain in full force and effect. No\nwaiver of any term or right in this Agreement will be effective\nunless made in writing and signed by an authorized representative\nof the waiving party. Any waiver or failure to enforce any\nprovision of this Agreement will not be deemed a waiver of future\nenforcement of that or any other provision. Except to the extent\notherwise expressly provided in this Agreement, this Agreement may\nonly be amended in writing signed by both parties hereto.
Notices. Any notices pertaining to this\nAgreement shall be addressed to the appropriate party as follows,\nunless otherwise provided in this Agreement:\n
For Company:
\n
legal@evercommerce.com
\n
-and-
\n
EverHealth Solutions Inc.\n
Attn: Legal
\n

\n\n# Introduction\n\nThis document is intended as a detailed reference for the precise behavior of\nthe DrChrono API. If this is your first time using the API, start with our tutorial.\nIf you are upgrading from a previous version, take a look at the changelog section.\n\n### Requests\n\nAll requests must be made using the base URL `https://app.drchrono.com`.\nFor each endpoint, up to six different kinds of requests may be permitted:\n\nPath | Method | Side Effects | Success Status | Failure Status | Response Content\n---- | ------ | ------------ | -------------- | -------------- | ---------------\n`:endpoint` | `GET` | None | `200` | `403` | Paginated list of all endpoint resources that the requester can access\n`:endpoint/:id` | `GET` | None | `200` | `403` or `404` | Object with requested ID\n`:endpoint` | `POST` | Create object | `201` | `400`, `403`, or `409` | Object(s) created\n`:endpoint/:id` | `PUT` | Update entire object | `204` | `400`, `403`, or `409` | Empty\n`:endpoint/:id` | `PATCH` | Update only included values of object | `204` | `400`, `403`, or `409` | Empty\n`:endpoint/:id` | `DELETE` | Delete object | `204` | `400` or `403` | Empty\n\n### Responses\n\nAll responses are in JSON format. Generally input may use the `application/json`, `application/x-www-form-urlencoded`, or `form/multipart` content types.\nThe list of objects returned by a `GET` request to `:endpoint` is paginated and has the following format:\n\n {\n \"previous\": URL or null, // URL of the previous page\n \"results\": array of objects, // these results follow the same format as `:endpoint/:id`\n \"next\": URL or null // URL of the next page (same as the requested URL, but with the page query parameter included)\n }\n\nMost page sizes default to 250, but can be lowered by setting the `page_size` query parameter. The 'api/appointments' endpoint is an exception to this rule as it has a max size of 20.\n\nSome endpoints may return a `302` redirect response. Most libraries handle this\nincorrectly by resending the response with different headers or a different HTTP method.\nYou will need to resend the original request with the right HTTP method and headers\nto the new \"Location\" specified by the `302` response.\n\n### Permissions\n\nAPI access is managed using scopes and permissions. Scopes are granted to an API\nApplication when a user authorizes and permissions are granted by a primary user\nto other users in their Practice Group. The scopes are granted during the OAuth\nprocess, whereas the permissions have to be granted from DrChrono web app. In order\nfor an app to access information on behalf of a DrChrono user, the user must authorize\nthe app for the requested scopes, and the user must have the appropriate permissions set.\nEach endpoint in this documentation will specify which scopes and permissions are\nneeded for access. Scopes are labeled `drchrono_oauth2` in the AUTHORIZATIONS section\nof each endpoint.\n\n### Data Types\n\nThe data types referred to in this documentation, for both requests and responses,\nare listed below:\n\nType | Example | Description\n---- | ------- | -----------\nboolean | `true` | a binary variable, having two possible values of `true` and `false`\ninteger | `123` | represents some range of mathmatical integers\nstring | `HelloWorld` | sequence of characters\nURL | `\"http://example.com/index.html\"` | An absolute URL, including protocol\nobject | `{\"key\": \"value\"}` | A nested object. All values that are type \"object\" will have a clickable dropdown of the object's format\narray | `[1,2]` | A value may have type \"array of :type\"\ndate | `\"2021-02-14\"` | An ISO 8601 encoded date\ndate range | `\"2021-02-17/2021-02-24\"` | A start and end date separated by a slash\nfile | `\"https://rackcdn.com/file.ext\"` | When uploading, this is provided as a standard `multipart/form-data` file\nbase64encoded file | `\"https://rackcdn.com/file.ext\"` | When uploading, this is provided as a base64 encoded file within JSON\ntime | `\"12:34:56\"` | An ISO 8601 encoded time\ntimestamp | `\"2021-02-14T13:40:39\"` | AN ISO 8601 encoded timestamp, with no as_system_timezone\ncolor | `\"#ABCDEF\"` or `\"rgb(12, 34, 56)\"` | A CSS color specified in either of these formats\ndecimal | `\"123.45\"` | A numeric value truncated to two decimal places. It may be passed to an endpoint as an integer, float, or string, but will always be returned as a string.\n\n### Verbose Parameter\n\nFor some endpoints, certain fields will be excluded in the response to a `GET` request\nunless the `verbose` query parameter is passed with the value `true`. These fields\nhave a particularly large performance penalty. Passing `verbose=true` will include\nthese keys in the response, but will reduce the default and maximum page sizes to 50.\n\n### Rate Limits\n\nApplications are subject to an hourly rate limit, which will reset at the top of each hour.\nRequests over this limit will receive a response with code `429`. By default, applications are\nlimited to 500 calls per hour. Contact api@drchrono.com or your account representative\nto request an increased rate limit.\n\n### Endpoint Levels\n\n`Level 1 API Call(s)` and `Level 2 API(s)` are defined in the following table and are based on the listed `Endpoint`; the Endpoint's corresponding `Level` number listed denotes whether that Endpoint constitutes a Level 1 API Call vs. a Level 2 API Call. DrChrono's definition of Level 1 API Calls and Level 2 API Calls as listed in the following table are subject to change at DrChrono's sole discretion.\n\nENDPOINT | Level\n---------- | -----\n`/api/allergies` | 1\n`/api/appointments` | 1\n`/api/appointment_profiles` | 1\n`/api/appointment_templates` | 1\n`/api/billing_profiles` | 1\n`/api/care_plans` | 1\n`/api/clinical_note_templates` | 1\n`/api/comm_logs` | 1\n`/api/consent_forms` | 1\n`/api/custom_appointment_fields` | 1\n`/api/custom_demographics` | 1\n`/api/custom_vitals` | 1\n`/api/doctors` | 1\n`/api/documents` | 1\n`/api/iframe_integration` | 1\n`/api/implantable_devices` | 1\n`/api/inventory_categories` | 1\n`/api/inventory_vaccines` | 1\n`/api/medications` | 1\n`/api/offices` | 1\n`/api/patients` | 1\n`/api/patients/:id/ccda` | 1\n`/api/patients/:id/qrda1` | 1\n`/api/patients/:id/onpatient_access` | 1\n`/api/patient_communications` | 1\n`/api/patient_flag_types` | 1\n`/api/patient_interventions` | 1\n`/api/patient_physical_exams` | 1\n`/api/patient_risk_assessments` | 1\n`/api/patients_summary` | 1\n`/api/problems` | 1\n`/api/reminder_profiles` | 1\n`/api/telehealth_appointments` | 1\n`/api/users` | 1\n`/api/user_groups` | 1\n`/o/authorize` | 1\n`/o/revoke_token` | 1\n`/o/token` | 1\n`/api/amendments` | 2\n`/api/claim_billing_notes` | 2\n`/api/clinical_notes` | 2\n`/api/clinical_note_field_types` | 2\n`/api/clinical_note_field_values` | 2\n`/api/custom_insurance_plan_names` | 2\n`/api/eligibility_checks` | 2\n`/api/eobs`| 2\n`/api/fee_schedules` | 2\n`/api/insurances` | 2\n`/api/lab_documents` | 2\n`/api/lab_orders` | 2\n`/api/lab_orders_summary` | 2\n`/api/lab_tests` | 2\n`/api/lab_results` | 2\n`/api/line_items` | 2\n`/api/medications/:id/append_to_pharmacy_note` | 2\n`/api/messages` | 2\n`/api/offices/:id/add_exam_room` | 2\n`/api/pateint_lab_results` | 2\n`/api/patient_messages` | 2\n`/api/patient_payments` | 2\n`/api/patient_payment_log` | 2\n`/api/patient_vaccine_records` | 2\n`/api/prescription_messages` | 2\n`/api/procedures` | 2\n`/api/sublabs` | 2\n`/api/tasks` | 2\n`/api/task_categories` | 2\n`/api/task_notes` | 2\n`/api/task_templates` | 2\n`/api/task_statuses` | 2\n`/api/transactions` | 2\n\n# Authorization\n\n## Initial authorization\n\nThere are three main steps in the OAuth 2.0 authentication workflow:\n\n1. Redirect the provider to the authorization page.\n2. The provider authorizes your application and is redirected back to\n your web application.\n3. Your application exchanges the `authorization_code` that came with\n the redirect for an `access_token` and `refresh_token`.\n\n### Step 1: Redirect to drchrono\n\nThe first step is redirecting your user to drchrono, typically with a button\nlabeled \"Connect to drchrono\" or \"Login with drchrono\". This is just a link that\ntakes your user to the following URL:\n\n https://app.drchrono.com/o/authorize/?redirect_uri=REDIRECT_URI_ENCODED&response_type=code&client_id=CLIENT_ID_ENCODED&scope=SCOPES_ENCODED\n\n- `REDIRECT_URI_ENCODED` is the URL-encoded version of the redirect URI (as registered for your application and used in later steps).\n- `CLIENT_ID_ENCODED` is the URL-encoded version of your application's client ID.\n- `SCOPES_ENCODED` is a URL-encoded version of a space-separated list of scopes, which can be found in each endpoint or omitted to default to all scopes.\n\nThe `scope` parameter consists of an optional, space-separated list of scopes your application is requesting.\nIf omitted, all scopes will be requested.\n\nScopes are of the form `BASE_SCOPE:[read|write]` where `BASE_SCOPE` is any of `user`, `calendar`, `patients`, `patients:summary`, `billing`, `clinical` and `labs`.\nYou should request only the scopes you need.\nFor instance, an application which sends \"Happy Birthday!\" emails to a doctor's patients on their birthdays would use the scope parameter `\"patients:summary:read\"`,\nwhile one that allows patients to schedule appointments online would need at least\n`\"patients:summary:read patients:summary:write calendar:read calendar:write clinical:read clinical:write\"`.\n\n### Step 2: Provider authorization\n\nAfter logging in (if necessary), the provider will be presented with a screen\nwith your application's name and the list of permissions you requested (via the\n`scope` parameter).\n\nWhen they click the \"Authorize\" button, they will be redirected to your redirect\nURI with a `code` query parameter appended, which contains an authorization code to be\nused in step 3. If they click the \"Cancel\" button, they will be redirected to\nyour redirect URI with `error=access_denied` instead.\n\nNote: This authorization code expires extremely quickly, so you must perform\nstep 3 immediately, ideally before rendering the resulting page for the end\nuser.\n\n### Step 3: Token exchange\n\nThe `code` obtained from step 2 is usable exactly once to obtain an access token\nand refresh token. Here is an example token exchange in Python:\n\n import datetime, pytz, requests\n\n if 'error' in get_params:\n raise ValueError('Error authorizing application: %s' % get_params[error])\n\n response = requests.post('https://app.drchrono.com/o/token/', data={\n 'code': get_params['code'],\n 'grant_type': 'authorization_code',\n 'redirect_uri': 'http://mytestapp.com/redirect_uri',\n 'client_id': 'abcdefg12345',\n 'client_secret': 'abcdefg12345',\n })\n response.raise_for_status()\n data = response.json()\n\n # Save these in your database associated with the user\n access_token = data['access_token']\n refresh_token = data['refresh_token']\n expires_timestamp = datetime.datetime.now(pytz.utc) + datetime.timedelta(seconds=data['expires_in'])\n\nYou now have all you need to make API requests authenticated as that provider.\nWhen using this access token, you'll only be able to access the data that the\nuser has access to and that you have been granted permissions for.\n\n## Refreshing an access token\n\nAccess tokens only last 48 hours (given in seconds in the `'expires_in'` key in\nthe token exchange step above), so they occasionally need to be refreshed. It\nwould be inconvenient to ask the user to re-authorize every time, so instead you\ncan use the refresh token like the original authorization to obtain a new access\ntoken. Replace the `code` parameter with `refresh_token`, change the value\n`grant_type` from `authorization_code` to `refresh_token`, and omit the\n`redirect_uri` parameter.\n\nExample in Python:\n\n ...\n response = requests.post('https://app.drchrono.com/o/token/', data={\n 'refresh_token': get_refresh_token(),\n 'grant_type': 'refresh_token',\n 'client_id': 'abcdefg12345',\n 'client_secret': 'abcdefg12345',\n })\n ...\n\n# Webhooks\n\nIn order to use drchrono API webhooks, you first need to have an API application on file\n(even if it is in Test Model).\nEach API webhook is associated with one API application, go to\nhere to set up both API applications and webhooks!\n\nOnce you registered an API application, you will see webhook section in each saved API applications.\nCreate a webhook and register some events there and save all the changes, then you are good to go!\n\n## Webhooks setup\n\nAll fields under webhooks section are required.\n\n**Callback URL**\nCallback URl is used to receive all hooks when subscribed events are triggered. This should be an URL under your control.\n\n**Secret token**\nSecret token is used to verify webhooks, this is very important, please set something with high entropy. Also we will\ntalk more about this later.\n\n**Events**\n\nEvents is used to register events you want to receiver notification when they happen. Currently we support following events.\n\nEvent name | Event description\n---------- | -----------------\n`APPOINTMENT_CREATE` | We will deliver a hook any time an appointment is created\n`APPOINTMENT_MODIFY` | We will deliver a hook any time an appointment is modified\n`APPOINTMENT_DELETE` | We will deliver a hook any time an appointment is deleted\n`CASH_PAYMENT_DELETE` | We will deliver a hook any time a patient payment is deleted\n`CLINICAL_NOTE_LOCK` | We will deliver a hook any time a clinical note is locked\n`CLINICAL_NOTE_UNLOCK` | We will deliver a hook any time a clinical note is unlocked\n`LAB_ORDER_CREATE` | We will deliver a hook any time a lab order is created\n`LAB_ORDER_MODIFY` | We will deliver a hook any time a lab order is modified\n`LAB_ORDER_DELETE` | We will deliver a hook any time a lab order is deleted\n`LINE_ITEM_CREATE` | We will deliver a hook any time a line item is created\n`LINE_ITEM_MODIFY` | We will deliver a hook any time a line item is modified\n`LINE_ITEM_DELETE` | We will deliver a hook any time a line item is deleted\n`LINE_ITEM_TRANSACTION_DELETE` | We will deliver a hook any time a line item transaction is deleted\n`PATIENT_CREATE` | We will deliver a hook any time a patient is created\n`PATIENT_MODIFY` | We will deliver a hook any time a patient is modified\n`PATIENT_ALLERGY_CREATE` | We will deliver a hook any time a patient allergy is created\n`PATIENT_ALLERGY_MODIFY` | We will deliver a hook any time a patient allergy is modified\n`PATIENT_FLAG_CREATE` | We will deliver a hook any time a patient flag is created\n`PATIENT_FLAG_CMODIFY` | We will deliver a hook any time a patient flag is modified\n`PATIENT_PROBLEM_CREATE` | We will deliver a hook any time a patient problem is created\n`PATIENT_PROBLEM_MODIFY` | We will deliver a hook any time a patient problem is modified\n`PATIENT_MEDICATION_CREATE` | We will deliver a hook any time a patient medication is created\n`PATIENT_MEDICATION_MODIFY` | We will deliver a hook any time a patient medication is modified\n`TASK_CREATE` | We will deliver a hook any time a task is created\n`TASK_MODIFY` | We will deliver a hook any time a task is modified and any time creation, modification and deletion of task notes, associated task item\n`TASK_DELETE` | We will deliver a hook any time a task is deleted\n`VACCINE_ADMINISTERED` | We will deliver a hook any time a vaccine consent form is signed\n\n\n## Webhooks verification\n\nIn order to make sure the callback URL in webhook is under your control, we added a verification\nstep before we send any hooks out to you.\n\nVerification can be done by clicking \"Verify webhook\" button in webhooks setup page. After you click\nthe button, we will send a `GET` request to the callback URL, along with a parameter called `msg`.\n\nPlease use your webhook's secret token as hash key and SHA-256 as digest constructor, hash the `msg` value with\nHMAC algorithm.\nAnd we expect a `200` JSON response, in JSON response body, there should be a key called `secret_token` existing, and its value should be\nequal to the hashed `msg`. Otherwise, verification will fail.\n\nHere is an example webhook verification in Python:\n\n import hashlib, hmac\n\n def webhook_verify(request):\n secret_token = hmac.new(WEBHOOK_SECRET_TOKEN, request.GET['msg'], hashlib.sha256).hexdigest()\n return json_response({\n 'secret_token': secret_token\n })\n\n

\nNote: Verification will be needed when webhook is first created and anytime callback URl is changed.\n

\n\n\n## Webhooks header and body\n\n**Header**\n\nKey | Value\n--- | -----\n`X-drchrono-event` | Event that triggered this hook, could be any one event above or `PING`\n`X-drchrono-signature` | Secret token associated with this webhook\n`X-drchrono-delivery` | ID of this delivery\n\n**Body**\n\nKey | Value\n--- | -----\n`receiver` | This will be an JSON representation of the webhook\n`object` | This will be an JSON representation of the object related to the triggered event, this would share same serializer as drchrono API\n\n## Webhooks ping and deliveries\n\nWebhooks ping and deliveries will be sent as `POST` requests.\n\n**PING**:\n\nYou can always ping your webhook to check things, by clicking the \"Ping webhook\" button in webhook setup page. And a hook with header `X-drchrono-event: PING` would be sent to the callback URL.\n\n**Deliveries**:\n\nYou can check recent deliveries by clicking the \"deliveries\" link in webhook setup page. And you can resend a hook by clicking \"redeliver\" button after select a specific delivery.\n\n## Webhooks delivery mechanism\n\nWe will delivery a hook the moment a subscribed event is triggered. We will not record any response header or body you send back after you receive the hook.\nHowever we only consider the response status code. We will consider any `2xx` responses as successfully delivered.\nAny other responses, like `302` would be considered failing.\nAnd we will try to redeliver unsuccessfully delivered hooks 3 times, first redeliver happens at 1 hour after the initial event,\nsecond redeliver happens 3 hours after the initial event, and the third redeliver happens 7 hours after the initial event.\nAfter these intents, if the delivery is still unsuccessful, you have to redeliver it by hand.\n\n\n## Webhooks security\n\nYou may want to secure your webhooks to only consider requests send out from drchrono. And this is where secret_token is needed in\nrequest header.\nTry to set the secret_token to something with high entropy, a good example could be taking the output of\nruby -rsecurerandom -e 'puts SecureRandom.hex(20)'.\nAfter this, you might want to verify all request headers you received on your server with this token.\n\n\n# iframe integration\n\nSome API apps provide additional functionality for interacting with patient data\nnot offered by drchrono, and can benefit by being incorporated into drchrono's\npatient information page via iframe. We have created a simple API to make this\npossible.\n\nTo make an existing API application accessible via an iframe on the patient\npage, you need to update either \"Patient iframe\" or \"Clinical note iframe\" section in API management page,\nto make the iframe to appear on (either the patient page or the clinical note page),\nwith the URL that the iframe will use for each page, and the height it should\nhave. The application will be reviewed before it is approved to ensure that it\nis functional and secure.\n\n## Register a Doctor\n\niframe applications will appear as choices on the left-hand menu of the patient\npage for doctors registered with your application. To register a doctor with\nyour application, make a `POST` request to the `/api/iframe_integration`\nendpoint using the access token for the corresponding doctor. This endpoint does not\nexpect any payload.\n\nTo disable your iframe application for a doctor, make a `DELETE` request to the\nsame endpoint.\n\n## Populating the iframe\n\nThere are two places where the iframe can be displayed, either within the\npatient detail page or the clinical note page, shown below respectively:\n\n### Patient Chart\n![Iframe on the patient page](https://app.drchrono.com/site_media/public/images/iframe_patient_page.png \"Patient Chart iFrame\")\n\n### Clinical Note\n![Iframe on the clinical note page](https://app.drchrono.com/site_media/public/images/iframe_clinical_note.png \"Clincal Note iFrame\")\n\nWhen requesting approval for your iframe app, you must specify a URL for one or\nboth of these pages which will serve as the base URL for your IFrame\ncontents. When a doctor views your iframe, the source URL will have various\nquery parameters appended to it, for example for the patient page the `src`\nparameter of the IFrame will be:\n\n```\n?doctor_id=&patient_id=&practice_id=&iat=&jwt=\n```\n\nThe `jwt` parameter is crucial if your application transfers any sort of PHI and\ndoes not implement its own login system. It encapsulates the other parameters\nin a [JSON web token (JWT)](http://jwt.io) and signs them using SHA-256 HMAC\nwith your `client_secret` as the key. This verifies that the iframe is being\nloaded within one of drchrono's pages by an authorized user. In production, you\nshould validate the JWT using an approved library (which are listed on the\n[official site](http://jwt.io)), and only use the parameters extracted from the\nJWT. Using Python and Django, this might look like:\n\n import jwt\n\n CLIENT_SECRET = \n MAX_TIME_DRIFT_SECONDS = 60\n\n def validate_parameters(request):\n token = request.GET['jwt']\n\n return jwt.decode(token, CLIENT_SECRET, algorithms=['HS256'], leeway=MAX_TIME_DRIFT_SECONDS)\n\nModern browsers' same-origin policy means that data cannot be passed between\nyour application and drchrono's page through the iframe. Therefore, interaction\nmust happen through the API, using information provided in JWT.\n\n# Versions and deprecation\n\n## Stability Policy\n\nChanges to this API version will be limited to adding endpoints, or adding fields to existing\nendpoints, or adding optional query parameters. Any new fields which are not read-only will be optional.\n\n## Deprecation Policy\n\nThe drchrono API is versioned. Versions can be in the following states:\n\n* **Active:** This is our latest and greatest version of the API. It is actively supported by\nour API team and is improved upon with new features, bug fixes and optimizations that do\nnot break backwards compatibility.\n\n* **Deprecated:** A deprecated API version is considered second best--having been\nsurpassed by our active API version. An API version remains in this state for one year,\nafter which time it falls to the not supported state. A deprecated API version is passively supported;\nwhile it won't be removed until becoming unsupported, it may not receive new features but will likely\nbe subject to security updates and performance improvements.\n\n* **Unsupported:** An API version in the not supported state may be deactivated at any\ntime. An application using an unsupported API version should migrate to an active API version.\n\n## Version Map\n| Version Name | Previous Name | Start Date | Deprecation Date |\n|--------------|---------------|------------|------------------|\n| v2 | v2015_08 | 08/2015 | TBA |\n| v3 | v2016_06 | 06/2016 | |\n| v4 | N/A | 09/2018 | |\n\nIf you are looking for documentation for an older version\n\n- [V4(Hunt Valley)](/api-docs-old/v4/documentation) (old V4 documentation)\n- [V3(Sunnyvale)](/api-docs-old/v3/documentation)\n- [V2(Mountain View)](/api-docs-old/v2/documentation)\n\n# Changelog\n\nHere's changelog for different versions\n\n- [Current Changelog](https://headwayapp.co/drchrono-changelog)\n- [V4 Changelog](/api-docs-old/v4/changelog)\n- [V3 Changelog](/api-docs-old/v3/changelog)" version: "0.1.0" license: MIT --- # DrChrono # APPLICATION PROGRAMMING INTERFACE LICENSE TERMS AND CONDITIONS

EverHealth Solutions Inc. doing business as DrChrono. (“Company”) requires developers (“Developer”) accessing the Company’s database through any of the standard application programming interface (“API”), including Fast Healthcare Interoperability Resources (“FHIR”) APIs and Proprietary APIs, to accept and adhere to these terms and conditions (the "Agreement"). By accessing or using Company’s API, Developer agrees to be bound by this Agreement. Company may update this Agreement from time to time and Developer will have 30 days to reject the updated terms by providing written notice to Company. If Developer continues to use or receive the services following such period, the updated Agreement will be deemed accepted.

Definitions
1. “FHIR APIs" are standardized APIs developed by HL7 International to promote healthcare data interoperability.
2. "Proprietary APIs" are custom-built interfaces. These APIs are tailored to the unique needs of the platform but may not follow industry-wide standards.
Developer Account.
To access Company’s APIs, Developer will be required to register by establishing a developer account and provide certain information such as contact information (e.g., name, address, telephone number and e-mail address), demographic information (e.g., zip code, organization and/or role), or, if applicable, billing information (e.g., credit or debit card numbers). Any registration information Developer gives to Company will always be accurate and up to date and Developer will inform Company promptly of any updates. If Company assigns Developer credentials, Developer must use them with the applicable APIs. Developer will not misrepresent or mask its identity when using the APIs or developer account.
License.
1. License Grant. During the term of this Agreement, and subject to the terms and conditions set forth herein, Company hereby grants to Developer a limited, non-exclusive, non-transferrable, non-sublicensable, revocable license to access and use the API to: (A) integrate the Developer’s technology (“Technology”) with the Electronic Health Record (“EHR”), test, read/write data, and deploy the API and the data; (B) access and use a dedicated test environment of the EHR (the, “Environment”) for the purposes of testing the API; (C) use the documentation and specifications for the API (“Documentation,” and collectively with the API, EHR and the Environment, the “Services”) for the purpose of fulfilling Developer’s rights and obligations hereunder; and (D) make available and use the API and data through the Technology on behalf of Developer’s customers (“Customers”). Company may change, modify, improve, upgrade, suspend, or discontinue any aspect of the API or Service at any time without notice, including the availability of the API. Company may also impose limits on certain features or restrict Developer’s access to parts or all of the API or the Service (including limiting the number of Developer’s API Calls) without notice or liability
2. Restrictions. Developer will not: (a) resell, lease, encumber, sublicense, distribute, publish, transmit, transfer, assign or provide such access or use to any third party in any medium whatsoever, except for as described in Section 1.1 above; (b) devise specifications from, reverse engineer, reverse compile, disassemble, or create derivative works based on the Services; (c) apply systems to extract or modify information in the Services using technology or method such as those commonly referred to as “web scraping,” “data scraping,” or “screen scraping”; (d) knowingly input or post through or to the Services any content that is illegal, threatening, harmful, lewd, offensive, or defamatory or that infringes the intellectual property rights, privacy rights or rights of publicity of others, (e) transmit through or store data on the Services that is regulated by the PCI Data Standards (f) input or transmit through or to the Services any virus, worm, Trojan Horse, or other mechanism that could damage or impair the operation of the Services or grant unauthorized access thereto; (g) use or access the Services for purposes of monitoring the availability, performance or functionality of the Services or for any other benchmarking or competitive purposes; or (h) cause, assist, allow or permit any third party (including an end-user) to do any of the foregoing; (i) use the Services to compete with Company in any way; or (j) permit any third party to use or access the Services other than Customers, or Developer’s direct employees or agents who are acting on Developer’s behalf.
3. Maintenance. Developer agrees that Company may update, correct or modify the Services as Company deems necessary from time to time. All such updates, corrections and modifications will be considered part of the Services for purposes of this Agreement.
4. Applicable Laws. Developer’s access to and use of the Services is subject to all applicable international, federal, state and local laws and regulations. Developer may not use the Services or any data in violation of or to violate any law, rule or regulation. Ensuring Developer’s use of the Services is compliant with applicable laws is the responsibility of Developer.
5. Suspension of API. Company has the right to immediately suspend the API, including sandbox access and API applications(a) in order to prevent damage to or degradation of the Services or unauthorized or non-compliant use or (b) for operational reasons such as repair, maintenance, or improvement or because of any emergency, or (c) if, following notice from Company, Developer has failed to pay any amounts due and owing. In the case of (a) or (b) Company will give Developer prior notice if reasonable and will ensure that the API is restored as soon as possible after the event giving rise to suspension has been resolved to Company’ reasonable satisfaction.
Ownership.
1. Company. Company’s intellectual property, including without limitation the EHR, the API and the Documentation, its trademarks and copyrights, and any modification thereof, are and will remain the exclusive property of Company and its licensors. No licenses or rights are granted to Developer except for the limited rights expressly granted in this Agreement.
2. Developer. developer’s intellectual property, including without limitation the Technology, the design and architecture of the integration of the Technology with the EHR via the API, or with any other electronic health records system, or equivalent medical patient and scheduling software, the source code and any text or binary executable representation of that source code which enables integration of the Technology with the Company EHR, its trademarks and copyrights and any modification thereof, are and will remain the exclusive property of Developer and its licensors. No licenses or rights are granted to Company except for the limited rights expressly granted in this Agreement.
3. Feedback. Developer agrees that advice, feedback, criticism, or comments provided to Company related to the EHR, the API and the Documentation are given to Company and may be used by Company freely and without restriction and will not enable Developer to claim any interest, ownership or royalty in Company’ intellectual property. Likewise, Company agrees that advice, feedback, criticism, or comments provided to Developer related to the Technology are given to Developer and may be used by Developer freely and without restriction and will not enable Company to claim any interest, ownership or royalty in Developer’s intellectual property.
Fees/Payment Terms.
1. Fees. Company may charge a fee for Developer’s use of the Services and/or for support related to Developer’s use of the Services. For details about these fees, please contact the Company at api@drchrono.com.
2. Payment Terms. The fees set forth in Section 5.1 (“Fees”) are due and payable by the Licensee within 30 days of receipt of an invoice from the Company. Any amounts past due will be subject to a monthly charge of 1.5% or the maximum rate permitted by law, whichever is less. In the event that any amounts are not paid when due, the Licensee agrees to pay all reasonable costs of collection. All fees are payable in United States Dollars and are non-refundable.
3. Taxes. The fees outlined above do not include any local, state, federal, or foreign taxes, levies, or duties of any nature, including value-added tax, sales tax, use tax, or withholding taxes (“Taxes”). The Licensee is responsible for paying all Taxes for which it is liable under this section. The Company may invoice taxes to the Licensee, and the Licensee will pay such taxes unless it provides a valid tax exemption certificate from the appropriate taxing authority.
4. Exemption for Patient API Access. At the Company's sole discretion, these fees will not apply to API access related to patient access use case. The Company may determine, based on the specific nature of the access, that fees for patient-facing API interactions are waived or treated differently.
Marketing. Neither party will make any public statements or press releases without the prior written approval of the other party which may be withheld in the approving party’s sole discretion. Developer may include Company’ name and EHR in its published list of supported EHR integrations and partnerships for the purposes of Developer sales and marketing of the Technology. Developer acknowledges that the Company’s trademarks are owned solely and exclusively by Company and agrees to use the Company’s trademarks only in the form and manner as prescribed by Company. All use of the Company’s trademark shall inure to the benefit of the Company. Developer shall defend, indemnify, and hold harmless Company and its affiliates in connection with any third party claims or actions arising out of Developer’s unauthorized use of the Company trademarks. Company may terminate Developer’s right to use Company trademarks under this section (either in part or whole) immediately on notice, with or without cause. Such termination shall not terminate or otherwise affect this Agreement. Moreover, this permission shall terminate immediately upon termination or expiration of this Agreement. Upon termination or expiration of this Agreement, Company shall immediately stop using the Company trademarks.
Confidentiality.
1. Confidential Information. “Confidential Information” means any information disclosed by one party to the other whether orally or in writing that is designated as confidential or that reasonably should be understood by the receiving party to be confidential, notwithstanding the failure of the disclosing party to designate it as such. Confidential Information may include information that is proprietary to a third party and is disclosed by one party to another pursuant to this Agreement. The Services, all features and functions thereof and related pricing and product plans will be the Confidential Information of Company.
2. Non-Disclosure. Each party agrees to maintain the confidentiality of the other party’s Confidential Information with the same security and measures it uses to protect its own Confidential Information of a similar nature (but in no event less than reasonable security and measures) and not to use such Confidential Information except as necessary to perform its obligations or exercise its rights under this Agreement. The receiving party may disclose Confidential Information of the disclosing party to those employees, officers, directors, agents, affiliates, consultants, users, and suppliers who need to know such Confidential Information for the purpose of carrying out the activities contemplated by this Agreement and who have agreed to confidentiality provisions that are no less restrictive than the requirements herein. Such party will be responsible for any improper use or disclosure of the disclosing party’s Confidential Information by any such party. Except as expressly permitted by this Section, the receiving party will not disclose or facilitate the disclosure of Confidential Information of the disclosing party to any third party. The restrictions in this Section shall continue until such time as the information is covered by an exclusion set forth below.
3. Exclusions. The receiving party will have no obligation under this Section with respect to information provided by the disclosing party that: (a) is or becomes generally available to the public other than as a result of a breach of this Agreement by the receiving party, (b) is or becomes available to the receiving party from a source other than the disclosing party, provided that such source is not known to the receiving party to be bound by an obligation of confidentiality to the disclosing party with respect to such information, (c) was in the receiving party’s possession prior to disclosure by the disclosing party, or (d) is independently developed by the receiving party without reference to the Confidential Information. Further either party may disclose Confidential Information (i) as required by any court or other governmental body or as otherwise required by law, or (ii) as necessary for the enforcement of this Agreement or its rights hereunder.
Compliance with Laws.
1. PHI. “PHI” means “protected health information” as that term is used in the Health Insurance Portability and Accountability Act of 1996 as associated regulations as may be amended from time to time (“HIPAA”). Neither Party is the business associate of the other. If a Party requires PHI from the other to perform its obligations hereunder, and to the extent that the operation of any Interface capability as to any mutual client involves the use or disclosure of PHI by the other Party, each Party requesting or receiving such PHI agrees to: (a) obtain the written authorization of the client of all such uses and disclosures of information of that client and that client’s patients; (b) enter into an agreement with the client that complies with the applicable business associate provisions required by HIPAA prior to obtaining any PHI and requires that any patient consent that may be required by law for such uses and disclosures is obtained by the client; and (c) adopt and enforce appropriate physical, administrative, and technical measures to maintain privacy and security of such information in accordance with HIPAA and Applicable Law. Any PHI of a client unintentionally or incidentally disclosed to the other Party shall be held in confidence by the other Party in accordance with Applicable Law. Each Party will take reasonable steps to limit its request or requirement from the other Party of any client’s PHI to the minimum amount necessary to accomplish the intended purpose of requests for, and uses and disclosures of, such PHI in accordance with 45 C.F.R. 502(b)(1), and as authorized under HIPAA.
2. Personal Information. “Personal Information” means any information that a party collects, receives, or obtains, from or on behalf of Customers that does or can identify a specific individual or by or from which a specific individual may be identified, contacted, or located, such as the individual’s name; address; social security number; driver’s license number or state-issued identification card number; and any other information relating to an identified or identifiable individual, or may otherwise constitute personally identifiable information under any applicable law. Each party acknowledges and agrees that, in the course of performance of this Agreement, it may receive or have access to Personal Information. Each party shall comply with the terms and conditions set forth in this Agreement in its collection, receipt, transmission, storage, disposal, use, and disclosure of such Personal Information and be responsible for the unauthorized collection, receipt, transmission, access, storage, disposal, use, and disclosure of Personal Information under its control or in its possession.
3. Data Transmissions. In connection with any transfer of Personal Information or PHI between them in the operation of the API, each party: (i) will transfer such Personal Information or PHI only through use of a dedicated connection to which they are the only authorized parties or such other method of communication, such as encrypted communication, between them as offers an equivalent level of security and authentication of the recipient; (ii) will not permit any third party to use any such connection to the extent that such use is within that party’s control, except as permitted herein; and (iii) will take adequate and reasonable steps to ensure that access to that Personal Information and PHI at each facility that party has or on each system utilized by such party or its subcontractors is limited to authorized personnel of that party. Each party will take reasonable care to ensure that data transmissions between them in the operation of the API that contain any Personal Information or PHI are timely, complete, and accurate, and each party will take reasonable steps to retransmit any such data transmission to the other party upon discovery that the original transmission has been lost in transmission or is corrupted. If either party receives data from the other and is informed or believes that such data was not intended for it, the receiving party will notify the sender, promptly take effective steps to return such data, or at the direction of the other party immediately and permanently delete such data from its systems.
4. Compliance with Laws. Each party represents that its collection, access, use, storage, disposal, and disclosure of Personal Information and PHI does and will comply with all applicable law. Without limiting the parties’ obligations in the preceding sentence, each party shall implement administrative, physical, and technical safeguards to protect Personal Information and PHI that are no less rigorous than generally accepted industry standards, including, but not limited to, with respect to implementation, client service, payment security, functionality, ease of use, and the creation, access, storage, destruction, or exchange of Personal Information and PHI. If, in the course of performance of this Agreement, a party has access to or will collect, access, use, store, process, dispose of or disclose credit, debit, or other payment cardholder information, that party shall at all times remain in compliance with the Payment Card Industry Data Security Standard (“PCI DSS”) requirements, including remaining aware at all times of changes to the PCI DSS and promptly implementing all procedures and practices as may be necessary to remain in compliance with the PCI DSS, in each case, at such party’s sole cost and expense.
5. Anti-Fraud and Abuse Law Compliance. By entering into this Agreement, the parties specifically intend that no part of any consideration paid hereunder is a prohibited payment for the recommending or arranging for the referral of business or the ordering of items or services; nor are the payments intended to induce illegal referrals of business. If any part of this Agreement is determined to violate an applicable law, the parties agree to negotiate in good faith revisions to the provision or provisions that are in violation. If the parties are unable to agree to new or modified terms as required to bring the entire Agreement into compliance with such applicable law within 30 days, either party may terminate this Agreement on no less than 30 days prior written notice to the other party or sooner if required by any applicable law.
6. No Exclusion. If a party becomes debarred, excluded, suspended, or otherwise determined to be ineligible to participate in federal health care programs, that party shall provide notice thereof to the other party. Upon receipt of such notice, this Agreement shall automatically terminate without further action or notice.
Disclaimer. COMPANY DOES NOT WARRANT THAT THE SERVICES WILL BE ERROR-FREE OR UNINTERRUPTED, THAT COMPANY WILL CORRECT ALL ERRORS OR THAT THE SERVICES WILL MEET DEVELOPER’S REQUIREMENTS OR EXPECTATIONS. COMPANY IS NOT RESPONSIBLE FOR ANY ISSUES RELATED TO THE PERFORMANCE, OPERATIONS OR SECURITY OF THE SERVICES THAT ARISE FROM DEVELOPER’S TECHNOLOGY OR THIRD PARTY APPLICATIONS OR SERVICES PROVIDED BY THIRD PARTIES. COMPANY EXPRESSLY DISCLAIMS (TO THE GREATEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW) ALL OTHER WARRANTIES EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, TITLE, OR FITNESS FOR A PARTICULAR PURPOSE.
Limitation of Liability. IN NO EVENT WILL COMPANY OR ITS AFFILIATES BE LIABLE FOR ANY INDIRECT, CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR EXEMPLARY DAMAGES, OF ANY KIND OR NATURE ARISING OUT OF THIS AGREEMENT OR THE SERVICES, INCLUDING WITHOUT LIMITATION, ANY COST TO COVER PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES (WHICH THE PARTIES AGREE WILL NOT BE CONSIDERED DIRECT DAMAGES), OR ANY LOSS OF REVENUE, PROFITS, SALES, DATA, DATA USE, GOOD WILL, OR REPUTATION. COMPANY’ MAXIMUM LIABILITY ARISING OUT OF OR RELATED TO THE SERVICES OR THIS AGREEMENT WILL BE LIMITED TO THE AMOUNT OF FEES DEVELOPER HAS PAID TO COMPANY IN THE 3 MONTHS PRIOR TO THE EVENT(S) GIVING RISE TO SUCH LIABILITY. THE LIMITATIONS SET FORTH IN THIS SECTION APPLY REGARDLESS OF THE LEGAL THEORY ON WHICH A CLAIM IS BROUGHT, EVEN IF COMPANY HAS BEEN NOTIFIED OF THE POSSIBILITY OF DAMAGE OR IF SUCH DAMAGE COULD HAVE BEEN REASONABLY FORESEEN AND NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE OF ANY EXCLUSIVE REMEDY PROVIDED IN THIS AGREEMENT.
Indemnity.
1. By Company. Company will indemnify and hold Developer, its affiliates and each of its and its affiliates’ employees, contractors, directors, suppliers and representatives harmless against any action brought against Developer by a third party to the extent such action is based on a claim that the unmodified Services as used in accordance with this Agreement infringe a copyright, patent, trademark or misappropriate a trade secret of such third party or other proprietary right enforceable in the country in which Company has authorized Developer to use the Services. Should the Services become, or in Company’ opinion be likely to become, the subject of any infringement claim, Company may, at its option: (a) procure for Developer, at Company’ expense, the right to continue using the Services, (b) modify, at Company’ expense, the Services so that it becomes non-infringing but remains functionally equivalent, or (c) terminate Developer’s right to use the Services and refund to Developer any unused pre-paid fees for such Services. Company will have no liability for any claim of intellectual property infringement that is based on (i) the use or combination of the Services with any products, services, data or other materials not provided by Company, provided such infringement would not have arisen but for such combination, (ii) the use of other than a current, unaltered version of the Service, (iii) specifications or designed provided by Developer, or (iv) any unauthorized modification of the Services.
2. By Developer. Developer agrees to defend and indemnify Company and its affiliates from and against any legal action, demand, suit, or proceeding brought against Company or its affiliates by a third party arising out of or related to Developer’s use of the Services.
3. Indemnification Procedures. Each party’s indemnification obligations are subject to conditions that the indemnified party must: (a) notify the indemnifying party promptly in writing of such claim; (b) permit the indemnifying party to have sole control of the defense, compromise, or settlement of such claim, including any appeals, provided, that the indemnifying party will not settle any claim in a manner that adversely affect the rights of the indemnified party without the indemnified party’s prior written consent; and (c) fully cooperate with the indemnifying party at the indemnifying party’s expense in the defense or settlement of such claim.
4. Disclaimer. This Section states the entire liability of Company, and Developer’s sole and exclusive remedy, with respect to the infringement of any intellectual property rights by the Service.
Term and Termination.
1. Term. This Agreement will be effective as of the Developer’s initial creation of a developer’s account or access of the APIs (“Effective Date”) and remain in effect until terminated by either party as permitted by this Agreement. The initial term will be for one year, thereafter, this Agreement will automatically renew for successive one-year periods, unless cancelled by either party in accordance with this Agreement.
2. Termination. Either party may terminate this Agreement for any reason or no reason by providing at least 90 days’ prior written notice. Either party may terminate this Agreement immediately for a breach by the other party of any of its material terms, if the breaching party has failed to cure such breach (if curable) within 30 days of receipt of written notice from the non-breaching party describing the breach. Either party may terminate this Agreement without notice if the other party becomes insolvent, makes or has made an assignment for the benefit of creditors, is the subject of proceedings in voluntary or involuntary bankruptcy instituted on behalf of or against such party (except for involuntary bankruptcies which are dismissed within 60 days), or has a receiver or trustee appointed for substantially all of its property.
3. Effects of Termination. Upon the expiration or termination of this Agreement for any reason, (a) Developer will immediately cease using the Services for any of Developer’s Customers who have not yet executed a contract with Developer for the deployment of Technology dependent on the Services, (b) upon request, each party will return or destroy all Confidential Information of the other party, provided, that each party may retain one copy of the Confidential information of the other party as necessary to comply with applicable law or its records retention or archival policies or practices (and such retained Confidential Information will remain subject the non-disclosure obligations in this Agreement) and (c) any unpaid, undisputed amounts due through termination will become immediately due and payable and (d) for those Customers who are in contract with Developer, and who have deployed and are using the Technology in conjunction with the Services, Developer shall cease using the Services for, with and on behalf of those Customers within a 90 day period from the date of termination, during which Customers have the opportunity to remove business and technical dependencies and migrate away from the Technology (“Wind-Down”). This Wind-Down period may be extended by mutual, written agreement of the parties.
4. Survival. Any provisions of this Agreement that expressly, or by implication, are intended to survive its termination or expiration will survive and continue to bind the parties, including without limitation provisions relating to confidentiality, representations and warranties, indemnification, limitations on liability, intellectual property, and Developer’s payment obligations under this Agreement.
Assignment. Developer may not assign or transfer this Agreement or any of its rights or obligations hereunder in whole or in part without the prior written consent of Company. Subject to the foregoing, this Agreement will inure to the benefit of, be binding upon, and be enforceable against, each of the parties hereto and their respective successors and assigns.
Attorney’s Fees. In the event any proceeding or lawsuit is brought in connection with this Agreement, the prevailing party in such proceeding will be entitled to receive its reasonable costs, expert witness and attorneys’ fees.
Relationship of the Parties. This Agreement does not create any joint venture, partnership, agency, or employment relationship between the parties.
No Third-Party Beneficiaries. This Agreement is being entered into for the sole benefit of the parties hereto, and nothing herein, express or implied, is intended to or will confer upon any other person or entity any legal or equitable right, benefit or remedy of any nature whatsoever.
Equitable Remedies. Each party acknowledges and agrees that (a) a breach or threatened breach by such party may give rise to irreparable harm to the other party for which monetary damages may not be an adequate remedy; and (b) if a breach or threatened breach by such party occurs, the other party will in addition to any and all other rights and remedies that may be available to such other party at law, at equity or otherwise in respect of such breach, be entitled to seek equitable relief that may be available from a court of competent jurisdiction, without any requirement to post a bond or other security.
Force Majeure. Neither party will be liable under this Agreement for any failure or delay in the performance of its obligations (except for the payment of money) on account of strikes, shortages, riots, insurrections, fires, flood, storm, explosions, acts of God, war, governmental action, pandemics, earthquakes, material shortages, or any other cause that is beyond the reasonable control of such party.
Export Compliance. Developer must comply with United States, foreign and international laws and regulations, including without limitation, the United States Export Administration Regulations and the United States Office of Foreign Asset Control regulations, and other anti-boycott and import regulations. Such export laws govern use of the Services including technical data and any deliverables provided under this Agreement and Developer agrees to comply with all such laws and regulations (including “deemed export” and “deemed re-export” regulations). Developer is responsible for ensuring that no data, information, software programs and/or materials resulting from the Services (or direct product thereof) will be exported directly or indirectly in violation of these laws. Developer will indemnify Company for any violation by Developer of any applicable export controls or economic sanctions laws and regulations.
Governing Law, Jurisdiction and Venue. This Agreement will be governed by and construed in all respects in accordance with the laws of the State of Delaware, without regard to its conflicts of laws principles. Each party hereby consents to the exclusive venue and jurisdiction of the courts of Indiana. THE PARTIES FURTHER AGREE, TO THE EXTENT PERMITTED BY APPLICABLE LAW, TO WAIVE ANY RIGHT TO TRIAL BY JURY WITH RESPECT TO ANY CLAIM, COUNTERCLAIM OR ACTION ARISING FROM THE TERMS OF THIS AGREEMENT.
Severability, Waiver and Amendment. If any provision of this Agreement is held by a court of competent jurisdiction to be unenforceable or invalid, such provision will be changed and interpreted as to best accomplish the objectives of the original provision to the fullest extent permitted by law, and the remaining provisions will remain in full force and effect. No waiver of any term or right in this Agreement will be effective unless made in writing and signed by an authorized representative of the waiving party. Any waiver or failure to enforce any provision of this Agreement will not be deemed a waiver of future enforcement of that or any other provision. Except to the extent otherwise expressly provided in this Agreement, this Agreement may only be amended in writing signed by both parties hereto.
Notices. Any notices pertaining to this Agreement shall be addressed to the appropriate party as follows, unless otherwise provided in this Agreement:
For Company:

legal@evercommerce.com

-and-

EverHealth Solutions Inc.
Attn: Legal

# Introduction This document is intended as a detailed reference for the precise behavior of the DrChrono API. If this is your first time using the API, start with our tutorial. If you are upgrading from a previous version, take a look at the changelog section. ### Requests All requests must be made using the base URL `https://app.drchrono.com`. For each endpoint, up to six different kinds of requests may be permitted: Path | Method | Side Effects | Success Status | Failure Status | Response Content ---- | ------ | ------------ | -------------- | -------------- | --------------- `:endpoint` | `GET` | None | `200` | `403` | Paginated list of all endpoint resources that the requester can access `:endpoint/:id` | `GET` | None | `200` | `403` or `404` | Object with requested ID `:endpoint` | `POST` | Create object | `201` | `400`, `403`, or `409` | Object(s) created `:endpoint/:id` | `PUT` | Update entire object | `204` | `400`, `403`, or `409` | Empty `:endpoint/:id` | `PATCH` | Update only included values of object | `204` | `400`, `403`, or `409` | Empty `:endpoint/:id` | `DELETE` | Delete object | `204` | `400` or `403` | Empty ### Responses All responses are in JSON format. Generally input may use the `application/json`, `application/x-www-form-urlencoded`, or `form/multipart` content types. The list of objects returned by a `GET` request to `:endpoint` is paginated and has the following format: { "previous": URL or null, // URL of the previous page "results": array of objects, // these results follow the same format as `:endpoint/:id` "next": URL or null // URL of the next page (same as the requested URL, but with the page query parameter included) } Most page sizes default to 250, but can be lowered by setting the `page_size` query parameter. The 'api/appointments' endpoint is an exception to this rule as it has a max size of 20. Some endpoints may return a `302` redirect response. Most libraries handle this incorrectly by resending the response with different headers or a different HTTP method. You will need to resend the original request with the right HTTP method and headers to the new "Location" specified by the `302` response. ### Permissions API access is managed using scopes and permissions. Scopes are granted to an API Application when a user authorizes and permissions are granted by a primary user to other users in their Practice Group. The scopes are granted during the OAuth process, whereas the permissions have to be granted from DrChrono web app. In order for an app to access information on behalf of a DrChrono user, the user must authorize the app for the requested scopes, and the user must have the appropriate permissions set. Each endpoint in this documentation will specify which scopes and permissions are needed for access. Scopes are labeled `drchrono_oauth2` in the AUTHORIZATIONS section of each endpoint. ### Data Types The data types referred to in this documentation, for both requests and responses, are listed below: Type | Example | Description ---- | ------- | ----------- boolean | `true` | a binary variable, having two possible values of `true` and `false` integer | `123` | represents some range of mathmatical integers string | `HelloWorld` | sequence of characters URL | `"http://example.com/index.html"` | An absolute URL, including protocol object | `{"key": "value"}` | A nested object. All values that are type "object" will have a clickable dropdown of the object's format array | `[1,2]` | A value may have type "array of :type" date | `"2021-02-14"` | An ISO 8601 encoded date date range | `"2021-02-17/2021-02-24"` | A start and end date separated by a slash file | `"https://rackcdn.com/file.ext"` | When uploading, this is provided as a standard `multipart/form-data` file base64encoded file | `"https://rackcdn.com/file.ext"` | When uploading, this is provided as a base64 encoded file within JSON time | `"12:34:56"` | An ISO 8601 encoded time timestamp | `"2021-02-14T13:40:39"` | AN ISO 8601 encoded timestamp, with no as_system_timezone color | `"#ABCDEF"` or `"rgb(12, 34, 56)"` | A CSS color specified in either of these formats decimal | `"123.45"` | A numeric value truncated to two decimal places. It may be passed to an endpoint as an integer, float, or string, but will always be returned as a string. ### Verbose Parameter For some endpoints, certain fields will be excluded in the response to a `GET` request unless the `verbose` query parameter is passed with the value `true`. These fields have a particularly large performance penalty. Passing `verbose=true` will include these keys in the response, but will reduce the default and maximum page sizes to 50. ### Rate Limits Applications are subject to an hourly rate limit, which will reset at the top of each hour. Requests over this limit will receive a response with code `429`. By default, applications are limited to 500 calls per hour. Contact api@drchrono.com or your account representative to request an increased rate limit. ### Endpoint Levels `Level 1 API Call(s)` and `Level 2 API(s)` are defined in the following table and are based on the listed `Endpoint`; the Endpoint's corresponding `Level` number listed denotes whether that Endpoint constitutes a Level 1 API Call vs. a Level 2 API Call. DrChrono's definition of Level 1 API Calls and Level 2 API Calls as listed in the following table are subject to change at DrChrono's sole discretion. ENDPOINT | Level ---------- | ----- `/api/allergies` | 1 `/api/appointments` | 1 `/api/appointment_profiles` | 1 `/api/appointment_templates` | 1 `/api/billing_profiles` | 1 `/api/care_plans` | 1 `/api/clinical_note_templates` | 1 `/api/comm_logs` | 1 `/api/consent_forms` | 1 `/api/custom_appointment_fields` | 1 `/api/custom_demographics` | 1 `/api/custom_vitals` | 1 `/api/doctors` | 1 `/api/documents` | 1 `/api/iframe_integration` | 1 `/api/implantable_devices` | 1 `/api/inventory_categories` | 1 `/api/inventory_vaccines` | 1 `/api/medications` | 1 `/api/offices` | 1 `/api/patients` | 1 `/api/patients/:id/ccda` | 1 `/api/patients/:id/qrda1` | 1 `/api/patients/:id/onpatient_access` | 1 `/api/patient_communications` | 1 `/api/patient_flag_types` | 1 `/api/patient_interventions` | 1 `/api/patient_physical_exams` | 1 `/api/patient_risk_assessments` | 1 `/api/patients_summary` | 1 `/api/problems` | 1 `/api/reminder_profiles` | 1 `/api/telehealth_appointments` | 1 `/api/users` | 1 `/api/user_groups` | 1 `/o/authorize` | 1 `/o/revoke_token` | 1 `/o/token` | 1 `/api/amendments` | 2 `/api/claim_billing_notes` | 2 `/api/clinical_notes` | 2 `/api/clinical_note_field_types` | 2 `/api/clinical_note_field_values` | 2 `/api/custom_insurance_plan_names` | 2 `/api/eligibility_checks` | 2 `/api/eobs`| 2 `/api/fee_schedules` | 2 `/api/insurances` | 2 `/api/lab_documents` | 2 `/api/lab_orders` | 2 `/api/lab_orders_summary` | 2 `/api/lab_tests` | 2 `/api/lab_results` | 2 `/api/line_items` | 2 `/api/medications/:id/append_to_pharmacy_note` | 2 `/api/messages` | 2 `/api/offices/:id/add_exam_room` | 2 `/api/pateint_lab_results` | 2 `/api/patient_messages` | 2 `/api/patient_payments` | 2 `/api/patient_payment_log` | 2 `/api/patient_vaccine_records` | 2 `/api/prescription_messages` | 2 `/api/procedures` | 2 `/api/sublabs` | 2 `/api/tasks` | 2 `/api/task_categories` | 2 `/api/task_notes` | 2 `/api/task_templates` | 2 `/api/task_statuses` | 2 `/api/transactions` | 2 # Authorization ## Initial authorization There are three main steps in the OAuth 2.0 authentication workflow: 1. Redirect the provider to the authorization page. 2. The provider authorizes your application and is redirected back to your web application. 3. Your application exchanges the `authorization_code` that came with the redirect for an `access_token` and `refresh_token`. ### Step 1: Redirect to drchrono The first step is redirecting your user to drchrono, typically with a button labeled "Connect to drchrono" or "Login with drchrono". This is just a link that takes your user to the following URL: https://app.drchrono.com/o/authorize/?redirect_uri=REDIRECT_URI_ENCODED&response_type=code&client_id=CLIENT_ID_ENCODED&scope=SCOPES_ENCODED - `REDIRECT_URI_ENCODED` is the URL-encoded version of the redirect URI (as registered for your application and used in later steps). - `CLIENT_ID_ENCODED` is the URL-encoded version of your application's client ID. - `SCOPES_ENCODED` is a URL-encoded version of a space-separated list of scopes, which can be found in each endpoint or omitted to default to all scopes. The `scope` parameter consists of an optional, space-separated list of scopes your application is requesting. If omitted, all scopes will be requested. Scopes are of the form `BASE_SCOPE:[read|write]` where `BASE_SCOPE` is any of `user`, `calendar`, `patients`, `patients:summary`, `billing`, `clinical` and `labs`. You should request only the scopes you need. For instance, an application which sends "Happy Birthday!" emails to a doctor's patients on their birthdays would use the scope parameter `"patients:summary:read"`, while one that allows patients to schedule appointments online would need at least `"patients:summary:read patients:summary:write calendar:read calendar:write clinical:read clinical:write"`. ### Step 2: Provider authorization After logging in (if necessary), the provider will be presented with a screen with your application's name and the list of permissions you requested (via the `scope` parameter). When they click the "Authorize" button, they will be redirected to your redirect URI with a `code` query parameter appended, which contains an authorization code to be used in step 3. If they click the "Cancel" button, they will be redirected to your redirect URI with `error=access_denied` instead. Note: This authorization code expires extremely quickly, so you must perform step 3 immediately, ideally before rendering the resulting page for the end user. ### Step 3: Token exchange The `code` obtained from step 2 is usable exactly once to obtain an access token and refresh token. Here is an example token exchange in Python: import datetime, pytz, requests if 'error' in get_params: raise ValueError('Error authorizing application: %s' % get_params[error]) response = requests.post('https://app.drchrono.com/o/token/', data={ 'code': get_params['code'], 'grant_type': 'authorization_code', 'redirect_uri': 'http://mytestapp.com/redirect_uri', 'client_id': 'abcdefg12345', 'client_secret': 'abcdefg12345', }) response.raise_for_status() data = response.json() # Save these in your database associated with the user access_token = data['access_token'] refresh_token = data['refresh_token'] expires_timestamp = datetime.datetime.now(pytz.utc) + datetime.timedelta(seconds=data['expires_in']) You now have all you need to make API requests authenticated as that provider. When using this access token, you'll only be able to access the data that the user has access to and that you have been granted permissions for. ## Refreshing an access token Access tokens only last 48 hours (given in seconds in the `'expires_in'` key in the token exchange step above), so they occasionally need to be refreshed. It would be inconvenient to ask the user to re-authorize every time, so instead you can use the refresh token like the original authorization to obtain a new access token. Replace the `code` parameter with `refresh_token`, change the value `grant_type` from `authorization_code` to `refresh_token`, and omit the `redirect_uri` parameter. Example in Python: ... response = requests.post('https://app.drchrono.com/o/token/', data={ 'refresh_token': get_refresh_token(), 'grant_type': 'refresh_token', 'client_id': 'abcdefg12345', 'client_secret': 'abcdefg12345', }) ... # Webhooks In order to use drchrono API webhooks, you first need to have an API application on file (even if it is in Test Model). Each API webhook is associated with one API application, go to here to set up both API applications and webhooks! Once you registered an API application, you will see webhook section in each saved API applications. Create a webhook and register some events there and save all the changes, then you are good to go! ## Webhooks setup All fields under webhooks section are required. **Callback URL** Callback URl is used to receive all hooks when subscribed events are triggered. This should be an URL under your control. **Secret token** Secret token is used to verify webhooks, this is very important, please set something with high entropy. Also we will talk more about this later. **Events** Events is used to register events you want to receiver notification when they happen. Currently we support following events. Event name | Event description ---------- | ----------------- `APPOINTMENT_CREATE` | We will deliver a hook any time an appointment is created `APPOINTMENT_MODIFY` | We will deliver a hook any time an appointment is modified `APPOINTMENT_DELETE` | We will deliver a hook any time an appointment is deleted `CASH_PAYMENT_DELETE` | We will deliver a hook any time a patient payment is deleted `CLINICAL_NOTE_LOCK` | We will deliver a hook any time a clinical note is locked `CLINICAL_NOTE_UNLOCK` | We will deliver a hook any time a clinical note is unlocked `LAB_ORDER_CREATE` | We will deliver a hook any time a lab order is created `LAB_ORDER_MODIFY` | We will deliver a hook any time a lab order is modified `LAB_ORDER_DELETE` | We will deliver a hook any time a lab order is deleted `LINE_ITEM_CREATE` | We will deliver a hook any time a line item is created `LINE_ITEM_MODIFY` | We will deliver a hook any time a line item is modified `LINE_ITEM_DELETE` | We will deliver a hook any time a line item is deleted `LINE_ITEM_TRANSACTION_DELETE` | We will deliver a hook any time a line item transaction is deleted `PATIENT_CREATE` | We will deliver a hook any time a patient is created `PATIENT_MODIFY` | We will deliver a hook any time a patient is modified `PATIENT_ALLERGY_CREATE` | We will deliver a hook any time a patient allergy is created `PATIENT_ALLERGY_MODIFY` | We will deliver a hook any time a patient allergy is modified `PATIENT_FLAG_CREATE` | We will deliver a hook any time a patient flag is created `PATIENT_FLAG_CMODIFY` | We will deliver a hook any time a patient flag is modified `PATIENT_PROBLEM_CREATE` | We will deliver a hook any time a patient problem is created `PATIENT_PROBLEM_MODIFY` | We will deliver a hook any time a patient problem is modified `PATIENT_MEDICATION_CREATE` | We will deliver a hook any time a patient medication is created `PATIENT_MEDICATION_MODIFY` | We will deliver a hook any time a patient medication is modified `TASK_CREATE` | We will deliver a hook any time a task is created `TASK_MODIFY` | We will deliver a hook any time a task is modified and any time creation, modification and deletion of task notes, associated task item `TASK_DELETE` | We will deliver a hook any time a task is deleted `VACCINE_ADMINISTERED` | We will deliver a hook any time a vaccine consent form is signed ## Webhooks verification In order to make sure the callback URL in webhook is under your control, we added a verification step before we send any hooks out to you. Verification can be done by clicking "Verify webhook" button in webhooks setup page. After you click the button, we will send a `GET` request to the callback URL, along with a parameter called `msg`. Please use your webhook's secret token as hash key and SHA-256 as digest constructor, hash the `msg` value with HMAC algorithm. And we expect a `200` JSON response, in JSON response body, there should be a key called `secret_token` existing, and its value should be equal to the hashed `msg`. Otherwise, verification will fail. Here is an example webhook verification in Python: import hashlib, hmac def webhook_verify(request): secret_token = hmac.new(WEBHOOK_SECRET_TOKEN, request.GET['msg'], hashlib.sha256).hexdigest() return json_response({ 'secret_token': secret_token })

Note: Verification will be needed when webhook is first created and anytime callback URl is changed.

## Webhooks header and body **Header** Key | Value --- | ----- `X-drchrono-event` | Event that triggered this hook, could be any one event above or `PING` `X-drchrono-signature` | Secret token associated with this webhook `X-drchrono-delivery` | ID of this delivery **Body** Key | Value --- | ----- `receiver` | This will be an JSON representation of the webhook `object` | This will be an JSON representation of the object related to the triggered event, this would share same serializer as drchrono API ## Webhooks ping and deliveries Webhooks ping and deliveries will be sent as `POST` requests. **PING**: You can always ping your webhook to check things, by clicking the "Ping webhook" button in webhook setup page. And a hook with header `X-drchrono-event: PING` would be sent to the callback URL. **Deliveries**: You can check recent deliveries by clicking the "deliveries" link in webhook setup page. And you can resend a hook by clicking "redeliver" button after select a specific delivery. ## Webhooks delivery mechanism We will delivery a hook the moment a subscribed event is triggered. We will not record any response header or body you send back after you receive the hook. However we only consider the response status code. We will consider any `2xx` responses as successfully delivered. Any other responses, like `302` would be considered failing. And we will try to redeliver unsuccessfully delivered hooks 3 times, first redeliver happens at 1 hour after the initial event, second redeliver happens 3 hours after the initial event, and the third redeliver happens 7 hours after the initial event. After these intents, if the delivery is still unsuccessful, you have to redeliver it by hand. ## Webhooks security You may want to secure your webhooks to only consider requests send out from drchrono. And this is where secret_token is needed in request header. Try to set the secret_token to something with high entropy, a good example could be taking the output of ruby -rsecurerandom -e 'puts SecureRandom.hex(20)'. After this, you might want to verify all request headers you received on your server with this token. # iframe integration Some API apps provide additional functionality for interacting with patient data not offered by drchrono, and can benefit by being incorporated into drchrono's patient information page via iframe. We have created a simple API to make this possible. To make an existing API application accessible via an iframe on the patient page, you need to update either "Patient iframe" or "Clinical note iframe" section in API management page, to make the iframe to appear on (either the patient page or the clinical note page), with the URL that the iframe will use for each page, and the height it should have. The application will be reviewed before it is approved to ensure that it is functional and secure. ## Register a Doctor iframe applications will appear as choices on the left-hand menu of the patient page for doctors registered with your application. To register a doctor with your application, make a `POST` request to the `/api/iframe_integration` endpoint using the access token for the corresponding doctor. This endpoint does not expect any payload. To disable your iframe application for a doctor, make a `DELETE` request to the same endpoint. ## Populating the iframe There are two places where the iframe can be displayed, either within the patient detail page or the clinical note page, shown below respectively: ### Patient Chart ![Iframe on the patient page](https://app.drchrono.com/site_media/public/images/iframe_patient_page.png "Patient Chart iFrame") ### Clinical Note ![Iframe on the clinical note page](https://app.drchrono.com/site_media/public/images/iframe_clinical_note.png "Clincal Note iFrame") When requesting approval for your iframe app, you must specify a URL for one or both of these pages which will serve as the base URL for your IFrame contents. When a doctor views your iframe, the source URL will have various query parameters appended to it, for example for the patient page the `src` parameter of the IFrame will be: ``` ?doctor_id=&patient_id=&practice_id=&iat=&jwt= ``` The `jwt` parameter is crucial if your application transfers any sort of PHI and does not implement its own login system. It encapsulates the other parameters in a [JSON web token (JWT)](http://jwt.io) and signs them using SHA-256 HMAC with your `client_secret` as the key. This verifies that the iframe is being loaded within one of drchrono's pages by an authorized user. In production, you should validate the JWT using an approved library (which are listed on the [official site](http://jwt.io)), and only use the parameters extracted from the JWT. Using Python and Django, this might look like: import jwt CLIENT_SECRET = MAX_TIME_DRIFT_SECONDS = 60 def validate_parameters(request): token = request.GET['jwt'] return jwt.decode(token, CLIENT_SECRET, algorithms=['HS256'], leeway=MAX_TIME_DRIFT_SECONDS) Modern browsers' same-origin policy means that data cannot be passed between your application and drchrono's page through the iframe. Therefore, interaction must happen through the API, using information provided in JWT. # Versions and deprecation ## Stability Policy Changes to this API version will be limited to adding endpoints, or adding fields to existing endpoints, or adding optional query parameters. Any new fields which are not read-only will be optional. ## Deprecation Policy The drchrono API is versioned. Versions can be in the following states: * **Active:** This is our latest and greatest version of the API. It is actively supported by our API team and is improved upon with new features, bug fixes and optimizations that do not break backwards compatibility. * **Deprecated:** A deprecated API version is considered second best--having been surpassed by our active API version. An API version remains in this state for one year, after which time it falls to the not supported state. A deprecated API version is passively supported; while it won't be removed until becoming unsupported, it may not receive new features but will likely be subject to security updates and performance improvements. * **Unsupported:** An API version in the not supported state may be deactivated at any time. An application using an unsupported API version should migrate to an active API version. ## Version Map | Version Name | Previous Name | Start Date | Deprecation Date | |--------------|---------------|------------|------------------| | v2 | v2015_08 | 08/2015 | TBA | | v3 | v2016_06 | 06/2016 | | | v4 | N/A | 09/2018 | | If you are looking for documentation for an older version - [V4(Hunt Valley)](/api-docs-old/v4/documentation) (old V4 documentation) - [V3(Sunnyvale)](/api-docs-old/v3/documentation) - [V2(Mountain View)](/api-docs-old/v2/documentation) # Changelog Here's changelog for different versions - [Current Changelog](https://headwayapp.co/drchrono-changelog) - [V4 Changelog](/api-docs-old/v4/changelog) - [V3 Changelog](/api-docs-old/v3/changelog) Give your agent hands-on access to DrChrono. Ask for what you need in plain language — your agent runs the right command and gets structured JSON back, ready to act on. No tab-switching, no copy-paste: 329 operations across 89 areas, runnable from chat or any automation. ## What you can do - **Allergies** — Manage allergies - **Amendments** — Manage amendments - **Appointment Profiles** — Manage appointment profiles - **Appointment Templates** — Manage appointment templates - **Appointments** — Manage appointments - **Appointments List** — Manage appointments list - **Audit Log** — Manage audit log - **Availability** — Manage availability - **Billing Profiles** — Manage billing profiles - **Care Plans** — Manage care plans - **Care Team Members** — Manage care team members - **Claim Billing Notes** — Manage claim billing notes - **Clinical Note Field Types** — Manage clinical note field types - **Clinical Note Field Values** — Manage clinical note field values - **Clinical Note Field Values List** — Manage clinical note field values list - **Clinical Note Templates** — Manage clinical note templates - **Clinical Notes** — Manage clinical notes - **Clinical Notes List** — Manage clinical notes list - **Comm Logs** — Manage comm logs - **Consent Forms** — Manage consent forms - **Custom Appointment Fields** — Manage custom appointment fields - **Custom Demographics** — Manage custom demographics - **Custom Insurance Plan Names** — Manage custom insurance plan names - **Custom Vitals** — Manage custom vitals - **Day Sheet Charges** — Manage day sheet charges - **Day Sheet Credits** — Manage day sheet credits - **Day Sheet Patient Payments** — Manage day sheet patient payments - **Day Sheet Totals** — Manage day sheet totals - **Doctor Options** — Manage doctor options - **Doctor Work Schedule** — Manage doctor work schedule - **Doctors** — Manage doctors - **Documents** — Manage documents - **Eligibility Checks** — Manage eligibility checks - **Eligibility Checks List** — Manage eligibility checks list - **Eobs** — Manage eobs - **Fee Schedules** — Manage fee schedules - **Fee Schedules V2** — Manage fee schedules v2 - **Implantable Devices** — Manage implantable devices - **Insurances** — Manage insurances - **Inventory Categories** — Manage inventory categories - **Inventory Vaccines** — Manage inventory vaccines - **Lab Documents** — Manage lab documents - **Lab Orders** — Manage lab orders - **Lab Orders Summary** — Manage lab orders summary - **Lab Results** — Manage lab results - **Lab Tests** — Manage lab tests - **Line Item Deletions** — Manage line item deletions - **Line Items** — Manage line items - **Line Items List** — Manage line items list - **Medications** — Manage medications - **Message Threads** — Manage message threads - **Messages** — Manage messages - **Office Work Schedule** — Manage office work schedule - **Offices** — Manage offices - **Patient Authorizations** — Manage patient authorizations - **Patient Communications** — Manage patient communications - **Patient Flag Types** — Manage patient flag types - **Patient Interventions** — Manage patient interventions - **Patient Lab Results** — Manage patient lab results - **Patient Messages** — Manage patient messages - **Patient Payment Log** — Manage patient payment log - **Patient Payments** — Manage patient payments - **Patient Physical Exams** — Manage patient physical exams - **Patient Risk Assessments** — Manage patient risk assessments - **Patient Vaccine Records** — Manage patient vaccine records - **Patients** — Manage patients - **Patients List** — Manage patients list - **Patients Summary** — Manage patients summary - **Prescription Messages** — Manage prescription messages - **Prescription Messages List** — Manage prescription messages list - **Problems** — Manage problems - **Procedures** — Manage procedures - **Recurring Appointment Instances** — Manage recurring appointment instances - **Reminder Profiles** — Manage reminder profiles - **Schedule Blocks** — Manage schedule blocks - **Signed Consent Forms** — Manage signed consent forms - **Staff** — Manage staff - **Sublabs** — Manage sublabs - **Task Categories** — Manage task categories - **Task Notes** — Manage task notes - **Task Statuses** — Manage task statuses - **Task Templates** — Manage task templates - **Tasks** — Manage tasks - **Telehealth Appointment History** — Manage telehealth appointment history - **Telehealth Appointments** — Manage telehealth appointments - **Transactions** — Manage transactions - **Transactions List** — Manage transactions list - **User Groups** — Manage user groups - **Users** — Manage users Each area ships with a bundled skill that teaches your agent the commands, flags, and common workflows — install and it knows what to do. ## Quick Start ```bash # Check connectivity $DRCHRONO_BIN ping # See all available commands $DRCHRONO_BIN --help ``` ## Authentication This plugin uses OAuth (authorization code) to connect to your DrChrono account. 1. Create an OAuth application in the DrChrono developer console 2. Set the redirect URI to `http://localhost:31752/callback` 3. Set `DRCHRONO_CLIENT_ID` and `DRCHRONO_CLIENT_SECRET` environment variables ```bash # Start the OAuth login flow $DRCHRONO_BIN auth login # Check auth status $DRCHRONO_BIN auth status ``` ## Commands | Command | What it does | |---------|--------------| | `ping` | Check API reachability | | `doctor` | Verify credentials and connectivity | | `allergies create` | Create patient allergy | | `allergies list` | Retrieve or search patient allergies | | `allergies partial-update` | Update an existing patient allergy | | `allergies read` | Retrieve an existing patient allergy | | `allergies update` | Update an existing patient allergy | | `amendments create` | Create patient amendments to a patient's clinical records | | `amendments delete` | Delete an existing patient amendment, you can only interact with amendments created by your API application | | `amendments list` | Retrieve or search patient amendments. You can only interact with amendments created by your API application | | `amendments partial-update` | Update an existing patient amendment, you can only interact with amendments created by your API application | | `amendments read` | Retrieve an existing patient amendment, you can only interact with amendments created by your API application | | `amendments update` | Update an existing patient amendment, you can only interact with amendments created by your API application | | `appointment-profiles create` | Create appointment profiles for a doctor's calendar | | `appointment-profiles delete` | Delete an existing appointment profile | | `appointment-profiles list` | Retrieve or search appointment profiles for a doctor's calendar | | `appointment-profiles partial-update` | Update an existing appointment profile | | `appointment-profiles read` | Retrieve an existing appointment profile | | `appointment-profiles update` | Update an existing appointment profile | | `appointment-templates create` | Create appointment templates for a doctor's calendar | | `appointment-templates delete` | Delete an existing appointment template | | `appointment-templates list` | Retrieve or search appointment templates for a doctor's calendar | | `appointment-templates partial-update` | Update an existing appointment template | | `appointment-templates read` | Retrieve an existing appointment template | | `appointment-templates update` | Update an existing appointment template | | `appointments create` | Create a new appointment or break on doctor's calendar | | `appointments delete` | Delete an existing appointment or break | | `appointments list` | Retrieve or search appointment or breaks. Note: Either `since`, `occurred_since`, `date` or `date_range` parameter must be specified. results returned in order of scheduled date. | | `appointments partial-update` | Update an existing appointment or break | | `appointments read` | Retrieve an existing appointment or break | | `appointments update` | Update an existing appointment or break | | `appointments-list create` | Create | | `appointments-list delete` | Delete | | `appointments-list list` | List | | `appointments-list partial-update` | Partial update | | `appointments-list read` | Read | | `appointments-list update` | Update | | `audit-log list` | Retrieve or search audit logs. Note: Either `since`, `date` or `date_range` parameter must be specified. | | `availability availability` | Retrieve availability slots for the given date and office, doctor, or exam room. If the `exam_room` parameter is not specified, the response will include availability for all exam rooms in the… | | `billing-profiles list` | Retrieve or search billing profiles | | `billing-profiles read` | Retrieve an existing billing profiles | | `care-plans list` | Retrieve or search care plans | | `care-plans read` | Retrieve an existing care plan | | `care-team-members list` | List | | `care-team-members read` | Read | | `claim-billing-notes create` | Create a new billing note | | `claim-billing-notes list` | Retrieve or search billing notes | | `claim-billing-notes read` | Retrieve an existing billing note | | `clinical-note-field-types list` | Retrieve or search clinical note field types | | `clinical-note-field-types read` | Retrieve an existing clinial note field type | | `clinical-note-field-types update` | Update the `freedraw_image_size` of an existing clinical note FreeDraw Field | | `clinical-note-field-values create` | Create clinical note field value | | `clinical-note-field-values list` | Retrieve or search clinical note field values | | `clinical-note-field-values partial-update` | Update an existing clinical note field value | | `clinical-note-field-values read` | Retrieve an existing clinical note field value | | `clinical-note-field-values update` | Update an existing clinical note field value | | `clinical-note-field-values-list create` | Create clinical note field value list request. Use the UUID returned in the response to retrieve the batch of records. Results returned in order of ID. | | `clinical-note-field-values-list list` | Retrieve or search clinical note values (soap notes) in batches. Results returned in order of ID or by updated_at. | | `clinical-note-templates list` | Retrieve or search clinical note templates | | `clinical-note-templates read` | Retrieve an existing clinical note tempalte | | `clinical-notes list` | List | | `clinical-notes read` | Read | | `clinical-notes-list create` | Create clinical note list request. Use the UUID returned in the response to retrieve the batch of records. Results returned in order of ID. | | `clinical-notes-list list` | Retrieve or search clinical notes in batches. Results returned in order of ID. | | `comm-logs create` | Create communication (phone call) logs | | `comm-logs list` | Retrieve or search communicatioin (phone call) logs | | `comm-logs partial-update` | Update an existing communication (phone call) logs | | `comm-logs read` | Retrieve an existing communication (phone call) logs | | `comm-logs update` | Update an existing communication (phone call) logs | | `consent-forms create` | Create a patient consent form | | `consent-forms list` | Retrieve or search patient consent forms | | `consent-forms partial-update` | Update an existing patient consent form | | `consent-forms read` | Retrieve an existing patient consent form | | `consent-forms update` | Update an existing patient consent form | | `consent-forms apply-to-appointment` | Assign (apply) a consent form to appointment | | `consent-forms unapply-from-appointment` | Unassign (unapply) a consent form from appointment | | `custom-appointment-fields create` | Create custom appointment fields | | `custom-appointment-fields list` | Retrieve or search custom appointment fields | | `custom-appointment-fields partial-update` | Update an existing custom appointment field | | `custom-appointment-fields read` | Retrieve an existing custom appointment field | | `custom-appointment-fields update` | Update an existing custom appointment field | | `custom-demographics create` | Create custom demographics fields | | `custom-demographics list` | Retrieve or search custom demographics fields | | `custom-demographics partial-update` | Update an existing custom demographics field | | `custom-demographics read` | Retrieve an existing custom demographics field | | `custom-demographics update` | Update an existing custom demographics field | | `custom-insurance-plan-names list` | Retrieve or search custom insurance plan names | | `custom-insurance-plan-names read` | Retrieve an existing custom insurance plan name | | `custom-vitals list` | Retrieve or search custom vital types | | `custom-vitals read` | Retrieve an existing custom vital type | | `day-sheet-charges daysheet-charges-list` | Retrieve daysheet charges report for a given date range | | `day-sheet-credits daysheet-credits-list` | Retrieve daysheet credits/adjustments report for a given date range | | `day-sheet-patient-payments list` | Retrieve daysheet cash report for a given date range | | `day-sheet-totals daysheet-totals-list` | Retrieve daysheet totals report for a given date range | | `doctor-options list` | Retrieve or search doctor options within practice group | | `doctor-options read` | Retrieve existing options for a doctor | | `doctor-work-schedule list` | Get the work schedule for the authed doctor's primary office (beta) | | `doctor-work-schedule partial-update` | Update an existing doctor's work schedule | | `doctor-work-schedule read` | Retrieve a work schedule for the doctor (beta) | | `doctor-work-schedule update` | Update an existing doctor's entire work schedule | | `doctors list` | Retrieve or search doctors within practice group | | `doctors read` | Retrieve an existing doctor | | `documents create` | Create documents | | `documents delete` | Delete an existing appointment template | | `documents list` | Retrieve or search documents | | `documents partial-update` | Update an existing patient document | | `documents read` | Retrieve an existing patient document | | `documents update` | Update an existing patient document | | `eligibility-checks list` | Retrieve or search past eligibility checks for patient | | `eligibility-checks read` | Retrieve an existing past eligibility check | | `eligibility-checks-list create` | Create eligibility checks list request. Use the UUID returned in the response to retrieve the batch of records. Results returned in order of id or updated_at. | | `eligibility-checks-list list` | Retrieve or search eligibility checks in batches. Results returned in order of ID or updated_at. | | `eobs create` | Create EOB object | | `eobs list` | Retrieve or search EOB objects | | `eobs read` | Retrieve an existing EOB object | | `fee-schedules list` | List | | `fee-schedules read` | Read | | `fee-schedules-v2 list` | List | | `fee-schedules-v2 read` | Read | | `implantable-devices list` | Retrieve or search implantable devices | | `implantable-devices read` | Retrieve an existing implantable device | | `insurances list` | List | | `insurances read` | Read | | `inventory-categories list` | Retrieve or search inventory categories | | `inventory-categories read` | Retrieve an existing inventory category | | `inventory-vaccines create` | Create vaccine inventory | | `inventory-vaccines list` | Retrieve or search vaccine inventories | | `inventory-vaccines read` | Retrieve an existing vaccine inventory | | `lab-documents create` | Create lab order documents. An example lab workflow is as following: - When you get orders, submit them via `/api/lab_orders`, such that doctors can see them in drchrono. - When results come in… | | `lab-documents delete` | Delete an existing lab order document | | `lab-documents list` | Retrieve or search lab order documents | | `lab-documents partial-update` | Update an existing lab order document | | `lab-documents read` | Retrieve an existing appointment template | | `lab-documents update` | Update an existing lab order document | | `lab-orders create` | Create lab orders. An example lab workflow is as following: - When you get orders, submit them via `/api/lab_orders`, such that doctors can see them in drchrono. - When results come in, submit the… | | `lab-orders delete` | Delete an existing lab order | | `lab-orders list` | Retrieve or search lab orders | | `lab-orders partial-update` | Update an existing lab order | | `lab-orders read` | Retrieve an existing lab order | | `lab-orders update` | Update an existing lab order | | `lab-orders-summary list` | List | | `lab-orders-summary read` | Read | | `lab-results create` | Create lab results. An example lab workflow is as following: - When you get orders, submit them via `/api/lab_orders`, such that doctors can see them in drchrono. - When results come in, submit the… | | `lab-results delete` | Delete an existing lab result | | `lab-results list` | Retrieve or search lab results | | `lab-results partial-update` | Update an existing lab result | | `lab-results read` | Retrieve an existing lab result | | `lab-results update` | Update an existing lab result | | `lab-tests create` | Create lab tests. An example lab workflow is as following: - When you get orders, submit them via `/api/lab_orders`, such that doctors can see them in drchrono. - When results come in, submit the… | | `lab-tests delete` | Delete an existing lab test | | `lab-tests list` | Retrieve or search lab tests | | `lab-tests partial-update` | Update an existing lab test | | `lab-tests read` | Retrieve an existing lab test | | `lab-tests update` | Update an existing lab test | | `line-item-deletions list` | Retrieve or search billing line item deletions. When a billing line item is deleted, a record of its original ID and the appointment it was attached to will be logged and is accessible from this… | | `line-items create` | Create billing line item for appointments | | `line-items delete` | Delete | | `line-items list` | Retrieve or search billing line items | | `line-items partial-update` | Partial update | | `line-items read` | Retrieve an existing billing line item | | `line-items update` | Update | | `line-items-list create` | Create a billing line items list request | | `line-items-list list` | Retrieve the list of billing line items | | `medications create` | Create patient medications | | `medications list` | Retrieve or search patient medications | | `medications partial-update` | Update an existing patient medications | | `medications read` | Retrieve an existing patient medications | | `medications update` | Update an existing patient medications | | `medications append-to-pharmacy-note` | Append a message to the "pharmacy_note" section of the prescription, in a new paragraph | | `message-threads list-beta` | Retrieve or search message threads in doctor's message center. (beta) Message threads are grouped conversations that aggregate related messages by subject and patient. Use this endpoint to display an… | | `message-threads partial-update-beta` | Partially update a message thread. Only the following fields can be updated: - `archived` (boolean): Mark thread as archived/unarchived - `starred` (boolean): Mark thread as starred/unstarred -… | | `message-threads read-beta` | Retrieve a single message thread by ID (beta) Work to support message threads is currently in development. This is not ready for full use. | | `messages create` | Create messages in doctor's message center | | `messages delete` | Delete an existing message in doctor's message center | | `messages list` | Retrieve or search messages in doctor's message center | | `messages partial-update` | Update an existing message in doctor's message center | | `messages read` | Retrieve an existing message in doctor's message center | | `messages update` | Update an existing message in doctor's message center | | `office-work-schedule list` | Get the work schedule for the authed doctor's primary office (beta) | | `office-work-schedule partial-update` | Update an existing office's work schedule | | `office-work-schedule read` | Retrieve a work schedule (beta) | | `office-work-schedule update` | Update an existing office's entire work schedule | | `offices list` | Retrieve or search offices | | `offices partial-update` | Update an existing office | | `offices read` | Retrieve an existing office | | `offices update` | Update an existing office | | `offices add-exam-room` | Add an exam room to the office | | `patient-authorizations list` | Retrieve or search patient authorizations | | `patient-communications create` | Create patient communication for CQM | | `patient-communications list` | Retrieve or search patient communications for CQM | | `patient-communications partial-update` | Update an existing patient communication for CQM | | `patient-communications read` | Retrieve an existing patient communication for CQM | | `patient-communications update` | Update an existing patient communication for CQM | | `patient-flag-types create` | Create patient flag types | | `patient-flag-types list` | Retrieve or search patient flag types | | `patient-flag-types partial-update` | Update an existing patient flag type | | `patient-flag-types read` | Retrieve an existing patient flag type | | `patient-flag-types update` | Update an existing patient flag type | | `patient-interventions create` | Create patient intervention for CQM | | `patient-interventions list` | Retrieve or search patient interventions for CQM | | `patient-interventions partial-update` | Update an existing patient intervention for CQM | | `patient-interventions read` | Retrieve an existing patient intervention for CQM | | `patient-interventions update` | Update an existing patient intervention for CQM | | `patient-lab-results create` | Create | | `patient-lab-results delete` | Delete | | `patient-lab-results list` | List | | `patient-lab-results partial-update` | Partial update | | `patient-lab-results read` | Read | | `patient-lab-results update` | Update | | `patient-messages create` | Create | | `patient-messages list` | List | | `patient-messages partial-update` | Partial update | | `patient-messages read` | Read | | `patient-messages update` | Update | | `patient-payment-log list` | Retrieve or search patient payment logs | | `patient-payment-log read` | Retrieve an existing patient payment log | | `patient-payments create` | Create patient payment | | `patient-payments list` | Retrieve or search patient payments | | `patient-payments read` | Retrieve an existing patient payment | | `patient-physical-exams create` | Create patient physical exam for CQM | | `patient-physical-exams list` | Retrieve or search patient physical exams for CQM | | `patient-physical-exams partial-update` | Update an existing patient physical exam for CQM | | `patient-physical-exams read` | Retrieve an existing patient physical exam for CQM | | `patient-physical-exams update` | Update an existing patient physical exam for CQM | | `patient-risk-assessments create` | Create | | `patient-risk-assessments list` | List | | `patient-risk-assessments partial-update` | Partial update | | `patient-risk-assessments read` | Read | | `patient-risk-assessments update` | Update | | `patient-vaccine-records create` | Create patient vaccine records | | `patient-vaccine-records list` | Retrieve or search patient vaccine records | | `patient-vaccine-records partial-update` | Update an existing patient vaccine records | | `patient-vaccine-records read` | Retrieve an existing patient vaccine records | | `patient-vaccine-records update` | Update an existing patient vaccine records | | `patients create` | Create patient | | `patients delete` | Delete an existing patient | | `patients list` | Retrieve or search patients | | `patients partial-update` | Update an existing patient | | `patients read` | Retrieve an existing patient | | `patients update` | Update an existing patient | | `patients ccda` | Retrieve patient CCDA | | `patients ccda-async` | Retrieve patient CCDA async. | | `patients create-onpatient-access` | Send new onpatient invite to patient | | `patients delete-onpatient-access` | Revoke sent onpatient invites | | `patients get-onpatient-access` | Retrieve or search existing onpatient access invites | | `patients qrda1` | Retrieve patient QRDA1 | | `patients-list create` | Submit patient list request. Use the UUID returned in the response to retrieve the batch of patients. | | `patients-list list` | Retrieve or search patients in batches. This resource returns identical data to `GET /api/patients` but uses an asynchronous batch-based approach to data delivery. This is an efficient choice for… | | `patients-summary create` | Create | | `patients-summary delete` | Delete | | `patients-summary list` | List | | `patients-summary partial-update` | Partial update | | `patients-summary read` | Read | | `patients-summary update` | Update | | `prescription-messages list` | Retrieve or search prescription messages | | `prescription-messages read` | Retrieve an existing prescription message | | `prescription-messages-list create` | Create prescription messages list request. Use the UUID returned in the response to retrieve the batch of records. Results returned in order of id or updated_at. | | `prescription-messages-list list` | Retrieve or search prescription messages in batches. Results returned in order of ID or updated_at. | | `problems create` | Create patient problems | | `problems list` | Retrieve or search patient problems | | `problems partial-update` | Update an existing patient problems | | `problems read` | Retrieve an existing patient problems | | `problems update` | Update an existing patient problems | | `procedures list` | List | | `procedures read` | Read | | `recurring-appointment-instances list` | List all instances (materialized and virtual) within a recurring appointment series. Returns the same appointment response format as `/api/appointments`. Materialized instances have a real `id`;… | | `reminder-profiles create` | Create reminder profile | | `reminder-profiles delete` | Delete an existing reminder profile | | `reminder-profiles list` | Retrieve or search reminder profiles | | `reminder-profiles partial-update` | Update an existing reminder profile | | `reminder-profiles read` | Retrieve an existing reminder profile | | `reminder-profiles update` | Update an existing reminder profile | | `schedule-blocks create` | Create a new schedule block to block off time on a provider's calendar. This prevents appointments from being scheduled during the specified time period. Use this to block time for lunch breaks… | | `schedule-blocks delete` | Delete an existing schedule block. This will remove the block from the provider's calendar and allow appointments to be scheduled during that time period again. | | `schedule-blocks list` | Retrieve or search schedule blocks. Schedule blocks are used to block off time on a provider's calendar to prevent appointments from being scheduled. Use this to retrieve existing blocks for lunch… | | `schedule-blocks partial-update` | Partially update an existing schedule block. You can modify the time, description, color, or other properties. Use this to reschedule a block or change its details. | | `schedule-blocks read` | Retrieve an existing schedule block by ID | | `schedule-blocks update` | Update an existing schedule block. Unlike PATCH, PUT requires all fields to be provided. Use this when you want to completely replace the schedule block data. | | `signed-consent-forms create` | Create a signed consent form record for a patient and consent form | | `signed-consent-forms list` | Retrieve or search signed consent forms | | `signed-consent-forms partial-update` | Update an existing consent form signature | | `signed-consent-forms read` | Retrieve a single signed consent form record by id | | `staff list` | List | | `staff read` | Read | | `sublabs create` | Create sub-vendors - When you get orders, submit them via `/api/lab_orders`, such that doctors can see them in drchrono. - When results come in, submit the result document PDF via… | | `sublabs delete` | Delete an existing sub vendor | | `sublabs list` | Retrieve or search sub vendors | | `sublabs partial-update` | Update an existing sub vendor | | `sublabs read` | Retrieve an existing sub vendor | | `sublabs update` | Update an existing sub vendor | | `task-categories create` | Create a task category | | `task-categories list` | Retrieve or search task categories | | `task-categories partial-update` | Update an existing task category | | `task-categories read` | Retrieve an existing task category | | `task-categories update` | Update an existing task category | | `task-notes create` | Create a task note | | `task-notes list` | Retrieve or search task notes | | `task-notes partial-update` | Update an existing task note | | `task-notes read` | Retrieve an existing task note | | `task-notes update` | Update an existing task note | | `task-statuses create` | Create a task status | | `task-statuses list` | Retrieve or search task statuses | | `task-statuses partial-update` | Update an existing task status | | `task-statuses read` | Retrieve an existing task status | | `task-statuses update` | Update an existing task status | | `task-templates create` | Create a task template | | `task-templates list` | Retrieve or search task templates | | `task-templates partial-update` | Update an existing task template | | `task-templates read` | Retrieve an existing task template | | `task-templates update` | Update an existing task template | | `tasks create` | Create a task | | `tasks list` | Retrieve or search tasks | | `tasks partial-update` | Update an existing task | | `tasks read` | Retrieve an existing task | | `tasks update` | Update an existing task | | `telehealth-appointment-history create` | Create | | `telehealth-appointment-history list` | List | | `telehealth-appointment-history read` | Read | | `telehealth-appointments create` | Create | | `telehealth-appointments list` | List | | `telehealth-appointments partial-update` | Partial update | | `telehealth-appointments read` | Read | | `telehealth-appointments update` | Update | | `transactions list` | Retrieve or search insurance transactions associated with billing line items | | `transactions read` | Retrieve an existing insurance transaction | | `transactions-list create` | Create transactions list request. Use the UUID returned in the response to retrieve the batch of records. Results returned in order of id or updated_at. | | `transactions-list list` | Retrieve or search transactions in batches. Results returned in order of ID or updated_at. | | `user-groups list` | Retrieve or search user groups | | `user-groups read` | Retrieve an existing user group | | `users list` | Retrieve or search users, `/api/users/current` can be used to identify logged in user, it will redirect to `/api/users/{current_user_id}` | | `users read` | Retrieve an existing user, `/api/users/current` can be used to identify logged in user, it will redirect to `/api/users/{current_user_id}` | ## Bundled Skills | Skill | What it does | |-------|--------------| | `drchrono-quickstart` | Probe the API and learn the available subcommands. | | `drchrono-allergies` | Manage allergies | | `drchrono-amendments` | Manage amendments | | `drchrono-appointment-profiles` | Manage appointment profiles | | `drchrono-appointment-templates` | Manage appointment templates | | `drchrono-appointments` | Manage appointments | | `drchrono-appointments-list` | Manage appointments list | | `drchrono-audit-log` | Manage audit log | | `drchrono-availability` | Manage availability | | `drchrono-billing-profiles` | Manage billing profiles | | `drchrono-care-plans` | Manage care plans | | `drchrono-care-team-members` | Manage care team members | | `drchrono-claim-billing-notes` | Manage claim billing notes | | `drchrono-clinical-note-field-types` | Manage clinical note field types | | `drchrono-clinical-note-field-values` | Manage clinical note field values | | `drchrono-clinical-note-field-values-list` | Manage clinical note field values list | | `drchrono-clinical-note-templates` | Manage clinical note templates | | `drchrono-clinical-notes` | Manage clinical notes | | `drchrono-clinical-notes-list` | Manage clinical notes list | | `drchrono-comm-logs` | Manage comm logs | | `drchrono-consent-forms` | Manage consent forms | | `drchrono-custom-appointment-fields` | Manage custom appointment fields | | `drchrono-custom-demographics` | Manage custom demographics | | `drchrono-custom-insurance-plan-names` | Manage custom insurance plan names | | `drchrono-custom-vitals` | Manage custom vitals | | `drchrono-day-sheet-charges` | Manage day sheet charges | | `drchrono-day-sheet-credits` | Manage day sheet credits | | `drchrono-day-sheet-patient-payments` | Manage day sheet patient payments | | `drchrono-day-sheet-totals` | Manage day sheet totals | | `drchrono-doctor-options` | Manage doctor options | | `drchrono-doctor-work-schedule` | Manage doctor work schedule | | `drchrono-doctors` | Manage doctors | | `drchrono-documents` | Manage documents | | `drchrono-eligibility-checks` | Manage eligibility checks | | `drchrono-eligibility-checks-list` | Manage eligibility checks list | | `drchrono-eobs` | Manage eobs | | `drchrono-fee-schedules` | Manage fee schedules | | `drchrono-fee-schedules-v2` | Manage fee schedules v2 | | `drchrono-implantable-devices` | Manage implantable devices | | `drchrono-insurances` | Manage insurances | | `drchrono-inventory-categories` | Manage inventory categories | | `drchrono-inventory-vaccines` | Manage inventory vaccines | | `drchrono-lab-documents` | Manage lab documents | | `drchrono-lab-orders` | Manage lab orders | | `drchrono-lab-orders-summary` | Manage lab orders summary | | `drchrono-lab-results` | Manage lab results | | `drchrono-lab-tests` | Manage lab tests | | `drchrono-line-item-deletions` | Manage line item deletions | | `drchrono-line-items` | Manage line items | | `drchrono-line-items-list` | Manage line items list | | `drchrono-medications` | Manage medications | | `drchrono-message-threads` | Manage message threads | | `drchrono-messages` | Manage messages | | `drchrono-office-work-schedule` | Manage office work schedule | | `drchrono-offices` | Manage offices | | `drchrono-patient-authorizations` | Manage patient authorizations | | `drchrono-patient-communications` | Manage patient communications | | `drchrono-patient-flag-types` | Manage patient flag types | | `drchrono-patient-interventions` | Manage patient interventions | | `drchrono-patient-lab-results` | Manage patient lab results | | `drchrono-patient-messages` | Manage patient messages | | `drchrono-patient-payment-log` | Manage patient payment log | | `drchrono-patient-payments` | Manage patient payments | | `drchrono-patient-physical-exams` | Manage patient physical exams | | `drchrono-patient-risk-assessments` | Manage patient risk assessments | | `drchrono-patient-vaccine-records` | Manage patient vaccine records | | `drchrono-patients` | Manage patients | | `drchrono-patients-list` | Manage patients list | | `drchrono-patients-summary` | Manage patients summary | | `drchrono-prescription-messages` | Manage prescription messages | | `drchrono-prescription-messages-list` | Manage prescription messages list | | `drchrono-problems` | Manage problems | | `drchrono-procedures` | Manage procedures | | `drchrono-recurring-appointment-instances` | Manage recurring appointment instances | | `drchrono-reminder-profiles` | Manage reminder profiles | | `drchrono-schedule-blocks` | Manage schedule blocks | | `drchrono-signed-consent-forms` | Manage signed consent forms | | `drchrono-staff` | Manage staff | | `drchrono-sublabs` | Manage sublabs | | `drchrono-task-categories` | Manage task categories | | `drchrono-task-notes` | Manage task notes | | `drchrono-task-statuses` | Manage task statuses | | `drchrono-task-templates` | Manage task templates | | `drchrono-tasks` | Manage tasks | | `drchrono-telehealth-appointment-history` | Manage telehealth appointment history | | `drchrono-telehealth-appointments` | Manage telehealth appointments | | `drchrono-transactions` | Manage transactions | | `drchrono-transactions-list` | Manage transactions list | | `drchrono-user-groups` | Manage user groups | | `drchrono-users` | Manage users | ## Data Privacy This plugin runs entirely on your machine. API calls go directly from your computer to the DrChrono API — no data passes through NeboAI servers. Credentials are stored locally and never leave your device.

DrChrono

About this plugin