# Presentation: 430442

## TIU or NOT TIU IT MAY BE A BUSINESS RULE!

- Class #132H

**Notes:**
TIU or Not TIU – It may be a Business Rule.  This is Class 132H a hands on class to introduce you to business rule.

## FACULTY

- Boots Brinkman, RRT, MS
- Clinical Applications Coordinator
- VA Gulf Coast Veterans Health Care System
- Anne Rega
- Clinical Product Support
- Clinical 3 Team

**Notes:**
My name is Boots Brinkman.  I am a clinical applications coordinator from VA Gulf Coast and this is Anne Rega.  She is a Clinical Product Support Specialist with the Clin 3 Team.

## HOUSEKEEPING

-  QUESTIONS??
- Please use 3” X 5” cards to write down all questions.
- Please hold all questions until end of session.
- Those not answered today will be on the VeHU website
- Please mute all cell phones, blackberries, etc.
- If you loose your place during the hands on session, please raise your hand high for a room assistant.

**Notes:**
If you have any questions during the presentation please use the 3X5 cards provided to write them down.  The room assistants will be picking them.  Please hold all questions until the end of the session and those not answered during this session will be posted on the VeHU website.  Please mute all electronic devices.  If you loose your place during the hands on session, please raise your hand high for a room assistant.

## Learning Objectives

- Review the basic Text Integration Utility (TIU) hierarchy.
- Describe the components of Authorization Subscription Utility (ASU).
- Learn how to create business rules.
- Recognize the impact of business rules.

**Notes:**
The learning objectives for this class are to  review the basic Text Integration Utility (TIU) hierarchy.  To describe the components of Authorization Subscription Utility (ASU).  To learn how to create business rules.  And to recognize the impact of business rules.

## TEXT INTEGRATION UTILITY (TIU)

- TIU is a collection of software tools that manage clinical documents in a standardized way.
- In conjunction with ASU,  they allow providers to enter, edit, sign and print different kinds of documents from a single program.

**Notes:**
Text Integrated Utilities or TIU is a collection of software tools that manage clinical documents in a standardized way. In conjunction with Authorization Subscription Utility or ASU providers and others can view, enter, edit, sign and print different kinds of documents.  TIU manages document definitions.  When a provider selects a progress note title (such as a clinic visit or a discharge summary) that title is linked to a Document Definition in the Document Definition hierarchy.  That document definition stores the behavior of the document (for example, the note must be signed before anyone can view it). The document definition hierarchy is composed of titles, at the lowest layer, and then document class and class.

## TIU HIERARCHY

- CLASS

- DOCUMENT CLASS

- TITLES

**Notes:**
A Class is a category that allows for the grouping of one or more classes or document classes.  Clinical documents is at the top of the pyramid.  Under it are classes for other clinical documents such as progress notes and discharges summaries, just to name a couple.  Document class is the second layer and it is a grouping that may contain one or more titles.  Document classes allow for grouping by location , role and service.  The title is the individual document piece that is used for documentation.  

## AUTHORIZATION SUBSCRIPTION UTILITY (ASU)

- ASU originated in response to the “Scope of Practice” model.
- A “Knowledge Base” or table of “Production Rules” that can be developed in compliance with the site’s local by-laws.

**Notes:**
ASU originated in response to the “Scope of Practice” model.  A “Knowledge Base” or table of “Production Rules” that can be developed in compliance with the site’s local by-laws. This package will define the user. ASU can be thought of as a refined security key.  Security keys allow or disallow, while ASU allows you to authorize the actions at the appropriate level.  ASU provides a method for identifying who is Authorized to do something and who will Subscribe to receive notice of an action.  Defining the user is the second part of our venture towards business rules.

## A BUSINESS RULE

- An UNSIGNED (CLASS)CLINICAL DOCUMENT may be SIGNED by a PROVIDER who is an EXPECTED COSIGNER

- The parts:
- STATUS (unsigned)
- DOCUMENT TYPE
- (clinical document)
- ACTION (signed)
- USER CLASS (provider)
- USER ROLE
- (expected cosigner)

**Notes:**
This example of a business rules covers all of the possible fields.  An unsigned clinical document may be signed by a provider who is an expected cosigner.  The status is Unsigned.  The document type is the class of clinical documents.  The action is to sign.  The user class is provider and the user role is expected cosigner.

## VISTA LOG-ON INSTRUCTIONS

- Each work station has their own unique VistA system.
- ACCESS CODE:
- 55VEHU
- VERIFY CODE:
- VEHU55

**Notes:**
There are a couple of things to point out before we get started with our log on.  You will be working in your own world.  Each of you will be creating in your own system so that we don’t impact each other.  Your access code is 10VEHU and your verify code is VEHU10. Remember if you get lost raise your hand high so that a room assistant can assist you.  Go ahead and get logged on.   If everyone is logged on we’ll get started.

## PART 3 - TROUBLESHOOTING

- Four case studies will be presented, one at a time.
- FIRST.....

## CASE 1

- The phone starts ringing off the hook... No one seems to be able to sign their own Progress Note.
- Hmm... The phones started right after you added a rule so clinical service chiefs can sign unsigned notes.

## CASE 1

- Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
Getting started:
Sign onto CPRS as 10VEHU/VEHU10

- Getting started:
- Sign onto CPRS as 10VEHU/VEHU10

- CASE 1

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
Getting started:
Sign onto CPRS as 10VEHU/VEHU10
Try to write and sign a note (esig: VEHU10) – you can use any patient and any title

- Getting started:
- Sign onto CPRS as 10VEHU/VEHU10
- Try to write and sign a note (esig: VEHU10) – you can use any patient and any title

- CASE 1

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
Getting started:
Sign onto CPRS as 10VEHU/VEHU10
Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
Try deleting

- Getting started:
- Sign onto CPRS as 10VEHU/VEHU10
- Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
- Try deleting

- CASE 1

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
Getting started:
Sign onto CPRS as 10VEHU/VEHU10
Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
Try deleting
Go look at the Business Rules
Clinical Documents
Progress Notes

- Getting started:
- Sign onto CPRS as 10VEHU/VEHU10
- Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
- Try deleting
- Go look at the Business Rules
- Clinical Documents
- Progress Notes

- CASE 1

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
Getting started:
Sign onto CPRS as 10VEHU/VEHU10
Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
Try deleting
Go look at the Business Rules
Clinical Documents
Progress Notes
Remember how the hierarchy is used in evaluating rules!

- Getting started:
- Sign onto CPRS as 10VEHU/VEHU10
- Try to write and sign a note (esig: VEHU10) – you can use any patient and any title
- Try deleting
- Go look at the Business Rules
- Clinical Documents
- Progress Notes
- Remember how the hierarchy is used in evaluating rules!

- CASE 1

## CASE 1

- Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
- CAUSE: The rule for signing progress notes by the clinical service chief was written at the progress note level.  The rule for signing documents by the author/dictator is at the Clinical Document level.

## CASE 1

- Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.
- SOLUTION:

## Case: No one can sign their own progress note after a rule was added allowing clinical service chiefs to sign unsigned notes.

SOLUTION:
Enter the following rule at the Progress Note level:
An UNSIGNED (CLASS) PROGRESS NOTE may BE SIGNED by an AUTHOR/DICTATOR.

- SOLUTION:
- Enter the following rule at the Progress Note level:
- An UNSIGNED (CLASS) PROGRESS NOTE may BE SIGNED by an AUTHOR/DICTATOR.

- CASE 1

## CASE 2

- The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.
- Set-up this case on your system.  The note title, **Enter in Error** has been created for you.  Use VEHU,TWENTY in this exercise.
-                              Access Code   20VEHU
-                              Verify Code      VEHU20

## CASE 2

- The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.
- STEPS:

## The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.

STEPS:
Assign Medical Information Section user class to appropriate User. (For this class, Vehu, Twenty)

- STEPS:
- Assign Medical Information Section user class to appropriate User. (For this class, Vehu, Twenty)

- CASE 2

## The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.

STEPS:
Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
Create two business rules:

- STEPS:
- Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
- Create two business rules:

- CASE 2

## The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.

STEPS:
Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
Create two business rules:
An UNTRANSCRIBED (TITLE) ENTER IN ERROR may BE ENTERED by a MEDICAL INFORMATION SECTION

- STEPS:
- Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
- Create two business rules:
- An UNTRANSCRIBED (TITLE) ENTER IN ERROR may BE ENTERED by a MEDICAL INFORMATION SECTION

- CASE 2

## The site wants to have a note title called Enter in Error, but is should only be used by the Medical Information Section.  Also, you don’t want anyone else but MIS and the author to view the note.

STEPS:
Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
Create two business rules:
An UNTRANSCRIBED (TITLE) ENTER IN ERROR may BE ENTERED by a MEDICAL INFORMATION SECTION
A COMPLETED (TITLE) ENTER IN ERROR may BE VIEWED BY A MEDICAL INFORMATION SECTION

- STEPS:
- Assign Medical Information Section user class to appropriate class. (For this class, Vehu, Twenty)
- Create two business rules:
- An UNTRANSCRIBED (TITLE) ENTER IN ERROR may BE ENTERED by a MEDICAL INFORMATION SECTION
- A COMPLETED (TITLE) ENTER IN ERROR may BE VIEWED BY A MEDICAL INFORMATION SECTION

- CASE 2

## CASE 3

- CASE:  Your site has begun a new Respiratory Therapy training program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE.
- Start:  Be sure that they will have all the same abilities as the respiratory therapist user class.
- 	VEHU,THIRTY is a respiratory student.
-                            Access code  30VEHU
-                            Verify code    VEHU30

## CASE 3

- CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

## CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a co-signature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

STEPS:
Create a new user class - Respiratory Therapist Student

- STEPS:
- Create a new user class - Respiratory Therapist Student

- CASE 3

## CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

STEPS:
Create a new user class call Respiratory Therapist Student
Add it as a subclass to Respiratory Therapist

- STEPS:
- Create a new user class call Respiratory Therapist Student
- Add it as a subclass to Respiratory Therapist

- CASE 3

## CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

STEPS:
Create a new user class call Respiratory Therapist Student
Add it as a subclass to Respiratory Therapist
Assign the new user class to the user Vehu, Thirty.

- STEPS:
- Create a new user class call Respiratory Therapist Student
- Add it as a subclass to Respiratory Therapist
- Assign the new user class to the user Vehu, Thirty.

- CASE 3

## CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

STEPS:
Create a new user class call Respiratory Therapist Student
Add it as a subclass to Respiratory Therapist
Assign the new user class to the user Vehu, Thirty.
Using the TIU Parameters menu, Document Parameter Edit, RESP TREATMENT NOTE, assign the new user class to the Required Cosignature field.

- STEPS:
- Create a new user class call Respiratory Therapist Student
- Add it as a subclass to Respiratory Therapist
- Assign the new user class to the user Vehu, Thirty.
- Using the TIU Parameters menu, Document Parameter Edit, RESP TREATMENT NOTE, assign the new user class to the Required Cosignature field.

- CASE 3

## CASE:  Your site began a Respiratory Therapy program.  The only note that the students will require a cosignature on is the title, RESP TREATMENT NOTE. (The note title is in place.)

STEPS:
Create a new user class call Respiratory Therapist Student
Add it as a subclass to Respiratory Therapist
Assign the new user class to the user Vehu, Thirty.
Using the TIU Parameters menu, Document Parameter Edit, RESP TREATMENT NOTE, assign the new user class to the Required Cosignature field.
Don’t forget to populate all fields!

- STEPS:
- Create a new user class call Respiratory Therapist Student
- Add it as a subclass to Respiratory Therapist
- Assign the new user class to the user Vehu, Thirty.
- Using the TIU Parameters menu, Document Parameter Edit, RESP TREATMENT NOTE, assign the new user class to the Required Cosignature field.
- Don’t forget to populate all fields!

- CASE 3

## CASE 4

- CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.
- Start:  Fortyfive, Inpatient has an unsigned LTC discharge summary written by Vehu,Forty.  To see that you can’t delete, sign onto CPRS as 40VEHU/VEHU40 and try to delete the unsigned discharge summary.

## CASE 4

- CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

Steps:  
Check the TIU hierarchy

- Steps:
- Check the TIU hierarchy

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

Steps:  
Check the TIU hierarchy
Check the business rules

- Steps:
- Check the TIU hierarchy
- Check the business rules

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

Steps:  
Check the TIU hierarchy
Check the business rules
Notice on the Discharge Summaries DOCUMENT CLASS there is the following rule:
An UNSIGNED (DOCUMENT CLASS) DISCHARGE SUMMARY may BE DELETED by an AUTHOR/DICTATOR.

- Steps:
- Check the TIU hierarchy
- Check the business rules
- Notice on the Discharge Summaries DOCUMENT CLASS there is the following rule:
- An UNSIGNED (DOCUMENT CLASS) DISCHARGE SUMMARY may BE DELETED by an AUTHOR/DICTATOR.

- CASE 4

## CASE 4

- CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

BUT:

- BUT:

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

BUT:
The LTC Discharge Summary title is in a different document class.

- BUT:
- The LTC Discharge Summary title is in a different document class.

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

BUT:
The LTC Discharge Summary title is in a different document class.

SOLUTION: 

- BUT:
- The LTC Discharge Summary title is in a different document class.
- SOLUTION:

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

BUT:
The LTC Discharge Summary title is in a different document class.

SOLUTION: 
 Move the existing rule “up” to the Discharge Class Level or

- BUT:
- The LTC Discharge Summary title is in a different document class.
- SOLUTION:
-  Move the existing rule “up” to the Discharge Class Level or

- CASE 4

## CASE:  A resident calls and complains he can’t delete an unsigned discharge summary for his long term care patient, but he seems to have no problems with a general discharge summary.

BUT:
The LTC Discharge Summary title is in a different document class.

SOLUTION: 
 Move the existing rule “up” to the Discharge Class Level or
Create the same rule but for the LTC Document Class.

- BUT:
- The LTC Discharge Summary title is in a different document class.
- SOLUTION:
-  Move the existing rule “up” to the Discharge Class Level or
- Create the same rule but for the LTC Document Class.

- CASE 4

## Slide 45