This is not the document you are looking for? Use the search form below to find more!

Report home > Others

SEER Registry Data Management Project

0.00 (0 votes)
Document Description
SEER Registry Data Management Project
File Details
  • Added: April, 26th 2011
  • Reads: 178
  • Downloads: 0
  • File size: 677.09kb
  • Pages: 246
  • Tags: data mining, datawarehousing, data management
  • content preview
Submitter
  • Name: rita
Embed Code:

Add New Comment




Related Documents

Master Data Management methodology

by: marielle, 21 pages

Database ArchitechsCustomer Data Hub methodology August 2009 – Master Data ManagementMastering Customer DataCustomer Data Hub (CDH) architectural overview

Solix Technologies and Quistor to Deliver Data Management Solutions to JD Edwards Customers in Europe

by: solixtechnologies, 2 pages

Solix Technologies announces its partnership with Quistor, to offer JD Edwards’ customers in Europe data management capabilities to harness the full potential of the application. With this ...

Manage Your Data with New Age Enterprise Data Management Software

by: solixtechnologies, 2 pages

With business expansion, there is a possibility of data volumes increasing for mission crucial databases. This affects the business agility as the application performance falters. Recently, the ...

Solix Technologies and SRA OSS to Deliver Complete Data Management Governance Solutions

by: solixtechnologies, 2 pages

Solix Technologies, a U.S. based leading data governance solutions provider, announced a new partnership with SRA OSS, one of the leading solutions providers for Cloud Computing and Data Centers, ...

Solix Enterprise Data Management Suite Achieves Oracle Database Ready, Oracle WebLogic Ready and Oracle Linux Ready Status

by: solixtechnologies, 2 pages

Solix Technologies announced that Solix Enterprise Data Management Suite (EDMS) 5.0 has achieved Oracle Database Ready, Oracle WebLogic Ready, and Oracle Linux Ready status through Oracle ...

Solutions to Cope with Data Management Issues

by: solixtechnologies, 1 pages

Data management is an insoluble issue as enterprises struggle to maintain stability in budgets due to the exponential rise in data. The growth of data is an inevitable event due to implementation of ...

How a Data Management Company Can Make Your Work Easier

by: mosservices, 2 pages

Data management services are a great help to business establishments. Businesses can improve their performance with the help of data management services.

The Value of Optim Data Management

by: estuate, 1 pages

Data, and how it is managed, is arguably the core of any business. So we must ask the question: how well does your company manage its data? If you are unsure of how to answer this question, perhaps ...

IBM Optim Test Data Management Solution

by: estuate, 1 pages

For any company that performs application testing, the process can be costly and time-consuming. However, speed and cost are not the only issues, what about reliability and quality? In order to ...

A Brief Introduction to IBM Optim Data Management

by: estuate, 1 pages

Any business with poor application and database performance is in need of IBM Optim data management, but what is it? In simple terms, the IBM Optim solution was created to optimize and manage a ...

Content Preview
NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) SEER Registry Data Management Project Process Model Text – Processes and Sources/Sinks The text is one part of the process model. The other part is the diagram. The development of this model is in progress, so the following text is incomplete. SEERSYS\Requirements\Process Models\6 – NP\BPM Registry Operations – Processes NP.doc First draft: July 12, 2002 Last update: April 17, 2003 Stage: New Physiological (NP) This model is being developed using a staged approach. This represents the new world of registry operations accounting for facts of life, facts of policy and some facts of implementation only. Notes to SEER Team: For processes that interact with Rules or Criteria, need to determine if this is a rules based or parameterized FieldL – laptop: free standing, disconnected from the CRO. Does not technically have to be a ‘laptop’ computer. GUI may have to be different from CRO GUI. FieldH – home: logged in to the CRO, does not have to be a desktop computer. Processes are running remotely on the CRO. GUI may have to be different from CRO GUI. This has to cross the firewall. Overall DESIGN NOTE: In any process where a person would have to stare at computer screen for a long amount of time, they should be able to print the information (print health record, print patient set, print consolidation screen, print text fields). These people like paper because it’s easier on the eyes. However, they need the ability to restrict the printing of information with a password. Probably need to consider verifying that printer selected by user is in a secure location. Overall DESIGN NOTE: this should be obvious but: 1. Automate as much as possible. 2. Unlimited text fields are a must! Processes 1.0 Conduct Screening ID: 1.0 Description This involves determining the reportability status of records received. For each record, is the cancer/tumor/case reportable? To whom is it reportable? (SEER, local, special study) Also includes screening for Special Study Reportability, even if non-cancer. The Field Rep may need to have access to additional medical information to make the determination. This may include obtaining additional demographic information from a data source, i.e. Follow Back. In some cases the Source Document may look like a CTC, but later may be ruled out. If so, the CTC is still accounted for as a non-reportable diagnosis. Records that don’t even look like CTCs (or special study) are not kept because it is illegal to do so. LOCATION NOTE: sometimes the record doesn’t come into the registry. The registry staff member goes out to the facility (i.e. a path lab) and screens the records on-site. In these cases, this is the first process that occurs. (Followed by search for patient match and conduct abstracting) DESIGN NOTE: Opportunity to incorporate rules and use pattern-based technology DESIGN NOTE: as this becomes more electronic, it will probably be easier to find all CTCs close to diagnosis. This means all CTCs will be ‘rapid’. 04/30/03 Page 1 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Processing of Death info: 1. Death list/index is obtained by the registry. It is scanned for new CTCs (passes fine filter for Cancer/Tumor/Case). If true then a death certificate is requested from the state. Some registries may only be doing this if there was no patient/CTC match. 2. The DC is obtained. If the index entry was marked as a new CTC, the DC is screened to verify that it really is a CTC and is then added as an incomplete patient set (or CTC set if patient exists.) In this case, then do follow-back to gather facility information (hopefully an abstract) about the CTC. Interested Registries Interested: Not Interested: Local Procedures DT is doing most of this at the facilities. They are trying to find all CTCs within 1 month of diagnosis. They would do ‘1.3.1 Collect Additionally Required SS Variables’ at the same time. They also collect as much info as possible during this task (since they have the medical records, not just a health record). Leads are transmitted to the registry. UT is similar to DT. LA & UT are starting to get the Canadian ISIS package installed in some of their path labs. They are getting the screened results and send the information on to the relevant hospitals. SEA: does 100% casefinding at registry. They tell the facilities what cases they are expected to receive, whether or not they abstract it themselves. SEA: they call this the pull list algorithm. They retain the excluded records (their hospitals are sometimes interested in records SEA is not because of catchment issues.) The lists are marked as to whether the computer or a person made the decision. The person must provide comment defending decision. The Includes list (reportable) go to through 4.0, 2.0, 5.1.3 and 18.4. The Excludes list go through 4.0 passive follow-up and are retained for QC purposes. SEA: in the name of QC, the re-run all the case finding records received during the year to make sure that all records were handled appropriately. Degree of Automation Fully and Semi Processor Case finder/screener Special Study Manager Computerized The following may participate in the role of case finder: Field Staff (abstractor) Office Staff Hospital Staff Medical Editor Abstractor/Cancer Registrar Data Manager Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules If possible, would be nice to allow editing of data at end of this step. However, data was edited in ‘13.0 Confirm Receipt of Record’ and no new information has been added, so editing seems redundant to the designers. 04/30/03 Page 2 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Sensitivity Trigger (Acceptable Health Info Arrived – which subsets as: ) Health Record Arrives Electronically or Paper Health Record Deemed acceptable Metrics Frequency: Volume: SEA: screens 154,000 disease index records; 51,000 path reports and 77,000 rad/chemo therapy records per year. NJ: 110,000-120,000 records (30,000-40,000 paper paths, headed towards AIM) – not including correction or follow-up. Duration: HI: 50 a day per person: screen, check for dups, visual edits, match & consolidate. Manual Duration: LA: Also Manual, no feel for how much electronic would reasonably expect to do. Quality/Error rate: LA: suggested contacting SEA or NM about this Quality/Error rate: SEA: out of about 350,000 CF records, they find 1500-1700 records that need to be investigated. (dropped inappropriately) 1.1 Conduct Initial Screen ID: 1.1 Description This automated process determines the reportability of a record entering the registry for SEER, local, Special Study, etc. All records that are deemed as not being reportable at the gross screening level, ‘Non Cancer/Tumor/Case Records Not Reportable to a Special Study’, are discarded for legal reasons. These are records we are sure we don’t need. We don’t track why they were kicked out. If a record fails this gross filter, it is still matched against existing patient sets for passive follow-up purposes. If it is useful for passive follow-up, we’ll have to keep basic information (Patient ID, Facility ID, Date of Contact) for tracking purposes so we can source the follow-up information to it. Records that are considered ‘boarder line’ may be stored with a non-reportable flag and non-reportable reason. Records that are deemed as reportable are stored and move to either process 3.0 or 4.0 If a record is inconclusive as to whether or not it is reportable, a flag will be set so that the record can be manually reviewed. Processing of Death Info: Although most health records which fail the broad screen are removed from the data store, DC tape/list/index records are retained in the name of passive follow-up. These are public records. Interested Registries Interested: Not Interested: LA (until records begin to arrive electronically) Local Procedures Local differences exist in what is a reportable disease per registry Degree of Automation Fully Processor Computerized Location Central Registry Office Field Laptop (freestanding) 04/30/03 Page 3 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Policies/Business Rules When a record is “kicked out” as “non-cancer/tumor/case and record not special study reportable”, and is not used in passive follow-up, we would also want to remove it from the Health and Supplemental Record data store. Death certificates would be an exception to this rule as you would want to keep these for follow-up information for future CTCs that haven’t been abstracted yet. The implementation of this is still to be determined. Sensitivity Trigger (Acceptable Health Info Arrived – which subsets as: ) Health Record Arrives Electronically or Paper Health Record Deemed acceptable Metrics Frequency: Volume: Duration: Quality/Error rate: 1.1.1 Determine Potential CTC and Special Study ID: 1.1.1 Description This is an automated gross filter to eliminate records that absolutely do not meet reportability criteria. We are filtering out not-reportable diagnoses like broken legs, herniated disks, childbirth, etc. We are examining Converted ICD Codes or unconverted disease text (keywords, including Pathology Reports) in Valid Health Record or Additional Disease Codes + Keywords in Death Certificates to determine if there is a Potentially Reportable Cancer/Tumor/Case Record. As noted in 1.1, if a record fails the gross screen, it may be used to passive follow-up. Basic information (Patient ID, Facility ID, Date of Contact) would have to be kept for tracking purposes. Special Study Criteria is considered because there may be some instances where records are not going to pass SEER or Local screening and would otherwise be thrown out. We want to keep these – “Non Cancer Special Study Records”. Can also result in questionably reportable info, if the text phrase is not handled well in the rules. For example, ‘definitely not cancer’ may confuse the computer, but be perfectly clear to a person. Records of this type should probably result in new rules for screening be considered or added to the Rules. Interested Registries Interested: Not Interested: Local Procedures Degree of Automation Fully Processor Computerized Location Central Registry Office Policies/Business Rules Sensitivity 04/30/03 Page 4 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Trigger Health Record Arrives Electronically Metrics Frequency: Volume: LA: currently manually screening about 800,000 paths a year, hope to screen 100,000 paths per year when e-path reporting occurs. Only keeping about 20,000 paths. 50,000 abstract pass screening. Duration: Quality/Error rate: 1.1.2 Do Initial Screening for Local/SEER Reportability ID: 1.1.2 Description Reviews SEER Reportable List and Local Reportable List to determine if the potentially reportable record is truly reportable either to SEER or locally per SEER and Local rules. The rules include whether the record is reportable to either SEER or local based on residency and would set the residency status appropriately. If not reportable, then ‘not reportable reason’ is given per SEER and per local reporting organization. Note: The Registry determines what goes to each specific organization later, when the data is extracted for reporting. If the screen is completed successfully, the data is sent to ‘4.0 Match and Consolidate patient set’. The incomplete patient set information may also be used by ‘2.0 Conduct Abstracting’. Interested Registries Interested: Not Interested: Local Procedures DT: collects CIN3 and CIS cancers. NM: collects benign brain and non-SEER rpt skin Degree of Automation Fully Processor Computerized Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules Sensitivity Trigger Paper Health Record Deemed acceptable or Yes, Potential CTC Metrics Frequency: Volume: Duration: Quality/Error rate: 1.1.3 Do Initial Screening for Special Study Reportability ID: 1.1.3 Description An automate process that retains any record that meets the criteria for a any Special Study. 04/30/03 Page 5 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) The rules include whether the record is reportable via a Special Study based on residency and would set the residency status appropriately. A “Potentially Reportable Cancer/Tumor/Case Record ”that does not meet the criteria for a Special Study will be retained regardless of the screening result for SEER and Local Reportability – these are deemed are non-reportable to Special Studies. If record is not potentially reportable to SEER or Local, but passed the broad Special study screen, the special study non-reportable reason may be saved and the record flagged as non-reportable. No patient set will be created. Some registries may choose not to do this and they don’t seem to be externally audited on it, but functionality should be available. See Screen for Possible Local & SEER Reportability, 1.2 Since multiple CTCs may be reportable to multiple Special Studies, we need to know which Special Studies the record is reportable to. If the record is deemed eligible and is part of a rapid case ascertainment special study, then rapid case ascertainment indicator is turned on for the record. For an abstract, this means expedited travel through the rest of the processes. For a non-abstract health record, need to allow a path (15.0, Match Patient Set; 4.0 Consolidate Patient Set; 3.0, Support Special Studies) for those CTCs where an abstract is not needed. In these cases, the abstract will be obtained AFTER record has gone to special study, in normal registry timing. At completion of ‘screen’, the incomplete patient information may be used by ’15.0 Match Patient Set’ or ‘2.0 Conduct Abstracting’ If Matched non-reportable CTC info passes the screen, this information would go directly to 2.0 and/or 4.0. Interested Registries Interested: Not Interested: Local Procedures Local rules may be broader than SEER rules. Some registries would like to treat this step as the setting of a status flag. All records that made it to this step would be turned into patient sets – with SEER reportable flag and Local reportable flag, both of which may be off. Degree of Automation Fully Processor Computerized Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules Currently, one reason there is not a kick out (deletion) of ‘non-reportables’ because they want to track (if it comes up again) that they’ve already screened it and deemed it ‘non reportable’ along with the reason they deemed it ‘non-reportable’. Another reason we keep these records that are kicked out is for QC audit purposes. Yet another reason we keep these records is that sometimes two records that separately look non-reportable can combine to look reportable (e.g., the first includes a histology that’s not reportable; but another record indicates that the histology was wrong, and the CTC is actually reportable). Sensitivity Trigger 04/30/03 Page 6 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Paper Health Record Deemed acceptable or Yes, Potential SS Patient & SS exists or Yes, Potential SS Patient & RCA needed Metrics Frequency: Volume: Duration: Quality/Error rate: 1.2 Complete Final Local/SEER Screen ID: 1.2 Description This manual process reviews records that process 1.1.1 deemed as questionably reportable or process 1.1.2 deemed as inconclusive for Local/Seer Reportability and ultimately decides if the potentially reportable record is truly reportable either to SEER or locally per SEER and Local rules. The same rules apply as in 1.1.2; however, conversion of free form text may also take place here. If follow-back is required, a health record update may be generated here to attach the follow-back response to the health record being screened. DESIGN NOTE: for conversion of codes and selection of keywords (13.4 tasks) which can not be automated, they would manually do those tasks while screening as needed. Interested Registries Interested: Not Interested: Local Procedures Degree of Automation Semi Processor Case finder/Screener Abstractor (in role of case finder) Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules Sensitivity Trigger Computer can't decide if CTC (hence reportable) Metrics Frequency: Volume: Duration: Quality/Error rate: 1.3 Complete Final Special Study Screen ID: 1.3 Description This manual process reviews records that process 1.1.1 deemed as questionably reportable or process 1.1.3 deemed as inconclusive for Special Study Reportability and ultimately decides if the potentially reportable record is truly reportable either to any Special Study. 04/30/03 Page 7 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) If additionally special study variables are needed, they are gathered here. Usually, only additionally variables needed to complete the screen are collected by the registry. If follow-back is required, a health record update may be generated here to attach the follow-back response to the health record being screened. Interested Registries Interested: Not Interested: Local Procedures Degree of Automation Semi Processor Case finder/Screener Abstractor (in role of case finder) Special Study Manager Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules Sensitivity Trigger Additional Spec Study variables needed or Computer can't decide if eligible for Special Study Metrics Frequency: Volume: Duration: Quality/Error rate: 1.3.1 Collect Additionally Required SS Variables ID: 1.3.1 Description When a special study requires variables outside of the standard registry collection list, additional effort is required to track down the information. This also includes the collection of additional variables needed to finish the screening task. (Possibly county which is not usually found on path reports) For some special studies, this process may be concurrent with 2.1 Create Abstract. For others (especially those which require rapid case ascertainment), this could happen as soon as or while the CTC is screened and noted as ‘reportable to special study’ and the 2.1 Create Abstract would happen months later. Seems to mostly refer to rapid case ascertainment of path reports. Usually for variables needed for screening and the special study staff collects anything else they have interest in. For SEER POC studies, the cohort has been selected and the registry staff has gone back to a facility to gather this information. Interested Registries Interested: Not Interested: Local Procedures LA only collects variables that are necessary to complete the screening process (residency, etc). Degree of Automation 04/30/03 Page 8 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Semi Processor Case finder/Screener Abstractor Location Field Laptop (freestanding) Policies/Business Rules Sensitivity Trigger Additional Spec Study variables needed (Follow-back Complete) Metrics Frequency: Volume: Duration: Quality/Error rate: 1.3.2 Make Final Decision Regarding SS Eligibility ID: 1.3.2 Description The actual fine screening of a record or document to determine whether or not it is reportable to (or eligible for) an on-going special study. In the case of rapid case ascertainment, this task may be concurrent or after 1.3.1 Collect Variables to Assess Special Study Reportability. This manual process reviews records that process 1.1.1 deemed as questionably reportable or process 1.1.3 deemed as inconclusive for Special Study Reportability and ultimately decides if the potentially reportable record is truly reportable to a special study per that study’s criteria. The same rules apply as in 1.1.3; however, conversion of free form text may also take place here. DESIGN NOTE: for conversion of codes and selection of keywords (13.4 tasks) which can not be automated, they would manually do those tasks while screening as needed. Interested Registries Interested: Not Interested: Local Procedures Degree of Automation Semi Processor Case finder/Screener Abstractor (in role of case finder) Special Study Manager Location Central Registry Office Field Laptop (freestanding) Policies/Business Rules Sensitivity Trigger Computer can't decide if eligible for Special Study (Follow-back Complete) 04/30/03 Page 9 NCI – SEER Registry Data Management Project Business Process Model Text: Registry Operations New Physio-Logical (NP) Metrics Frequency: Volume: Duration: Quality/Error rate: 2.0 Conduct Abstracting ID: 2.0 Description Iterative process of patient data evaluation in order to gather enough information to 1) determine whether we need to create an abstract and 2) create or request the abstract if needed and 3) requesting the medical records. Can also produce abstract facility leads to other locations (referred from, referred to) NOTE: sometimes the registry staff member is on-site to do Conduct Screening and Conduct Abstracting. In those cases, the information may need to flow directly from Screening to Abstraction. In some registries existing patient sets are not available to the staff member while on site. DESIGN NOTE: for conversion of codes and selection of keywords (13.4 tasks) which can not be automated, registries would manually do those tasks while screening as needed. The balance of these tasks would be done during the Consolidate processes or Conduct Abstracting, as appropriate. Information received at the central registry does not have to be structured as an Abstract before being consolidated. Interested Registries Interested: Not Interested: Local Procedures Degree of Automation Processor Location Central Registry Office Field Laptop (freestanding) Field Registry Staff Home (logged in) Policies/Business Rules Sensitivity Trigger No patient match for potential CTC or No CTC match for potential CTC or No treatment match for potential CTC (May be run as periodic batch if most efficient) Metrics Frequency: Volume: Duration: Quality/Error rate: 2.1 Create Abstract ID: 2.1 Description 04/30/03 Page 10

Download
SEER Registry Data Management Project

 

 

Your download will begin in a moment.
If it doesn't, click here to try again.

Share SEER Registry Data Management Project to:

Insert your wordpress URL:

example:

http://myblog.wordpress.com/
or
http://myblog.com/

Share SEER Registry Data Management Project as:

From:

To:

Share SEER Registry Data Management Project.

Enter two words as shown below. If you cannot read the words, click the refresh icon.

loading

Share SEER Registry Data Management Project as:

Copy html code above and paste to your web page.

loading