Difference between revisions of "Summary"
(Created page with "== Updox Integration Summary == This document describes Updox Direct Messaging integration methods to satisfy ONC 2014 Edition criteria for Meaningful Use Stage 2. With Updox,...") |
|||
| Line 60: | Line 60: | ||
All API calls share a minimum, common, request message. Request messages are always a JSON object, containing, at a minimum, the following element(s): | All API calls share a minimum, common, request message. Request messages are always a JSON object, containing, at a minimum, the following element(s): | ||
| − | Field Description Notes | + | {| class="wikitable" |
| − | applicationId GUID/STRING (required) | + | |- |
| − | applicationPassword GUID/STRING (required) | + | ! Field !! Description !! Notes |
| − | accountId STRING (required, unique) Uniquely identifies a group of users (typically represents a practice) | + | |- |
| − | userId STRING (required, unique within account) Uniquely identifies a user within the specified account | + | | applicationId || GUID/STRING || (required) |
| + | |- | ||
| + | | applicationPassword || GUID/STRING || (required) | ||
| + | |- | ||
| + | | accountId || STRING || (required, unique) Uniquely identifies a group of users (typically represents a practice) | ||
| + | |- | ||
| + | | userId || STRING || (required, unique within account) Uniquely identifies a user within the specified account | ||
| + | |} | ||
=== Recipient Identifiers === | === Recipient Identifiers === | ||
Revision as of 09:01, 27 September 2013
Updox Integration Summary
This document describes Updox Direct Messaging integration methods to satisfy ONC 2014 Edition criteria for Meaningful Use Stage 2. With Updox, electronic health record (EHR) partners can satisfy the following criteria:
- 170.314(b)(2) - Transitions of care - create and transmit transition of care/referral summaries
- 170.314(b)(1) - Transitions of care - receive, display and incorporate transition of care/referral summaries
- 170.314(e)(1) - View, download, and transmit to 3rd party
- 170.314(e)(3) - Secure messaging
Updox offers several integration options for EHRs to meet their unique environments. Specific scenarios include:
If an EHR is Direct ready, and the EHR user interface (UI) can be used to send/receive messages, the Updox Direct infrastructure can be accessed via APIs. As an alternative, the EHR can access Updox via Single Sign On (SSO) and utilize a private anded Updox UI for sending/receiving. In addition, the EHR can use its own portal or Updox provides a patient portal
The following provides an overview of how Updox can be leveraged to meet each of the 2014 criteria named above, with notes indicating the relevant APIs within the document.
Contents |
Transition of Care (Send)
There are two options for sending the Transition of Care (ToC).
For the API approach, the EHR will need to provide users with a screen to capture the To address, Title of Message and a Body of Text. Once collected, the DirectMessageSend API will be called to send the message, and the CCDA pushed to Updox through the API. In this approach the address book in the EHR will be used. A failed message will provide an error message that will need to be displayed in the EHR. The EHR will also be responsible for logging the action (e.g. who sent, when and what).
The other option for EHRs that do not have the UI to initiate the sending of the ToC, is to use SSO. Please see the SSO section for more detailed information. In this approach, the user will launch an EHR anded screen through SSO, and on this screen the user can enter the To, Title and Message body. The document will pushed to Updox via the DirectMessageSendUI. In this method the Updox address book can be used to store addresses. An optional one way sync from the EHR address book to the Updox address book is available. Any sending error messages will be displayed in the Updox screen. Logging information, including who, when, what will be called by Updox via (API), as implemented by the EHR.
Transition of Care (Receive)
The majority of time, EHRs will provide a location for inbound ToCs to land. In this scenario, an inbound ToC will arrive in the Updox infrastructure, and Updox will provide the MessageListSince/MessageRetrieve API for the EHR to retrieve the document. A custom notification can be created to send to the EHR when a document/message arrives, or the EHR can check to pull the document.
As an alternative, if the EHR does not have a message center to receive documents, an EHR anded version of the Updox can be accessed via a SSO.
View/Download/Transmit
For this criterion, the patient must be able to view, download and transmit their clinical document.
For EHRs that are using their own portal, Updox will assist with the Transmit portion of V/D/T using Direct. Within the EHR?s portal, the UI needs to contain the ability to enter a To address, title and body of text. The EHR?s portal will call the PatientDirectMessageSend API to transmit the document. At the time of transmit, the patient will be given a hidden address for purposes of routing replies to the message sent. The EHR?s portal will use its address book and will need to display any sending error messages. The EHR?s portal will be responsible for logging the who, what time and what action, since the transmit will be initiated from the EHR. In addition, if someone responds to the message the patient transmits, the inbound message will be retrievable by the EHR via the MessageRetrieve API and the EHR will manage the routing of the message to the patient.
For EHRs that are using the Updox portal, Updox will handle all portions of V/D/T. From the EHR, it will have the ability to create portal accounts for patients via the PortalAccountSave API. The EHR can then send a document to a patient via the PortalDeliverRecord API. The patient will have the ability to view, download and then transmit the document from the Updox portal. The address book within the Updox portal will be used. In addition, the Updox portal will have the ability for responsible parties to view accounts for which they have access, and the portal will display what actions a patient has taken in respect to V/D/T. The log of activity, e.g. who, when, what action, will be accessible via the EventLog API for the EHR to add to their Meaningful Use dashboard. Any replies to the patient will be placed in the patient?s inbox in the Updox portal. Users will be required to use the Updox UI for portal configuration (e.g. to set up the portal).
Secure Messaging
For EHRs using the Updox patient portal, Updox will assist with meeting the Secure Messaging criteria. From the EHR, a user can send a message to a patient via the portal. The EHR will create patient portal accounts via the PortalAccountSave API and send the message to the patient via the PortalDeliverMessage API. The patient can then logon to the portal and view the message. In addition, authorized representatives will have access too. Patients can send messages to the EHR users. The EHR has two options, if there is a place to view messages within the EHR, the messages can be retrieved via the PatientMessageListSince/MessageRetrieve API. If not, the incoming message can be viewed in the Updox inbox and then imported into the EHR. Updox will provide logging information, including which patients logged in, so the EHR can incorporate in their Meaningful Use Dashboard. This approach assumes the Updox UI is used to configure the patient portal.
Direct Email Account Management
There are two access points to manage Direct email accounts, one accessible by the EHR and one by the EHR users.
For the EHR staff, a web-based interface is provided to set up a practice and establish Direct email addresses. On this screen, the EHR?s implementation staff establishes Updox accounts. Alternatively the the UserSave API can be used to automatically set these up.
Once set up, users of the EHR can modify their Direct accounts. The EHR has the option of building account management screens and then calling the the UserSave API. Or as an alternative, if the EHR does not have screens for managing the accounts, the SSO process can be used to access the Updox account management screens.
Updox Overview Diagram
Authentication
API Authentication is implemented using the fields
Common Request Format
All API calls share a minimum, common, request message. Request messages are always a JSON object, containing, at a minimum, the following element(s):
| Field | Description | Notes |
|---|---|---|
| applicationId | GUID/STRING | (required) |
| applicationPassword | GUID/STRING | (required) |
| accountId | STRING | (required, unique) Uniquely identifies a group of users (typically represents a practice) |
| userId | STRING | (required, unique within account) Uniquely identifies a user within the specified account |
Recipient Identifiers
A recipient identifer is a string in the format of [type]:[id]. Current types:
contact:[unique Updox id] member[unique Updox id] direct:[direct address] patient:[chart number] fax:[fax number]
