Monitored Subject Methods

POST

  1. If you do not intend to use an object, don’t send the object and the value in the post.
  2. If monitorProducts: null, Dash will use the client designated monitor products. To create a subject without monitorProducts & monitoring, monitorProducts: [].
{
 "externalId": "A unique identifier",
 "type": "individual",
 "firstName": "",
 "lastName": "",
 "middleName": null,
 "dob": "1990-01-01",
 "npi": "",
 "ssn": "",
 "tin": "",
 "specialties": [
   ""
 ],
 "taxonomies": [
   ""
 ],
 "addresses": [
       {
           "addressType": "Personal",
           "name": "ProviderTrust",
           "addressLine1": "406 11th Ave North",
           "addressLine2": "Suite 250",
           "city": "Nashville",If 
           "state": "TN",
           "zip": "37203",
           "county": "Davidson",
           "country": "USA"
       }
 ],
 "endDate": "2021-08-13",
 "lastInteractionDate": "2021-08-13",
 "monitorProducts": null
}

Data Explanation

ObjectDescription
externalIDstring (uuid); An optional tag used to identify the subject across monitoring.
typeString; individual or organization
firstNameString; required for individual
lastNameString; required for individual
nameString (business/organization name); required for organization
npiInteger (10-digits)
dobDate (yyyy-mm-dd); optional
ssnInteger (9-digits, no hyphens); optional
tinInteger (9-digits, no hyphens); optional
specialtiesstring, use as an array; optional
taxonomiesstring, use as an array; optional
addressesstring, can have multiple addresses as an array; optional
endDateDate (yyyy-mm-dd); optional. On this date, the subject will be removed from monitoring. An update with this field as null and daysToAutoTerm as null or absent will remove the endDate
lastInteractionDateDate (yyyy-mm-dd); optional. If unset, will default to the current day. Used in combination with daysToAutoTerm to auto-calculate endDate

API Reference: Create a Monitored Subject

PUT

  1. You can update the monitor subject by providing the monitorSubjectID. To stop monitoring a subject and keep the historical monitoring record you must update the subject by removing a monitor product(s). Deleting the subject will remove them completely from the system.
  2. Unlike monitored-subject creation, Dash will not treat null monitorProducts as the Client default monitor products for an update. Null monitorProducts will be treated as no monitor products/unmonitored

API Reference: Update a Monitored Subject

DELETE

  1. You can delete the monitor subject by providing the monitorSubjectID.
  2. Deleting the subject will completely remove them from the product. Deleting a subject should only be done if the subject was created by mistake. If monitoring no longer needs to be performed for a provider it’s suggested to remove all monitor products from the subject via PUT {/monitor/monitored-subjects/{monitoredSubjectId}}.

API Reference: Delete a Monitored Subject

POST Search

{
    "page":0,
    "size":30,
    "sortBy":null,
    "desc":true,
    "type":null,
    "filter":null,
    "monitoredList": [
        {
            "monitoredProduct": "LICENSES",
            "issuer": ["Alabama"],
            "type": ["REGISTERED NURSE", "dentist"],
            "status": ["NOT_FOUND"]
        },
        {
            "monitoredProduct": "EXCLUSIONS_STATE",
            "source": ["OHIO"],
            "status": ["MATCH"]
        }
    ],
    "networkIds":null,
    "businessUnitId":null,
    "includeTrashed":false,
    "externalId":null
}

Data Explanation

descboolean; optional (default false)
pagenumber; optional (default 0)
sizenumber; optional (default 30; max 1000)
sortBystring (enum); optional; Must be one of "NAME", "NPI", "EXTERNALID", "TYPE", "SPECIALTIES"
typestring (enum); optional; Must be one of "individual" or "organization"
extenralIdString; optional
businessUnitIdsstring array (uuid); optional
networkIdsstring array (uuid); optional
filterString; optional;
monitoredListObject array; optional; see below for schema

Page Fields

  • desc: true if the sortBy is applied in descending order, false if it is applied in ascending order
  • page: Which ordered group of "size" results should be returned. The first page of results is page: 0. You can get all of the returned Monitored-Subjects for a search by making multiple POSTs, incrementing page until (page+1)*size >= total, where page and size are your request-body parameters and total is the value from the response.
  • size: The maximum number of Monitored-Subjects to return in the response, ie the size of a page
  • sortBy: How to sort the results. Default sort order is by Monitored-Subjects ID

Filter Fields

All of these fields are ANDed together (an Monitored-Subjects must match all filters to be returned), with the exception of businessUnitIds and networkIds, which are ORed together (an Alert must match either filter to be returned). If a field is an array, then all of the filter items in that array are ORed together (an Alert must match any filter to be returned

  • type: Filter Monitored-Subjects by their type (individual or organization).
  • externalId: Filter Monitored-Subjects by their unique External IDs.
  • networkIds: Filter Monitored-Subjects by the IDs of Networks that the Monitored-Subject participates in
  • businessUnitIds: Filter Monitored-Subjects by the IDs of Business Units that the Monitored-Subject participates in. A Subject is considered to be participating in a Business Unit if it has a Participation for a Network under that Business Unit. Add null to the array to include Alerts for Subjects that have no Participations
  • filter: Filter Monitored-Subjects by the Monitored-Subjects’ Names, NPIs, and TINs. Partial/substring matches will return. This filter is applied to all 3 fields.
  • monitoredList: Filter Monitored-Subjects by the Monitored-Subject's Type (monitorProduct, source if applicable, issuer and type if applicable, and status). All filter objects in this array must contain the "monitoredProduct" field. The following fields are available:
  • monitoredProduct: Must be one of: NPI, SSDMF, CMS_PRECLUSION_LIST, EXCLUSIONS, OFAC, OPTOUT, or LICENSES
  • source: This field is required for EXCLUSIONS and should not be used otherwise. It is an array of Strings representing Exclusion-Sources to filter on. Each entry must be one of: SAM_EXCLUSIONS, EPLS, OIG_WAIVERS, OIG_HIGH_RISK, OIG_LEIE, MICHIGAN, COLORADO, NEW_HAMPSHIRE, WASHINGTON, ALASKA, MINNESOTA, MONTANA, NEW_JERSEY, ALABAMA, NEVADA, IOWA, PENNSYLVANIA, VERMONT, WYOMING, FLORIDA, OHIO, NORTH_DAKOTA, CONNECTICUT, MARYLAND, ARKANSAS, ILLINOIS, LOUISIANA, MISSOURI, MISSISSIPPI, NEBRASKA, SOUTH_CAROLINA, WEST_VIRGINIA, GEORGIA, IDAHO, NORTH_CAROLINA, INDIANA, TENNESSEE, NEW_YORK, WASHINGTON_DC, CALIFORNIA, MAINE, DELAWARE, KANSAS, MASSACHUSETTS, TEXAS, HAWAII, KENTUCKY
  • issuer: This field is required for LICENSES. It is an array of Strings representing the mappedIssuer field of the License to filter on. Valid choices are available at the /monitor/license-definition/issuer endpoint.
  • type: This field is required for LICENSES. It is an array of Strings representing the mappedType field of the License to filter on. Valid choices are available at the /monitor/license-definition/type endpoint.
  • status: This field is required for all monitoredProduct choices. It is an array of Strings representing resultStatuses to filter on. The following options are available for each Monitor Product:
    NPI: NPI_ACTIVE, NPI_NOT_FOUND, NPI_INACTIVE, NPI_INVALID
    SSDMF: MATCH, NO_MATCH
    CMS_PRECLUSION_LIST: MATCH, NO_MATCH, SUSPECTED_MATCH
    EXCLUSIONS: MATCH, NO_MATCH, SUSPECTED_MATCH
    OFAC: MATCH, NO_MATCH, SUSPECTED_MATCH
    OPTOUT: MATCH, NO_MATCH, SUSPECTED_MATCH
    LICENSES: REVOKED, MORE_INFO_NEEDED, ACTIVE, EXPIRED, FEE_REQUIRED, NOT_FOUND, PROBATION, RESTRICTED, BOARD_PENDING, INACTIVE, SUSPENDED, TEMPORARY, SURRENDERED
    Can be applied to all of the above: INSUFFICIENT_DATA

API Reference: Search all Monitored Subjects