IWeb Administrator Guide

STC Summary on Patient Active/Inactive Status, Ownership, and Service in Relation to IWeb and SMaRT AFIX

Click here to jump to the Frequently Asked Questions section.

The following information explains how STC handles patient active/inactive status (PAIS), ownership, and service as they relate to both the IWeb (as of version 5.17.5) and SMaRT AFIX applications. The information is generally used for immunization assessments and reminder/recall. Much of the information below was taken from the 2015 MIROW guidelines.

Introduction to Patient Active/Inactive Status (PAIS)

Patient Active/Inactive Status (PAIS) is a term used to describe a provider or geographic jurisdiction (i.e., state) level's responsibility for an individual's immunization(s). In other words, PAIS is a designation for the relationship of an individual with a provider or the jurisdiction in which the individual resides. PAIS at the provider level conveys information with respect to the relationship of a patient to a provider.

When an individual has an Active status with a specific provider or jurisdiction, it indicates that the provider or jurisdiction has responsibility for that individual's immunizations. An Inactive status of an individual with a provider or jurisdiction indicates that the provider or jurisdiction does not have responsibility for the individual's immunizations.

Although an IIS can use two common approaches to implementing the concept of a provider having responsibility for immunizing a patient, a 1:1 (one-to-one) approach or a 1:M (one-to-many) approach, IWeb (versions 5.17.5 and higher) only uses the 1:1 approach. This means that only one provider or geographic jurisdiction level can have responsibility for a patient at a time. This also means that a patient can be included in reminder/recall notifications and assessment reports for only one provider at a point in time (e.g., the provider that owns the patient at that time).

As of IWeb version 5.17.5, only one provider can have clear responsibility for a patient. This provider can focus resources for reminder/recalls and assessments for that patient. Routinely, the provider that administered the most recent immunization for that patient is documented as the one provider bearing the responsibility for them. (Note that a patient may not be connected to any provider at all. However, once a provider provides an immunization to the patient, that provider automatically assumes responsibility for them, unless they are blocked from assuming all patient ownership.)

What's New Regarding PAIS as of IWeb Version 5.17.5?

The differences you can see starting in version 5.17.5 include:

Improved workflow for activation on the Vaccination View/Add page
Improved reports, including Coverage Rate, Patient Detail, and several data quality reports
Required verification/confirmation of death when marking a patient as Deceased
Only three statuses are used in the application: Active, Inactive, and Deceased. Other inactive reason codes are received and recognized, but are consolidated in the application and only displayed as Inactive
Consistent report outputs when reports are run by Service, Ownership, Active, or Include Inactives.
User notification when activating or inactivating a patient through the UI
Blocking ownership also blocks the ability to activate patients (e.g., when immunizations are given)

IWeb Terms and How they Relate to MIROW Guidance

The following terms are used in the IWeb application and documentation. Here is how the terms and actions relate to MIROW guidance.

Ownership in IWeb

Ownership in IWeb occurs when an organization or facility performs a qualifying event for a patient by creating a new patient or conducting the most recent vaccination encounter. Ownership in IWeb is a 1:1 relationship. That means that only one organization and/or facility can own a patient at a time. If an organization or facility has automatic ownership blocked (see Search/Add/Edit Organizations and Search/Add/Edit Facilities for the Automatic Ownership Blocked option), they cannot take ownership of a patient even if they perform a qualifying event. An authorized user can remove ownership of a patient on the Manage Population page. Otherwise, ownership is lost only when another provider administers a more recent vaccination.

Reports by Service in IWeb

Service is defined in IWeb as an administered vaccination encounter with a patient (not a historical vaccination). In IWeb , a patient can have service records for many providers. These records are often referred to as reserve records. Reserve records do get updated for a demographic change and recording of historical vaccinations, but those types of encounters are not considered when reports are run by service in the IIS.

If a provider administers a vaccination for a patient, that patient appears in the provider's list if a report is run by service. Note: A provider can have a service record for a patient that they do not own. They can also have a service record for a patient that is inactive with their organization/facility. If a user wants to receive a report output that displays every patient that they have ever vaccinated, they should run the report by service and include inactive patients.

Not Acceptable Provider Type

Provider organization of an acceptable type is shorthand for Acceptable provider organization type for reminder/recalls or assessments. In other words, the provider type should be considered acceptable when conducting reminder/recall or assessment reports for a patient.

MIROW 2015 guidance indicates that Active status can only be set by an acceptable provider type. In IWeb , a Not Acceptable Provider Type is equal to a provider that has automatic ownership blocked. A provider with automatic ownership blocked (a pharmacy, school, or mass immunization provider, for example) cannot take ownership of a patient or assign an Active status for a patient, even if they administer a vaccination or create a new patient. It is the responsibility of the state to ensure that these providers are set up appropriately in the IIS (see Search/Add/Edit Organizations and Search/Add/Edit Facilities for the Automatic Ownership Blocked option).

If, for some reason, one of these organizations has Active patients in the system (for example, if they administered vaccinations before their ownership was set as blocked), an authorized user can give away the ownership (see Manage Population) and/or inactivate the patient directly in the UI.

Acceptable Vaccination Encounter Type

An acceptable vaccination encounter (i.e., an office visit) should impact PAIS. Knowing the type of vaccination encounter, however, can help determine if PAIS should be changed. A mass vaccination event should not be considered an acceptable vaccination encounter and should not affect PAIS. Examples that can be considered mass vaccinations include:

H1N1
Flu-only clinics
Tdap provided in schools
Bundled influenza over a period of days
Walk-in treatment centers with one-time events

Note that the IIS is unlikely to know about the majority of these types of mass vaccination events and cannot make judgements based on it. The appropriate way to prevent a mass immunization event from disrupting PAIS in the IIS is to have the provider set up as a Not Acceptable Provider type (by blocking automatic ownership).

Impact on SMaRT AFIX Assessments

SMaRT AFIX simply accepts the patients that have been identified as Active from IWeb . By default, all patients with an Active patient status in each age cohort is included in an AFIX assessment for the relevant provider.

IWeb 's move to a 1:1 relationship (starting in version 5.17.5) between a patient and a provider means that a patient appears in only the assessment for the facility in which the patient is active.

The Full Patient List within SMaRT AFIX identifies all active patients included in a given cohort. Patient lists include a Last Vaccination Date field, which refers to the last vaccination date for the patient regardless of the facility where it occurred. Patient status cannot be changed in SMaRT AFIX; all patient management must be performed within IWeb.

IWeb Scenarios

Scenario 1: An organization or facility sets an Active status for a patient

A patient status of Active can only be set for an organization or facility if:

The organization or facility does not have the Automatic Ownership Blocked option enabled
The organization or facility directly identifies the individual as a patient in the UI
The organization or facility indirectly identifies the individual as an active patient by administering a new vaccine or creating the person as a new patient in the IIS (for example, by submitting or entering a patient's demographic-only information and/or historical-only immunization information for a patient not already in the IIS)

Demographic changes and historical-only vaccinations to existing patient records do not give ownership or assign patient Active status to the provider.

Scenario 2: A user sets a patient's status to Inactive in the user interface (UI)

If the provider does not want to include a patient for reminder/recall or assessments, a patient should be inactivated directly in the UI. However, patient status at the organization or facility level should only be considered Inactive if any of the following is true:

The patient has transferred to another provider organization
The patient has moved out of the area
Attempts to contact the individual have been documented, but no documented response has been received by the provider
The provider organization or facility has no means to contact the patient (for example, no address or cell phone number is available)

Since IWeb is maintaining PAIS and ownership as separate concepts, when the user manually assigns an Inactive status to a patient that it currently owns, ownership remains with that provider until they either give it away or the patient has received a more recent immunization from another provider organization (that does not have automatic ownership blocked). This helps to prevent patients from "falling through the cracks" until their next vaccination.

Scenario 3: An action by another provider indirectly sets a patient's status to Inactive for the original organization/facility

A patient's status at the organization or facility level is set as Inactive due to the actions of another provider if the following is true:

The patient has received a more recent vaccination from another provider that does not have automatic ownership blocked, and
The provider and vaccination are of an acceptable type

When this happens, the following occurs in IWeb:

Ownership transfers to the new provider
Patient status is set to Active for the new provider
Patient status is set to Inactive for the original provider
The patient is included in reminder/recall and assessments for the new provider. The patient is only included in reports for the original provider if the reports are run by service and inactive patients are included

Scenario 4: A user wants to set a patient's status to Deceased

A patient's status at the provider and geographic jurisdiction levels should be set to Deceased only if a patient's death is confirmed. Examples of confirmation include a family member informing the IIS or provider, or a notification is received from Vital Records. The patient's status at the organization and facility level is set to Deceased throughout the entire application if any organization or facility - not just the owning organization/facility - has assigned this status to the patient. The status can be set to Deceased by:

Manually setting the status in the application UI
An HL7 submission of Y in PID-30 and the date of death in PID-30. (PID1-16 can be set to A, P, I, M, L, U, or left blank; it does not change the patient status of Deceased if PID-30 is set to Y.) This updates the status for all organizations and facilities in the system

Scenario 5: An unacceptable provider type creates new patient

If a provider organization with the Automatic Ownership Blocked option enabled creates a new patient in IWeb, the patient is not owned by or active for that provider. Instead, the patient becomes the responsibility of the geographic jurisdiction in which they reside.

Scenario 6: An organization/facility wants to prevent ownership and active status during a mass immunization event

Mass immunization events are not considered vaccination encounters of an acceptable type. In the IIS, an immunization event always applies ownership and active status if the organization/facility is set up in the IIS as an acceptable type. The IIS cannot differentiate with regard to mass immunization events versus general vaccination encounters. However, the IIS provides an alternative method of entry and/or special provider organizations to capture these separately from standard well visits.

To prevent ownership and active status during a mass immunization event, ensure that the provider is set up with the Automatic Ownership Blocked option enabled (selected). (See Search/Add/Edit Organizations and Search/Add/Edit Facilities for more information.) Alternatively, make sure to select the Do not take ownership option upon manual entry of each vaccination.

When electronically submitting an HL7 message, entering an inactive code counts the vaccination but does not activate the patient for the submitting provider.

Scenarios from the 2015 MIROW Guidelines

The scenarios listed below were taken directly from the 2015 MIROW guidelines and describe how each situation is handled in IWeb. In some cases, adjustments were made to the information to describe IWeb options and actions.

Scenario 1: Patient lives with divorced parents (S301)

Description	Status	Consequences
The patient, a child, lives interchangeably with each of her divorced parents (i.e., three months with one parents and then three months with another parent) The patient switches back and forth every three months between Provider Organization A and Provider Organization B Provider Organization A and Provider Organization B are contributing equally to the patient's immunizations Provider Organization A conducted the latest vaccination event for the patient	Patient status is set to Active relative to Provider Organization A (by the IIS or by Provider Organization A) Patient status is then automatically set to Inactive by the IIS relative to Provider Organization B	The patient is included in reminder/recall and assessment reports for Provider Organization A The patient is excluded from reminder/recall and assessment reports for Provider Organization B The same applies for Provider Organization B when the patient moves back from Provider Organization A to Provider Organization B

Scenario 2: Provider organization of an acceptable type (S501)

Description	Status	Consequences
The patient has an Active status with Provider Organization A, where he/she regularly receives vaccinations The patient received a flu vaccination from Provider Organization B, which is a pharmacy The IIS considers Provider Organization B (a pharmacy) as an acceptable provider organization types (i.e., the Automatic Ownership Blocked option is disabled/not selected in IWeb )	Patient status is set to Active for Provider Organization B (pharmacy) Patient status is set to Inactive for Provider Organization A Note that if the Automatic Ownership Blocked option is enabled in IWeb for Provider Organization B, the opposite is true	The patient is included in reminder/recall and assessment reports for Provider Organization B The patient is excluded from reminder/recall and assessment reports for Provider Organization A Note that if the Automatic Ownership Blocked option is enabled in IWeb for Provider Organization B, the opposite is true

Scenario 3: Vaccination encounter of an acceptable type (S601)

Description	Status	Consequences
The patient has an Active status with Provider Organization A, where he/she regularly receives vaccinations The patient received a non-seasonal influenza (e.g., H1N1) vaccination from Provider Organization B IIS considers this vaccination encounter of an acceptable type (not a mass vaccination) IIS considers Provider Organization B as an acceptable provider organization type	Patient status is set to Active for Provider Organization B Patient status is automatically set to Inactive for Provider Organization A	The patient is included in reminder/recall and assessment reports for Provider Organization B The patient is excluded from reminder/recall and assessment reports for Provider Organization A

Scenario 4: Patient demographics received with no address and no vaccination (S701)

Description	Status	Consequences
IIS received a demographic-only submission from Provider Organization A IIS considers Provider Organization A to be of an acceptable provider organization type No address is provided in the submission No vaccination data was ever received for the patient No status was indicated in the submission	Patient status at the geographic jurisdiction level (state) is set to Inactive If a new patient's record is created in the IIS for this patient, the patient status is set to Active for Provider Organization A at the provider organization level If an existing patient's record is updated in the IIS, the patient status remains the same with Provider Organization A	IIS makes a determination whether to include the patient in the geographic jurisdiction (state, city) reminder/recalls. The patient is included in the geographic jurisdiction (state) assessments If a new patient's record for this patient is created in the IIS (with an Active status), the patient is included in the Provider Organization A's reminder/recalls and assessments

Scenario 5: Patient demographics and historical immunizations in an existing record (S704)

Description	Status	Consequences
Provider Organization B submits patient demographics and historical immunizations for a patient Provider Organization B is an acceptable provider type No status is indicated in the submission There is an existing patient record in IIS with Active status for Provider Organization A	Patient status remains Active for Provider Organization A Patient status remains Inactive for Provider Organization B	Patient is included in reminder/recall and assessment reports for Provider Organization A Patient is not included in reminder/recall and assessment reports for Provider Organization B

Scenario 6: Patient demographics and historical immunizations for a new patient (no existing record type) and the provider is not of an acceptable provider type (S706)

Description	Status	Consequences
Provider Organization A submits patient demographics and immunization data Provider Organization A is not an acceptable provider type The patient has no existing record in the IIS No status is indicated in the submission	Patient status is set to Active at the geographic jurisdiction level if no address is included or if the address is within the jurisdiction Patient status is set to Inactive at the provider organization level	Patient is included in reminder/recall and assessment reports for the geographic jurisdiction Patient is not included in reminder/recall or assessment reports for Provider Organization A

Scenario 7: Patient demographics and historical immunizations for an existing patient, with Active status sent (S801)

Description	Status	Consequences
Provider Organization A submits patient demographics and immunization data A status of Active is indicated in the submission There is an existing patient record in the IIS with an Active status for Provider Organization B	Patient status is set to Active for Provider Organization A Patient status is set to Inactive for Provider Organization B	Patient is included in reminder/recall and assessment reports for Provider Organization A Patient is not included in reminder/recall or assessment reports for Provider Organization B

IWeb Data Migration Plan for Implementation from 1:M to 1:1

The table below describes how the migration from older versions of IWeb (which used 1:M) to version 5.17.5 (using 1:1) occurs.

Patient Master				Patient Reserve
Patient Master				Owning Organization						Non-Owning Organization
Status Before	Status After	Owning Org	Owning Fac	Owning Organization (No Facility)		Owning Facility		Non-Owning Facility		Non-Owning Organization
Status Before	Status After	Owning Org	Owning Fac	Status Before	Status After	Status Before	Status After	Status Before	Status After	Status Before	Status After
D	D	Y	Y	ANY	D	ANY	D	ANY	D	ANY	D
D	D	Y	NULL	ANY	D			ANY	D	ANY	D
D	D	NULL	NULL							ANY	D
L, M, U, I	I	Y	Y	ANY	I	ANY	I	ANY	I	ANY	I
L, M, U, I	I	Y	NULL	ANY	I			ANY	I	ANY	I
L, M, U, I	I	NULL	NULL							ANY	I
NULL (Active)	NULL (Active)	Y	Y	ANY	NULL (Active)	ANY	NULL (Active)	ANY	I	ANY	I
NULL (Active)	NULL (Active)	Y	NULL	ANY	NULL (Active)			ANY	I	ANY	I
NULL (Active)	I	NULL	NULL							ANY	I

PAIS Business Rules / Triggers

The following diagram summarizes the triggers (business rules) within the application that are leveraged to assign/unassign PAIS:

Application business rules used to assign/unassign patient active/inactive status (PAIS)

The specific business rules (BR) that apply to IWeb are as follows. These business rules are implemented as specified in the 2015 MIROW PAIS guide:

BR402A (1:1) - Patient status is set to Active under the following circumstances:
- The provider is of an acceptable provider type. This means that the Automatic Ownership Blocked option is disabled (not selected)
- The provider indirectly identifies the patient as Active by:
  - Administering a new vaccination
  - Creating a new patient record
BR404A (1:1), BR405, BR406 - Patient status is set to Inactive under the following circumstances:
- The provider does one of the following:
  - Inactivates patient in the user interface
  - Removes provider ownership of patient on the Manage Population page
  - Provides HL7 submission of L, M, or U in PD1-16, which sets the patient status to Inactive for the sending facility
- The patient receives a more recent immunization from another provider organization of an acceptable type, which automatically sets the patient status to Inactive for the original provider
BR421 - Patient status is set to Deceased under the following circumstances:
- The provider confirms that the patient is deceased and does one of the following:
  - Sets the patient status to Deceased and acknowledges such on the confirmation pop-up in the IWeb user interface
  - Provides HL7 submission of Y in PID-30 and the date of death in PID-30. (PID1-16 can be set to A, P, I, M, L, U, or left blank; it does not change the patient status of Deceased if PID-30 is set to Y.) These set the patient's status to Deceased for ALL organizations and facilities in the system

Frequently Asked Questions

Do we have the ability to manually re-assign a patient's facility ownership in their demographic information?

No. The only way to take ownership of a patient is to administer a vaccination to that patient. When a vaccine is administered, both facility ownership and organization ownership are updated. However, a user can indicate that they no longer own a patient via the Manage Population page if they are the current owner and no longer see the patient.

Do we have the capability to run a report on each facility to list which patients are active and which are inactive?

Yes. IWeb 's move to a 1:1 relationship (starting in version 5.17.5) between a patient and a provider means that a patient appears in only the assessment for the facility in which the patient is active. Run the report from the Manage Population page.

Are we able to see from a state perspective which patients are active and inactive from a geographic ownership perspective?

All patients who are not marked as Deceased are considered active within the registry from the geographic jurisdiction perspective (assuming the patient's address is available in the IIS).

When a provider selects BR404A to inactivate a patient, does it require the provider to enter who the new provider is?

No. The provider is not required to select another provider. It would not be expected that the provider always has that information.

What happens to patients that are marked as Inactive (other than death) by providers? Is there any way to use reminder/recall for these patients by demographics?

Yes. When a provider marks a patient as Inactive, it only marks them as inactive for that particular organization/facility. The patient can still be returned in a reminder/recall run by a Registry Client user who does not have specific ties to an organization or facility.

How is the Unknown/Unspecified status utilized by IWeb ? Where do we find a listing of patients with an unknown status?

As of version 5.17.5, IWeb only uses Inactive, not Unspecified. There is no method of searching for patients with a status of Unspecified.

How is PAIS hierarchy used in IWeb in regard to facility ownership versus geographic jurisdiction level?

See Ownership in IWeb above for specifics. If a facility inactivates a patient and no other facility activates the patient with a qualifying event, the patient becomes the responsibility of the geographic jurisdiction in which they reside. (Assuming the geographic jurisdiction of the patient is available in the IIS.)

How can a patient remain in an active status at the geographic level, but be inactive at facility level?

As of IWeb version 5.17.5, PAIS is 1:1. A patient can only be active for one organization/facility and, if inactivated at that level without another organization/facility taking over ownership, the patient becomes the responsibility of the geographic jurisdiction in which they reside. (Assuming the geographic jurisdiction of the patient is available in the IIS.) An organization/facility can remove active patients either by inactivating them in the UI or by removing ownership on the Manage Population page.

Will we have a report to identify patients receiving vaccines, but marked as inactive?

Yes. When running reports such as the Patient Detail and Coverage Rate Report, users can choose to filter by service and include inactive patients to view a list of all patients who have received vaccinations from the organization/facility.

Are the rules of ownership defined differently based on the category of facility, such as clinic versus pharmacy?

On the Organization and Facility Maintenance pages, there is a Automatic Ownership Blocked option for the specified organization/facility. This is the only setting that impacts the organization/facility ownership logic.

What happens to the patients owned by a facility that closes when the facility is changed to inactive?

They remain owned and active until they have received a new vaccination by another organization and facility that is allowed to own patients.