Documentation
Getting Started With the MDCH Incident System
Last Updated: 08/09/2010
Overview
This document is intended to provide an introduction to the MDCH Incident System.
It will cover the use of this site, as well as a brief introduction to the web
services.
- The Implementation Guide section provides technical submission information.
- The Requirements section provides information on the incident reporting requirements.
- The XML Schema section provides links to the XML schema documents used with this service.
- The Downloads section provides any useful downloads that may be available.
Submissions
The Submit tab on this site is where you will submit your XML incident submission files, and
receive a response to those submissions. To begin submitting data, you will first want to understand
the reporting requirements, and the XML schema for submissions. Then, you will build an XML
submission file and submit the file on this site.
Queries
The Query tab on this site is where you will be able to query the system about past submissions.
You will have the option of submitting an XML query file and receiving the results in one of
several formats, or you may enter the query parameters in the format provided and submit your
query that way.
Summaries
The Summary tab of this site provides some basic builtin reports that you may find useful.
If the reports provided do not meet your needs, you can use the Query functionality to get
data and build your own reports.
Histories
The History tab provides summary information and download links for all of your past incident
submissions and queries.
Administration
The Administration tab provides administrator functionality. PIHP administrators can create users,
modify users, activate and deactivate users, and manage CMH information for their PIHP. DCH administrators
can also create PIHP administrators, manage PIHP information, and upload QI data.
Contact
The Contact tab allows you to contact the maintainers of this site. You can request access to the site,
report bugs or unexpected behavior, and even request features that you feel are necessary but currently
do not exist.
Web Services
All functionality offered by this site is also available for programmatic access via WCF Web Services.
AdministrationService
Description: Methods that offer administrative functionality.
Service Reference: https://mipihpwarehouse.org/Services/AdministrationService.svcAppUtilService
Description: Methods that offer functionality commonly needed when building an application.
Service Reference: https://mipihpwarehouse.org/Services/AppUtilService.svcAuthenticationService
Description: Methods for authenticating a user. This is the only service that does not require credentials to be passed with requests.
Service Reference: https://mipihpwarehouse.org/Services/AuthenticationService.svcQueryService
Description: Methods for querying previous submission data, as well as obtaining histories of past queries.
Service Reference: https://mipihpwarehouse.org/Services/QueryService.svcSubmissionService
Description: Methods for submitting incident data, as well as obtaining histories of past submissions.
Service Reference: https://mipihpwarehouse.org/Services/SubmissionService.svc
These services can be added to a Visual Studio project by right clicking on the project name and selecting 'Add Service Reference'.
Some things to remember if you are developing against the web services:
-
Always make sure connections get closed when you are done with them, or you can get some strange timeouts and other behavior. This can be done in the following manner:
class Test { static void Main() { AppUtilServiceClient client = new AppUtilServiceClient(); // Use the 'client', enclose in try block. try { var pihps = client.GetPIHPs(); } catch { client.Abort(); } finally { // Always close the client. client.Close(); } } }
-
The service configurations, found in the web.config or app.config of your application, will set the default maxReceivedMessageSize value to 65536. Some of the response sizes, especially the history methods, can exceed this size, sometime by a fair amount. If the response size exceeds your value, an exception will be thrown. Adjust this value as you see fit, the maximum allowed size is 2147483647.
-
You will probably want to download the data types dll from the Downloads section. This dll will allow you to reuse service data types between services, which can be very helpful. Make sure you download this dll first, and add it as a reference to your project. Then, when adding the service references, make sure that the 'Reuse Data Types' box is checked.
Incident Data Reporting
Technical Implementation Guide
Data Exchange
Workgroup – CIO Forum
Last Updated: September 21, 2022
Document Purpose:
This document clarifies the intent and use of the MDCH/PIHP Incident Reporting data file specifications. The attached group of XML Schema files defines the syntax for the submission of critical incidents, the error response, and the querying of accepted incidents. The submission process allows for the alteration or deletion of previously submitted incidents.
XML Schema Files:
- critical_incident_submission.xsd – Incident submission.
- critical_incident.xsd – Response to an incident submission (including errors).
- critical_incident.xsd – Query of incidents accepted by the receiver.
- critical_incident_query_response.xsd – Response to a query of accepted incidents.
MDCH shall publish the most recent versions of these schemas at a fixed URL corresponding to the schema namespace. Client applications shall have capacity to programmatically query the current schemas.
Codesets:
The list of valid code set values, including incident types, sub-types, and sub-type qualifiers shall be maintained by MDCH. Client applications shall have capacity to programmatically query these code sets.
Complete File Rejection:
An incident submission file or an incident query file will be rejected if it fails to validate against the matching XML schema. This ensures minimal structural conformance, allowing a processing engine to read the file. This validation step ensures that the basic structure matches what is expected, that required fields are present, and that data values are in an expected format (a date field is actually a date). This type of rejection should occur infrequently.
Incident Submission:
The actions (specified in the <Action> element) available for an incident record are:
- Add (A) – Add a new incident. A unique incident identifier (unique to and defined by CMHSP) is applied to the incident.
- Replacement (R) – Change a successfully submitted incident. The unique identifier must match an existing, accepted incident for that CMHSP.
- Void (V) - Delete an existing incident. The unique identifier must match an existing, accepted incident for that CMHSP.
Individual Incident Record Errors:
After a file has passed schema validation, each incident record is processed. This step examines each data value, ensuring that it is a valid choice. It also may look at the situational validity of values in relation to other values. Some situational validation may be based on the date of the incident. Validation may also be done based on other, previously accepted incidents.
All submitted records will receive a response which will include the unique incident identifier and a true/false flag indicating whether or not the record was accepted. This response detail may contain one or more response codes and descriptions. The two types of error responses are Rejected (RE) or a warning response (IO). MDCH may define other error codes and reasons.
Response Category | Response Code | Description |
RE | 100 | Adding an incident which references a unique identifier already in use by an accepted incident. |
RE | 101 | Incident replacement / void – no match to unique identifier |
RE | 200 | Incident date is in the future |
RE | 201 | Incident date is too far in the past |
RE | 202 | Incident Date is on or after 10/01/2022, this system will not accept new incidents. Incidents on or after 10/01/2022 need to be reported to new data systems. |
IO | 400 | A QI match could not be made for the given PIHP, CMHSP, CONID, and fiscal year of the incident date |
RE | 501 | CMHSP ID is invalid |
RE | 600 | Incident type is invalid |
RE | 601 | Subtype is invalid for the type |
RE | 602 | Subtype qualifier is invalid for the subtype |
RE | 700 | Incident occurred after a previously reported death |
Query of incidents accepted by the receiver:
The selection criteria are specified in the <Query> element. Multiple Query elements may be defined. Incidents may be queried by:
- PIHP
- CMHSP
- CONID
- Incident date range
- Submission date range
- Incident type, subtype, and subtype qualifier
- Unique incident ID
- Submitted batch ID
The result document should conform to the critical incident query result schema. Each result set should be the set of incidents matched by the <Query> parameters.
Change management and version control:
It is likely that after initial implementation, changes will need to be made to the schema documents. A combination of schema namespace changes and schema version attribute changes will allow for flexible change management.
MDCH/PIHP Event Reporting
Data Exchange Workgroup – CIO Forum
Version 1.1
Last Updated: May 13, 2011
Description of MDCH Event Reporting System:
The MDCH Event Reporting System is a file-based system to submit consumer-specific information about five specified events on a timely and regular basis from CMHSP’s/PIHP’s to MDCH. Information on Reportable Events is the first type of data sent on a new Event-Driven reporting system being developed jointly between MDCH and PIHP’s through the CIO Forum.
The five specific reportable events are:
- Suicide
- Non-suicide Death
- Emergency Medical Treatment due to Injury or Medication Error
- Hospitalization due to Injury or Medication Error
- Arrest of Consumer
Each type of Reportable Event has a “reportable population.” While some of these events are reported for all active consumers, others are only reported for certain identified groups of consumers. For instance, many types of events are only reported for populations considered especially vulnerable.
Purpose of MDCH Event Reporting System:
The system being developed will allow MDCH to better monitor the types of events which occur in particular populations. Since individual consumer identification will be included with each event, MDCH can look for potential trends by comparing reportable events to data already existing in the QI/Encounter files.
The MDCH Event Reporting System will serve as a replacement for the current Sentinel Events reporting and for the Death Report, which will be discontinued.
The MDCH Event Reporting System is not designed to provide normative judgments about the relative quality of care of different CMHSP’s/PIHP’s, and should not be used for that purpose. This is based on the following:
- Specific Events have not been selected for reporting on the basis of their ability to serve as performance indicators. Instead, they were selected to help MDCH gain a consumer-specific view of population events, in part to meet CMS reporting requirements. It is entirely possible that higher prevalence of certain events, which on the surface may be indicative of a lower quality of care, could actually be indicative of closer monitoring and more accurate reporting of events.
- Events are reported to MDCH without evaluation or judgment of cause or fault. For instance, suicides and deaths are reported for all “open” consumers regardless of whether or not the CMHSP/PIHP had any ability to prevent the event from occurring (e.g., a suicide while in a State Facility would still be reported).
- Some of the events are overly inclusive for comparison purposes. For instance, there is no attempt to gauge the seriousness of the injury which leads to emergency medical care prior to reporting the incident to MDCH.
Finally, the MDCH Reportable Events system is not intended to serve as a notification system for critical incidents of which MDCH must be immediately aware. For instance, critical incidents which may be newsworthy or represent a community crisis situation should be relayed to MDCH using other established mechanisms.
Event Submission Requirements:
- Common Fields to be reported for all 5 types of Reportable Events:
- Consumer ID
- Event Date
- Event Type (value is specific to each Event)
- The “Events File” shall be submitted to MDCH on a monthly basis, at approximately the same time the QI and Encounter files are submitted. Event files will include CMHSP and PIHP ID.
- An “Event ID” will not be needed to link different Reportable Events together. The purpose of such an ID would have been to show MDCH that a single precipitating event was the cause of multiple Events (e.g., an injury led later to a death, a single event caused the death of multiple family member consumers, etc.). There is insufficient justification to add this complexity.
- The submission format will have a method for revising and/or deleting previous submissions.
- CMHSP’s will submit this data through PIHP’s.
Definitions and Terms used in this Document
CMHSP
Community Mental Health Service Provider.
PIHP
Prepaid Inpatient Health Plan.
CMHSP/PIHP
The CMHSP or PIHP that is gathering data for a particular submission, in recognition of the fact that particular duties may be handled either party (e.g., depending on payment source, either the CMHSP or PIHP may authorize the consumer to begin treatment).
Actively Receiving Services
For the sake of this reporting, a consumer is considered to be actively receiving services when any of the following occur:
- A face-to-face intake has occurred and the individual was deemed eligible for ongoing service, or
- The CMHSP/PIHP has authorized the individual for ongoing service, either through a face to face assessment or a telephone screening, or
- The individual has received a non-crisis, non-screening encounter.
The period during which the consumer is considered to be actively receiving services shall take place between the following begin date and end date, inclusively:
- Beginning Date: Actively receiving services begins when the decision is made to start providing ongoing non-emergent services. Specifically, the beginning date shall be the first date that any of the 3 conditions referenced above occurs.
- End Date: when the consumer is formally discharged from services. The date the discharge takes effect shall be the end date. This should also be the date that is supplied to the consumer when the consumer is notified that services are terminated.
Recipient of Specific Service
Some of the population definitions used for specific Events require the consumer to not only be active, but to be currently receiving a particular type of service. In these cases, the consumer is considered to be receiving that type of service between the following start and end dates (inclusive of the start and end dates):
Start: The date the consumer has been determined to be eligible and has received at least one of these services.
End: The date the consumer is formally terminated from this type of service. Such formal termination happens via transfer to another unit, discharge from the unit that provides the service, discharge from the CMHSP, or removal of the service from the consumer’s individual plan of service. Any one of these events signifies the end of the service.
Reportable Events Submission Details
- Suicide
Definition: For the purpose of the Reportable Events System, a Consumer’s death shall be reported as a suicide when either one of the following two conditions exists:
- The CMHSP serving the consumer determines, through its death review process, that the consumer’s death was a suicide, or
- The official death report (i.e., coroner’s report) indicates that the consumer’s death was a suicide.
Population on which Suicide must be reported: Any consumer actively receiving services, and all consumers who have received an emergent service within the last 30 calendar days.
Time Frame for Reporting:
- Once it has been determined whether or not a death was suicide, the suicide must be reported within 30 days after the end of the month in which the cause of death was determined.
- If 90 calendar days has elapsed without a determination of cause of death, the CMHSP must submit a “best judgment” determination of whether the death was a suicide. In this event the time frame described in “a” above shall be followed, with the submission due within 30 days after the end of the month in which this “best judgment” determination occurred.
- In case of error, or changes in suicide determination, the CMHSP shall resubmit a consumer’s suicide status according to the time frame described in “a” above.
Timing Examples:
- It is determined on March 10th that a death was a suicide. This suicide death must be reported on or before April 30st.
- A death occurs on January 10th. Ninety days later (April 10th) the cause of death is still not determined, although the CMHSP’s best judgment is that the death was due to suicide. This death must be reported as a suicide on or before May 30th .
Special Fields: Event Type is 01 – Suicide
Other Comments: None.
- Non-Suicide Death
Definition: A non-suicide death is any death, for consumers in the reportable population, that was not otherwise reported as a suicide.
Population on which Death must be reported: Consumers who, at the time of their deaths were actively receiving services and met any one of the following two conditions:
1) Living in a 24-hour Specialized Residential setting (per the Administrative Rule R330.1801-09) or in a Child-Caring Institution, or
2) Receiving Community Living Supports, Supports Coordination, Targeted Case Management, ACT, Home-Based, Wraparound, Habilitation Supports Waiver Services, SED Waiver Services or Child Waiver Services.
Time Frame for Reporting: Due within 60 days after the end of the month in which the death occurred, unless reporting is delayed while the CMHSP attempts to determine whether the death was due to suicide. In this case the submission is due within 30 days of the end of the month in which CMHSP determined the death was not due to suicide.
Special Fields:
Event Type: “02 – Non-Suicide Death”
Type of Death:
01 – Natural Causes
02 – Accidental
03 – Homicide
Natural Cause Reason:
For deaths due to natural cause indicate the specific natural cause:
01 – Heart disease
02 – Pneumonia/influenza
03 – Aspiration or Aspiration pneumonia
04 – Lung disease.
05 – Vascular disease
06 – Cancer
07 – Diabetes mellitus
08 – Endocrine disorders
09 – Neurological disorders
10 – Acute bowel disease
11 – Liver disease/cirrhosis
12 – Kidney disease
13 – Infection, including AIDS
14 – Inanition
15 – Complication of treatment
16 – Unknown
Definitions for these fields are available through the Death Report in the MDCH Annual Death Report “Codebook”
Other Comments:
The purpose of this reporting is generally to understand the co-morbidity of consumers served within the public mental health system.
- Emergency medical treatment due to Injury or Medication Error
Definitions: Situations where an injury to a consumer or a medication error results in face-to-face emergency treatment being provided by medical staff. Any treatment facility, including personal physicians, medi-centers, urgent care clinics/centers and emergency rooms should be reported, provided the treatment was sought due to an injury or medication error.
“Medication error” is defined as a situation where a mistake is made when a consumer takes prescribed medication (i.e., incorrect dosage taken, prescription medication taken that is not prescribed, medication taken at wrong time, medication used improperly), or a situation where non-prescription medication is taken improperly.
“Injury” is defined as bodily damage that occurs to an individual due to a specific event such as an accident, assault, or misuse of the body. Examples of injuries include bruises (except those due to illness), contusions, muscle sprains, and broken bones. If emergency treatment is sought due to a possible or suspected injury, the event shall be considered a reportable injury unless medical staff indicate that no injury occurred (i.e., not diagnosed as an injury and no treatment provided for an injury).
“Physical Managment” is a technique used as an emergency intervention to restrict the movement of an individual by continued direct physical contact in spite of the individual’s resistance in order to prevent him or her from physically harming him/herself or others. Additional information regarding the definition of physical management, and examples of physical management, are present in the MDCH Technical Requirement (Technical Requirement for Behavior Treatment Plan Review Committees - contract attachment P1.4.1). The Technical Requirement shall be used as the definitive definition of physical management rather than this document.
“Injury during physical management” means any injury to the consumer that occurred while physical management techniques were being used with the injured consumer by staff or others (e.g., police, parents, hospital staff). “Injury during physical management” can only occur during the time period that physical management is being used (e.g., during the time the consumer is being held). The fact that an injury occurred during physical management does not imply that the physical management caused the injury. The physical intervention may have caused the injury, or it may in fact have reduced the severity and/or number of injuries.
Example of an injury that should be reported as “during physical management”
A consumer looks like he/she will become aggressive, and staff initiates physical management. The consumer’s arm is broken while he/she is held on the floor.
Example of an injury that should be reported as “not during physical management.”
A consumer punches and breaks a window, injuring her hand. Staff then restrain the consumer to avoid further harm to the consumer and damage to the facility. The consumer’s hand was cut by the glass when punching the window and she is taken to urgent care for treatment.
Population on which EMT must be reported: Consumers who, at the time of the event were actively receiving services and met at least one of the following conditions:
1) Living in a 24-hour Specialized Residential setting (per the Administrative Rule R330.1801-09), or in a Child-Care Institution, or
2) Receiving either Habilitation Supports Waiver services, SED Waiver Services or Child Waiver services.
Time Frame for Reporting : Due within 60 days after the end of the month in which the emergency medical treatment began.
Special Fields :
Event-type = “03 – EMT due to Injury/Med Error”
EMT Cause:
01 = Injury
02 = Medication Error
Injury Sub-type Qualifier (to be present only when EMT Cause = Injury):
01 = Injury was not during physical management
02 = Injury was during physical management
03 = Unknown whether injury was during physical management. Physical
Management was used with the consumer near the time of the injury, but it
is unknown whether the injury actually occurred during the physical management.
Other Comments: While the reportable population is currently specialized residential, it would probably be more appropriate in future reporting to focus on the provision of Community Living Supports rather than the facility setting. This would allow the appropriate reporting to continue for a vulnerable population regardless of the methods/facilities used to serve that population.
- Hospitalization due to Injury or Medication Error.
Definitions: Admission to a general medical facility due to Injury or Medication Error. Hospitalizations due to the natural course of an illness or underlying condition do not fall within this definition.
“Medication error” is defined as a situation where a mistake is made when a consumer takes prescribed medication (i.e., incorrect dosage taken, prescription medication taken that is not prescribed, medication taken at wrong time, medication used improperly), or a situation where non-prescription medication is taken improperly.
“Injury” is defined as bodily damage that occurs to an individual due to a specific event such as an accident, assault, or misuse of the body. Examples of injuries include bruises (except those due to illness), contusions, muscle sprains, and broken bones. If emergency treatment is sought due to a possible or suspected injury, the event shall be considered a reportable injury unless medical staff indicate that no injury occurred (i.e., not diagnosed as an injury and no treatment provided for an injury).
“Physical Managment” is a technique used as an emergency intervention to restrict the movement of an individual by continued direct physical contact in spite of the individual’s resistance in order to prevent him or her from physically harming him/herself or others. Additional information regarding the definition of physical management, and examples of physical management, are present in the MDCH Technical Requirement (Technical Requirement for Behavior Treatment Plan Reivew Committees - contract attachment P1.4.1).. The Technical Requirement shall be used as the definitive definition of physical management rather than this document.
“Injury during physical management” means any injury to the consumer that occurred while physical management techniques were being used with the injured consumer by staff or others (e.g., police, parents, hospital staff). “Injury during physical management” can only occur during the time period that physical management is being used (e.g., during the time the consumer is being held). The fact that an injury occurred during physical management does not imply that the physical management caused the injury. The physical intervention may have caused the injury, or it may in fact have reduced the severity and/or number of injuries.
Population on which Hospitalization must be reported: Consumers who, at the time of the event were actively receiving services and met at least one of the following conditions:
1) Living in a 24-hour Specialized Residential setting (per the Administrative Rule R330.1801-09), or in a Child-Care Institution, or
2) Receiving either Habilitation Supports Waiver services, SED Waiver Services or Child Waiver services.
Time Frame for Reporting : Due within 60 days after the end of the month in which the hospitalization began.
Special Fields :
Event-type : “04 – Hospitalization due to Injury/Med Error”
Hospitalization Cause:
01 = Injury
02 = Medication Error
Injury Sub-type Qualifier (to be present only when Hospitalization Cause = Injury):
01 = Injury was not during physical management
02 = Injury was during physical management
03 = Unknown whether injury was during physical management. Physical
Management was used with the consumer near the time of the injury, but it
is unknown whether the injury actually occurred during the physical management.
Other Comments : While the reportable population is specialized residential, it would probably be more appropriate in future reporting to focus on the Community Living Supports being service provided instead of the facility setting. This would allow the appropriate reporting to continue for a vulnerable population regardless of the methods used to serve that population.
- Arrest
Definition: Arrest is defined as situations where a consumer is held or taken by a law enforcement officer based on the belief that a crime may have been committed. Situations where a consumer is transported for the purpose of receiving emergency mental health services, or situations where a consumer is held in protective custody, are not considered to be an arrest.
Population on which Arrest must be reported: Consumers who, at the time of the event, were actively receiving services and met at least one of the following conditions:
1) Living in a 24-hour Specialized Residential setting (per the Administrative Rule R330.1801-09), or in a Child-Care Institution, or
2) Receiving either Habilitation Supports Waiver services, SED Waiver Services, or Child Waiver services.
Time Frame for Reporting: Due within 60 days after the end of the month in which the arrest took place.
Special Fields:
Event-type : “05 – Arrest”
Other Comments: None
Quick Reference Chart
Report the incident if of the indicated services have been provided, or if the consumer resides in any of the living situations. Only one checked situation is necessary for the incident to require reporting.
Service | Suicide | Death | EMT | Hospital | Arrest |
CLS | ● | ● | |||
Supports Coord | ● | ● | |||
Case Management | ● | ● | |||
ACT | ● | ● | |||
Homebased | ● | ● | |||
Wraparound | ● | ● | |||
Hab Waiver | ● | ● | ● | ● | ● |
SED Waiver | ● | ● | ● | ● | ● |
Child Waiver | ● | ● | ● | ● | ● |
Any other Service | ● | ||||
Living Situation | |||||
Specialized Resid | ● | ● | ● | ● | ● |
CCI | ● | ● | ● | ● | ● |
Frequently Asked Questions:
FAQ related to definition of “Actively Receiving Services”:
Q: What start date should be used when an intake assessment takes more than one
session?
A: Use the date the decision whether to provide ongoing services was made.
Q: What should be done if the consumer is provided non-emergent services prior to
a formal assessment?
A: If non-emergent services are provided without an assessment, the date of the
first service should be used as the start date. This situation is uncommon.
Q: What dates should be used if the consumer no-shows for the first appointment
after the assessment?
A: This does not change the start date.
Q: What should be done if the consumer never shows up for any appointments after
the assessment?
A: The consumer is still considered active for a time period. The start date would
remain unchanged (date of decision). These no-shows would eventually lead to discharge
of the consumer. The date the discharge became effective would be the end date.
Q: Our agency doesn’t open consumers who never make an appointment. Do we need to
consider them active?
A: Yes. These types of differences in internal procedures should not affect the
definitions used.
Q: What about a consumer who is medically hospitalized and then has an Event?
A: Unless the consumer is formally discharged, effective prior to the Event, the
consumer would be considered “active” while in the hospital.
Q: Our organization terminated a consumer 6 months ago, and told the consumer of
that fact, but didn’t complete the “paperwork” until now. What date is the consumer
no longer “actively receiving services?”
A: Now. The end date does not happen until the consumer is formally discharged.
Q: A consumer is open, but then admitted by the CMHSP/PIHP to a StatePsychiatric
Hospital for which the CMHSP/PIHP pays. Is he/she still considered to be “actively
receiving services” while in the hospital.
A: Yes.
Q: A consumer is open, but then goes on a week long home visit. An event occurs
during this visit. Is he/she still considered by be “actively receiving services?”
A: Yes.
Q: An inactive consumer receives crisis services, is psychiatrically hospitalized,
and then discharged. He/she is scheduled for an appointment with the CMHSP/PIHP
but then no-shows. Is he/she considered to be “actively receiving services?”
A: This depends on whether a decision was made for the consumer to receive ongoing
treatment. If such a decision had been made (e.g., during discharge planning), then
the consumer is “actively receiving services.”
Q: A consumer who was not actively receiving service receives crisis services from
the CMHSP/PIHP and then is psychiatrically hospitalized. A non-suicide event occurs
in the hospital. Is the consumer “actively receiving services?”
A: No. In this case, even if a decision was made to begin ongoing treatment, the
CMHSP/PIHP was not in a position to provide those services. Note: this is a very
precise situation, and this answer should not be generalized to other situation
where the CMHSP/PIHP believes itself unable to provide ongoing service.
FAQ related to Suicide Deaths:
Q: What if the coroner rules the death as a suicide and the CMHSP disagrees?
A: Report the death as a suicide.
Q: What if the coroner rules the death a non-suicide, and the CMHSP disagrees?
A: Report the death as a suicide.
Q: What if a CMHSP sends a “best guess” determination of suicide, and the official
death report disagrees?
A: It depends. If the CMHSP revises its determination to non-suicide, send the updated
suicide information. If the CMHSP officially determines that cause-of-death is suicide,
then do not resend status.
Q: If an inactive consumer gets a phone screening, never shows up in person, and
commits suicide the next day, should the death be reported?
A: No. In this case there was no reportable encounter.
Q: Should a possible suicide be reported if no death report exists.
A: The CMHSP should determine whether it believes the death to be a suicide, and
report accordingly.
FAQ: related to Emergency Medical Treatment due to Injury or Med Error
Q: Does calling a physician constitute “treatment?”
A: No. The treatment must be face-to-face.
Q: Does planned/scheduled treatment need to be reported?
A: Yes, if the treatment was precipitated by an injury or medication error.
Q: If any injury results in multiple treatments (e.g., putting on a cast and later
removing it), does each have to be reported?
A: No. Only the first treatment should be reported.
Q: A consumer was provided emergency treatment due to signs of confusion. No precipitating
incident was noticed. The examination was unable to determine if an injury was involved.
Does the visit still need to be reported?
A: No, because there was no reason to believe that injury was involved.
Q: A consumer develops a serious fever and is taken to urgent care. The flu is diagnosed.
Does this need to be reported?
A: No. The treatment was due to an illness, and was not caused by an injury or medication
error.
Q: A consumer accidentally takes the wrong medications. As a precaution, even though
there are no symptoms, staff take him/her to the doctor. Does this need to be reported?
A: Yes. The treatment was for a medication error (taking unprescribed prescription
medication), and led to emergency medical treatment.
Q: A consumer who monitors and takes his/her own medications without staff involvement
makes an error in taking medication. Is this still considered a med error, even
though staff made no mistake?
A: Yes. However, it is only reportable if the med error leads to emergency medical
treatment or hospitalization.
Q: A waiver consumer has selected his parents to help administer medications. Is
the CMH responsible for creating a system to track all mistakes?
A: The CMH is not required to create such a system for the purpose of this reporting.
Q: A consumer has an allergic reaction to a prescribed medication, and is taken
to the ER to be assessed. Does this need to be reported?
A: No. Assuming the medication was taken as prescribed, this does not qualify as
a medication error.
Q: A consumer appears to have a pulled muscle, and is treated by her physician.
Staff didn’t see how it happened, so it wasn’t necessarily an injury per se. Does
this need to be reported?
A: Yes. Staff do not have to witness the event that caused the injury for the situation
to be considered an injury. In this event, injury is the most likely cause of the
pulled muscle.
Q: A consumer has an illness which leads to an injury, which leads to emergency
medical treatment (e.g., a seizure leads to a fall which leads to an injury). Does
this still need to be reported, even though the CMHSP/PIHP had no control over the
illness?
A: Yes. Events are reported without regard to whether the CMHSP/PIHP is “at fault.”
Q: After an injury a consumer is not taken to emergency medical treatment, but a
physician visit is then scheduled. Is that reportable?
A: This injury is reportable if either of the following two conditions are met:
- The primary purpose of the visit was to examine the injury, or
- Emergency treatment would have been scheduled had the consumer not been visiting the doctor anyway.
Q: A consumer has an injury. When staff attempt to transport him/her for medical
treatment he/she refuses. Should this be reported?
A: Yes. If a consumer “should have” had treatment the event is reportable.
Q: A consumer says he swallowed a battery. Staff take him to the ER, where it was
determined that nothing inappropriate was swallowed. Because there was an ER trip,
does this need to be reported?
A: No. Even though there was a suspected injury, results of the examination revealed
that no actual injury had taken place. However, if a battery had been swallowed the event
would have been reportable.
Q: A consumer drinks mouth wash in a suicide attempt and is taken for emergency medical
treatment to see whether any treatment is needed. This doesn’t seem like a normal “injury,”
so should it be reported?
A: This is a difficult call. Swallowing inappropriate amounts of mouthwash would be a
“misuse of the body” and therefore can meet the definition of injury. However,trivial amounts
would be unlikely to do harm. The decision whether or not to report is based on whether or not
medical staff indicate the presence of an injury (via diagnosis or treatment).
Q: A consumer drinks mouth wash as a suicide gesture and is taken for psychiatric evaluation.
The psych unit always requires a medical evaluation to “clear” a consumer. The Medical
evaluation finds no problem resulting from the mouth wash. Should this be reported, since
emergency medical treatment (in the form of a medical evaluation) was provided?
A: No. The consumer wasn’t taken for emergency medical treatment, because staff didn’t
believe there was a physical inury. Furthermore, the medical clearance said there had been no
injury. Note: the answer would be different if the medical evaluation found throat or stomach
problems due to the mouthwash (e.g., pumped the stomach). In this second case an injury would
have been confirmed, even though staff had not originally suspected an injury.
Q: A staff person uses physical management, and it is suspected that the consumer’s finger may
be sprained during the physical management. She is taken to urgent care where it is discovered
that nothing is wrong. Since there was no injury does this need to be reported?
A: No. Although an injury was suspected, it was confirmed by neither diagnosis or treatment.
Q: A consumer is escalating and staff decides to use physical management to protect the consumer.
During the physical management the consumer gets a scrape that is treated at the home by staff.
Does this need to be reported because physical management was used?
A: No. Only injuries that result in emergency medical treatment or hospitalization get reported.
Q: A consumer punches out a window and hurts his hand. Physical management is then used to help
calm the situation. Does the physical management have to be reported?
A: No. If it is known that the injury did not occur during the use of physical management than
the physical management sub-type qualifier should be marked as “not during physical management.”
Q: A consumer becomes agitated and physical management is used to protect her safety. During the
physical management the consumer swings her arm and bruises it. Those who know the consumer
believe her injuries would have been worse had staff not intervened. Does the presence of
physical management still have to be reported?
A: Yes, because physical management was being used while the injury was received. Reporting
“yes” on physical management does not imply fault in any way, nor does it imply that the physical
management “caused” the injury.
FAQ related to Hospitalization due to Injury or Medication Error:
Q: If a consumer is admitted for scheduled surgery does this get reported?
A: If the surgery is precipitated by an injury or medication error, it should be
reported. Otherwise, it should not be reported.
Note: The FAQ’s in the emergency medical treatment section apply equally well for hospitalization.
FAQ related to Arrest of Consumer:
Q: If a consumer is removed by a policy officer and told he/she is under arrest,
but subsequently release without being booked into jail, is the situation considered
an arrest.
A: Yes. An arrest can occur without a subsequent booking.
Q: If a consumer is arrested, but the arrest occurs away from a CMH while no CMH
services are being provided, should the arrest still be reported.
A: Yes. These factors do not affect the need to report the arrest.
Q: If a consumer says he/she has been arrested, but the CMH has not verified it,
should the arrest be reported.
A: Yes, unless the CMH has serious reason to believe the arrest did not happen.
Q: PIHP’s and CMHSP’s don’t necessarily know when certain consumers are arrested.
What steps, if any, does the CMHSP, PIHP or provider have to take to discover arrests?
A: The reportable population for arrests is restricted to consumers receiving high
levels of service. Given this, it is the expectation that the CMH will know, about
the vast majority of arrests that happen through the treatment process.
Q: Is it necessary for the CMHSP and/or PIHP to check with law enforcement to cross-check
records of arrest?
A: No
Q: Does being picked up for truancy count as an arrest?
A: Only when the truancy leads to an arrest.
Q: Does being picked up for probation violation count as an arrest.
A: Only if the officer arrests the individual.
MDCH Incident System
Code List
Type, Sub-type and Qualifier
Fiscal Year 2011
Last Updated: 05/16/2011
Incident Types
Type Code | Description |
01 | Suicide |
02 | Non-Suicide Death |
03 | Emergency Medical Treatment due to Injury or Medication Error |
04 | Hospitalization due to Injury or Medication Error |
05 | Arrest |
Incident Sub-Types
Type Code | Sub-Type Code | Description |
01 | N/A | [no sub-type codes] |
02 | 01 | Natural Causes |
02 | Accidental | |
03 | Homicide | |
03 | 01 | Injury |
02 | Medication Error | |
04 | 01 | Injury |
02 | Medication Error | |
05 | N/A | [no sub-type codes] |
Incident Sub-Type Qualifiers
Type Code | Sub-Type Code | Sub-Type Qualifier Code | Description |
02 | 01 | 01 | Heart Disease |
02 | 01 | 02 | Pneumonia/Influenza |
02 | 01 | 03 | Aspiration or Aspiration pneumonia |
02 | 01 | 04 | Lung Disease |
02 | 01 | 05 | Vascular Disease |
02 | 01 | 06 | Cancer |
02 | 01 | 07 | Diabetes mellitus |
02 | 01 | 08 | Endocrine disorders |
02 | 01 | 09 | Neurological disorders |
02 | 01 | 10 | Acute bowel disease |
02 | 01 | 11 | Liver disease/cirrhosis |
02 | 01 | 12 | Kidney disease |
02 | 01 | 13 | Infection, including AIDS |
02 | 01 | 14 | Inanition |
02 | 01 | 15 | Complication of treatment |
02 | 01 | 16 | Unknown |
03 | 01 | 01 | Injury was not during physical management |
03 | 01 | 02 | Injury was during physical management |
03 | 01 | 03 | Unknown whether injury was during physical management. Physical Management was used with the consumer near the time of the injury, but it is unknown whether the injury actually occurred during the physical management. |
04 | 01 | 01 | Injury was not during physical management |
04 | 01 | 02 | Injury was during physical management |
04 | 01 | 03 | Unknown whether injury was during physical management. Physical Management was used with the consumer near the time of the injury, but it is unknown whether the injury actually occurred during the physical management. |
XML Schema
Critical Incident Submission
Schema document governing Critical Incident Submissions.Schema Document Sample XML Document
Critical Incident Submission Response
Schema document governing Critical Incident Submission Responses.Schema Document Sample XML Document
Critical Incident Query
Schema document governing Critical Incident Queries.Schema Document Sample XML Document
Critical Incident Query Response
Schema document governing Critical Incident Query Responses.Schema Document Sample XML Document
Warehouse Downloads
Services Data Types DLL
Assembly for working with the warehouse web services. This dll allows you to reuse service data types across services.Download DLL
Download XML Documentation