|
|
| (5 intermediate revisions by one user not shown) |
| Line 1: |
Line 1: |
| − | The main entry point to access and invoke Updox API calls is through creating an Account. An Account represents a single group of Users, Contacts, Patients, Settings, and Portal accounts. Different systems refer to this same concept in different ways; for example: clients, practices, accounts, etc.
| + | This page has been separated into an [[Account Management]] page and a [[User Management]] page. Please update your bookmark(s) accordingly. |
| − |
| + | |
| − | Within each Account there must be at least one User to auth with. A User represents a single group of Messages, Preferences, and Settings. Different systems also refer to users in various, sometime overlapping, ways; for example: providers, doctors, nurses, admins, office, etc.
| + | |
| − | | + | |
| − | = Account Management =
| + | |
| − | | + | |
| − | The Updox API provides three methods to create an Account: PracticeCreate, PracticeUpdate, and PracticeSave.
| + | |
| − | | + | |
| − | Creating or updating an Account requires [[Vendor credentialing|Vendor-level credentials]].
| + | |
| − |
| + | |
| − |
| + | |
| − |
| + | |
| − |
| + | |
| − | == PracticeCreate ==
| + | |
| − | | + | |
| − | The PracticeCreate API method is an explicit call to create a new Account. It accepts multiple fields of both information about the Account as well as settings, though only the <code>name</code> field is required. Providing Account information will help to facilitate referencing the Account for support issues, while providing settings may be required for use in a particular integration.
| + | |
| − | | + | |
| − | {{API Method Links|PracticeCreate}}
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | === Account Information Fields ===
| + | |
| − | ==== <code>name</code> ====
| + | |
| − | Name of the account or practice.
| + | |
| − | ==== <code>address1</code> ====
| + | |
| − | ==== <code>address2</code> ====
| + | |
| − | ==== <code>city</code> ====
| + | |
| − | ==== <code>state</code> ====
| + | |
| − | Valid state or US territory
| + | |
| − | ==== <code>postal</code> ====
| + | |
| − | Five or nine digits only
| + | |
| − | ==== <code>phone</code> ====
| + | |
| − | Ten digits only
| + | |
| − | ==== <code>fax</code> ====
| + | |
| − | | + | |
| − | === Account Settings Fields ===
| + | |
| − | ==== <code>accountId</code> ====
| + | |
| − | | + | |
| − | When creating an Account, the <code>accountId</code> passed into the Application Authentication Header with the request will become the new <code>accountId</code> used to reference and auth with the newly created Account. If that <code>accountId</code> is already in use, then the request will fail with an <code>responseCode</code> value of <code>4130: account already exists</code>.
| + | |
| − | | + | |
| − | ==== <code>active</code> ====
| + | |
| − | | + | |
| − | The <code>active</code> setting for Accounts sets the active status. An inactive account will be denied authorization, and in the interests of security, any attempt to authorize will be met with the same failure message as invalid credentials. The exceptions to this are the methods {{PracticeUpdateLink}} and {{PracticeSaveLink}} which allow re-activation of an Account. Thus, care must be taken when setting the <code>active</code> flag.
| + | |
| − | | + | |
| − | ==== <code>directAddress</code> ====
| + | |
| − | | + | |
| − | The <code>directAddress</code> setting for Accounts sets the direct address for the Account. This is the address that will be used for direct messages sent from the Account level, opposed to a specific User. Direct messages sent from and to the Account are viewable by all Users in the Account.
| + | |
| − | | + | |
| − | ==== <code>timeZone</code> ====
| + | |
| − | | + | |
| − | The <code>timeZone</code> setting for Accounts sets the timeZone for the Account which effects the representation of date-times for items. The default value is Zulu time, and the valid values are:
| + | |
| − |
| + | |
| − | : America/Anchorage
| + | |
| − | : America/Chicago
| + | |
| − | : America/Denver
| + | |
| − | : America/New_York
| + | |
| − | : America/Los_Angeles
| + | |
| − | : America/Phoenix
| + | |
| − | : America/Puerto_Rico
| + | |
| − | : Pacific/Honolulu
| + | |
| − | : Zulu
| + | |
| − | | + | |
| − | ==== <code>websiteAddress</code> ====
| + | |
| − | | + | |
| − | The <code>websiteAddress</code> setting for Accounts sets the specific domain for the Patient Portal for that account. For example, in the Updox production region, if an Account sets the <code>websiteAddress</code> to "updox" then the web address for the Patient Portal of that account would be https://updox.myupdox.com. The <code>websiteAddress</code> must be globally unique across all Updox accounts and the call to create a practice will fail if the address is already in use.
| + | |
| − | | + | |
| − | == PracticeUpdate ==
| + | |
| − | | + | |
| − | PracticeUpdate is an explicit call to update the information or settings of an Account. It provides the same fields as PracticeCreate, and '''''every field will be updated with the new values'''''. That is, if an Account has a value saved for <code>city</code>, then not passing in a value for <code>city</code> to PracticeUpdate will '''''clear''''' that value.
| + | |
| − |
| + | |
| − | Note that when updating an Account, the <code>accountId</code> passed into the Application Authentication header will reference the Account to be updated. If an Account does not exist for that <code>accountId</code>, the request will fail.
| + | |
| − | | + | |
| − | *[[API Method PracticeCreate|Sample code and request/response JSON transactions using this API method]]
| + | |
| − | *[https://updoxqa.com/iodox/updox-iodox# Interactive API page for this API method]
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == PracticeSave ==
| + | |
| − | | + | |
| − | PracticeSave is a non-explicit call to *either* create *or* update an Account. If an Account does not exist for the <code>accountId</code> passed into the Application Authentication header, then a new Account will be created. Otherwise, the matching Account will be updated.
| + | |
| − |
| + | |
| − | In the respective cases, PracticeSave performs as PracticeCreate and PracticeUpdate.
| + | |
| − | | + | |
| − | *[[API Method PracticeCreate|Sample code and request/response JSON transactions using this API method]]
| + | |
| − | *[https://updoxqa.com/iodox/updox-iodox# Interactive API page for this API method]
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | = User Management =
| + | |
| − | | + | |
| − | The Updox API provides three methods to create a user: [[#UserCreate]], [[#UserUpdate]], and [[#UserSave]].
| + | |
| − | | + | |
| − | Creating or updating a User requires [[account-level credentials]].
| + | |
| − | | + | |
| − | == UserCreate ==
| + | |
| − | | + | |
| − | {{UserCreateLink}} is an explicit call to create a new User. It accepts multiple fields of both information about the User as well as settings, though only the <code>firstName</code> and <code>lastName</code> fields are required. Providing Account information will help to reference the User for support issues, while providing settings may be required for use in a particular integration.
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | === User Information Fields ===
| + | |
| − | ==== <code>userId</code> ====
| + | |
| − | Note that when creating a User, the <code>userId</code> passed into the Application Authentication Header with the request will become the new userId used to reference and auth with the newly created User. If that <code>userId</code> is already in use, then the request will fail.
| + | |
| − | ==== <code>firstName</code> ====
| + | |
| − | ==== <code>middleName</code> ====
| + | |
| − | ==== <code>lastName</code> ====
| + | |
| − | ==== <code>address1</code> ====
| + | |
| − | ==== <code>address2</code> ====
| + | |
| − | ==== <code>city</code> ====
| + | |
| − | ==== <code>state</code> ====
| + | |
| − | ==== <code>postal</code> ====
| + | |
| − | | + | |
| − | === User Settings Fields ===
| + | |
| − | ==== <code>active</code> ====
| + | |
| − | The active setting for Users sets the active status. An inactive User will be denied authorization, and for security any attempt to auth will be met with the same unauthorized message as invalid credentials. The exceptions to this are the methods UserUpdate and UserSave which allow re-activation of a User. Thus, care must be taken when setting the active flag.
| + | |
| − |
| + | |
| − | ==== <code>directAddress</code> ====
| + | |
| − | | + | |
| − | The directAddress setting for Users sets the direct address for that User. This is the address that will be used for direct messages sent from the User. Direct messages sent from and to the User are viewable only by that User, or by others who have visibility to that User's workspace.
| + | |
| − | | + | |
| − | ==== <code>loginId</code> and <code>loginPassword</code> ====
| + | |
| − | | + | |
| − | The loginId and loginPassword settings for Users sets the login ID (or username) and login password to be used both for the Individual Authorization for that user, and for logging into the full Updox application.
| + | |
| − | | + | |
| − | ==== <code>timeZone</code> ====
| + | |
| − | | + | |
| − | The timeZone setting for Users sets the timeZone for the User which effects the representation of date-times for items. The default value is Zulu time, and the valid values are:
| + | |
| − |
| + | |
| − | : America/Anchorage
| + | |
| − | : America/Chicago
| + | |
| − | : America/Denver
| + | |
| − | : America/New_York
| + | |
| − | : America/Los_Angeles
| + | |
| − | : America/Phoenix
| + | |
| − | : America/Puerto_Rico
| + | |
| − | : Pacific/Honolulu
| + | |
| − | : Zulu
| + | |
| − | | + | |
| − | == UserUpdate ==
| + | |
| − | | + | |
| − | {{UserUpdateLink}} is an explicit call to update the information or settings of a User. It provides the same fields as {{UserCreateLink}}, and '''''every field will be updated with the new values'''''. That is, if a User has a value saved for <code>middleName</code>, then not passing in a value for <code>middleName</code> to {{UserUpdateLink}} will clear that value.
| + | |
| − |
| + | |
| − | Note that when updating a User, the <code>userId</code> passed into the Application Authentication header will reference the User to be updated. If a User does not exist for that <code>userId</code>, the request will fail.
| + | |
| − | | + | |
| − | == UserSave ==
| + | |
| − | | + | |
| − | {{UserSaveLink}} is a non-explicit call to *either* create *or* update a User. If a User does not exist for the <code>userId</code> passed into the Application Authentication header, then a new User will be created. Otherwise, the matching User will be updated.
| + | |
| − |
| + | |
| − | In the respective cases, {{UserSaveLink}} performs as {{UserCreateLink}} and {{UserUpdateLink}}.
| + | |
