Section 11-Why does SDIR work this way.pub

Section 11-Why does SDIR work this way.pub
Your Guide to SDIR ►
Why Does SDIR Work This Way?
Computer software application development is a complex science that combines logic, mathematics and
computer programming. In the case of immunization registries, that computer science is combined with
immunization policies, recommendations, requirements and clinical practice. Many SDIR users wonder about
the racionale or basic premises of how the SDIR application works to bring all these factors together. The
purpose of this document is to present some of the assumptions and premises –in other words, the “behind-thescenes” workings of the SDIR computer application.
This insider’s view is organized according to major features (tabs) in the SDIR application. Please note that
separate documents are available to view the vaccine forecast algorithm rules (known as the VFM) used in the
application.
First of all, it’s important that users understand that in SDIR there are different kinds of users and levels of
access.
SDIR has several different levels of user access which are required based on state law and the HIPAA ‘need-toknow’ guideline. There are administrative users, “full” users, Limited Clinical Providers (LCPs) and read or
view-only users.
Administrative Users:
This level of access is for the SDIR Help Desk and registry staff. There are certain functions and reports that
can be accessed.
Full Users:
These users are health care providers who administer vaccines and enter vaccine data into the registry. They are
able to view all demographic information as well as edit and save data to their home records.
Limited Clinical Providers (LCPs)) users:
The LCP user designation covers Women, Infant and Children (WIC) users, the County of San Diego HHSA
CalWORKS (California Work Opportunity and Responsibility to Kids) ‘welfare’ programs and schools (which
are also read-only users). According to the state law that governs immunization registries—California Health
and Safety Code Section 120440, entities such as schools, child care, facilities, WIC, health care plans, and
county welfare departments are authorized to participate in the immunization information system (registry). In
the case of schools, child care facilities, family child care homes, and county welfare departments, the purpose
of their access is to carry out their responsibilities regarding required immunization for attendance or
participation benefits, or both, as described in the California Health and Safety code and in the Welfare and
Institutions Code.
Furthermore, users within these entities, which in the SDIR are categorized as Limited Clinical Providers will
not be able to view or see on printed records from the registry any information pertaining to the individual’s or
their parent’s/guardian’s address, phone number, SSN, and Medi-Cal number. LCP users are allowed and
encouraged to enter and view all other demographic and immunization information.
quickly as possible find something in the database, presuming they have some basic information on which to
search. The MatchMerge feature is to correctly match multiple sourced records in the database.
Page 10.1
Section updated 09/06
Your Guide to SDIR ►
As outlined in formal agreements between SDIR and, WIC, CalWORKS and school districts, users from
these organizations will copy immunization information and documented disease history into the registry
from the individual California Immunization Record (CIR) also known as the yellow card.
With the exception of the four demographic data elements previously mentioned, LCP users are able to enter
all other pertinent information on the individual. They can also print out from the SDIR several important
documents such as the California Immunization Record (yellow card) and for school users, the California
School Immunization Record (blue card). The LCP user’s manual explains other features and functions
available to the LCP user.
Demographic Tab
How does the Search feature work?
There are different kinds of searches, used in different places in the application.
Note: The search feature does not use “Soundex” an algorithm for encoding a word so that similar sounding words are encoded the same for the computer. The MatchMerge feature (includes record ‘linking’)
uses “Soundex.”
The Basic Search searches on the fields you see on the screen. It looks for prefixes on the name fields you are probably familiar with this - but not soundex. Basic search is optimized for frequent use.
Advanced Search is similar to Basic Search but has more field options and can give search options and
ranges such as using “and's” and “or's”, “equals” or “contains” relationships. It is slower but gets more
results in the set and is intended for occasional use when the basic search does not produce results.
MatchMerge uses a search to match a given record to other records. The matching algorithm has much
more to work with, since it starts with a complete record and not just a string the user types in. The
MatchMerge purpose is different from the basic and advanced search. The basic search features are for
users to look as
Page 10.2
Section updated 09/06
Your Guide to SDIR ►
The MatchMerge method uses a more complicated search algorithm called “soundex”. MatchMerge matches
records for the same provider (i.e. true duplicates), so it can be used to prevent the user from re-entering a
record when it is already present in the database. An typical example of the process is to search to the record of
a patient with the last name of “Lamark.” The user would probably find the desired record by typing in "Lam"
under Last Name, even if he had a spelling like "LaMarque" in mind, when the data had "LaMark" (one is
incorrect).
Another name such as "Kernak" however would not be found if the user entered "Kir" under Last Name. As
entering just "K" would return too many matches, he may not be able to find the record using the search. He
could try "K" for the last name, and "Alex" for the first name and find it or use the correct date of birth, but the
user may not have this information correct, or may not go this far.
Best practice: Users should only enter enough letters in the search to narrow the search to a small number of
records. It is also faster for the user not to have to type too many letters.
Please note: If the user can't find the record using the search, such as in the "Kir" example above, the user
usually enters a new record. But, before saving, the application runs the MatchMerge algorithm, and the
correct record is found. The fact that the matching record is also a home record is noted on the bottom half of
the screen, so the user is alerted that he is entering a duplicate. The appropriate thing to do now is note the
existing spelling of the name, go back to the search screen, and find the correct record and operate on it.
Linking Records :(after a patient is added)
Since MatchMerge is run after adding a patient, the system finds its potential match, but it will not complete
the process without the user's approval. Also, it won't automatically enter a record either. If you press "new
patient", after doing an unsuccessful search, it puts the search criteria into the demographic record just to save
you from typing it, but the user doesn't have to accept the original information.
In fact, in one example, the software allowed the user to abandon their “Add new record” and go back to the
search, because the “MatchMerge” function happened to hit one of the rare records that required the user to
manually confirm the match. In the (majority of) cases where the computer can decide, it will match the record
and save it. The application has to save the record due to the presence of the activity log. In order to maintain a
good data structure for activity log, a record is required unless there is other information in the database
somewhere else.
Archiving Records:
When a record is archived, it is copied into the Archive_* tables and deleted from the regular database. This is
a way to delete the data without really “deleting” it; there is no path for the user to get the data back, but a
database administrator could restore the data from the data tables manually.
Page 10.3
Section updated 09/06
Your Guide to SDIR ►
This feature should only be used when there are duplicate records of the same patient from the same source,
which indicates an undesirable situation in the registry where a provider has two or more immunization records
for the same patient. (There is also a new feature as of SDIR release 8.7, that assists users in consolidating
duplicate home records. See the Search section of the User Training Manual.)
For action to work correctly, the user should archive the top record if s/he realizes that it is a duplicate of an
existing home record. The top record will be unlinked and removed from the database. This is a proper use of
archive feature. Choose the default reason - "Duplicate Patient" - then choose go back to search. The user can
then type in the correct spelling and rerun the search.
How does the change of Confidentiality Status work?
Since a patient/parent or guardian has the right to share or not share the immunization record at any time,
health care providers can change the confidentiality status of a patient without having to call the SDIR Help
Desk. If a patient/parent/guardian appears at your office and requests that a previously confidential record be
shared, ask the patient/parent/guardian to sign the “SDIR Stop-Start Sharing Request” and then change the
confidentiality status in the registry. All changes in confidentiality status will be recorded automatically in the
patient’s activity log.
The procedure for changing confidentiality status works this way: The user will see new text at the bottom of
the demographic screen: "Confidential [Y/N] as of [date] and then in blue letters CHG. Click on the blue
letters. The user will be asked if s/he are sure that the status should be changed. S/he clicks "Yes”. The user
will then be sent back to the demographic screen and will be able to create or update the home record for this
patient.
Please note (again): The "Stop-Start Sharing Request" forms should be filed in the patient's medical record and
may be subject to periodic audits by SDIR to comply with state law. You can download a copy of this form
from the SD Immunization Program website by clicking on the following link:
http://www.immunization-sd.org/sdir/support.html#stopstart
Immunization Tab
What is the Vaccine Forecast Module (VFM) and how does it work?
The VFM is run whenever a patient ‘object’ is saved. (See glossary for the definition of an ‘object’.) In this
care, a patient ‘object’ could include any new data coming into the registry database such as a data conversion
or a batch load of data, or a real-time update. These are all computer database processes that are invisible to the
user. However, a patient object is also created when the user has added new information and clicks on the
“Save” button. The VFM date and list of vaccines needed is saved until the next time the user opens the patient
record or changes the patient object (data), saves it and the VFM is run once again.
For patients entered in by the County’s CalWORKS (formerly known as AFDC) program, the VFM is also run
right after the new data is saved. The CalWORKS VFM is different than the health care provider VFM as the
Page 10.4
Section updated 09/06
Your Guide to SDIR ►
optimum return date forecasted is at the end of the recommended interval instead of the beginning of the
interval.
How is the Next Due Date Work?
The Next Due Date can be one of two dates:
-the Vaccine forecast module date or the date the user chooses and manually fills in.
The Vaccine Forecast Module (VFM) date is calculated to give a patient a maximum number of shots in a visit
within a 15 day window of the earliest vaccine forecasted. The computer logic is as follows:
Note: max=maximum; min=minimum
1. "Next Shot" date is determined: the due date of the next shot of any group - see selected line in the example
file;
2. max_date is the minimal max_date of forecasts before "Next Shot"
3. min_date is the maximal min_date of forecasts before both "Next Shot" and max_date
In other words, it looks for a date that is the latest possible due date of all next shots, so that it can give the
maximum number of shots at once. However the VFM doesn't choose a date so late that the max_date of any of
the due shots is exceeded, or that the next dose after this one is already due. This explains why it sometimes
looks like a shot may be due now, but the VFM next due date is forecasted to be in the future. It is choosing a
date for the patient to come into the office and the computer tries to pick a date when they can get the most
shots on the same day.
Note: The VFM date is programmed to not chose a Sunday but can be overridden.
Who makes up the rules for the Vaccine Forecast Module and how often do they change?
The Vaccine Forecast Module (VFM) is dictated by rules developed by the SDIR Medical Director and Clinic
Services staff. They based their decisions on the latest American Committee for Immunization Practices
(ACIP) recommendations. When these recommendations change, it can take several weeks for the rules to be
revised (on paper) and then for the computer algorithm to be changed. The immunization recommendation
would then be put into new releases of the SDIR that will occur on a monthly or bimonthly basis.
How can users change the Next Due Date?
Next Due Date on Immunization Screen initially is the same date as VFM Due Date, but can be changed by
user if the date falls on a weekend or holiday when the practice is not open. It is only stored if the user presses
the Update button below Next Due Date, and subsequently saves the patient record.
Page 10.5
Section updated 09/06
Your Guide to SDIR ►
Why does the VFM forecast for both the past and future?
The Vaccine Forecast can display vaccines that were due for an individual in the past. That individual is
considered “overdue for shot(s). If the individual is up-to-date on their current vaccines, it will forecast shots
based on the “optimization rule”; that based on the VFM rules, the computer examines all upcoming doses with
the 15 days of the earliest forecast. The optimal date is the latest forecast date within that 15 day window.
What is the Vaccine Forecast on the Immunization Screen?
The Vaccine Forecast area of the Immunization Screen shows the vaccines that can be given today. It is
possible that by the Next Due Date, other vaccines will be due and the list would look different. This list is
most useful to use on the day the patient comes in.
Why are there three Immunization Screen Views of Immunization Records?
There are three different ways that a user can view shot records s on the Immunization Screen. They are:
showing “Unique” records (for the most part without duplicates), “Valid only” (those that have been validated
according to the computer algorithm rules for validation) and “All records” (showing all the shot history
including duplicate records.
What happens when there are Duplicate Shots?
There are instances of when the user will see what appear to be duplicate shots on the “Unique” records screen.
This is due to data entry differences between the various providers that have entered historical records for this
patient. Although the computer has been programmed to first choose administered shots with vaccine lot
numbers, the question of historical shots (those given by another provider without any vaccine lot number) can
create a conflicting situation for the computer. (Our software engineers call this “The Battle of the Same
Dose.”) To resolve the computer’s dilemma, the SDIR technical committee decided to have the computer
choose the first historical immunization date entered.
Why are there times when different Shots (but in the same vaccine family) are given on the same date?
An immunization registry’s information is only as accurate as the data users enter. There are cases in the SDIR
in which users have made an error in the vaccines for historical shots. Two shots in the same vaccine family but
different antigens, e.g., DTaP and DTP, may show up as given on the same day or even a window of a few
days. The computer cannot always choose which vaccine entry is the correct one to select to show on the
computer’s screen, therefore, the computer will show both.
Utility Tab
How do the Reports work?
There are a number of different reports that SDIR users can and should run regularly to keep the quantity of
information to a manageable level. Particularly in the case of reminder/recall reports, if these reports are not
done on a regular and periodic basis, say, every week, provider staff may be overwhelmed by a long list of
patients. Also, it may seem obvious to say so, but if a specific range of dates and ages of individuals is picked,
the reports will exclude patients that do not fit those specific criteria. In addition, completion of all information
Page 10.6
Section updated 09/06
Your Guide to SDIR ►
on the immunization screen, such as the manual due date (the date that can be manually entered by the user so
that the patient is not scheduled to return on a holiday or weekend) is extremely important if that criteria
(manual due date) is selected for a report. Finally, it is very important that users realize that the counts for the
different reports are dependent upon the facility that they originally selected when they logged on to the
computer.
Why are the totals sometimes different for the same site for the Daily Assessment Report, the
Immunization Report and the Vaccine Usage Report?
Ideally, all the totals in the reports for the same provider, same facility, and same day should show the same
totals. However, users need to be careful when they first sign-on to the SDIR and select the facility they will be
entering data for during that session. Special attention must be paid when looking on the demographic page for
the patient’s information. The user must make sure that the value (name) in the facility field reflects the correct
place. If the facility is incorrect on the demographic screen then all the totals will be thrown off for the reports.
The computer uses the facility on the sign-on screen as the default (chosen) value for reports.
What is the difference between the two Assessment Reports—Detailed (now known as the Patient
Record Activity Report) and the Summary—(now known as the User Activity Report)
The Patient Record Activity Report details what was done to a patient record, listed by patient.
The User Activity Report summarizes what different users did to patient records by different age ranges.
What’s the difference between the Reminder and the Recall Reports?
Reminder report:
This report gives you a listing of patients who should be sent a reminder notice one week prior (or for another
date range determined and entered by the user) prior to when their next immunization is due.
Recall report:
This report gives the user a listing of patients who are overdue for their immunizations by two weeks (default
setting) or by a greater or lesser amount of time depending on the date range chosen by the user.
How is the best way to use the Reminder/Outreach Report to be sure not to miss patients (and get
penalized on the County’s Immunization Program’s Annual Audit –if applicable)?
There are several ways that users can run the reminder/recall reports. They can select the manual due date, or
the VFM date and select children to reminder or recall based on birth date
There is an advantage for users to fill in the manual due date on the immunization screen so that this date can
be used for reports. If the manual due date is not filled in, it will automatically be dated by the computer with
the VFM date. This is acceptable too, however, there are occasional instances, for example, when new vaccine
recommendations are made, when the VFM has to be run on the entire database. This circumstance creates an
Page 10.7
Section updated 09/06
Your Guide to SDIR ►
incorrect VFM (and manual) due date based on the computer’s running the rule through the database and not
on the actual patient’s VFM.
Since changes to vaccine schedules happen periodically and determined at the national level, SDIR advises
user to narrow the focus of the population to be reminded or recalled, the user should select the individuals
based on birth date
What about the Activity Logs?
Entries on the Activity Logs are both auto-populated, this is by the computer when an activity is performed,
and manually when the user opens the Log to write notes or important information.
Users will note that some types of activity logs (error, error correct, reminder, recall, outreach, confidentiality
are 'shared' among providers. So that activity logs of those types are displayed even if they belong to 'grey'
records
Encounter, save, link and unlink activity logs are displayed only from 'white' records. That is, only the provider
with the “home” record can see these entries.
Regular user’s can skip this section since it is relevant only to Administrative level users, that is, the SDIR
staff. However, for those who want to know more about the registry computer application, read on...
Administration for Admin. Users only
How do Vaccine Tables work?
The most important tables that store vaccines are the Shot table and the Dose table. A shot is defined as the
shot (injection or other means of administration) that is given. . A dose refers to the medical vaccine. This is
important when combination vaccines are given—it is defined as a shot and several doses.
The Dose Table gives both the vaccine group (Vaccine_Group) and the medical vaccine (Medical_Vaccine).
Examples of medical vaccines are DTP, Hep B, Hib. The Vaccine Forecast Module (VFM) combines several
additional tables (VFM_Schedule, Forecast and Demo_Forecast) that are based on doses (not shots). In
summary, doses are assigned to vaccine groups/families, whereas specific shots (vaccines) are not.
The Shot Table gives the manufacturer vaccine (MFG Vaccine), lot number, etc. Examples or manufacturer
vaccine are DTP, Hep B, Hib, Comvax, and DTaP, HepB-IPV. Inventory in the application is based on shots.
The Vaccine combination Table, labeled “Vaccine_Comb”, provides the relationship between a manufacturer’s
vaccine and a medical vaccine. The Vaccine_Comb table indicates, for example, that the manufacturer vaccine
DTaP-HepB-IPV corresponds to the medical vaccines DTaP, Hep B, and IPV The Vaccine_Comb table,
Page 10.8
Section updated 09/06
Your Guide to SDIR ►
however, has entries for all vaccines, not just combination ones. When entering a new vaccine through the user
interface, an entry must be added to Vaccine_Comb as well as to the Medical_Vaccine and Mtg_Vaccine.
Therefore, the following steps should be followed when entering vaccines:
1) add new medical vaccine
2) add new mfg vaccine
3) add new Vaccine Combo to link the medical and mfg vaccines.
What is Manual Verification and how does it work?
When a demographic record (with or without immunizations) is added to the system—whether through the
demographic screen, by a real-time update or by a batch process, it runs through the MatchMerge module and
the Verify ID is set to the MatchMerge Y.x. If the module can definitely match it to existing record(s), it is
linked. If the computer module determines that it cannot match to any other records, it is assigned a new
“IPID” (patient identification). If MatchMerge cannot tell, it does not assign a “IPID” which results in it
becoming available to the Manual Verification module.
Manual Verification is run periodically by the Computer Services Supervisor to manually match records that
cannot be resolved by MatchMerge automatically, especially after batches are loaded.
A record with a no IPID will be returned by the Search module. In this case, the manual verification will ‘turnon’ when a home user attempts to access it. A person’s first, last and middle names, mother’s maiden name,
date of birth and birth order are considered in the SDIR matching algorithm.
What record is chosen by the computer when reports are run?
When any of the administrative level reports are run, the latest home record is pulled for a child who has
multiple or linked records.
What happen when two users at the open the same record at the same time?
Two stusers from the same provider can access one record at the same time. The 2nd user will not be notified that
the 1 user has that record open. The user that saves the record last will overwrite the user who saved it first.
If the two users are from different providers, they cannot edit the same portions of the record because each
provider would have their own ‘home’ record.
Can inactive vaccinators be removed from the vaccinator’s list?
Vaccinators cannot be entirely removed from the vaccinator list because they relate to existing data in the
database., but inactive vaccinators can be hidden from view. As of release 8.7, inactive vaccinators can be
archived (hidden from view) or selected to be viewed. There is also feature however, that, on a daily basis,
allows a site to mark a vaccinator as being in that day; this results in only these vaccinators appearing on the
drop-down box when the user adds immunizations through the application. The “today” feature does not last
from day to day.
Page 10.9
Section updated 09/06
Your Guide to SDIR ►
Where does the Vaccine Usage Report get its data?
This report prints vaccine used by dose number and uses the Dose Table. The vaccine usage report also pulls
data from the Shot, Demographic and manufacturer (mgf)_vaccine tables.
How is the Provider Id and Source ID created?
The source id’s are generated at the administrative level. When adding a source (provider), a source_ID is
automatically generated. The “provider Id “field is not used in the database at the present time.
Page 10.10
Section updated 09/06
Your Guide to SDIR ►
SDIR Glossary:
“Algorithm”: A detailed sequence of actions to perform to accomplish some task.
Named after an Iranian mathematician, Al-Khawarizmi. The term is also used loosely for
any sequence of actions (which may or may not terminate).
“Home” Record: The demographics record of a patient that a specific provider has entered
into the registry that appears after typing the patient’s name during the Search functions.
“Other” Record: A demographic record that has been identified as belonging to the same
patient as the “home” record during the Search function.
Multiple-sourced records: Since it is recognized that an individual will visit different
health care providers to obtain their immunization, the SDIR application was created to
allow for more than one demographic record for each patient within the application. Each
record for a given patient should be from a different health care provider and is stored in
a separate demographic record. Duplicate records for a patient within one provider
organization does also occasionally occur. The MatchMerge feature will link the
multiple-sourced records for the same patient.
Level of Users: There are two levels of users in SDIR—Administrative and regular.
Administrative users can see all the tables and reports. Regular users only have access to
a limited number of reports and functions in the Utility Tab– Under reports, regular user
can update vaccinators, produce vaccine usage reports, vaccine, change their password
and export data to the CASA software program.
Patient object: This term refers to internal data structure that holds all the information
for a single patient. A patient object can refer to any piece of an individual’s information,
the date of birth, immunization shot, date of shot, etc., that is saved in the database.
“Soundex”: Soundex is the name of a computer decision-making process or algorithm
used for encoding a word so that similar sounding words/letters are enclosed the same.
For example, “SMITH” or “SMYTHE” would both be enclosed as the same.
Tables: In computer programming, a table is a database structure used to organize
information, just as it is on paper. It consists of rows and columns and is stored on a
computer disk.
Verify: This term refers to the action to check that the data in one record matches or does
not match the data in another record. During the verification process, the MatchMerge
function will show the “home” record and other records for the same patient are in the
“other” section. The red lettered text over the fields in the “other” record, show where the
information is different between the two records.
Page 10.11
Section updated 09/06
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement