high level business requirements€¦ · 1.1. purpose of the document the purpose of this document...

High Level Business Requirements

NCAMP 2012

Version 1.0102

Date 17 Feb23 May 2012

Owner Business Analysis Team

Status Ammendment to First Release

Business Requirements: NCAMP 2012 version 1.0102

17 23Feb May 2012 In Confidence of 75

IDO Projects/NCR 3529 NCAMP2012/Product file/Analysis & Design

Table of contents

1. Introduction .................................................................................................................................. 5

1.1. Purpose of the Document .................................................................................................... 5 1.2. Project Background ............................................................................................................. 5 1.3. Project Goals and Objectives .............................................................................................. 5 1.4. Business Scope ................................................................................................................... 6

1.4.1 In Scope................................................................................................................ 6 1.4.2 Out of scope ......................................................................................................... 7

2. Business Rules, Assumptions, Dependencies and Relevant Facts ....................................... 8

2.1. Business Rules .................................................................................................................... 8 2.2. Assumptions ........................................................................................................................ 8 2.3. Dependencies ...................................................................................................................... 8 2.4. Relevant Facts ..................................................................................................................... 8

3. NBRS ............................................................................................................................................. 9

3.1. Implement validations to improve data quality #19 ............................................................. 9 3.2. OUT OF SCOPE Allow health specialty and CPAC tool to be updated at the same time #20 (Refer to Appendix B19) .......................................................................................................10

4. NNPAC ........................................................................................................................................11

4.1. Reject Duplicate Events #40 .............................................................................................11 4.2. OUT OF SCOPE Load Outpatient Events from private hospitals or private providers into NNPAC #45 (Refer to Appendix B20) ..........................................................................................12 4.3. OUT OF SCOPE Validate event type and purchase unit combinations #46 (Refer to Appendix B21) ..............................................................................................................................13 4.4. Add new health specialties for GPs/primary care #49 .......................................................13 4.5. Updates required to implement the National Service Framework Library Purchase Unit Data Dictionary (NSF PUDD) Version 17 #52 .............................................................................13

5. NMDS .......................................................................................................................................1415

5.1. Collect the agency/DHB of the principal purchaser to enable accurate reporting of nested contracting arrangements #28 .................................................................................................1415 5.2. OUT OF SCOPE Enable private hospitals to report how events have been funded (private insurers or the patient) #29 (Refer to Appendix B22) .................................................1718 5.3. OUT OF SCOPE ACC requirements for contracted private insurers (new purchaser codes) Included as a placeholder only #30 (Refer to Appendix B23) .....................................1718 5.4. OUT OF SCOPE Collect Time in Theatre and Time in recovery for all discharges #32 (Refer to Appendix B24) ..........................................................................................................1718 5.5. Collect Condition Onset Flag to monitor hospital acquired illness and injury #33 ........1718 5.6. Annual WIES and Cost Weight Changes #35 ...............................................................1819 5.7. OUT OF SCOPE Warning Message for events with a length of stay greater than 365 days #53 (Refer to Appendix B25) ...........................................................................................1920 5.8. OUT OF SCOPE Enable reporting of event level cost data supplied from the NCCPP SAS database in Business Objects. #56 (Refer to Appendix B26) .........................................1920 5.9. Sector PMS development to incorporate HIP functionality and fields #61 .................1920

6. PRIMHD ...................................................................................................................................2021

6.1. Changes to PRIMHD File Specification Document #62 ................................................2021 6.2. OUT OF SCOPE Last Modified Date does not always update when a referral is re-submitted #63 (Refer to Appendix B27) ...................................................................................2223 6.3. Inconsistency with submission of referral end code, referral to code and referral end date #64 2223 6.4. Separate Errors for Activity End, Classification and Collection Occasion DateTimes #652324 6.5. OUT OF SCOPE Correct the message for Extracted Datetime Error #66 (Refer to Appendix B28) ..........................................................................................................................2324 6.6. Prevent the creation of duplicate referrals #67 ..............................................................2324 6.7. OUT OF SCOPE Alert Users at logon if they have records listed on My Error records #68 (Refer to Appendix B29) ..........................................................................................................2425




7. Document Control ..................................................................................................................2526

7.1. Document History ..........................................................................................................2526 7.2. Document Contributors ..................................................................................................2627 7.3. Associated Documents ..................................................................................................2728

Appendix A – Additional Information .............................................................................................2829

A1 Impact of New NBRS Validations - #19 .............................................................................2829 A2 Principal Purchaser Codes #28, #29, #30 .........................................................................2930 A3 NMDS Events by Purchaser Code ....................................................................................3031 A4 Condition Onset Flag #33 ...................................................................................................3132

Appendix B – Deferred Requests: Additional Information ...........................................................3637

B1 NBRS Error messages to reflect current data item names #24 ........................................3637 B2 NBRS Enable reporting of all health specialty changes for a booking #25 .......................3738 B3 NBRS Add ‘suspicion of cancer’ indicator to all bookings #26 ..........................................3839 B4 NNPAC Extend the list of health provider types #50 .........................................................3940 B5 NNPAC Enable the load of publicly funded events previously delivered in secondary care, now delivered in primary care, by the service provider #42.....................................................4041 B6 NBRS/NMDS/NNPAC Use the HPI to validate agency and facility #36, #58, #59, #60 ...4041 B6.1 Enable NBRS to receive and validate HPI identifiers for agency, facility and health providers #60 ..........................................................................................................................4041 B6.2 Upgrade NNPAC to use the HPI for agency and facility #59 .......................................4243 B6.3 Upgrade NMDS to use the HPI for agency and facility #58 .........................................4243 B7 NMDS/NNPAC Accountability framework reports as business objects reports #38 .........4344 B8 NMDS Update to new NZ Country Code and Occupation Code lists #51 ........................4344 B9 NMDS/NNPAC Transfer support and maintenance of the NCCPP Cube into SDG #39 ...4445 B10 NNPAC/NMDS Have national IDF prices available in datamart for reporting #31 .........4445 B11 NMDS Redefine the acute, arranged, elective admission types to deferrable, non-deferrable #37 ..........................................................................................................................4546 B12 NBRS Future Requirements to be detailed by Elective Services during June #21 ..........4546 B13 NBRS Add a new status ‘Waiting diagnostics’ #22 ..........................................................4546 B14 NBRS Exclude from performance measures the length of time that a patient has requested a deferral of treatment. #23 ......................................................................................................4546 B15 NMDS Collect data required for Medicine Reconciliation measuring and reporting framework ................................................................................................................................4647 B16 NMDS Additional Maternity related data items on birth and mothers events ...................4748 B17 PRIMHD requests deferred at this time ............................................................................4950 B18 PRIMHD requests retired .................................................................................................5051 B19 NBRS Allow health specialty and CPAC tool to be updated at the same time #20 .........5051 B20 NNPAC Load Outpatient Events from private hospitals or private providers into NNPAC #45 5152 B21 NNPAC Validate event type and purchase unit combinations #46 ..................................5253 B22 NMDS Enable private hospitals to report how events have been funded (private insurers or the patient) #29 ........................................................................................................................5354 B23 NMDS ACC requirements for contracted private insurers (new purchaser codes) Included as a placeholder only #30 ........................................................................................................5455 B24 NMDS Collect Time in Theatre and Time in Recovery for all discharges #32 .................5455 B25 NMDS Warning Message for events with a length of stay greater than 365 days #53 ....5758 B26 NMDS Enable reporting of event level cost data supplied from the NCCPP SAS database in Business Objects. #56 .........................................................................................................5859 B27 PRIMHD Last Modified Date does not always update when a referral is re-submitted #635960 B28 PRIMHD Correct the message for Extracted Datetime Error #66 ....................................5960 B29 PRIMHD Alert Users at logon if they have records listed on My Error records #68 .........5960

Appendix C – Additional Information: Capital Expenditure Bids ................................................6162

C1 Expand NBRS to capture and track event level waiting times for patient journey from referral through outpatient services to inpatient treatment #27 ............................................................6162 C2 Collect diagnosis and procedure data for outpatient events #41 .......................................6162 C3 Enable reporting of event level National Costing data (collected from 2004/05 – onwards) from a national collection #34 ..................................................................................................6263




C4 PRIMHD Casemix ..............................................................................................................6364 C5 Enable the progressive implementation of KPI reporting for benchmarking across the mental health and addictions sector. ...................................................................................................6364

Appendix D – Additional Information: SDG Maintenance Releases ...........................................6566

D1 Items proposed for NBRS 2011/12 Maintenance Release ...............................................6566 D2 Items proposed for NNPAC 2011/12 Maintenance Release .............................................6768 D3 Items proposed for NMDS 2011/12 Maintenance Release ...............................................7172 D4 Items proposed for PRIMHD 2011/12 Maintenance Release ............................................7475

Appendix E - Abbreviations............................................................................................................7576

Confidentiality:

The information contained in this document is proprietary to the Ministry of Health. This document must not be used, reproduced, or disclosed to others except employees of the recipient of this document who have the need to know for the purposes of this assignment. Prior to such disclosure, the recipient of this document must obtain the agreement of such employees or other parties to receive and use such information as proprietary and confidential and subject to non-disclosure on the same conditions as set out above.

The recipient by retaining and using this document agrees to the above restrictions and shall protect the document and information contained in it from loss, theft and misuse.




1. Introduction

1.1. Purpose of the Document

The purpose of this document is to provide a vehicle for discussion of the requests for changes to the National Collections and to document the requirements of the final scope of the National Collections Annual Maintenance Programme (NCAMP2012).

1.2. Project Background

In order for the Ministry of Health (Ministry) to meet its statutory obligation of delivering information from the Ministry’s National Collections, an annual project known as the National Collections Annual Maintenance Programme (NCAMP) is completed. The project delivers changes to the following systems:

National Bookings Reporting System (NBRS)

National Non-admitted Patient Collection (NNPAC)

National Minimum Data Set (NMDS)

Programme for the Integration of Mental Health Data (PRIMHD),

Some NCAMP changes require District Health Boards (DHBs) to initiate changes to their Patient Administration Systems (PAS) (sometimes referred to as Patient Management Systems (PMSs)). The annual process for making these changes is outlined in the Operational Policy Framework (OPF) and a Memorandum of Understanding (MoU) with the District Health Boards.

1.3. Project Goals and Objectives

To enable DHBs to provide timely, accurate and comparative information. This will assist them to complete functions and meet objectives set out in the New Zealand Public Health and Disability Act 2000.

To enable the Ministry to meet its obligations of providing high quality data to the DHBs and other providers, particularly in relation to data processing and reporting, manual data entry, and application of data collection business rules.

To improve data quality to enable DHBs to more accurately report on the provision and funding of services or treatment, particularly in relation to inter-district flows.

To ensure data quality and integrity is maintained to avoid substantial rework by both the Ministry and DHBs.




1.4. Business Scope

1.4.1 In Scope

The ref# in the table below is a National Collections Change Request Number and is used for traceability throughout development. The “Section” refers to the section in this document.

Ref# Type Section Description Rating Change notice

35 NMDS 5.6 Annual WIES and Cost Weight Changes (Mandatory)

Must cn_2012_NMDS_WIES

52 NNPAC 4.5

Updates required to implement the National Service Framework Library Purchase Unit Data Dictionary Version 17

Must cn_2012_NNPAC_PUCs

28 NMDS NNPAC 5.1

Collect the agency/DHB of the principal purchaser to enable accurate reporting of nested contracting arrangements

Must

cn_2012_NMDS_FAgency

cn_2012_NMDS_FileVer

cn_2012_NNPAC_FAgency

cn_2012_NNPAC_FileVer

40 NNPAC 4.1 Reject Duplicate Events Must cn_2012_NNPAC_Dups

62 PRIMHD 6.1 Changes to PRIMHD File Specification Document

Must cn_2012_PRIMHD_FileSpec

NMDS NMDS Release Deployment Upgrade Must

33 NMDS 5.5 Collect Condition Onset Flag to monitor hospital acquired illness and injury

Should cn_2012_NMDS_COF cn_2012_NMDS_FileVer

49

NNPAC NBRS NMDS 4.4

Add new health specialties for GPs/primary care

Should cn_2012_NCR_GPHS

64 PRIMHD 6.3 Inconsistency with submission of referral end code, referral to code and referral end date

Should cn_2012_PRIMHD_ValRef

65 PRIMHD 6.4

Separate Errors for Activity End, Classification and Collection Occasion DateTimes

Should cn_2012_PRIMHD_DateMsg

19a NBRS 3.1

Implement validations to improve data quality (3,4,5,9 referral date and staged planned warning)

Should cn_2012_NBRS_Valn

NMDS, NBRS, NNPAC

Vendor Test Environment Should

61

NMDS NNPAC NBRS PRIMHD 5.9

Sector PMS development to incorporate HIP functionality and fields

Advisory to NCAMP Forum

67a PRIMHD 6.6 Prevent the creation of duplicate referral records.

Should cn_2012_PRIMHD_DupRef




1.4.2 Out of scope

Rating

M - MUST have this.

S - SHOULD have this if at all possible.

C - COULD have this if it does not affect anything else.

W - WON’T have this time but WOULD like in the future.

Ref# Type Section Description Rating

63 PRIMHD 6.2 Last Modified Date does not always update when a referral is re-submitted

Could

45 NNPAC 4.2 Load Outpatient Events from private hospitals or primary care providers

Could

53 NMDS 5.7 Warning Message for events with a length of stay greater than 365 days

Could

20 NBRS 3.2 Allow health specialty and CPAC tool to be updated at the same time

Could

66 PRIMHD 6.5 Correct the message for Extracted Datetime Error

Could

68 PRIMHD 6.7 Alert Users at logon if they have records listed on My Error records

Could

32a NMDS 5.4 Agreed definitions and items of theatre data to be collected and detail design of solution.

Could

29 NMDS NNPAC 5.2

Enable private hospitals to report how events have been funded (private insurer or patient)

Could

56 NMDS 5.8

Enable reporting of event level cost data supplied from the NCCPP SAS database in Business Objects

Could

30 NMDS NNPAC 5.3

ACC requirements for contracted private insurers (new purchaser codes)

Wont

46 NNPAC 4.3 Validate event type and purchase unit combinations

Wont

19b NBRS 3.1 Implement validations to improve data quality (1,2,6,7,8 Valid status records present)

Wont

32b NMDS 5.4

Collect Time in theatre and Time in recovery for all discharges (NCAMP2012 #3, #45) Option 1=Totals per patient event=17weeks, Option 2=Each theatre session per patient event 25weeks

Wont

67b PRIMHD 6.6 Prevent the creation of duplicate activity records. (Allow valid simultaneous activity) Wont




2. Business Rules, Assumptions, Dependencies and Relevant Facts

2.1. Business Rules

Where relevant the business rules will be listed individually with each request.

2.2. Assumptions

BA1. Maintenance items relating to the National Collections that do not impact DHBs processes or systems may potentially be delivered in maintenance releases during the year. The content of this maintenance work is listed in appendix D.

BA2. Major increases in capability to the National Collections will be delivered through projects endorsed in the annual capital expenditure and are subject to business case approval. These proposals are listed in appendix C.

BA3. Any issues related to the DHB Merge project are outside the scope of NCAMP2012 although changes to the national collections may be implemented at the same time as NCAMP2012.

BA4. The Health Identity Project (HIP) development is outside the scope of the NCAMP2012 project.

2.3. Dependencies

BD1. The DHB Merge project is currently planned to be delivered by 1 July 2012. BD2. The Health Identity Project is currently planned to deliver a new HPI and NHI in 2011/12.

2.4. Relevant Facts

BF1. The cut-off date for requests for NCAMP2012 was 1 July 2011. BF2. Final scope of NCAMP2012 was approved 27 October 2011 BF3. Vendor and DHB forum was held on 11 November 2011 to discuss details of changes.




3. NBRS

3.1. Implement validations to improve data quality #19

Description The following new validations are carried over from NCAMP2011. No new business rules are being introduced. The expectation that bookings are reported in this way is longstanding, but the validations have not been in place to enforce them.

Notes NCAMP2011 #48,#49,#97, #106

Refer to Appendix A1 for details of the DHBs likely to be affected by these changes.

Requestor Elective Services, Data Quality

Business Unit NHB

# Condition Error Message Action

1

Out of Scope

Action = Change and

current booking status = Active Review and

staged/planned procedure flag not Normal

Staged Planned or Surveillance procedures cannot have a status of Active Review

Reject

2

Out of Scope

action = Add and

booking does not exist and

booking status = Active review and

staged/planned procedure flag not Normal

Staged Planned or Surveillance procedures cannot have a status of Active Review

Reject

3 Referral date < Date of Birth -238 days Referral date must not be greater than 238 days (34 weeks) before the date of birth.

Reject

4 Date of FSA < Referral date Date of First Specialist Assessment must be on or after the date of referral.

Reject

5 First CPAC assessment date < Date of FSA

First CPAC assessment date must be on or after Date of FSA. (in combination with 4 this will ensure that Referral date is on or before first CPAC assessment date)

Reject

6

Out of Scope

Action = Add (status change) and

booking exists and

Current booking status = certainty, booked, deferred or rebooked and

New booking status = active review

An assured patient cannot be given an active review status

Reject

7

Out of Scope


booking exists and

Current booking status = active review and

New booking status = exit and

Exit category = treated electively

A patient in active review cannot be exited treated electively. Patient must be booked first.

Reject




8

Out of Scope


booking exists and

Current booking status = deferred or certainty and

New booking status = exit and

Exit category = treated electively

A deferred or certainty patient cannot be exited treated electively. Patient must be booked first.

Reject

9 Action=change

Existing Staged/planned procedure flag = staged, planned or surveillance

New Staged/planned procedure flag = normal

Staged planned or surveillance procedures should not be changed to normal

Warning

The in-scope validations described above apply to data submitted on the initial event or a change to a booking. The validations will apply to all bookings added or changes made regardless of any date contained in the record.

3.2. OUT OF SCOPE Allow health specialty and CPAC tool to be updated at the same time #20 (Refer to Appendix B19)




4. NNPAC

4.1. Reject Duplicate Events #40

Description Non admitted patient events are submitted with a purchase unit code (PUC). The purchase unit code describes the event eg Emergency Department Attendance, Diabetes Education and Care, Neurology - 1st Attendance, Oncology - subsequent attendance. There are business rules that govern the counting of events. These are not currently validated in the load which has resulted in multiple events for the same patient, on the same day with the same purchase unit.

This significantly overstates the volume of activity which impacts the price and costing process, IDF payments, electives funding and other ad-hoc analysis of the outpatient data. Multiple events for a patient may be valid for some purchase units but many duplicates are due to errors in reporting, for example a DHB contracts another DHB to provide specialist services and the events are reported by both DHBs when they should only be submitted by one. A DHB may collect events required for their own patient management that do not meet the counting rules for the national collection and are inadvertently submitted to NNPAC resulting in duplicate events eg telephone contact with the patient.

Reports have been regularly sent from Data Management Services (DMS) Data Quality team to DHBs over the past 2 years to correct any duplicate errors but the timeliness of this reporting means the work to resolve the errors is very intensive and is often not complete. The IDF process excludes many duplicates from the IDF calculations but this is not reflected in the NNPAC collection.

The following conditions will be considered a duplicate and will be rejected on the load.

1. Any event with same Agency, same NHI, same PUC and same date that exceeds the number of events allowed in a day for that PUC. See Appendix A5 for the reference list – Maximum Number of Events Allowed in a day by Purchase Unit.

The following was considered but is not practical to implement at this time due to current capability of outpatient systems to report accurate times on all events.

2. Where a PUC is defined to allow multiple events on the same day then any event for a patient with the same purchase unit that occurs within a 15 minute period of an already existing event. (where time of service is submitted on the event)

Limitations:

This does not address the instances where 2 DHBs both submit events for the activity. DMS Data Quality will continue to identify these duplicates and report to both DHBs for resolution. CCTAG have been asked to provide guidelines on which DHBs are to report data in these cases. At present it is an agreement between the two DHBs involved.

This does not address the issue where the same event may be submitted twice under different purchase units.

This does not address the issue where the same event is submitted to both the admitted and non admitted collections.

Notes NCAMP2011 #31

Requestor Funding

Supported by Elective Services, Planning and Analysis, DMS Data Quality, Common Counting Technical Advisory Group

# Requirement

1 Record the ‘Maximum events allowed in a day’ as an attribute of the purchase unit




2 Reject any event with same Agency, same NHI, same purchase unit and same Date of Service that exceeds the max number of events allowed in a day for that purchase unit, considering both events already updated to the datamart and other events in the load file. Exclude all events with an attendance code of DNA (did not wait) and DNW (did not attend) from the validation.

3 Report an error message with identifying details of the duplicate records

# Supplementary Detail

SD1 Facility to record ‘Maximum events allowed in a day’ – default value 99

SD2 All PUCs will have ‘Maximum events allowed in a day’ of 99 applied since their initial start date. In addition the PUCs specified in the list in Appendix A5 will have a ‘Maximum events allowed in a day’ from that list applied from 1 July 2012.

SD3 New Error Message NAP 5059 E

Message: Event exceeds the <max_daily_events> daily events allowed for this NHI <load file nhi/master nhi>, Purchase Unit <puc and description> Date of service <date> and agency <agency>

List for the other events found

“Existing events: “

extract system identifier ,

client system identifier and

pms unique identifier,

facility, (removed by project change request 3529-04)

Example

NAP 5059 E Event exceeds the 1 daily event allowed for ABC1234/ABC1234, M45002 Neurology 1

st Attendance, 21/7/2012, agency 4141.

Existing events : SIOPS, OP, 233667877449SEQQ, 4122

SD4

Start

Step 1 - Is

Max_daily_events=99

End

Step 5 -

Continue

Existing

Validation

Routines

Step 4

Validation Failed -

Produce Error

Message/s

NAP5059E

Yes

Step 3 - Is the count of

events found >

max_daily_events

No

For record type=EVENT

and Attendance Code

not in (‘DNA’,’DNW’)

Start when master NHI,

Funding Agency, date

of service and PUC

have been validated.

No

Yes

Step 2

Select and count all events

on the fact table and the

load file where master NHI,

Funding Agency, Date of

Service and PUC is same

as load file record being

considered and Attendance

Code not in (‘DNA’,’DNW’)

4.2. OUT OF SCOPE Load Outpatient Events from private hospitals or private providers into NNPAC #45 (Refer to Appendix B20)

Formatted: Strikethrough


Formatted: Not Strikethrough




4.3. OUT OF SCOPE Validate event type and purchase unit combinations #46 (Refer to Appendix B21)

4.4. Add new health specialties for GPs/primary care #49

Description To add a new health specialty G01 General Practice so that events delivered in a primary care setting or by a GP in a secondary care setting may be accurately coded when submitted to NNPAC and NMDS.

These events include : Emergency department events in smaller hospitals that are staffed by GPs. Skin lesion removals performed by a GP and funded by the DHB (delivered in primary care or in a secondary care setting) Limitations

Purchase units are created by specialty so the purchase unit rather than the health specialty code is generally used for reporting by specialty from NNPAC. There is some inconsistency in the data between the purchase unit and the health specialty.

Notes

Requestor Common Counting Technical Advisory Group (CCTAG)

Business Unit

# Requirement

1 Add a new health specialty G01 General Practice to the health specialty table in NMDS. This will be updated in the warehouse and available to NNPAC.

2 Impact on casemix is detailed in the casemix document. WIESNZ2012 V1.1.

4.5. Updates required to implement the National Service Framework Library Purchase Unit Data Dictionary (NSF PUDD) Version 17 #52

Description A change in business process means that changes to the NSF PUDD are now approved throughout the year rather than all at once. Maintenance item #13 in appendix D2.2 is to enable the load of approved changes every 2 months. An application has been developed and is currently being tested that enables purchase unit changes to be updated to NNPAC as they are approved. It is planned to be in production by December 2011. (SDG3564 NNPAC Maintenance Release BRv0.05 documents the requirements for the application) When that application is delivered, this requirement will become obsolete. However, a change notice will document the change in process and how NNPAC purchase units changes will be communicated to the data providers in future.

Notes

Requestor Technical Reference Group

Business Unit

# Requirement

1 Assess impact of NSF PUDD version 17 changes

2 Load changes to database and warehouse tables




5. NMDS

5.1. Collect the agency/DHB of the principal purchaser to enable accurate reporting of nested contracting arrangements #28

Description As more procedures are contracted out to private providers, primary care facilities or other DHBs there needs to be a way to accurately report the total volumes being funded by a particular DHB.

A typical way of contracting services is for the DHB funder arm to contract services from the DHB provider arm (example 1). Contracting models are changing and it is common now for the funder arm to contract private hospitals, other DHBs and private providers in the primary sector (examples 2-6 below) to deliver services. The DHB provider arm may also contract services to other providers (example 7). Currently NMDS and NNPAC collect the agency contracted to provide the service, the facility where it took place and the principal purchaser eg DHB MOH ACC etc.

For example Bay of Plenty contract Venturo to provide Urology services at Tauranga Hospital. Currently the data we collect will tell us that the service was provided at Tauranga Hospital by Venturo agency and it was purchased by a DHB but which specific DHB is not collected. At present analysts use the DHB of domicile of the patient or the facility’s location to extrapolate the funding DHB. More than one DHB may contract services from the same private provider so using the provider’s agency or facility to determining funding DHB may be inaccurate.

Examples 4, 6 and 7 are examples where using the DHB of the facility’s location will return inaccurate results.

Currently collected New field from 1 July

2012

# Scenario Agency Facility Principal Purchaser

Funder Agency

1 CapCoast DHB Funder contracts Wellington Hospital (DHB provider) to provide emergency services at Wellington

CapCoast DHB

Wellington Hospital

DHB CapCoast

2 CapCoast DHB Funder contracts Wakefield Hospital (private) to provide orthopaedic services at Wakefield Hospital

Wakefield Wakefield Hospital

DHB CapCoast

3 Otago DHB Funder contracts Oamaru Charitable Trusts to deliver medical outpatient services at Oamaru Charitable Trust facility.

Oamaru Charitable Trusts

Oamaru Charitable Trusts Facility

DHB Otago

4

Auckland and Waitemata DHB

XYZ XYZ DHB Auckland




Funders contract XYZ Medical Centre to provide Skin Lesion Removal Services at the XYZ Clinic

XYZ XYZ DHB Waitemata

5 Bay of Plenty DHB Funder contracts Venturo to deliver urology services to be delivered at Tauranga Hospital.

Venturo Tauranga DHB Bay of Plenty

6 Canterbury DHB Funder contracts Wanganui DHB Provider to do hip replacements at Wanganui Hospital

Wanganui DHB

Wanganui Hospital

DHB Canterbury DHB

7 CapCoast DHB funder contracts CapCoast Provider (Wellington Hospital) who then contracts Wellington After Hours Medical Service to provide medical services at WAHMS.

CapCoast DHB (provider)

WAHMS DHB CapCoast DHB (funder)

8 Capital Coast DHB funder contracts Wellington After Hours Medical Service to provide medical services at WAHMS.

WAHMS WAHMS DHB CapCoast DHB

Highlighted scenarios 2, 3, 5, 6, 8 are being reported in a variable way across the country at present. Where there are funding considerations many DHBs have been reporting the funding agency as the agency. Introducing this new funder agency field will enable DHBs to report both the provider and funding agency of health events.

Notes NCAMP2011 #35

The same requirement applies to NNPAC

Requestor Funding, Finance

Business Unit NHB

# Requirement

1 Collect and report the agency code of the principal purchaser in NMDS and NNPAC

2 New Funder Agency field on the NMDS load file and transactional database, NNPAC load file and warehouse.

3 Report NNPAC and NMDS Funder Agency from warehouse and Business Objects

4 Update the ASE Viewer application to display the new Funder Agency field

# Supplementary Detail

N M D S

SD1 Funding agency will be reported in the new version of the load file v015.0




SD2 Funding agency will be added to the NMDS load file Health Event record, Health Event table in the transactional DB, the warehouse and BO universes

SD3 Funding agency on existing rows on the database will be initialised with the value from the current agency code (provider agency)

This requirement was removed as per change request 3529-03

SD4 Events submitted in a pre V015.0 file will have the funding agency set to the value of the provider agency.


SD5 Funding Agency will be validated as follows

Pu

rch

ase

r

Co

de

Description Funding Agency code Validation Publicly funded

17 Accredited employer Unknown (null) (null) or in the agency table

Y

20 Overseas eligible DHB agency code

In the agency table and agency type = 01 DHB

Y

34 MOH-funded purchase MOH agency code =1236

Y

35 DHB-funded purchase DHB agency code


Y

55 Due to strike

DHB who would have funded the event in absence of a strike


Y

98

Mixed funding where no MOH, DHB or ACC purchase is involved Unknown (null)

(null) or in the agency table

Y

19 Overseas chargeable Unknown (null) (null) or in the agency table

N

06 Privately funded Unknown (null) (null) or in the agency table

N

A0 ACC - direct purchase ACC Agency Code =1237 N

All other Purchaser codes are retired or not in use

SD6 The funding agency will be used to determine if a health event is included in casemix funding.

NN

PA

C

SD7 Funding agency will be reported in the new version of the load file V5.0

SD8 Funding agency will be added to the NNPAC load file event record, the warehouse and BO universes

SD9 Funding agency on existing rows on the database will be initialised as per SD3 above


SD10 Events submitted in a pre V5.0 file will have the funding agency set to the value of the provider agency


SD11 Funding Agency will be validated as in SD5 above




5.2. OUT OF SCOPE Enable private hospitals to report how events have been funded (private insurers or the patient) #29 (Refer to Appendix B22)

5.3. OUT OF SCOPE ACC requirements for contracted private insurers (new purchaser codes) Included as a placeholder only #30 (Refer to Appendix B23)

5.4. OUT OF SCOPE Collect Time in Theatre and Time in recovery for all discharges #32 (Refer to Appendix B24)

5.5. Collect Condition Onset Flag to monitor hospital acquired illness and injury #33

Description “The condition onset flag is a means of differentiating those conditions which arise during an admission from those that were present at the time of admission. A better understanding of those conditions arising during the episode of admitted patient care may inform prevention strategies particularly in relation to complications of medical care. The costs of hospital acquired illness and injury is substantial as they may add 15-20% to the costs of hospital care.” Extracted from NCCH ebook July 2010, Classification of Hospital Acquired Diagnoses.

Condition Onset Flag was included in the ICD10-AM, Sixth Edition. New Zealand upgraded to this edition in 2008 but it was decided at the time to defer the implementation of this new capability. 3M Codefinder can record the condition onset flag but hospital’s clinical data collection processes, Patient Management Systems and the National Collection (NMDS) will need to be changed to collect this data. An initial survey of DHB coding departments by the National Collections Classification and Terminology team indicates that no DHBs have implemented the Condition Onset Flag for their own internal reporting. However Canterbury DHB is in the process of doing so.

Available with ICD10-AM Seventh Edition is the Classification of Hospital Acquired Diagnoses (CHADx) which allows hospitals to track the entire spectrum of unintentional patient harms, both conventional markers of patient safety, along with more ‘mundane’ hospital acquired conditions that have received less attention.

CHADx is primarily intended for within-hospital use rather than for public reporting and it does not currently incorporate risk (or casemix) adjustment to allow facility-level comparisons of rates of these adverse patient outcomes. It allows hospitals to track rates of CHADx over time and monitor trends at a systems level where the patient risk factors can be assumed to be stable.

See Appendix A4 for more details

Notes NCAMP2012 - new

Requestor Communicated by NCR Classification and Terminology – on behalf of Case mix Costweights group and DHBNZ.

Costweights group discussed this in the June meeting and are very supportive of it going ahead at the earliest opportunity

Business Unit

# Requirement

1 Collect the ‘condition onset flag’ on all diagnosis records with a clinical code type= A (diagnosis), B (injury) E (external cause), M (Morphology) or V (supplementary)

2 New field required on the load file and the procedure table of the transactional database.




3 Condition onset flag will be added to the warehouse and Business Objects Universes

4 Update the ASE viewer application to display the Condition Onset Flag

5 Remove from the .sqr file the unused fields - Cancer Basis and Stage, Melanoma level and thickness, Lab Code and report the Condition Onset Flag in their place.

# Supplementary detail

SD1 Condition Onset Flag will be reported in the new file version V015.0

SD2 Some facilities may be exempt from the 1 July 2012 implementation date. A mechanism is required to record by facility, their implementation date of the coding of the Condition Onset Flag (refered to as COF implementation date).

SD3 All historic rows on the Diagnosis procedure table will have the Condition Onset Flag set to 9-not reported. Removed with Project Change Request 3529_08

SD4 Add new field “Condition Onset Flag” to the Input File Diagnosis Record (HD Record) of the NMDS Input File.

Valid values 1 = condition onset during the episode of care

2 = condition onset before the episode of care/unknown

9 = not reported (only for exempt facilities)

For input file version V015.0 For events reported with an event end date less than the COF implementation date the Condition Onset Flag may be 1, 2 or 9. (This will allow events prior to implementation to be sent/resent either coded appropriately or as unreported) For events with an event end date greater than or equal to the COF implementation date the Condition Onset Flag may be 1 or 2. For input file version less than V015.0 For events reported with an event end date less than the COF implementation date the Condition Onset Flag will be set to 9 null on the database.

For events with an event end date greater than or equal to the COF implementation date the event will be rejected with an error message “Event End Date > or = COF Implementation Date, use a file V15.0 or later to report the COF” Where the event end date is not submitted the event start date should be used for the validation.

SD5 Principal diagnosis must should have condition onset flag = 2 condition onset before the episode of care If the condition onset flag is not 2 for a principal diagnosis the event will be rejected with a warning. The event may be re-submitted with an A2 override to accommodate the coding rules required for newborns Ref:Project Change Request 3529_06

SD6 Condition Onset flag will be included on all mappings of clinical code systems

5.6. Annual WIES and Cost Weight Changes #35

Description The New Zealand Casemix Framework 2012 /13 (WIES12 Final V1.1-25112011) is available on the NCAMP website www.health.govt.nz/ncamp. The following changes have been included:

o Three new procedure codes have been added to the Aggregated Gastroenterology Block.

o ERCP (Endoscopic retrograde cholangiopancreatography), Colonoscopy and Gastroscopy exclusions are limited to events with at most three procedure codes. This rule has been further restructured to be independent of the order of procedure coding, and to assign their excluded purchase







units (XPUs) by a cost hierarchy. o Adjusted Skin Lesion Procedures (MS02016) exclusion rule so events

excluded can have at most four procedure codes. o Adjusted Ophthalmology Injections (S40004) exclusion rule to include

events where both eyes have been injected in the same event. o Weight schedule – adjusted low boundary points and introduced one day

weights for AR-DRGs F10B and O01B. Weights for the NZDRGs C03W and J11W have been recalculated to reflect new outpatient pricing for FY 12/13.

o Adjusted the heading descriptions for Surgical Termination of Pregnancy 1st and 2nd Trimester.

o Adjusted Scoliosis rule in Box 1c changed ‘OR’ to ‘AND’ in the second “OR” statement.

o Use the new field Funding Agency in all areas referring to Agency. o Addition of the new health specialty code for General Practice (G01) o Change references to “Information Delivery and Operations Group” to the

new “Information Group”

Requestor Technical Reference Group

Business Unit

# Requirement

1 Detailed requirements provided in the New Zealand Casemix Framework 2012 /13 (WIES12 Final V1.1-25112011)

2 The new Funding Agency field will be used to determine if an event will be included in casemix.

5.7. OUT OF SCOPE Warning Message for events with a length of stay greater than 365 days #53 (Refer to Appendix B25)

5.8. OUT OF SCOPE Enable reporting of event level cost data supplied from the NCCPP SAS database in Business Objects. #56 (Refer to Appendix B26)

5.9. Sector PMS development to incorporate HIP functionality and fields #61

Description Notify sector that any new Patient Management System (PMS) development is to incorporate the new Health Identity Programme web services and/or functionality and/or new fields into DHB B2B interfaces to the NHI and HPI. This will not require any development work within the NCAMP2012 project but will be part of the sector notification and communications.

Notes

Requestor Information Strategy group

Business Unit

# Requirement

1 Communicate above to DHB CIOs and other stakeholders




6. PRIMHD

6.1. Changes to PRIMHD File Specification Document #62

Description The following items are changes to the PRIMHD File Specifications document. They do not require any system development or testing within the PRIMHD application. However items 1 and 2 will impact some NGOs/DHBs. They will need to collect and report patient activities/outcomes not currently being submitted. Reporting of this data will be required of affected NGOs/DHBs to gain NCAMP2012 compliance

Notes

Requestor Barry Welsh

Business Unit SCI Mental Health and Addiction Programmes Data Quality

# Issue Requirement NCR Primhd ref#

1 The reporting of long term in-patient client bed nights every month. Section 3.2.1 step1 page 13 was unclear in regard to those long term clients whose status did not change from month to month.

Change section 3.2.1 PRIMHD XML Extract Processing Step 1, paragraph 2. page 13.to read :

The extracts should include all Referrals and Legal Status XML files where associated data has been added, changed or deleted since the previous extract. Referrals with an open bed night activity record (i.e. Activity Record Type defined as occupied bed days or leave) should also be included in all extracts while the referral remains open. The system can handle re-sending of the same information if the extract periods overlap due to system or operational constraints but it is preferable that this is kept to a minimum. Notify sector and make this a requirement for NCAMP2012 compliance.

File Spec 05

2 The reporting of HoNOS secure and HONOS LD It was always the intention that PRIMHD would collect HoNOS secure and HONOS LD outcome measures. PRIMHD has been set up to handle these two measures and some DHBs are already reporting them. This will clarify to providers that data for the two tools should be provided to PRIMHD.

Document in an appropriate place that HoNOS secure and HONOS LD should be reported. Notify sector and make this a requirement for NCAMP2012 compliance.

(This is only relevant for DHBs, No NGOs will report HONOS Secure and HONOS LD outcomes)

File Spec 06




3 Add error file details

When an XML file fails at the ODS level because of a fundamental XML format error that does not allow processing to continue, eg date with no time portion, then the file is included in the acknowledgement file with a prefix of ERROR. But this error file is not documented in the file specification.

Add to the file specification a description of files rejected with a file prefix ERROR including examples of the kind of errors that may occur in this file.

BA Query 13

4 Use extract date in name of the XML File

The file specification includes details on the XML file naming structure. RYYYYMMDD_<Org_ID> _<referral_ID>.XML and LYYYYMMDD_<Org_ID> _<Legal_status_ID>.XML. While the Org_ID, referral_ID and Legal_status_ID is self explanatory there is no recommendation for what date the YYYYMMDD should be. YYYYMMDD should be the extract date and should be consistent with the zip file within which it is contained. Similarly the zip file name for the PRIMHD extract file is PEYYYYMMDD_<submitting_Org_ID>_nnn.zip. YYYYMMDD should be the date the file was extracted. Extract date, rather than referral date or some other date, is currently used by most organisations and seems the best choice to recommend.

Add to the file specification that the RYYYMMDD, LYYYYMMDD and PEYYYYMMDD should be the date the files were extracted. Pg 17 step 2).

File Spec 01

5 Update XML extract processing steps 6, 7, 8.

The file specification states on page 14,step 6 : "Web Services Interface: A web services interface is planned as an enhancement for a later phase of the project. This will provide a more automated alternative to FTP for data transfer. It will not be available in the first version of PRIMHD on 1 July 2008.4." As there is no existing plan to provide this enhancement, this statement should be removed from the file specification. Steps 7 and 8 describe the PRIMHD online application and should be updated to reflect this.

Make Changes to section 3.2 PRIMHD XML Extract Processing Steps 6-8 page 14 and 15 of the file spec. Step 6 - remove. Update wording of steps 7 and 8

File Spec 02

6 RM-P62-48 “Diagnosis Type in a CN record is not a mental health diagnosis type. It should be type A,B or P. “

This is rejected as an Error but the file spec has it as a warning.

Change the file spec to make RM-P62-48 to be an Error

File Spec 03

7 Add "and delegated DHB Shared Agencies" to Section 2.2.3 Security of Data

File Specification Section 2 Scope Section 2.2.3 Security of Data. Add "and delegated DHB Shared Agencies" so that is now reads : DHBs, NGO providers, and delegated DHB Shared Agencies can also obtain access to their own data through the use of

Sector feedback on V0.09 of this document




Business Objects Desktop Intelligence reporting tools

8 Clarify in the PRIMHD File Spec the requirement for reporting of IP transfers

File Specification Section 2.2.7 - Collection Methods. Add following statement : When clients are transferred between inpatient units within an organisation a new referral should be opened against the team the client is transferred into to show that there has been a transfer of care.


9 Include error processing timeframe expectations

File Specification Section 3 File Processing 3.2.1 Step 5 Acknowledgement Reconciliation will now read : "On receipt of acknowledgment files, the inputting organisation should validate that the extracted items have all been acknowledged and processed correctly. Errors should be corrected and the associated XML files resubmitted in the next extract."


10 Update File Spec 2.2.6 National reports and Publications to reflect current process

File Specification Section 2 Scope -Section 2.2.6 - National Reports and Publications will now read: The MoH has developed a set of standard reports using PRIMHD data and these are available via Infoview. These include Funder and Planner, NGO and KPI reports. The annual Mental Health publications will be populated with information sourced from PRIMHD.


11 Update File Spec section 5 to add reference to HISO data set

File Specification Section 5 PRIMHD Record Types. Add the following in bold before section 5.1. Please also refer to the PRIMHD Data Set document for a full list of the PRIMHD Record Types


6.2. OUT OF SCOPE Last Modified Date does not always update when a referral is re-submitted #63 (Refer to Appendix B27)

6.3. Inconsistency with submission of referral end code, referral to code and referral end date #64

Description There is a gap in the PRIMHD validation business rules. We have business rule BR-P41-13 – "Referral End Code and Referral End Date Time must be supplied when the Referral To field is populated". But, there is no corresponding business rule to say that when a Referral_End_DateTime has been supplied that the Referral_To and Referral_End_Code are required. Consequently, we have some




referrals in PRIMHD that have an End date but do not have a Referral To Code or Referral End Code

The rule will be "If any of Referral End Code, Referral End Date Time and Referral To are supplied then all three fields must be populated"

Notes PRIMHD Online already enforces this rule

Requestor SCI Mental Health and Addiction Programmes, Data Management - Data Quality

Business Unit

# Requirement

1 Change the business rule in the file specification

2 Add validations to ensure reporting of all three fields

6.4. Separate Errors for Activity End, Classification and Collection Occasion DateTimes #65

Description This relates to RM-P42-34 The Referral End Date Time is before the Activity End Date Time or Classification End Date Time or Collection Occasion Date Time. This is too broad and makes it difficult to identify the error in a referral with a number of activities. It also makes it difficult to allocate the error to the appropriate person within an organisation for correction. It should be split into 3 errors, one for each date.

Notes BA Query 11


Business Unit

# Requirement

1 Add separate business rules for each date.

2 Add validations and error messages to be more precise in the error reported.

6.5. OUT OF SCOPE Correct the message for Extracted Datetime Error #66 (Refer to Appendix B28)

6.6. Prevent the creation of duplicate referrals #67 Removed 3529_07

Description NOTE : This change was removed during development phase of the project as a number of sector organisations advised they could not meet the requirement of no duplicate referrals due to internal processes. Produce an error when duplicate referrals are added. A duplicate referral is where the same consumer has more than one referral for the same team at the same time. BR-P41-nn Duplicate referral is a referral with same NHI AND Team Code ID AND (Start Date and End date OR Start and End date overlap another referrals episode) BR-P41-nn A referral can start on the day another one ends.

Notes The prevention of duplicate/concurrent activity is OUT OF SCOPE for NCAMP2012






Business Unit

# Requirement

1 Develop business rules to identify duplicates

2 Add validations to PRIMHD ODS

3 Add validations to PRIMHD Online

6.7. OUT OF SCOPE Alert Users at logon if they have records listed on My Error records #68 (Refer to Appendix B29)







7. Document Control

7.1. Document History

Date Ver. Description of Changes Author(s)

27 May 2011

0.01 Initial Draft for consultation Anne Goodwin

31 May 2011

0.02 Adding Appendix A4 Condition Onset Flag

Editing to Appendix B5 NNPAC loading primary care events

Added appendix D2 NNPAC Maintenance

Added appendix D3 NMDS Maintenance

Anne Goodwin

03 June 2011

0.03 Editing section 5.4 Theatre Minutes

Editing section 4.1 Duplicate NNPAC events

Anne Goodwin

22 June 2011

0.04 Added embedded list to Appendix A5 NNPAC Number of events in a day by purchase unit

Added AppendixA6 Theatre minutes previous years information and survey results

Edited the following sections

3.5 Exclude time patient deferred #23

4.1 NNPAC Duplicates #40

4.2 Outpatient events #45

4.4 New Specialty for GP #49

5.1 Agency of Principal Purchaser #28

5.2 Theatre Minutes #32

5.3 ACC requirements #30

Deferred Redefine Acute/Elective #37

Anne Goodwin

23 June Reviewed by Tony Griffiths

10 July 2011

0.05 Added PRIMD #62 - #68

Edited various sections

Added #58, #59, #60, #61,

Anne Goodwin

14 July 2011

0.06 Edited Appendix C and D

Edited various sections

Anne Goodwin

15 July 2011

0.07 Corrected Appendix C4 PRIMHD Casemix

Update priorities on NCR Requirements log in 1.4

Anne Goodwin

18 July 2011

Reviewed by Dave Berry

3 Aug 2011

0.08 Section 1.4 Replaced NCR Requirements Tracking log V0.07 with Prioritising NCAMP2012 Requests V0.02

Updated D4 PRIMHD Maintenance

Updated D1.2 NBRS Maintenance

Anne Goodwin

12 Aug 2011

0.09 Corrections to sections 5.2 and 5.3 Anne Goodwin

12 Aug Distributed to NCAMP users group for consultation

04 Nov 0.10 These changes address items raised in the feedback received from NCAMP users group and the NCAMP board selection of

Anne




2011 items to be included in scope.

Appendix C – Added Mental Health KPI project information

Section 1.4 Scope defined. Mark all out of scope items and move details to Appendix B deferred requests.

Section 3.1 NBRS Validations Make more explicit and reword to make consistent with current error messages.

Section 4.1 NNPAC Duplicates-added detail

Section 4.4 GP Specialty Added detail

Section 4.5 NSF PUCs Added explanation of new application

Section 5.1 Funding Agency Added Detail

Section 5.5 COF Added detail

Section 6.1 clarified 1, added 7,8,9,10,11

Section 6.6 PRIMHD remove validation for ‘duplicate activity’. Only reject duplicate referrals

Section 6 minor typing corrections

Goodwin

08 Nov 2011

0.10 Distributed to NCAMP User Group before the Vendor/DHB forum

24 Nov 0.10.02

Changes made following internal document review. (mainly formatting and clarification)

30 Nov 1.0 Published with NCAMP2012 Sector Change Notices Anne Goodwin

17 Feb 2012

1.01 Incorporates Change Request 3529-03 (Remove requirement to populate funding agency on historic rows from NMDS and NNPAC) Section 5.1 SD 3, 4, 9 and 10

Incorporates Change Request 3529-02 (Remove redundant fields from NMDS .sqr file and add COF field) Section 5.5.5

Incorporates Change Request 3529-01 (Exclude DNA and DNW from NNPAC Duplicates validation) Section 4.1.2

Anne Goodwin

23 May 2012

1.02 Section 4.1 SD3 Change details reported for NNPAC duplicates error Change Request 3529-04

(No changes required for Change Request 3529-05)

Section 5.5 SD3 Make COF<>2 on principal diagnosis a warning Change Request 3529-06

Section 6.6 Remove the PRIMHD duplicates validation Change Request 3529-07

Section 5.5 SD5 Remove the back populating of COF to 9 on historic records Change Request 3529-08

Anne Goodwin

7.2. Document Contributors

Position Name Action

Business Analyst Anne Goodwin Author

Team Leader, Data Management, National Collections. Angela Pidd Contributor

Senior Analyst,Classification and Terminology Tracey Thompson Contributor

Senior Analyst, NHB, DHB Performance, Elective Services

Sylvia Watson Contributor




Manager, NHB, Analysis Stuart Powell Contributor

Team Leader, NHB, DHB Performance, Funding Mhairi Mchugh Contributor

Elective Services Information Management group Contributor

Common Counting Technical Advisory Group Contributor

Senior Data Quality Analyst (PRIMHD), Data Management, National Collections.

Hilary Sharp Contributor

Principal Technical Specialist, SCI Mental Health and Addition Programmes

Barry Welsh Contributor

Business Analysis Team Leader Tony Griffiths Reviewer

Senior Lead Business Analyst (Acting) Dave Berry Reviewer

Business Analyst Niki Heywood Reviewer

7.3. Associated Documents

Document Name Version Date Signed-off

WIESNZ2012 V1.1 25/11/2011

SDG3564 NNPAC Maintenance Release BR

V0.5

NCAMP12 CR 3529-01 23/12/2012

CR 3529-02 NMDS SQR 1/2/2012

Change Request 3529-03 17/2/2012




Appendix A – Additional Information

A1 Impact of New NBRS Validations - #19

Looking at all bookings in NBRS with an initial CPAC assessment date >= 1 July 2010 the following were found :

Referral Date < Date of Birth AGENCY COUNT

2047 BOP 6

3081 Mid Central 2

3091 CapCoast 2

3092 Hutt 9

4121 Canterbury 6

4Date of FSA < Referral Date AGENCY COUNT

1022 Auckland 4

1023 Counties 1

2047 BOP 14

2051 Tairawhiti 3

2071 Taranaki 10

3091 CapCoast 33

3092 Hutt 7




A2 Principal Purchaser Codes #28, #29, #30

Purchaser Code Description Start Finish

17 Accredited employer 1/07/2000 (null)

19 Overseas chargeable 1/07/2003 (null)

20 Overseas eligible 1/07/2003 (null)

34 MOH-funded purchase 1/07/2007 (null)

35 DHB-funded purchase 1/07/2007 (null)

55 Due to strike 1/01/1999 (null)

98 Mixed funding where no MOH, DHB or ACC purchase is involved (null) (null)

06 Privately funded 1/07/2003 (null)

A0 ACC - direct purchase 1/07/1999 (null)

RETIRED or No longer in use

15 Breastscreen Aotearoa 7/07/1999 30/06/2009

16 Independent Practice Association 1/01/2000 (null)

13 HFA base purchase 1/07/1999 30/06/2007

18 HFA accident purchase - overseas patients non-MVA non-work related 1/08/2000 30/06/2007

10 HFA Northern Office Waiting Time Fund (null) 30/06/2004

11 Supplementary purchase (NB does not include "new money") 1/07/1998 30/06/2004

12 Paediatric purchase 1/07/1998 30/06/2004

14 HFA additional sustainable purchase 1/07/1999 30/06/2004

01 HFA Northern Office (retired 1 July 1999) (null) 30/06/2004

02 HFA Midland Office (retired 1 July 1999) (null) 30/06/2004

03 HFA Central Office (retired 1 July 1999) (null) 30/06/2004

04 HFA Southern Office (retired 1 July 1999) (null) 30/06/2004

05 ACC (direct) (retired 1 July 1999) (null) 30/06/2004

07 HFA Southern Office Waiting Time Fund (null) 30/06/2004

08 HFA Central Office Waiting Time Fund (null) 30/06/2004

09 HFA Midland Office Waiting Time Fund (null) 30/06/2004

A1 FSI - direct purchase, Fusion Insurance Services 1/07/1999 (null)

A2 NZI - direct purchase, NZ Insurance Ltd 1/07/1999 (null)

A3 HIH - direct purchase, HIH Work Able Ltd 1/07/1999 (null)

A4 MMI - direct purchase, MMI General Insurance (NZ) Ltd 1/07/1999 (null)

A5 FMG - direct purchase, Farmers' Mutual Accident Care Ltd 1/07/1999 (null)

A6 @WK - direct purchase, At Work Insurance Ltd 1/07/1999 (null)

A7 CIG - direct purchase, Cigna Insurance Ltd 1/07/1999 (null)




A3 NMDS Events by Purchaser Code

Count of NMDS public and private hospital facility Events by Purchaser Code (as at 17 May 2011)

Privately funded Privately funded Total

Publicly Funded Publicly Funded

Total

Grand Total

06 19 98 15 16 17 20 34 35 55 98 A0 A1 A6

Fin

an

cia

l Y

ea

r

Fa

cili

ty T

yp

e D

escrip

tio

n

Priva

tely

fu

nde

d

Ove

rsea

s c

ha

rgeab

le

Oth

er/

no

t spe

cifie

d

Bre

asts

cre

en

Ao

tea

roa

Inde

pen

den

t P

ractice

Associa

tio

n

Accre

dite

d e

mp

loye

r

Ove

rsea

s e

ligib

le

MO

H-f

un

ded

pu

rcha

se

DH

B-f

un

de

d p

urc

hase

Du

e to

str

ike

Oth

er/

no

t spe

cifie

d

AC

C -

dire

ct p

urc

hase

FS

I -

dire

ct p

urc

ha

se

, F

usio

n

Insu

ran

ce

Se

rvic

es

@W

K -

dire

ct p

urc

hase

, A

t W

ork

Insu

ran

ce

Ltd

2007/08 Private Hospital 68097 48 487 68632 26 109 85 6692 40249 1 19351 66513 135145

Public Hospital 507 3037 3544 692 63 14623 7393 826349 1 60 11296 1 860478 864022

2008/09 Private Hospital 73029 40 555 73624 22 2 102 152 8406 44371 13105 66160 139784

Public Hospital 383 2709 3092 251 69 16601 1617 897868 9 11677 928092 931184

2009/10 Private Hospital 64624 44 475 65143 111 149 6892 41869 13240 62261 127404

Public Hospital 461 3225 3686 83 15970 1514 935581 1 9 11155 1 964314 968000

2010/11 Private Hospital 31183 23 254 31460 73 79 5019 21571 5606 32348 63808

Public Hospital 509 3375 3884 57 17255 1203 793092 1 29 8967 820604 824488

Grand Total 238793 12501 1771 253065 991 2 667 64914 38736 3600950 4 107 94397 1 1 3800770 4053835




A4 Condition Onset Flag #33

NCAMP 2012 Submission – Condition Onset Flag

Prepared by: T Thompson Senior Analyst NCR (4 April 2011)

This submission is to propose that New Zealand adopt the Condition Onset Flag concept and implement as part of NCAMP 2012.

The Condition Onset Flag enables the identification of conditions that were present on admission and that arise during an episode of care.

The condition onset are values are a one (1) or two (2) only:

1 = Condition with onset during the episode of admitted patient care

Condition which arises during the episode of admitted patient care and would not have been present on admission.

2 = Condition not noted as arising during the episode of admitted patient care

A condition present on admission such as the presenting problem, a comorbidity, chronic disease or disease status,

OR

A previously existing condition not diagnosed until the episode of admitted patient care.

Background

1 July 2008 New Zealand upgrade from ICD-10-AM Third Edition to ICD-10-AM Sixth Edition.

ICD-10-AM Sixth Edition included the new concept ‘Condition Onset Flag’ which New Zealand did not adopt at that time.

Adopting the Condition Onset Flag would have required system changes for all DHB PMSs, the NMDS, and clinical coder training; therefore due to the fact New Zealand was upgrading from Third Edition to Sixth Edition, the decision was that this change was too major to include as part of the Sixth Edition upgrade and was deemed to be out of scope for the project.

Since Sixth Edition Australia have further expanded on the Condition Onset Flag and developed a tool Classification of Hospital Acquired Diagnoses (CHADX) to group diagnoses coded in ICD-10-AM combined with the condition onset flag. See Appendix A4.2 for further information.

Purpose

Capturing and reporting the condition onset value for all diagnosis codes would assist in identifying the condition(s) the patient presents to hospital with and would also identify the condition(s) that arise during an episode of care. This may include hospital-acquired conditions, complications from surgery/medical care and injuries etc. See Appendix A4.1 for further information

Currently New Zealand is unable to accurately distinguish between conditions people arrived to hospital with and those they acquired while in hospital.

Over the last few months it has been raised by clinicians, DHBNZ and Ministry business units that there is a need to be able to identify conditions that arise during an episode of care, as the DHBs COO Dashboard contains a number of agreed performance indicators for example hospital acquired pressure ulcers and UTIs.

System Requirements Include:

The condition onset values are preset in the 3MTM CodefinderTM however as New Zealand does not use this function 3MTM HIS has omitted these values from the national upgrades.

To capture the condition onset value for each diagnosis, external cause and morphology code recorded for each event, there will be interface requirements between the 3MTM CodefinderTM and




the DHB PMS. This means an additional field would be required in the DHB PMS to capture and report the value to the NMDS.

The NMDS would also require an additional field in order to capture the value reported on a national basis.

The condition onset value would have to be positioned next to each diagnosis, external cause and morphology code.

Clinical Coder Requirements

Education would have to be provided to all Clinical Coders as it will be their responsibility to assign the appropriate condition onset value for each diagnosis, external cause and morphology code.

Appendix A4.1

AUSTRALIAN CODING STANDARD 0048 CONDITION ONSET FLAG

The condition onset flag is a means of differentiating those conditions which arise during, or arose before, an admitted patient episode of care. Having this information will provide an insight into the kinds of conditions patients already have when entering hospital and what arises during the episode of care. A better understanding of those conditions arising during the episode of admitted patient care may inform prevention strategies particularly in relation to complications of medical care.

Permissible values:

1 Condition with onset during the episode of admitted patient care

Definition

A condition which arises during the episode of admitted patient care and would not have been present on admission.

Examples of inclusions:

• a condition resulting from a misadventure during surgical or medical care in the current episode of admitted patient care.

• an abnormal reaction to, or later complication of, surgical or medical care arising during the current episode of admitted patient care.

• a condition arising during the episode of admitted patient care and not related to surgical or medical care, eg pneumonia, rash, confusion, cyst.

2 Condition not noted as arising during the episode of admitted patient care

Definition

A condition present on admission such as the presenting problem, a comorbidity, chronic disease or disease status,

OR

A previously existing condition not diagnosed until the episode of admitted patient care.

Explanatory notes:

Conditions that have not yet been diagnosed at the time of admission, but clearly did not develop after admission, should be assigned a value of 2. For example, if a patient presents with a symptom which is diagnosed during the admission as a malignancy, the malignancy should be considered to be present on admission.

Examples of inclusions:

• in the case of neonates, the condition(s) present at birth.




• a previously existing condition that is exacerbated during the current episode of admitted patient care.

• conditions that are suspected at the time of admission and subsequently confirmed during the episode of admitted patient care should be assigned a value of 2.1

EXAMPLE 1:

Patient is admitted with acute appendicitis and has an appendicectomy. A wound infection develops in the post operative period and a swab taken grows MRSA.

2 – K35.9 Acute appendicitis

1 – T81.41 Wound infection

1 – B95.6 Staphylococcus aureus

1 – Z06.32 Methicillin resistant agent (MRSA)

1 – Y83.6 Removal of organ (external cause code related to wound infection)

1 – Y92.22 Place of occurrence, health service area(of external cause)

Extracted from NCCH eBook, July 2008, General Standards for Diseases.

Appendix A4.2

CLASSIFICATION OF HOSPITAL ACQUIRED DIAGNOSES CHADx

Data on patient safety performance is an important tool for use by hospitals and others in reducing the rate of hospital-acquired illness and injury. The costs of hospital acquired illness and injury are substantial as they add between 15 and 20 per cent to the costs of hospital care.

The Classification of Hospital Acquired Diagnoses (CHADx) (pronounced 'Chaddix') allows hospitals to track the entire spectrum of unintentional patient harms, both conventional markers of patient safety, along with more 'mundane' hospital acquired conditions that have received less attention.

In 2007, all Australian states and territories agreed to the adoption of a national condition onset flag for diagnoses on inpatient episodes of care, commencing collection in July 2008. Guidance on national condition onset flag assignment has been published in the Australian Coding Standards (ACS) for ICD-10-AM, Sixth Edition.

For application of a condition onset flag of '1', the coder must ascertain that there was no evidence of the condition existing prior to admission, that is, a flag of '1' is used only for a condition arising after admission. This distinguishes incident diagnoses (arising during the current episode of inpatient care) from those treated in a previous episode, or arising in the community prior to admission (a flag of '2').

The Australian Classification of Hospital Acquired Diagnoses (CHADx) uses routinely abstracted hospital data on diagnoses coded in ICD-10-AM, combined with a condition-onset flag of '1', to identify complications across the entire spectrum of illness and injury. The CHADx was designed to provide a basis for the estimation of relative per-case and total expenditure attributable to hospital-acquired complications.

It provides hospitals with a tool to group over 4000 valid diagnosis codes typically used with an inpatient condition-onset flag into a smaller set (n=144) of clinically-meaningful classes for routine monitoring of complication rates.

The CHADx overcomes many of the shortcomings of existing classifications of patient safety events because it covers a broader range of hospital-acquired conditions than other monitoring systems (for instance, variable life adjusted display (VLAD), sentinel events, patient safety indicators (PSIs)). It uses ICD-10-AM, whereas most others have been developed using ICD-9-CM, and it makes use of




'condition onset' information (present on admission versus arising after admission) not available in other routine hospital data sets.

The CHADx is primarily intended for within-hospital use rather than for public reporting, and it does not currently incorporate risk (or casemix) adjustment to allow facility-level comparisons of rates of these adverse patient outcomes. It allows hospitals to track rates of CHADx over time, with timeliness limited only by the turn-around time of patient record abstraction. It gives jurisdictions the ability to monitor CHADx trends at a systems level where patient risk factors can be assumed to be stable.

Development of the CHADx by researchers at the Australian Centre for Economic Research on Health at the University of Queensland was funded by a once-off grant from the Australian Commission on Safety and Quality in Health Care (ACSQHC). The National Centre for Classification in Health (NCCH) in conjunction with the ACSQHC has now aligned the CHADx to ICD-10-AM Seventh Edition and has incorporated this vital information into the electronic version of the classification. This will enable users of the classification to identify the relevant CHADx code(s), or combination of CHADx codes, when associated with a condition onset flag of '1'.

Below is a listing of the 17 major CHADx (M CHADx) categories which include 144 CHADx classes based on ICD-10-AM Seventh Edition, with a condition onset flag of '1'. An expanded list of the CHADx can be found at the Commission's website at

http://www.safetyandquality.gov.au/internet/safety/publishing.nsf/Content/PriorityProgram-08_CostHAD

2

M CHADx 1 Post-procedural complications

M CHADx 2 Adverse drug events

M CHADx 3 Accidental injuries

M CHADx 4 Specific infections

M CHADx 5 Cardiovascular complications

M CHADx 6 Respiratory Complications

M CHADx 7 Gastrointestinal Complications

M CHADx 8 Skin Conditions

M CHADx 9 Genitourinary Complications

M CHADx 10 Hospital-acquired Psychiatric states

M CHADx 11 Early Pregnancy Complications

M CHADx 12 Labour, Delivery & Postpartum Complications

M CHADx 13 Perinatal Complications

M CHADx 14 Haematological Disorders

M CHADx 15 Metabolic Disorders

M CHADx 16 Nervous System Complications

M CHADx 17 Other Complications

2 Extracted from NCCH eBook, July 2010, Classification of Hospital Acquired Diagnoses CHADx.




A5 Number of Duplicates Allowed by Purchase Unit.

This list has been sent to the Common Counting Technical Advisory Group CCTAG before their meeting 14

th June 2011. Feedback received to date is collated within.

Nbr Events Allowed in a Day NSFV16_V0.05.xls




Appendix B – Deferred Requests: Additional Information

B1 NBRS Error messages to reflect current data item names #24

Description Error messages in NBRS are built dynamically from the field name and the NBRS error messages table. The field name reported is the variable name used in the Java code. The Java code variable name does not always reflect the documented name of the data item. Names of data items changed with version 2.5 of the data dictionary and documentation reflected those changes but the Java code variable names were not changed and so the error messages produced still use the old names. The NBRS error messages table also refers to the old name for some data items.

The following excerpt is from the NBRS File Specification V4.2 page 9:

Changes to File and Record Layouts from Version 2.2 to 2.5 (2005)

The field names in this document have been made consistent with those in the NBRS Data Dictionary. This table cross-references the former names with the new names:

Previously known as Now known as

Booking entry sequence Event local ID

Booking facility Facility code

Clinical code system Clinical coding system ID

Clinical code table type Clinical code type

Clinical responsibility group Professional group code

Date file sent to MOH Date sent

Date of referral for first specialist assessment Date of referral

HCU Identifier NHI number

Local booking entry ID Local booking system entry identifier

Local System Health Event Identifier Client system identifier

Version Number File version

The following corrections are required in the NBRS error messages table:

Error ID Current error message Correct error message

1039 The value '%2' in field %1 is not a valid HCU : %3

The value '%2' in field %1 is not a valid NHI : %3

1053

Date file sent is not compatible with the file version number V012.0

Date file sent is not compatible with the file version V012.0

4011

HCU (%1) and HCU (%2) do not identify the same Health Care User

NHI (%1) and NHI (%2) do not identify the same Health Care User

4036 Duplicate booking entry sequence Duplicate Event Local ID




Deferred because

There is considerable effort to change the names in the Java source for this number of data items at once and the effort is not justified at this time. However if any changes are being made to a data item for some other reason the opportunity will be taken to correct the Java code at that time. An example of this was NCAMP 2010 changing the Booking Referral Source to Booking Source.

Notes NCAMP2011 #98

Requestor Solutions Delivery Group

Business Unit Information Delivery and Operations

# Requirement

1 Report error messages that are consistent with the data names used in the data dictionary.

B2 NBRS Enable reporting of all health specialty changes for a booking #25

Description A patient's booking may be initially managed by one specialty but, due to changes in physician, the specialty may change eg General Medicine to Urology. When this happens that patient would move in the ESPIs from one specialty to another. If the days since certainty are over 180 days, changing specialty may have a significant impact on the individual specialty ESPIs results. Changing specialty is allowable and necessary to reflect accurately the history of a patient’s booking. The extent of how often this happens is unknown.

Currently NBRS can not report the history of health specialty changes throughout the booking. In NBRS health specialty is treated as a non-status data item, i.e. it is assumed to remain constant throughout the life of the booking, just as the procedure, purchaser and date of referral. If NBRS treated specialty as a status data item i.e. the specialty is an attribute of a change in status, eg the patient could be given certainty in general surgery but booked in urology, then the history could be reported.

There are two ways that change in specialty could be reported in the ESPIs

A. Report time series using only the latest health specialty. When viewing ESPI performance over the last 12 months a booking would appear under only its latest specialty. This would be consistent with how changes are treated at present.

B. rRport time series using the specialty that applied at that time. When viewing ESPI performance for the last 12 months a booking may appear in one specialty for the first five months and then it would be under another specialty for the next 2 months.

Option B is the preferred option as it accurately reflects the patient’s specialty.

Health specialty changes would need to be made as part of a status-change record.

Changes to DHB systems: Some additional analysis is required to estimate the impact on DHBs. i.e. How many DHBs currently submit health specialty with the status change records? The NBRS load currently ignores it on a status change record. It only accepts it on a non-status change record or the very first event for a booking. It is possible that these DHBs will require no/very little change.

Changes to National Collections: This would be a significant change with new fields required to 2 tables in the transactional database, changes to the load to maintain and validate the new fields, an additional field in the warehouse for initial specialty and the development required to maintain it, and changes to the ESPI calculations to reflect the health specialty changes.

Notes

Requestor Elective Services




Business Unit

Deferred because

This is considered a low priority at this time, but the requestor would like to see the estimated cost of such a change.

# Requirement

1 To receive a warning when health specialty is submitted on a non-status ? change record stating that it has been ignored

2 To submit health specialty only with a status-change record.

3 Report first and latest health specialty in Business Objects universe.

4 Use the health specialty applicable for the month when updating the KPI statistics

B3 NBRS Add ‘suspicion of cancer’ indicator to all bookings #26

Description Add ‘suspicion of cancer’ indicator to all bookings. This would be mandatory for all new bookings and can be changed using a 'change record'.

Definitions of the ‘suspicion of cancer’ indicator are:

D Formal definitive diagnosis of cancer

The referral for specialist assessment identifies that a formal diagnosis of cancer has been made based on histological or cytological findings

S Findings or symptoms strongly suggestive of cancer

The referral for specialist assessment identifies findings and/or patient signs/symptoms that are strongly suggestive of cancer, but does not provide information on a formal diagnosis of cancer being made.

N No indication of cancer The referral for specialist assessment does not provide any indication that the patient has any findings, signs or symptoms that are suggestive of cancer.

H History of cancer The referral for specialist assessment indicates that the patient has previously been treated for cancer.

Notes

Requestor Cancer Team

Business Unit

Deferred because

The suspicion of cancer indicator is most relevant at referral time. Wait time problems for cancer patients are mainly for diagnostic procedures and radiation generally done in an outpatient setting. Until NBRS encompasses outpatient waiting times the usefulness of this indicator is severely limited. See below for the DHB feedback received in NCAMP2010.

DHB/Vendor Feedback on NCAMP10#1

Nelson Marlborough

iSoft #1 (Very Large)

MKM Add new fields (consult iSOFT on new fields' availablility in iPM). Moderate amount of development effort required.

Canterbury PM - This will require changes to our a) referral forms (again) and b) our referral entry screen which is now very tight on real-estate - but I think this is straightforward.

Whanganui Will cost us to add this to our patient management system.

Capital and More analysis of likely impact is required. We had understood that, at present, the




Coast Laboratory provided cancer-related data to the Ministry. What is the expected benefit from capturing/providing this data to MoH Elective Services? Would "H" refer to this referral only, or any history of cancer?

Wairarapa This would be a significant change to our iSoft/Galen PAS and we prefer not to do that but incorporate it into the replacement PAS project instead.

Midcentral No issues with this change

Auckland

Suspicion of cancer field - need further consultation to determine feasibility - need more time to get back to MoH on this (Kamakshi Murthy). Does the CPAC score/Scoring Tool and Procedure code not provide enough information for the ministry to track cancer patients?

BOP

There are likely to be issues about where this information is sourced ? We should not rely on clerical staff who enter the data to make the call. DHBs would need adequate time to change clinical recording process: If this indicator is to be indicated on a GP referral, GPs will need to be advised and educated regarding this change of process. What about referrals to the treatment list from private facilities/other hospitals/internal referrals etc - this information would not necessarily be available at the time the person was entered on to the list. As the information is to be mandatory, we would need a watertight process to educate all medical staff, clerical staff, GPs etc

Hutt Will require new fields in IBA from iSoft. Potentially problematic issues for us. The Suspicion of Cancer field in NBRS because it wasn't clear at what point in the administrative process the suspicion would be available to be reported.

Waikato

Taranaki Support this and note that the relevant CPAC tools must allow for prioritisation of these patients.

Counties Manukau/ Waitemata

NOT Supported. Major Change. Need GP's to include this info in original referrals for assessment. Clerks loading receipt of GP referrals into PMS should not be making clinical categorisation decisions. Suggest investigate as manadatory field in E Referrals project.

B4 NNPAC Extend the list of health provider types #50

Description The valid provider types are currently Doctor, Nurse, Other.

The request to add Dentist to the list of valid provider types was made in order to more accurately record dental events. Currently, if an event with a dental purchase unit is submitted with the provider type of doctor then it is assumed to be dentist. This is of limited accuracy.

Deferred because

The HPI health provider index is under development and will be delivered as part of the identity project. (planned for 2011/12 year) This request would better be considered with the integration of the HPI. There is no evidence that any group is using this field currently for analysis.

Notes

Requestor Funding

Business Unit

# Requirement

1 Add provider type D = Dentist as a valid provider type.




B5 NNPAC Enable the load of publicly funded events previously delivered in secondary care, now delivered in primary care, by the service provider #42

Description Currently if a DHB contracts a private provider to provide outpatient services the DB submits the event on behalf of the service provider eg Venturo events are submitted by BoP. Request is to allow private providers to submit directly to NNPAC. There are likely to be no changes required to NNPAC but a detailed system impact analysis is required to determine this fully. Data Management resources would be required to educate and support the new data providers. As more secondary care services are provided in alternate settings the need for this capability will increase. It will encourage full reporting of secondary care events.

Notes NCAMP2011 #

Requestor Funding

Business Unit

Removed because :

As far as system changes are concerned this is covered by #45 Load Outpatient Events from Private hospitals or Primary Care providers. This request is addressing reporting requirements around events being delivered in a primary care setting. Currently, Electives approach is that for a DHB to be funded for elective services delivered in a primary care setting the DHB needs to report the events to a National Collection. It is considered that any changes to this can be driven by policy work from the business unit. It is unlikely to require system changes.

There is an identified gap in the data available for analysis at a national level where procedures previously done in secondary care setting and now done in primary are not being reported to a national collection. There is no national collection of primary care events but there is much interest in the level of secondary care that will transfer to primary care with the introduction of new primary care initiatives. Consideration needs to be given to how this may be quantified.

B6 NBRS/NMDS/NNPAC Use the HPI to validate agency and facility #36, #58, #59, #60

Description The Health Provider Index will become the standard reference for validating agency and facility and health provider IDs. This is a placeholder for the changes required to convert from using the current reference tables to the new HPI.

Deferred because

The Health Identity Project will deliver a new HPI and NHI over the next 12 months. Organisation and facility IDs will be delivered in the latter stages of the project. Enabling the national collections to receive the new identifiers and validate then against the new HPI will need to be considered during the next year, This request #36 is split into 3 requests #58, #59, #60 one for each of the applications affected. Listed below are an indication of the data items and tables affected.

Requestor Data Management – Identity team

Business Unit IDO

B6.1 Enable NBRS to receive and validate HPI identifiers for agency, facility and health providers #60

Description Listed below are the affected NBRS tables and data items

File / Table Affected data Proposed replacement

Input file Header record Agency code HPI Organisation ID




Input file Booking Record Facility code

Contract Agency

Treatment Facility

Clinical Responsibility

Professional Group

Assessor Code

Assessor Group

HPI Facility ID

HPI Organisation ID

HPI Facility ID

HPI CPN

HPI CPN Registration Authority

HPI CPN


Transactional DB

Batch tab

Agency code HPI Organisation ID

Transactional DB

Booking Entry tab

Agency code

Facility code

Contract Agency

Treatment Facility

InitialClinical Responsibility

Professional Group

HPI Organisation ID

HPI Facility ID

HPI Organisation ID

HPI Facility ID

HPI CPN


Transactional DB

Booking Entry Event tab

Agency code

Facility code


Professional Group

HPI Organisation ID

HPI Facility ID

HPI CPN


Transactional DB

Booking Entry Assessment tab

Agency code

Facility code

Assessor Code

Assessor Group

HPI Organisation ID

HPI Facility ID

HPI CPN


Transactional DB

Facility Scoring System tab

Agency code

Facility code

HPI Organisation ID

HPI Facility ID

Transactional DB

Provider tab

Agency code

Facility code

HPI Organisation ID

HPI Facility ID

DataMart Fact NBR booking snapshot

Agency code

Facility code


Professional Group

Assessor Code

Assessor Group

DHB Code

HPI Organisation ID

HPI Facility ID

HPI CPN


HPI CPN


DataMart Dim Agency Agency code HPI Organisation ID




Facility Facility code

DHB code

HPI Facility ID

DataMart Dim Agency Facility

Agency code

Facility code

HPI Organisation ID

HPI Facility ID

B6.2 Upgrade NNPAC to use the HPI for agency and facility #59

Description Listed below are the affected NNPAC tables and data items


Input file Event record Agency code

Facility code

HPI Organisation ID

HPI Facility ID

DataMart Fact NAP Event Agency code

Facility code

DHB Code

IDF DHB Code

HPI Organisation ID

HPI Facility ID

DataMart Dim External System

DHB code

DataMart Dim Agency Facility Agency code

Facility code

HPI Organisation ID

HPI Facility ID

B6.3 Upgrade NMDS to use the HPI for agency and facility #58

Description Listed below are the affected tables and data items


Input file Header Agency code HPI Organisation ID

Input file Health event Agency code

Facility code

Facility transfer from

Facility Transfer to

HPI Organisation ID

HPI Facility ID

HPI Facility ID

HPI Facility ID

Input File Diagnosis Facility code HPI Facility ID

Input file Psychiatric data Facility code HPI Facility ID

Transactional DB Batch tab Agency code HPI Organisation ID

Transactional DB Provider tab

Agency code

Facility code

HPI Organisation ID

HPI Facility ID

Transactional DB Health event

Agency code

Facility code



Facility type

HPI Organisation ID

HPI Facility ID

HPI Facility ID

HPI Facility ID

Transactional DB Location Code

Location code

Facility type

Transactional DB WIES Agency table





Transactional DB WIES Facility table

Facility code HPI Facility ID

Transactional DB Agency table


Transactional DB Facility table

Agency code

Facility code

HPI Organisation ID

HPI Facility ID

Transactional DB Agency type

Agency type ?

Transactional DB DHB table DHB code ?

Transactional Domicile Code table

DHB Code ?

DataMart Fact Health Event Agency code

Facility code



HPI Organisation ID

HPI Facility ID

HPI Facility ID

HPI Facility ID

DataMart Dim Agency Facility Agency code

Facility code

HPI Organisation ID

HPI Facility ID

B7 NMDS/NNPAC Accountability framework reports as business objects reports #38

Description Accountability framework reports are produced in a variety of ways. Some from SAS extracts from the National Collections and others directly from the National collects Infoview or Business Objects reports. If ALL reports were available as business objects reports then DHBs could see how the results were derived. This would provide consistency and transparency for DHBs.

Deferred because

More appropriate for DHB performance monitoring team to manage this process.

Requestor Canterbury DHB, Planning and Analysis

Business Unit

# Requirement

1 .

B8 NMDS Update to new NZ Country Code and Occupation Code lists #51

Description NZ Statistics department no longer support the versions of the Country Code and Occupation code reference that are used by NMDS. The new code sets use identifiers that are longer than our systems will allow .

Deferred because

There has been one request to add a new country. Item #40 D3.7 provides an interim solution for the requester. It is difficult at this time to justify the size of this work however there maybe a requirement from Stats NZ or an international body that may require the national collection to use the current datasets

Notes

Requestor DMS Data Quality

Business Unit

# Requirement

1 .




B9 NMDS/NNPAC Transfer support and maintenance of the NCCPP Cube into SDG #39

Description Transfer support and maintenance of the NCCPP OLAP based DHB Activity Cost Cube into SDG

Deferred because

At this time the cube will remain within the Planning and Analysis Team. Consideration maybe given to migrating it to SDG in the future.

Notes Depends on the outcome of capital bid C3 item #34

Requestor Planning and Analysis

Business Unit

# Requirement

1 .

B10 NNPAC/NMDS Have national IDF prices available in datamart for reporting #31

Description Currently the national IDF prices are not contained within the datamart but are often needed for analysis by MOH and DHB analysts. These are kept in a spreadsheet format and sent to DHBs on request. This is to be made available in the datamart to enable reporting financial impact of events in NNPAC and NMDS. It would be loaded annually recording the NSF version that the prices apply to and the dates that the price is valid for. The Funding team will supply the datamart with historic data for prices since 2006/07. Prices are finalised in late December for the following financial year eg Dec 2010 the prices for 20011/12 are set using the purchase units agreed for the 2010/11 year. Some adjustments are required when purchase units change from one year to the next. This would require a mechanism to make corrections to prices already loaded.

Excerpt from the current file.

pu_code pu_name Final 1011 prices

AH01001 Dietetics $ 114.99

AH01003 Occupational Therapy $ 139.85

AH01004 Orthoptist $ 192.76

AH01005 Physiotherapy $ 72.29

AH01006 Podiatry $ 132.22

AH01007 Social Work $ 146.46

AH01008 Speech Therapy $ 157.33

BSA-70 Breast Screening Treatment-Oncology -Chemotherapy $ 926.20

CS01001 Community Radiology $ 65.39

Notes NCAMP2011 #98


Business Unit

Deferred because:

It was decided to place the price lists in a common place on the MOH website, possibly the National Service Framework Library at this time. The expected cost to incorporate this in the datamart outweighed the anticipated benefit at this stage. This will be reviewed next year and maybe included in a subsequent maintenance release.

# Requirement

1 Business rules - TBD

2 Reporting requirements - TBD




B11 NMDS Redefine the acute, arranged, elective admission types to deferrable, non-deferrable #37

Description This is a placeholder for a Common Counting Technical Advisory Group item of work to review the long held discussions on the accuracy and consistency of reporting the admission type on inpatient events. CCTAG will review the issues and give recommendations. These may require changes to NMDS and/or definition of terms.


Requestor Common Counting Technical Advisory group

Business Unit

Deferred because:

CCTAG have not completed to work to be able to provide this request. It is expected to be put forward to NCAMP2013

# Requirement


2 Reporting requirements - TBD

B12 NBRS Future Requirements to be detailed by Elective Services during June #21

Description This is a placeholder for changes required as a result of the Report of the Office of the Auditor General.

Deferred because

This will be considered in the context of wider changes to NBRS that are currently being proposed and scoped.

Notes NCAMP2012 - New


Business Unit

B13 NBRS Add a new status ‘Waiting diagnostics’ #22

Description This new status would quantify the number of patients who are waiting for a diagnostic test to confirm their priority for treatment.

Deferred because

This will be considered in the context of wider changes to NBRS that are currently being proposed.


Requestor DHB’s via Elective Services Information Management Reference group (ESIM)

Business Unit

# Requirement

1 Add a new status 08 Waiting Diagnostics

2 To report the ICD10 code for the diagnostic test the patient is waiting for.


4 Effect on ESPIs - TBD

B14 NBRS Exclude from performance measures the length of time that a patient has requested a deferral of treatment. #23

Description Over the last 12 months elective services have had a particular focus on getting long wait patients treated and off the waiting list. DHBs are having difficulties with




achieving the ‘zero patients waiting over 6 months’ target where patients have requested a deferral of surgery for personal reasons. Some DHBs have solved this by referring the patient back to primary care with a fast-track return process when they eventually become available. These situations predominately happen in areas with seasonal work (for example dairy farming and oyster harvesting where the patient wants to use the off-season for surgery and recovery). If the patient returns to primary care and the booking is exited due to changed patient circumstances a national view of this group of 'waiting' patients is lost. The patient is then added back on to the waiting list as a new booking, which distorts the real wait time the patient has experienced.

DHBs have requested that where patients have requested a deferral of treatment that the time deferred be excluded from the calculations to determine long wait patients and Elective Services Performance Indicators, ESPIs.

For example. A patient is given certainty on 1 March and booked for treatment on 1 May. On March 30 the patient requests a deferral of treatment until July. The Patient is deferred and then rebooked and treated on the 30 August. The period from March 30 to 1 July (91days) would be excluded from the total waiting assured days. This result would be the patient waited 92 days rather than 183 days.

This request is yet to be agreed by Elective Services and would require policy development around inclusion or exclusion from performance indicators.

Further analysis is required to quantify the number of patients/bookings affected by this. Elective services are working on this.

Deferred because

This will be considered in the context of wider changes to NBRS that are currently being proposed and scoped.


Requestor DHBs via ESIM

Business Unit

# Requirement

1 Add a new KPI = Number of patients with a commitment to treatment waiting more than 6 months excluding any days deferred by the patient. This would have the same criteria as KPI 78 but with the patient deferred days excluded.

2 Add calculated fields to the datamart

Days deferred by patient

Days deferred by hospital

3 Change ESPI reports to replace KPI=78 Number of patients with commitment to treatment waiting more than 6 months to use the new KPI in 1 above.

B15 NMDS Collect data required for Medicine Reconciliation measuring and reporting framework

Description Medicine Reconciliation has been demonstrated to significantly reduce medication errors that occur at transition points of care (admission, transfer, discharge).

The goal is to complete the medicine reconciliation process for all patients at each transition point within 24 hours of admission, transfer and discharge within and from secondary care.

Deferred because

Work continues to finalise the requirements for the 2012 health target. It is expected that data for the first year of the target will be submitted by DHBs in a summary form and consideration will be given to possibly capturing this at event level on NMDS and to calculate the target results from NMDS from 2013.

Notes




Requestor Health Quality and Safety Commission, SCI

Business Unit

# Requirement

1 To Be Defined ?

B16 NMDS Additional Maternity related data items on birth and mothers events

Description

NCAMP2011 Request Number 29

What is the Problem/Requirement?

NMDS - for pregnancy/maternity events only, the addition of the following fields to the NMDS extract from the Health Event records sent to the MoH. 1. Parity (mother's record) 2. Gravida (mother's record) 3. Apgar score @ 5 min (baby's record) 4. Delivery Date (mother's record) 5. Estimated Delivery Date (EDD; mother's record) This data is currently collected by hospitals (i.e. at the DHB level) but there is no mechanism in place to provide a standardised national view of this information. Two very clear Government priorities are to 'improve data for better monitoring of maternity' and to increase the length of postnatal stays, in particular for new/first-time mothers. These fields are important in order to provide evidence to support the success of the policy implemented by the Minister of Health in 2009 and also any policy implemented by the Ministry of Health relating to either the Mother or Baby.

Collection NMDS

Main Contact Glenda Oben, Simon Ross, Caroline Greaney, Rosemary Simpson

Driver

This is a key priority for the Minister. The Minister has directed the Ministry to have better data for monitoring maternity services within the next 12 months.

These fields are vital pieces of the maternity picture. They provide the most information in order to successfully target and monitor new initiatives/policy.

This information is also useful to people external to the MoH, including the Perinatal and Maternity Mortality Review Committee (PMMRC) and researchers.

Currently the MoH only receives this information for a limited number of births (being those births where a LMC makes a claim). Information is not available about births where there is no claim for LMC services (including those attended by DHB midwives).

Reporting this information to NMDS would improve the consistency, quality, coverage and accessibility of this information for Ministry and external users.

Benefit

Ability to report on new/first-time mothers which is key for the monitoring the intended benefit of any new policy implemented by the Minister of Health.

Consistency across the maternity data sources




Deferred because

There are two projects currently underway which involve expanding and improving Maternity data within the Ministry; the Maternity Datamart Rebuild Project, which is due to close end ofJuly 2011, and the DHB Primary Maternity Data Project, which recently received Capital Bid approval. Upon completion of these projects, National Collections and Reporting (NCR) will have access to all of the proposed NCAMP Maternity fields with high levels of coverage. At this point it would be redundant to collect this data in NMDS, would represent an unnecessary reporting burden on DHBs, and would reflect badly on the Ministry for collecting the same information twice. Keep the following four fields on the table for NCAMP13 or beyond - as a back up in case project work is not completed to schedule; Parity (mother's record) Gravida (mother's record) 5 minute Apgar score (baby's record) Delivery date (mother's record)

Notes

Requestor Analytical Services, SCI

Business Unit

# Requirement

1 To Be Confirmed




B17 PRIMHD requests deferred at this time

Primhd reference# Description Reason Deferred

1 BA Query 17 Check on the ODS processing directories to report on any zero length files found

Needs further investigation

2 BA Query 19 Stop superfluous rows being created in legal status master


3 BA Query 20 Report to be used to ensure the Data Mart is reconciled to source


4 BA Query 09 Reword error message for referral start date Very low priority

5 BA Query 01 Add a validation on the file version Will revisit when there is a change in file format.

6 BA Query 18

Add a column to SHO.TEAM_TYPE to indicate whether the team is allowed dual diagnosis (the team type desc indicates this currently)

Requires further investigation

7 Enhancement 28 Default activity record for referral May compromise data quality

8 Enhancement 29 Ability to add more than one activity record at a time

This additional functionality seems reasonable but low priority at this time

9 Enhancement 30 More meaningful release version details in PRIMHD Online

Useful enhancement but low priority at this time

10 PRIMHD ODS PIR 21

Websphere upgrade to version 7 for next major PRIMHD release.


11 PRIMHD ODS PIR 22 Java executing XLS macros


12 PRIMHD ODS PIR 23 Java use of ODBC


13 PRIMHD ODS PIR 24 Application deployment model is overly complex


14 PRIMHD ODS PIR 25 File loading Java application


15 PRIMHD ODS PIR 26 Crashed java application.


16 PRIMHD ODS PIR 42 Hibernate framework upgrade



Need to increase size of container that PO sits on.


18 PRIMHD ODS PIR 18 Startup failure – whoever comes second



Teams # compliance and production out-of-sync (automate) Low priority

20 PRIMHD ODS PIR 05 Inadequate design of PRIMHD ODS

Outside scope of maintenance


Change Data Warehouse Full Extract to incremental

may be resolved adequately with PRIMHD ODS PIR 03

22 PRIMHD ODS PIR 28 Display open referrals only to NGO users



Adjustment of 100 search results limit (can be included in #28)



Ability to set personalised filters and default search/sort order for NGO users (can be included in #28)





25 PRIMHD ODS PIR 33 Audit trail of changes made to PRIMHD Online



Message of the day upon login to PRIMHD (Very low Priority) Very low priority


Present a user-friendly "System current unavailable" message Very low priority


Display of a progress bar to show the application is working would be useful Very low priority

29 PRIMHD ODS PIR 10 Hover functionality - 3 issues Very low priority


Tab from activity date field causes cursor focus to randomly shift to top of page. Very low priority

B18 PRIMHD requests retired

PRIMHD reference# Description Reason

1 BA Query 10 Relaxing the legal status end date validation to be the day after death.

No intention of ministry to change the BR on legal status end date

2 BA Query 16 New BO object to group T-codes into inpatient, alcohol and drug No longer required

3 BA Query 23 Add to BO the ICD10 mappings of DSM-IV diagnoses No longer required

4 Enhancement 12 Error and Duplicate Zip Files should not be displayed on Reconcile Batch Load screen Functionality not used

5 Enhancement 18 Remove Activity Setting Code CR from dropdown to discourage use Included in HISO requests

6 Enhancement Add Organisation ID to search criteria fields on Reconcile Batch Load

No longer required. Hilary to confirm

7 PRIMHD ODS PIR 11

Provider ID does not allow values that begin with zero.

Resolved with a CASD- unlikely to recur

8 PRIMHD ODS PIR 13

Unable to remove activity end date & time fields from existing activity record.

Work around will be described in training manual

9 PRIMHD ODS PIR 17 5:00am Break Put in training manual


Ability to submit data per NGO rather than per referral.

Outside the intention of Primhd online design


Ability to add activity records without being in edit mode for the referral

Resolved with improvement in performance

12 PRIMHD ODS PIR 44 Small Batch Process (Same as #36)

Outside the intention of Primhd online design

B19 NBRS Allow health specialty and CPAC tool to be updated at the same time #20

Description Health specialty and CPAC tool changes that occur after a booking has been added to NBRS are submitted on 2 different kinds of records. Where a change in health specialty also requires a change in the CPAC tool the validations result in neither change being allowed. The conflict develops where the specialty cannot be changed without first changing the CPAC, but to change the CPAC the specialty




needs changing. The work-around for these situations has been to erase all the events for a booking and add it back using only the new health specialty. This requires significant effort for DHBs to resolve and support, and education by DMS and can result in some loss of data. This request is to use the health specialty submitted on a status-change record to validate the CPAC tool code.

Consideration was given to restricting the change in health specialty to only reassess status change records. However validations already exist around what CPAC tools are allowed within specialties, and this restriction would only limit that validation process.

Notes NCAMP2011 #50


Business Unit NHB

Deferred because

Insufficient resources to deliver within the NCAM2012 budget

# Requirement

1 Continue to allow health specialty to be submitted on a change record

2 To optionally submit health specialty on a status-change record for bookings that already exist.

3 Use the submitted health specialty on status-change records to validate the CPAC tool.

4 Update the health specialty of the booking if it is submitted on a status-change record

B20 NNPAC Load Outpatient Events from private hospitals or private providers into NNPAC #45

Description Private hospitals currently report inpatient events to the Inpatient National Data Collection NMDS. Currently if a DHB contracts a private provider to provide outpatient services the DB submits the event on behalf of the service provider eg Venturo events are submitted by BoP. This request is to allow private providers to submit directly to NNPAC. As more secondary care services are provided in alternate settings the need for this capability will increase. There are likely to be minimal changes required to NNPAC but detailed requirements and system impact analysis is required to confirm this. The allocation of domicile when the sent domicile is not valid may be impacted. Data Management resources would be required to educate and support the new data providers. There are currently about 300 private hospitals submitting inpatient data. 70 to 100 of these are private surgical hospitals. There are potentially about 15 hospitals likely to provide outpatient data initially if requested although at this point we have not engaged with private hospitals to determine this. There are in addition small private providers that provide outpatient services that are not currently engaged with the private hospital team because they are not contracted to provide inpatient services for any DHBs. Limitations Is the existing purchase unit structure sufficient for reporting? There is no legal obligation for private providers to provide data on publicly or privately funded outpatient events to the National Collections. Currently the DHB usually reports the DHB funded outpatient events done in private settings.

Notes NCAMP2011 #40





Deferred because

Insufficient resources to deliver within the NCAM2012 budget. As this does not directly affect DHBs this may be delivered in another maintenance release.

Business Unit

# Requirement

1 System Impact of private providers submitting files to NNPAC

2 Where the domicile code submitted by the provider and the domicile code from the NHI are invalid and the DHB of the provider (in the External System table) is null then reject the event.

B21 NNPAC Validate event type and purchase unit combinations #46

Description There is no validation to ensure consistency between Event Type – OP, ED, CR and the purchase unit code. Prior to NCAMP2010 the event type was derived from the purchase unit code. Since NCAMP2010 it is a mandatory field to be submitted by DHBs.

The following validations are proposed

Event type ED emergency – All purchase units starting with ED

Event type CR community referred – All purchase units starting with CS

Event type OP Outpatient – All purchase units not starting with ED or CS

There is a concern that this validation maybe too restrictive. Eg where an event in the ED is reported as a MS01001 Nurse led clinic because no clinician is involved then the event type should be ED.

The following discrepancies were reported as at 20 June 2011. Many of these have since been corrected.

AGENCY PURCHASE UNIT DESCRIPTION

EVENT TYPE YEAR

COUNT of events

Bay of Plenty CS01001

Community Radiology OP 2010/11 15900

Otago CS04001

Community referred tests - cardiology OP 2010/11 671

Wairarapa CS04001

Community referred tests - cardiology OP 2010/11 225

Bay of Plenty CS04003

Community referred tests - audiology OP 2010/11 746

South Canterbury CS04003

Community referred tests - audiology OP 2010/11 417

Wairarapa CS04008

Community referred tests - respiratory OP 2010/11 201

Clutha Health First ED02001

Emergency Dept - Level 2 OP 2010/11 159

Oamaru Charitable Trust ED02001





Dunstan Charitable Trust ED02001


Southland MS01001

Nurse Led Outpatient Clinics ED 2010/11 259

Notes NCAMP2011 #32

Requestor DMS Data Quality

Business Unit

Deferred because

Feedback from the consultation on V0.09 of this document was theat this validation was considered too restrictive and of little benefit. Many of the above errors have been corrected and data quality (DMS) will continue to monitor.

# Requirement

1 Business rules - Validation above unless more flexibility is required

B22 NMDS Enable private hospitals to report how events have been funded (private insurers or the patient) #29

Description Privately funded secondary care events are collected from private hospitals and make up about 6% of NMDS annual events. Private hospital events up until Dec 2010 have been loaded into NMDS. This data allows policy and strategy to analyse the overall NZ demand for secondary care in-patient services. Analysis of the individual vs private insurance vs public funding contribution would provide valuable information for assessing the impact of various funding frameworks in the future.

Currently private hospitals report if the event is privately funded (principal purchaser code = 06 Privately Funded) or ACC funded (principal purchaser code = A0 ACC-direct purchase). But there is no visibility into whether the privately funded events are funded by a private insurance company or paid for by the patient.

This request is to collect the principal purchaser as reported by the patient.

Limitations

There is no legal requirement for private hospitals to submit data to the national collection so we can only request this additional information. However, any additional information, even if incomplete, is seen as very valuable by the policy and strategy team.

We can only use what is reported by the patient. Although it is likely the private hospital has accurate data on who is paying for the service there are instances where the patient may pay the hospital in full and seek reimbursement from the insurer later.

Only the principal purchaser would be collected. This request does not address the issue of multiple parties sharing the cost of treatment.

Consideration may be given to identifying the major private insurers. This will be considered when detail requirements are collected.

As yet we have not assessed how available this data will be from private hospitals.

Notes NCAMP2012 – New

The same requirement applies to NNPAC

Requestor Policy Strategy




Deferred because


Business Unit

# Requirement

1 Report the principal purchaser of the private hospital events as reported by the patient

2 Retire purchaser code 06

3 Add new purchaser codes

40 Privately funded, Purchaser not identified

41 Patient funded

42 Private Insurance

4 Report the agency code of the purchaser where the purchaser is Private Insurer. (May depend on the implementation of item #28)

B23 NMDS ACC requirements for contracted private insurers (new purchaser codes) Included as a placeholder only #30

Description The government is in the process of consulting on the possibility of extending the employer involvement in ACC’s Accredited Employers Programme (AEP) and introducing competition to the delivery of the ACC Work Account.

A number of new purchaser codes would need to be added to the purchaser code table so that DHBs could record which insurer the patient was covered by.

Should the government proceed with this item a more responsive process may be needed to add new insurers as they are approved by ACC. Currently new purchaser codes can only be added in an NCAMP release. Appendix A2 lists the existing purchaser codes.

Notes NCAMP2012 – New

The same requirement applies to NNPAC and NBRS

Requestor Data Management

Business Unit

Deferred because

Requirements for this change have not been confirmed and so will not be delivered within the NCAMP2012 project.

# Requirement

1 May need to retire A0 ACC and replace it with a new code.

2 May need to add new purchaser codes for non ACC insurers.

3 Consider updates required to the NMDS table ‘non public purchaser’ which lists the purchaser codes considered as not publicly funded.

B24 NMDS Collect Time in Theatre and Time in Recovery for all discharges #32

Description Collecting the Time in Theatre has been requested for the past 2 years in NCAMP2010 and NCAMP2011. Demand continues for the collection of this data at a national level. Analysis and Planning require this to inform their work on readmission rates and cost of failed surgeries. Auckland DHB at the May National Costing Collection and Pricing Programme (NCCP) forum identified the lack of theatre data in NMDS as a gap in the national dataset that could inform analysis in the area of theatre productivity.




Elective services has granted funding to 8 DHBs to implement The Productive Operating Theatre (TPOT) programme and has developed a number of productivity measures that DHBs will be submitting at a summary level to Electives for monitoring theatre productivity from July 2011. These measures require DHBs to provide data that could in a large part be satisfied by this request. The Health Safety and Quality Commission are in the very early stages of considering a National surgical site infection surveillance and response programme. Theatre data is a crucial part of this work.

Option 1 – Collect for all inpatient events

Total theatre minutes This would be the sum of all theatre-in to theatre-out times for all theatre sessions that occurred during the patient's admission to hospital.

Number of theatre sessions This would indicate the number of times the patient went to theatre during their hospital admission. This allows any analysis to exclude admissions where the patient has had more than 1 theatre session which might distort results.

Option 2 – Collect for all inpatient event theatre sessions

Theatre session ID This allows linking of the procedure data and the theatre data. It may be an ID from the DHB theatre module or it could be a combination of Theatre ID and Theatre Start Datetime.

Theatre ID Identifier for the actual theatre where the operation took place.

Theatre-In datetime Time the patient enters and leaves the theatre. This theatre-in/out time is probably of a more reliable quality than knife-to-skin, although knife-to-skin and skin-close is more widely collected. It maybe that it is sufficient to collect either theatre-in and out OR Knife-to-skin and Skin-closure.

Theatre-Out datetime

Recovery-In datetime These were identified by electives in 2010 as important for theatre productivity analysis Recovery-Outdatetime

Theatre Specialty The specialty of the surgeon. This would be necessary because the surgeon specialty varies significantly from the discharging specialist collected with the health event.

Surgeon ID DHBs have had issues around collecting these identifiers which would need to be addressed. Anaesthetist ID

Knife-to-skin datetime These items are of interest to surgical site infection (SSI) surveillance and maybe considered for inclusion if Health Quality and Safety Commission pursue any level of national collection of data in this area. They are in the early stages of investigation of a national SSI surveillance and response programme

Skin-closure datetime

Prophylactic antibiotic

type,

dose,

time of administration

time of repeat dose

Skin Preparation

Although option 1 provides for some high level analysis it is not enough to provide the




basis of monitoring theatre productivity or efficiency. Option 2 allows for more detailed analysis enabling productivity monitoring and comparison of times for particular procedures. Additional data on planned, resourced and allocated theatre time is necessary for theatre efficiency monitoring.

Notes NCAMP2011 #3, #45

Requestor

Business Unit

Deferred because


# Requirement

1 Option 1 To enable reporting by patient the time spent in theatre from ‘theatre in to theatre-out’ (or ‘knife-to-skin to skin-close’) for each visit to theatre. This requires the addition of total theatre minutes and number of theatre sessions on the health event (HE) record submitted, NMDS health event tables in database and datamart and in BO Universes

2 Option 2 To enable reporting by patient the time spent in theatre from ‘theatre in to theatre-out’ (or ‘knife-to-skin to skin-close’) for each visit to theatre. An inpatient event may include multiple theatre visits. A patient may have more than one theatre visit in a day. A theatre visit may include multiple procedures.

This requires

A new record type, theatre session data (HT) in the NMDS load file, a new table in the database and datamart and appropriate changes to BO Universes.

Information from Previous NCAMP Requests for Theatre Minutes #32

NCAMP2011 Request No 3

What is the Problem?

District Health Boards (DHBs) are currently unable to provide data on the length of time patients are in surgery (theatre minutes), via the NMDS collection. This data is currently collected at the DHB level but there is no mechanism in place to provide a standardised national view of this information.

Proposed Requirement

National data on Theatre Minutes: This update to NMDS introduced would be the inclusion of total theatre minutes in the NMDS input file from the health event record. This will be for the total theatre time (patient in to patient out) as opposed to skin to skin or anaesthetic minutes. If a patient has more than one visit to theatre during an event then the values should be summed to a total time for that event. This requirement will enable District Health Boards (DHBs) to provide data on length of time patients are in surgery (theatre minutes), via NMDS collection. This data is currently collected at the DHB level but there is no mechanism in place to provide a standardised national view of this information. As one of the Government’s main priorities is improving access to elective surgery, the Minister of Health has requested the theatre minutes data to provide evidence to support policy aimed at achieving this Health Target.

Main Contact Geoffrey Thompson/ Sylvia Watson




Driver

Minister's desire to understand theatre productivity and to enable the modelling necessary for implementing the Government's policy regarding additional dedicated elective surgical centres.

Benefit One source of information on theatre productivity and utilisation. Will allow theatres to be modelled in the same manner as beds are a present.

Effort to do the Work

High

Risk if we don't do the work

Major

Impact on Sector Significant due to lack of integration/connectivity between PMS and theatre modules in most DHBs

Likely Sector Response

Some resistance is expected as DHBs often do not have their theatre systems integrated onto their main PMS systems. However, DHBs are apparently supplying detailed theatre information already to the Health Round Table.

ID & Sector Services Activities to Implement

Include theatre minutes in the file specification, validate and load and include in the datamart with appropriate changes to BO universes.

Sector change YES

Sector Activities to Implement

Harvest data from theatre systems and include on the NMDS file.

Recommend in scope for 2011 (Yes/No)

YES

Survey results of timestamps collected by DHBs (2010)

All DHB theatre time stamps v2.xls

Theatre Minutes Memo + brief .doc

B25 NMDS Warning Message for events with a length of stay greater than 365 days #53

Description Events with a length of stay (LOS) greater than 365 days are excluded from case weights. Where dates are entered incorrectly on an event and the resulting length of stay is greater than a year these events are excluded from costweights. Data quality do periodic checks to identify these and suggest to DHBs to check that the dates are correct but it would be more effective to reject these with a warning on the load so that the DHB can verify and correct any errors promptly. The validation would not apply to residential care and mental health specialties i.e. those specialties starting with D or Y. If the event health specialty code does not begin with a D or a Y and the LOS >365 days and the record is loaded with an A1 action code then return the record with a warning asking for the LOS to be checked for this very long event. If the record is




submitted with an A2 action code then this warning is ignored and the record is loaded.


Requestor Casemix Cost Weights Group

Business Unit

Deferred because


# Requirement

1 Add validation

If Length of Stay > or = 365 and

Health Specialty does not begin with D or Y and

Message Function = A1

Reject the event with a warning message

“Event dates indicate a length of stay greater than or equal to 365 days”

(note that a message function of A2 will result in the event being loaded)

B26 NMDS Enable reporting of event level cost data supplied from the NCCPP SAS database in Business Objects. #56

(An interim measure until the National Costing data is available as a national collection - refer to appendix C3 Item #34)

Description This request would provide immediate benefits of enabling the view of cost data from the NMDS Business Objects universe with no impact on DHBs. It is proposed as an interim measure until item #34 is delivered (i.e. “Transfer the collection and reporting of National Costing data from the NHB Planning team to an SDG supported National Collection.”)

DHBs have submitted cost data to the NHB Planning and analysis team for years 2004/05 to the present. It is maintained in a SAS database that contains event level activity and cost data. Currently DHBs submit this data annually but this will be a 6 monthly submission which may reduce to a quarterly submission but not beyond that.

This request is to provide a feed of data from the Costing data SAS database to NMDS to be made available in the NMDS Datamart. This data feed could be received into a transactional database in a format that would eventually be submitted by DHBs to Data Management Services or consideration could be given to feeding this directly into the datamart.

Notes NCAMP2012 – new

Consider in conjunction with #34 in appendix C3.

Requestor NHB Analysis tem

Business Unit

Deferred because


# Requirement

1 Warehouse to receive a file from national cost data that contains event level cost data to be reported on NMDS

2 Update Business Objects Universe to include the cost data elements against each health event




B27 PRIMHD Last Modified Date does not always update when a referral is re-submitted #63

Description Sometimes when an existing referral record is updated (for example to add new activity records) and the referral is re-submitted to PRIMHD for processing, the Last Modified Date does not get updated (even though the update was successful). This causes confusion to users who are sometimes unsure if the update was successful, or who use the Last Modified Date as an indicator of the last time they modified the record.

Notes PRIMHD ODS PIR 12


Business Unit

Deferred because


# Requirement

1 Investigate and fix error

B28 PRIMHD Correct the message for Extracted Datetime Error #66

Description This relates to RM-P42-08 "The mandatory data element Extracted Date Time has not been supplied in the RD record." The system is reporting a message "The mandatory data element Extract To Date has not been supplied in the RD record." This should be corrected to reflect the file specification.

Notes BA Query 12


Business Unit

Deferred because


# Requirement

1 Correct the error message produced for RM-P42-08

B29 PRIMHD Alert Users at logon if they have records listed on My Error records #68

Description

This refers to PRIHD Online. Currently users need to click on the My Error Records tab to see if they have any errors listed that need to be addressed.

This could be improved by one of the following

1. Opening the my error records tab automatically if errors are present

2. Make the colour of the My Error Records tab green to indicate no errors and red to indicate there are errors.

3. Display a message to alert the user if errors are present

Notes PRIMHD ODS PIR 35


Business Unit

Deferred Insufficient resources to deliver within the NCAM2012 budget




because

# Requirement

1 Add capability to logon process of PRIMHD Online




Appendix C – Additional Information: Capital Expenditure Bids The following items are pieces of work proposed within the National Collections delivery stream that address projects that are outside the scope of maintenance projects. Inclusion of this appendix is to provide context for the reader and does not indicate a commitment to deliver. These projects are at various stages of business case or pre business case.

C1 Expand NBRS to capture and track event level waiting times for patient journey from referral through outpatient services to inpatient treatment #27

Description The National Booking and Reporting System (NBRS) data collection has contributed to the improvement of patient flow and wait times for inpatient surgical procedures. Currently, it doesn’t provide the ability to monitor patient level wait times from referral to FSA, and wait times for diagnostic tests. Collecting this data would enable the Ministry to respond to the changing clinical environment, where more procedures are done in outpatients. This is especially the case with cancer, where early diagnosis and fast access to treatment are considered crucial. Expanding the functionality of NBRS will provide a complete end to end view of the patient flow pathway, and more timely and accurate information to DHBs and other key stakeholders. It will also enable the Elective Services and Cancer teams to more effectively monitor DHBs’ patient flow processes. The time spent on identification and correction of errors, and modification of programme requirements when necessary may also be reduced. The information will also enable improved monitoring of patient access to, and waiting times for, cancer assessment and treatment services. The additional information collected will enable better understanding of timeliness of service provision and inequalities in access to elective services, and will improve understanding of the level of unmet need for elective health services. Improvements to validation and processing will improve the quality of data held in NBRS and reduce operational overheads.

Notes NCAMP2011 #73, #39


Status This went to the capital expenditure committee in March 2011 and funding has been allocated pending approval of a business case. Work is currently in progress to assist the business in developing a business case and high level requirements.

C2 Collect diagnosis and procedure data for outpatient events #41

Description NNPAC presently monitors the flow and volume of outpatients through DHBs. Information currently stored includes personal identifiers (eg NHI, date of birth, gender, domicile code), service specifications (eg date of service), event type (eg outpatient visit), attendance (eg did not attend), health specialty code (eg paediatric cardiology) and service type (eg first, follow-up). At present, no diagnostic coding of outpatient events occurs, making it difficult to assess why different individuals / groups of patients accessed different types of care. The addition of diagnostic (+/- procedure) information to this core dataset would potentially yield a large amount of key information at a fraction of the cost of establishing new collection procedures (eg child disability surveys / disability registers). Following coding, NNPAC could then provide an overview of the paediatric outpatient population and the number of children (regionally and nationally; by age, ethnicity or NZ Deprivation Index decile) with particular chronic conditions or disabilities (eg insulin dependent diabetes, autism, cystic fibrosis). The dataset could also be used to determine which groups of children were at greater risk of hospital admission / mortality and how patient




loads and flows for particular conditions varied by DHB.

While diagnostic coding of outpatient events is not a ministry requirement, a number of DHBs have instituted their own paediatric outpatient coding practices in response to the perceived need for more detailed clinical information.

In late 2010 a pilot was carried out in 4 DHBs to code outpatient Paediatric visits in both ICD10 and SNOMED for a 2 month period. The results of this pilot are currently being analysed.

Liz Craig’s report “Coding Outpatient Data to Assess the Health Needs of Children with Chronic Conditions and Disabilities” will be available in first quarter of 2010/11 year.

Notes NCAMP2011 #

Requestor Planning and Analysis, Funding, Society of Paediatricians, NNPAC Roadmap 2006,

Status Depending on the report from the pilot a request will be made for capital expenditure funding in Mar 2012 to provide for the implementation of diagnostic and procedure coding in NNPAC.

C3 Enable reporting of event level National Costing data (collected from 2004/05 – onwards) from a national collection #34

Description The NHB Analysis team have collected cost data from DHBs since 2004/05 onwards. The event level data has been cleansed and matched to events in NMDS and NNPAC. The costing data is currently maintained and managed in a SAS database environment by the NHB Analysis team. An OLAP based data cube allows the sector to access and interrogate, via a web based tool, cost and event level activity data collected since 2004/05. Although this database is in essence a national collection of cost data in that all DHBs submit data to it and all DHBs have access to the data, it is not managed or maintained within the usual MOH teams responsible for the other National Collections which provide services such as

DMS – Operations for file loading and secure transfer of files between DHBs and MOH.

DMS – Data quality for first line support of problems arising at load time and general data quality issues

Warehouse services – enable DHBs and MOH to report the costing data integrated with the other national collections (NNPAC,NMDS) using Business Objects

Service management and support

Notes NCAMP2011 - #41


Status A request will be made for capital expenditure funding in early 2012 to incorporate this costing data as a national collection so that DHBs can submit costing data to a national collection in a similar way to inpatient NMDS and outpatient NNPAC data at present.

# Requirement

1 Business rules may be derived from the NPP 2010 DHB Provider Arm Data Request




2 Costing collection and event level activity data from NNPAC and NMDS collections would be the source of the NCCPP OLAP Activity Cost Cube

C4 PRIMHD Casemix

Description Mental health data has not previously been able to be case mixed. The inclusion of casemixed capability in PRIMHD will enable the system to produce casemix adjusted ad hoc and standing order reports, which will be particularly useful for outcomes analysis, service development and monitoring. The casemixed data will also inform the possible development of mental health output measures that could lead to output purchasing of mental health services rather than the current purchasing by inputs. This project will build and implement a casemix grouper over the existing PRIMHD data to classify outcome episodes into case classes. This piece of work will be informed by the preliminary work undertaken by Te Pou. The case mix solution will involve the Ministry's Solutions Delivery Group.

Notes

Requestor Sector Capability and Implementation (SCI), Mental Health and Addiction Programmes

Status This went to the capital expenditure committee in the March 2011 and funding has been allocated pending approval of a business case. Work is currently in progress to assist the business in developing a business case and detailed requirements.

C5 Enable the progressive implementation of KPI reporting for benchmarking across the mental health and addictions sector.

Description NCAMP – KPI Inclusion with business requirements

Purpose

Enable the progressive implementation of KPI reporting for benchmarking across the mental health and addictions sector.

Support the clinical intent to use information to understand what it takes to deliver a well performing system and the changes needed to achieve this.

Benefits of this work

Provider (DHB and NGO) commitment to PRIMHD data quality and use

Clinical responsibility for system performance and the changes needed to improve performance

Data to demonstrate improvement at sector and organisational level

Notes

Requestor Key Performance Indicator Framework for New Zealand Mental Health & Addiction Services

Status A business case is being developed to expand the service coverage of the PRIMHD KPIs including:

Adult provider arm services – all 20 DHBs

Adult NGO services – up to 100 NGOs




Up to 2 additional provider arm services (eg child and youth and CADS)

# Requirement

1 Development of new KPIs: Support the development of up to 10 new KPIs to enable the services above to report meaningful information, understand variation between services and keep pace with the evolution of the sector.

2 Information Portal: Development of a web based portal where organisations can access their information and build customised reports to suit their purposes.

3 Ad hoc reporting and queries to maximise utility of PRIMHD data : Ad hoc reporting to support interpretation and use of PRIMHD data to bring about quality and performance improvement (eg DHB/NGO client overlap).




Appendix D – Additional Information: SDG Maintenance Releases

The following items are requests proposed for inclusion into maintenance releases. These have not yet been approved for delivery.

D1 Items proposed for NBRS 2011/12 Maintenance Release

D1.1 Allow reporting of the Client System Identifier for a given patient booking in the NBRS Business Objects environment.

Description NCAMP2010 introduced the requirement that the exit date for treated patients should be the actual date the patients received their surgery and that the booking record for these patients should link directly to the inpatient record of their treatment. This required the NMDS inpatient identifier to be reported on all NBRS bookings being exited as treated.

Although this NMDS inpatient identifier (called “Client System identifier”) is a mandatory field on all NBRS exit treated records and is collected in the NBRS transactional database, there is no field in the datamart for this identifier. So anyone using the warehouse and business objects is unable to utilise this data.

Having the “Client System Identifier” in the warehouse will enable exited bookings in NBRS to be linked to the relevant NMDS record which allows investigation of data quality, comparison of planned vs actual procedures and future correlation of waiting times with clinical outcomes.

This change should have been in NCAMP2010 and has been an outstanding request since then.

The regular weekly refresh will populate the field on all records for the past 12 months. The next historic refresh is scheduled for the middle of the year. This refresh will be sufficient to populate older historic records.

This addresses CASD97134.

Requestor Elective services

# Requirement

1 Report Client System Identifier from the datamart NBR fact booking snapshot table, and NBR business objects universes

2 Populate the Client System Identifier in the NBR fact booking snapshot table with the Client System Identifier in the Booking Entry table

D1.2 Develop KPI to report patients waiting over 4 months for treatment

Description There is a continuing focus on reducing patient waiting times for elective services treatment. Currently one of the elective services performance indicators (ESPI 5) measures DHBs performance in treating patients within 6 months of the commitment to treat.

Because of the decreasing tolerance for patients waiting over 6 months for treatment, it is proposed that a new KPI is added to the KPI universe. It will provide the numbers of patients waiting over 4 months. This will enable easier understanding of the number of patients approaching the 6 months waiting deadline.

This addresses CASD86425

Add new KPI Statistic 77 - Number on IP waiting lists who have been waiting with assured status > 4 months.

This statistic would be calculated as all bookings with




Current Booking Status = 01 (Booked), 02 (Given Certainty), 05 (Deferred) or 06

(Rebooked)

Publicly Funded = ‘Y’

Staged/planned/surveillance = 1

Days Waiting Assured > 120 days (page 70 NBRS DataMart Data dictionary

defines Days Waiting Assured)

(This is the same calculation used for KPI Statistic 78 using 120 days instead of 180 days)

Any reports to be written or changed to use the new KPI Statistic 77 will be taken care of by the Elective Services Team DHB Performance, NHB.


# Requirement

1 The NBR Datamart Refresh needs to calculate the new KPI statistic 77 as detailed above

D1.3 Change the description of KPI 92 to accurately describe its contents

Description In NCAMP 2010, a new value of ’04 Surveillance Procedure’ was added to the codes available for the Staged/Planned Procedure Flag. KPI 92 included this new code because the condition allows for any flag value that is not 01 (Normal).

The name of KPI 92 needs to be changed to accurately describe its contents. “Total number of patients for planned and staged procedures” should read “Total number of patients for planned, staged and surveillance procedures”.

One standard report has been identified that also needs updating.

“Overall DHB summary Key Statistics Report” – Change the description “Number

of patients awaiting planned or staged procedures (not included in other

statistics)” to “Number of patients awaiting planned, staged and surveillance

procedures (not included in other statistics)”

As yet no other reports have been identified that need changing.

Ensure that KPI 92 conditions include value ’04 Surveillance Procedure’ in addition to values 02 Staged and 03 Planned.


# Requirement

1 Change KPI92 description as described above

D1.4 Update the reference data required for the validation of the clinical code and CPAC tool combinations.

Description Elective Services has developed a list of preferred ICD10 clinical codes to be used to describe the procedures patients are waiting for in NBRS. These will be used as reference data to improve the validation of clinical code and CPAC tool codes. These lists have been distributed to DHBs and they are incorporating them in their systems. Until now validations have been based on clinical code block which adds unnecessary complexity that causes problems for many DHBs. Data Management Services and the Technical Services DBAs are loading the required reference data tables and testing the DHB load files in compliance. In addition, end to end testing including the datamart refresh may be required.


# Requirement




1 Update the NBRS reference tables to enable the Elective Services list of preferred ICD10 clinical codes to be used for procedure code and CPAC tool validation.

D2 Items proposed for NNPAC 2011/12 Maintenance Release

D2.1 Add the following validations to the NNPAC load #12

Description There are a number of validations that are missing from the NNPAC load process that have caused data quality issues. These require significant manual intervention. They are periodically reported to the DHBs by data management services for correction and resubmission. The following conditions should be rejected by the load.

Condition Error Message Action

Accident flag = Y and ACC Claim Number is null

ACC claim number is a required field when accident flag = Y

Reject

Volume is null Volume is invalid Reject

Attendance Code = ATT and Volume=0 and IDF Unit of Measure=Event

Volume invalid for attendance code ATT

Reject

Volume not = 0 or 1 and IDF Unit of Measure = event

Volume invalid for IDF Unit of measure = Event

Reject

Date of service > facility retired date

Facility invalid for date of service Reject

Date of service > agency retired date

Agency invalid for date of service Reject

Date of service > NHI date of death

NHI died before date of service Reject

Service Type =PREADM and Purchase unit type <> ‘P’

Service Type invalid for this purchase unit type

Reject

Requestor DMS-Data Quality

# Requirement

1 Validations as above

D2.2 Enable NNPAC purchase unit table to be updated every 2 months. #13

Description In line with changes to business process around review and approval of purchase units in the National Services Framework Purchase Unit Data Dictionary to a 2 monthly cycle it is important to reflect those changes in the NNPAC purchase unit table. The purchase units have an active from date so there are no system restrictions on when the table can be updated. Previously all changes to the NSF have been approved once a year around December and loaded to NNPAC with the July 1 NCAMP changes. It is proposed that after the NCAMP2011 changes are made in July 1 that a regular 2 monthly update of the NNPAC purchase unit table is made available. Data Management services will continue to provide the changes required as documented in the NSF changes documents and in consultation with the relevant Ministry and DHB stakeholders.

Requestor Jane Craven, DHB Performance, Accountability

# Requirement

1 Update NNPAC/NMDS purchase unit table at least every 2 months

D2.3 Process to maintain DHB email addresses #14




Description Provide a process to allow operations staff to update DHB email addresses that are notified of file loads, file fails etc. Currently changes are loaded using a csv file. Apex, a fast development Oracle tool, has been identified as a possible way to provide this functionality.

Notes NCAMP2011 #85

Requestor Data Warehousing, DMS - Operations

# Requirement

1 DMS Operations to update contact email addresses

D2.4 Allow scheduled valid DHB files to load when a file fails #15

Description If a group of DHB files are scheduled to be loaded and one file fails then the load process stops and no files are loaded. Even if the other files are correct and could have been loaded they are stopped. As files are only loaded at night this can cause significant delays if there are many DHB files scheduled to run. Examples of problems that result in a file failing are field length violations, incorrect date time format, alpha characters in a numberic field, extra fields on a record.

Notes NCAMP2011 #48

Requestor DMS-Operations

# Requirement

1 Allow all files scheduled in a group to be loaded except those that have errors

D2.5 Improve the NNPAC load efficiency #16

Description The minimum time for a file or set of files to load is about 20 minutes even if there is only 1 file containing only 10 records. This is because the indexes are turned off during the load and rebuilt in their entirety at the end of the load. This may be made more efficient by only rebuilding the parts of the indexes that have been affected by the load.

Notes NCAMP2011 #85

Requestor DMS-Operations

# Requirement

1 Improvements to load as described

D2.6 The ability to back out a single DHB’s load file. #17

Description Provide an effective back out process for NNPAC batches that will reinstate updated and deleted records.

Notes NCAMP2011 #83,#84

Requestor DMS-Operations, SDG – Data Warehousing

# Requirement

1 To backout a single specified providers load file

D2.7 Move the business rules into the IDS #18

Description An Intermediate Data Store (IDS) exists in the current NNPAC design but it is not used. Currently all business rules are applied when the datamart is updated which limits when DHB files can be loaded and restricts operational efficiency. Business rules should be applied in the IDS. This would allow loading DHB files as they are received, improving the turnaround and improving the management of the file loading process. (This is likely to be a prerequisite to items 2.3, 2.4, and 2.5.).




Notes NCAMP2011 #82

Requestor SDG – Data Warehousing

# Requirement

1 Move the business rules into the IDS

D2.8 Refresh data from the NHI that is stored with NNPAC events #44

Description The National Health Index (NHI) number is submitted with each non admitted patient event. If the event is validated and loaded to the data mart then the following fields from the NHI are stored with the non admitted patient event record.

Gender, Ethnicity 1, 2 and 3, Domicile code, Date of Birth, Age at visit.

Over time as the NHI may be corrected or updated these changes are not being reflected on the non admitted patient event.


# Requirement

1 ?

D2.9 Application to maintain the NSF PUDD and supply NNPAC and NMDS datamart with complete purchase unit data. #43

Description Currently the National Services Framework Purchase Unit Data Dictionary and changes to it are maintained in Excel spreadsheets. It is an intensively manual process to use this data to update the NNPAC/NMDS purchase unit table. This is due to the structure of how it is maintained in the NSF and also because there are some attributes that are not part of the NSF PUDD that are required by NNPAC. The NSF is also used to record purchase units that identify services in the contract and payments systems CMS, CCPS, PROCLAIM and FMIS. There is continual ongoing work to ensure purchase units in these systems are used consistently. NSF changes affecting NNPAC and NMDS are incorporated in a .csv file. This .CSV file is tested and loaded to the datamart as part of the annual NCAMP process. Note that since the beginning of this year purchase units are approved every 2 months and should be available in the datamart to allow DHBs to report on these. (request D2.2 #13)


# Requirement

1 An application to record and track the history of changes to the NSF Purchase Unit Data Dictionary purchase units and their attributes and adequately supply complete purchase unit data to NNPAC and NMDS datamarts.

D2.10 Enable the potential reload of the fact_nap_snapshot table so as to capture the version of NAP events used for IDFs. #47

Description During August the NNPAC data for the previous financial year is extracted as the basis of inter district flow, IDF calculations. A copy of the NNPAC Fact table is updated to the snapshot table so that the events that form the basis of the IDF calculations can be retained. This is an iterative process where DHBs are given an opportunity to review the IDFs, make corrections to the data and then another IDF extract will be taken from NNPAC. Each time an IDF extract is taken the snapshot table should be updated. Currently there is no way to purge the appropriate year of data from the snapshot before updating it. The snapshot table has only been updated with 2009/10.data.

A CASD will be raised for the warehouse team to purge the selected data if




multiple extracts of the 2010/11 IDF need to be loaded into the snapshot table.

Requestor Funding, DMS Operations

# Requirement

1 To purge a specified financial year’s data from the snapshot table.

D2.11 Validate that the file version and field count are consistent and fail the file without continuing with other validations. #48

Description Currently the load process does not check that the number of fields on a row is consistent with the file version. So if a DHB submits a file with the wrong version number in the header the system attempts to validate the rest of the record(s) and in doing so generates many error messages some very unrelated to the actual problem. This can be very confusing.

Requestor DMS Operations

# Requirement

1 Validate that the number of fields in each row of the DHB load file is consistent with the number of fields for the file version in the header.




D3 Items proposed for NMDS 2011/12 Maintenance Release

D3.1 Update the Data Quality NMDS application to generate current version load files and retire unused versions 10.0, 11.5 and 12.0. #5

Description Currently we are supporting load file versions V010.0, V011.0, V011.5, V012.0, V013.0 and V014.0 as of July 2011. There is considerable testing resource required to maintain all these versions. All DHBs are submitting load files with the current version V13.0.

We should retire versions V010.0, V011.5 immediately as they are not being used at all.

The Data Quality NMDS application that is used by Data Management Services to generate fix files for DHBs creates load files in version V012.0. This SAS utility should be updated to generate V014.0 files and retire V012.0. This utility is currently supported by Analytical Services

Requestor DMS-Data Quality, SDG-Testing

# Requirement

1 Upgrade SAS utility used by data quality to generate fix files in a V014.0 format

2 Retire V010.0, V011.5, V012.0 from regression testing and file specification document.

D3.2 Update the Private Hospital application to generate current version NMDS load files and retire version 11.0. #6

Description Currently the private hospital SAS application generates V011.0 files. A number of new fields were introduced in V011.5 and later versions that are not currently collected from private hospitals. Analysis is required to determine if that data could be collected or defaulted for private hospital data. The private hospitals SAS application needs to be changed to incorporate the new data elements and generate V014.0 files. This application is currently supported by Analytical Services.

Requestor DMS-Data Quality, SDG-Testing, NCR-Classification and Terminology PH

# Requirement

1 Collect or default new data fields added to NMDS since version 11.0 from private hospitals

2 Upgrade SAS utility used by private hospitals to generate load files in a V014.0 format

3 Retire V011.0from regression testing

D3.3 Relax the age and sex validations on some procedures/diagnoses #7

Description The clinical code table used for validating the ICD10 code submitted on NMDS in-patient events has High and Low Age and Sex Flag indicators that are maintained by Data Management Services and Classification and Terminology. These need to be reviewed for some diagnoses and procedures where clinical practice has changed. Currently NMDS rejects these items with a warning and the DHB must resubmit the event overriding the warning. These diagnoses/procedures now commonly occur and should not be rejected. For example breast reduction should have the sex flag set to both male and female, contraceptive devices needs the Low age reduced from the current setting of 16 years. Data Management Services and NCR Classification and Terminology will provide the list of changes required to the clinical code table. Technology services DBA team will update the tables in the transactional NMDS. SDG will need to provide impact analysis, testing resource and ensure the datamart clinical code tables are updated. No development work is required.

Requestor DMS-Data Quality, NCR-Classification and Terminology




# Requirement

1 Load changes changes to the clinical code table.

D3.4 Reject a birth event where one already exists for that NHI #8

Description Currently NMDS does not reject any BT (birth) events if one already exists for that Baby's NHI. Where this occurs Data Management reports this to the DHB for correction. These events should be rejected on the load.


# Requirement

1 Add Validation as described

D3.5 Reject birth event where Mother’s NHI is equal to the baby’s NHI #9

Description Reject any BT (birth) events reported with a mother’s NHI the same as the baby’s NHI. Reject any events where the difference in the age of the mother’s NHI and the age on the baby’s NHI is less than 10 years. Where this occurs Data Management reports this to the DHB for correction. These events should be rejected on the load.


# Requirement


D3.6 Reject events with a purchaser code A0 and accident flag is null #10

Description In the NMDS Data Dictionary and File Specification it is clearly documented that the accident flag should be set to ‘Y’ when the purchaser code A0 (ACC – direct purchase) is reported and the ACC claim number field should not be blank. This validation has been working in the past and system testers will review it with the NCAMP2011 testing and it may be corrected with that release. If not, it will need to be corrected in this maintenance release..

Requestor DMS-Data Quality

# Requirement


D3.7 Add Kosovo to the country code tables #11

Description Add a new country to the country code tables to allow health events to be accurately coded for patients who identify Kosovo as their country of birth - 434 Kosovo. Technology services DBA team will update the Country code table in the transactional NMDS. SDG will need to provide impact analysis, testing resource and ensure the datamart country dimension table is updated. No development work is required.

Notes MoH currently uses an old version of the country code list where the codes are 3 digits long. This is now out of date and has been superseded by a list with 4 digit codes. See Statistics NZ website http://www.stats.govt.nz/surveys_and_methods/methods/classifications-and-standards/classification-related-stats-standards/country.aspx. Upgrading to the new version is an item on the NCAMP2012 list.

Requestor DMS-Data Quality, Auckland DHB

# Requirement

1 Add 434 Kosovo to the Country Code table

http://www.stats.govt.nz/surveys_and_methods/methods/classifications-and-standards/classification-related-stats-standards/country.aspx

http://www.stats.govt.nz/surveys_and_methods/methods/classifications-and-standards/classification-related-stats-standards/country.aspx




D4 Items proposed for PRIMHD 2011/12 Maintenance Release

The following items have been identified for possible inclusion in a 2011/12 maintenance release.

PRIMHD reference # Description Priority

1, 2, 3

PRIMHD ODS PIR

06, 08 Addressed with the view to being resolved High

4 PRIMHD ODS PIR 27 Space after userid gives unexpected result on login High

5 PRIMHD ODS PIR 46 Schema needs to be updated High

6 PRIMHD ODS PIR 03

Change Data Warehouse Daily Refresh to a weekly refresh. The extract has stopped but the warehouse updates each day still High

7 PRIMHD ODS PIR 34 Have to restart browser after 15 minute timeout High

8 Report Enhancements

Report the correct funding DHB for NGOs in the Provider Monitoring Report - NGOs and Service Use by Client - NGOs (Use DHB of Domicile) High

9 BA Query 22 Update and publish the Warehouse data dictionary Medium

10 PRIMHD ODS PIR 07 Abstract Object Store Full - causing stack trace error Medium

11 PRIMHD ODS PIR 14 DA Tool outage causes PRIMHD Online Outage Medium

12 PRIMHD ODS PIR 15 Certificate issues cause outages Medium


Display Organisation Name on Search Team and Team Details page Medium

14 Enhancement 34 Better handling and capturing of application stack trace errors

15 BA Query 24 Seconds default to xx:xx:59 for end times in PRIMHD Online entered data

16 BA Query 02

A warning should not be applied to CO records where tool type C1 because Focus of care is not necessary for these records

17 BA Query 03 Two errors logged for one error "Referral Start before team open date" Low

18 BA Query 04 Remove the warning if submitting "R69" as a type A diagnosis when error already reported. Low

19 BA Query 05 Remove warning when an error already reported for sex or date of birth not included in the HC record

Fixed Closed

20 BA Query 06 Report a single error when submitting a valid ICD code but with the wrong system Low

21 BA Query 08 Remove tags from schema for deleted fields Low

22 BA Query 21

Correct inconsistencies in the environments. Outcome Tool Code Z1 No Outcome Tool Used is in TEST but not in DEV or PROD Low


Display Legal Status Code & Legal Status End Date on Legal Status Search Results list. Low


Display of full Tool Description on Collection Occasion Search Results list. Low




Appendix E - Abbreviations For the purposes of this document the following terms, acronyms and abbreviations have the specific meaning as listed in the definition below

Abbreviation Definition

ACC Accident Compensation Corporation

BA Business Analyst

CCTAG Common Counting Technical Advisory Group

DHB District Health Board

DHBNZ District Health Boards New Zealand

DMS Data Management Services

ESIM Elective Services Information Management Reference Group

HCU Healthcare User

HISO Health Information Standards Organisation

HPI Health Practitioner Index

IDF Inter District Flows

KPI Key Performance Indicators

MOH Ministry of Health

NBRS National Booking Reporting System

NCCPP National Costing Collection and Pricing Programme

NCR National Collections and Reporting

NHI National Health Index

NMDS National Minimum Data Set (Hospital In-patient events)

NNPAC National Non Admitted Patient Collection

PRIMHD Programme for the Integration of Mental Health Data

PUC Purchase Unit Code

PHO Primary Health Organisation