National Non-Admitted Patients Collection (NNPAC) DATA MART - DATA DICTIONARY. Version 2.7 May 2017

Transcription

1 National Non-Admitted Patients Collection (NNPAC) DATA MART - DATA DICTIONARY Version 2.7

2 (NNPAC) National Non-Admitted Patients Collection Reproduction of material The Ministry of Health ( the Ministry ) permits the reproduction of material from this publication without prior notification, providing all the following conditions are met: the information must not be used for commercial gain, must not be distorted or changed, and the Ministry must be acknowledged as the source. Disclaimer The Ministry of Health gives no indemnity as to the correctness of the information or data supplied. The Ministry of Health shall not be liable for any loss or damage arising directly or indirectly from the supply of this publication. All care has been taken in the preparation of this publication. The data presented was deemed to be accurate at the time of publication, but may be subject to change. It is advisable to check for updates to this publication on the Ministry s web site at Publications A complete list of the Ministry s publications is available from the Ministry of Health, PO Box 5013, Wellington, or on the Ministry s web site at Any enquiries about or comments on this publication should be directed to: Analytical Services Ministry of Health PO Box 5013 Wellington Phone: (04) Fax: (04) data-enquiries@moh.govt.nz Published by Ministry of Health 2017, Ministry of Health Version 2.47 MoH 2

3 (NNPAC) National Non-Admitted Patients Collection Introduction Objectives Audiences Format Changes to dictionary format The objectives of the Ministry of Health ( the Ministry ) Data Dictionaries are to: describe the information available within the National Collections promote uniformity, availability and consistency across the National Collections support the use of nationally agreed protocols and standards wherever possible promote national standard definitions and make them available to users. It is hoped that the greater level of detail along with clear definitions of the business rules around each element will assist with providing and using the data. The target audiences for Data Dictionaries are data providers, software developers, and data users. All data element definitions in the Data Dictionaries are presented in a format based on the Australian Institute of Health and Welfare National Health Data Dictionary. This dictionary is based on the ISO/IEC Standard Specification and Standardization of Data Elements the international standard for defining data elements issued by the International Organization for Standardization and the International Electrotechnical Commission. The format is described in detail in the appendices of this dictionary. A more rigorous approach to recording changes in the data elements has been introduced in these dictionaries along with background material on the features of time-series data for each element. In summary, the changes to the data dictionaries include: standardisation of the element names so that, for instance, a healthcare user s NHI number is referred to as NHI number in all collections elements are listed alphabetically within each table, and the tables are organised alphabetically each table is described verification rules, historical information, and data quality information are included alternative names for the elements are listed information about how the data is collected is given related data, and references to source documents and source organisations are included an alphabetical index is included code tables are included with the element, or a reference given to the Ministry s web site (for large or dynamic code tables). Version 2.47 MoH 3

4 (NNPAC) National Non-Admitted Patients Collection Table of Contents National Non-Admitted Patients Collection (NNPAC)... 7 NNPAC codes dimension table... 9 Accident flag Attendance code Event type Health provider type NAP codes dimension key Service type NNPAC event fact table ACC claim number Accident flag Affiliation dimension key Age at time of visit Age band dimension key Agency code Agency dimension key Alcohol Involved Alcohol Involved dimension key Attendance code Batch number Client system identifier Date of birth Datetime of departure Datetime of event end Datetime of first contact Datetime of presentation Datetime of service Dim funding agency code key Dim purchaser agency key Domicile code Encrypted HCU id Equivalent purchase unit Ethnicity code Ethnicity code Ethnicity code Event end date submitted Event end type code Event type Extract system identifier Facility code Facility dimension key Funding agency code Gender Geo dimension key Global time dimension key HCU identifiable dimension key Health care user dimension key Health provider type Health specialty code Health specialty dimension key IDF DHB dimension key IDF DHB source Location/Activity Setting Location dimension key Mode of Delivery Mode of Delivery dimension key NAP codes dimension key NAP date of service dimension key NAP event end type dimension key NAP time of service dimension key NAP triage level dimension key NHI number NMDS unique identifier PMS unique identifier Version 2.47 MoH 4

5 (NNPAC) National Non-Admitted Patients Collection Purchase unit dimension key Purchaser code Purchaser code dimension key Sent domicile code Sent domicile rating Sent geo dimension key Service type Submitting DHB dimension key Triage level Volume NNPAC event snapshot fact table ACC claim number Accident flag Affiliation dimension key Age at time of visit Age band dimension key Agency code Agency dimension key Attendance code Batch number Client system identifier Date of birth Datetime of departure Datetime of event end Datetime of first contact Datetime of presentation Datetime of service Dim funding agency code key Domicile code Equivalent purchase unit Ethnicity code Ethnicity code Ethnicity code Event end date submitted Event end type code Event type Extract system identifier Facility code Facility dimension key Financial year Funding agency code Gender Geo dimension key Global time dimension key Health care user dimension key Health provider type Health specialty code Health specialty dimension key IDF DHB dimension key IDF DHB source Location/Activity Setting Location dimension key Mode of Delivery dimension key NAP codes dimension key NAP date of service dimension key NAP event end type dimension key NAP time of service dimension key NAP triage level key NMDS unique identifier PMS unique identifier Purchase unit dimension key Purchaser code Purchaser code dimension key Sent domicile code Sent domicile rating Sent geo dimension key Service type Version 2.47 MoH 5

6 (NNPAC) National Non-Admitted Patients Collection Submitting DHB dimension key Triage level Volume Triage level dimension table Full description Short description Triage level Appendix A: Logical to Physical Table Mapping Appendix B: List of Shared Dimensions Appendix C: List of Views Appendix D: Data Dictionary Template Appendix E: Code Table Index Event End Type code table Location code table Mode of Delivery code table Triage Level code table Appendix F: NNPAC Data Model Appendix G: Collection of Ethnicity Data Appendix H: of NNPAC Purchaser Codes Appendix I: Guide for Use of Emergency Department (ED) Event End Type Codes Version 2.47 MoH 6

7 (NNPAC) National Non-Admitted Patients Collection National Non-Admitted Patients Collection (NNPAC) Purpose The National Non-Admitted Patients Data Mart stores data about nonadmitted face-to-face secondary care events, such as outpatient and emergency department visits. The main purposes of the NNPAC Data Mart are to: - monitor non-admitted patient events - analyse inter-district flows - monitor the impact of policy. Admitted patient events are held in the NMDS collection. Content The scope of the NNPAC data mart project is limited in phase one to event data only, and does not include information on diagnosis or procedures. Non-attendances are also in scope, and inclusion is mandatory for clinics run by doctors. A non-attendance is where the appointment was not cancelled but the patient either never arrived or left before being seen by the doctor. After ten years the NNPAC Data Mart will eventually hold approximately 36 million event records. It is anticipated that the NNPAC Data Mart will grow at a rate of 300,000 records per month. Start date The NNPAC Data Mart was established in 2006 and contains data from July The scope of the NNPAC Data Mart project is limited in phase one to event data only, and does not include information on diagnosis or procedures. All attributes are stored as they were at the time of the transaction, that is, they do not reflect current values, unless explicitly stated, for example, ethnicity, gender and geographic information. The main NNPAC fact table, Fact NAP Event, is not directly visible to end users. Depending on security permissions, end users have access to two views of fact_nap_event: - Fact NAP Event NI (a non-identifiable view) or - Fact NAP Event ID (an identifiable view). Contact information For further information about this collection or to request specific datasets or reports, contact the NZHIS Analytical Services team on - Phone: (04) Fax: (04) , - or data-enquiries@moh.govt.nz The NNPAC data is sourced from DHBs various management systems for non-admitted events. The data will be extracted by DHBs and other providers, transferred using FTP, in the format defined in the NNPAC File Specification document. Frequency of updates Security of data NNPAC receives monthly extracts from DHBs which are then loaded into the Ministry of Health data mart. The data in the Ministry of Health data warehouse (including NNPAC) is protected with database passwords, Business Object passwords and Virtual Private Database rules and is only available through the secure Health Intranet. Authorised members of the Ministry of Health and District Health Boards have access to the data for analytical purposes, via the Business Objects reporting tool and the secure Health Information Network (HIN). Business Objects contains a subset of the data described in the Data Dictionary. Version 2.47 MoH 7

8 NNPAC codes dimension table Privacy issues The Ministry of Health is required to ensure that the release of information recognises any legislation related to the privacy of health information, in particular the Official Information Act 1982, the Privacy Act 1993 and the Health Information Privacy Code Information available to the general public is of a statistical and nonidentifiable nature. Researchers requiring identifiable data will usually need approval from an Ethics Committee. In 2004 claims, the encrypted NHI number is stored for approximately 88 per cent of laboratory test records. (In earlier years, it varied, dropping to as low as 13 per cent in 1997 claims.) Identifying information is only held for health providers who request the test and not for the pathologist performing the test. National reports and publications Data provision The Ministry of Health releases monthly standard reports for DHBs via the HIN. Customised datasets or summary reports are available on request, either electronically or on paper. Staff from the Analytical Services team can help to define the specifications for a request and are familiar with the strengths and weaknesses of the data. The Analytical Services team also offers a peer review service to ensure that Ministry data is reported appropriately when published by other organisations. There may be charges associated with data extracts. Version 2.47 MoH 8

9 NNPAC codes dimension table NNPAC codes dimension table dim_nap_codes Primary key Business key Used to hold multiple NAP flags and codes. dim_nap_codes_key attendance_code, event_type, health_provider_type, accident_flag, service_type Table has one row for every combination of the flags and codes that are in the table. Relational rules Data content Version 2.47 MoH 9

10 NNPAC codes dimension table Accident flag A flag that denotes whether a person is receiving care or treatment as the result of an accident. accident_flag dim_nap_codes varchar2(64) A Y The health event/treatment is assumed to be or is assessed as the result of an accident N The health event/treatment is the result of an illness. U Unknown. Must match flag in NMDS for admissions from the Emergency Department with Purchase Unit Codes like 'ED%A' Version 2.47 MoH 10

11 NNPAC codes dimension table Attendance code Attendance code for the Health Care User event. attendance_code dim_nap_codes varchar2(64) AAA ATT (attended) DNA (did not attend) DNW (did not wait) ATT (Attended) An attendance is where the healthcare user is assessed by a registered medical practitioner or nurse practitioner. The healthcare user received treatment, therapy, advice, diagnostic or investigatory procedures. DNA (Did Not Attend) Where general outpatient did not arrive, this is classed as did not attend. DNW (Did Not Wait) Used for ED where the patient did not wait. Also for use where general outpatient arrives but does not wait to receive service. Mandatory Version 2.47 MoH 11

12 NNPAC codes dimension table Event type Code identifying the type of health event. event_type dim_nap_codes varchar2(64) AA CR (community referred diagnostic) ED (emergency department) OP (outpatient) As at 1 Jul 2008, the Event Type is determined from the submitted Purchase Unit Code. If the first two characters of the submitted Purchase Unit Code = 'ED', the Event Type is set to 'ED'. In all other cases, the Event Type is set to 'OP'. From 1st July 2010 the direct reporting of Event type is mandatory as opposed to being derived from the Equivalent Purchase Unit. 'CR' was introduced on 1st July Equivalent purchase unit Version 2.47 MoH 12

13 NNPAC codes dimension table Health provider type A code for the registration body of the provider. health_provider_type dim_nap_codes varchar2(64) Health practitioner type A M (doctor), N (nurse), O (other) Version 2.47 MoH 13

14 NNPAC codes dimension table NAP codes dimension key Generated artificial key for the dim_nap_codes table dim_nap_codes_key dim_nap_codes integer Generated artificial key #,##0 Version 2.47 MoH 14

15 NNPAC codes dimension table Service type Type of service service_type dim_nap_codes varchar2(64) X(8) 'First' 'Followup' 'Preadm' 'CRD' As defined in the Nationwide Service Framework Data Dictionary: FIRST Face-to-face client contact (including telemedicine) by registered medical practitioner or nurse practitioner for first assessment for that client for that condition for that specialty. This includes follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. FOLLOWUP Subsequent face-to-face client consultation by registered medical practitioner or nurse practitioner for the same condition in the same specialty. This does not include follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. Service is provided in a ward and/or at a designated outpatient clinic or other suitable setting. PREADM (Pre-admission) Attendance at a clinic where the purpose is to medically/anaesthetically assess prior to an elective procedure. CRD (Community Referred Diagnostic) The Community Referred Diagnostic Event should only be used when the diagnostic is independent of any FSA follow up or treatment procedure and has been ordered by the GP. Mandatory for all events with a Date of Service on or after 1 July 2010 Event type Version 2.47 MoH 15

16 NNPAC event fact table NNPAC event fact table fact_nap_event Hold details of an indiviual non-admitted patient event or emergency department event that includes non-attended events. Primary key Business key client_system_identifier, pms_unique_identifier This table is not directly visible to end users. Depending on security permissions, end users have access to two views of fact_nap_event: Fact NAP Event NI (a non-identifiable view) or Fact NAP Event ID (an identifiable view). KEY: Dim Age band key Dim Agency key Dim Facility key Dim HCU identifiable key Shared Dim health care user key Shared Dim health specialty key Shared Dim location key Dim NAP codes key Dim NAP date of service key Dim NAP time of service key Dim Purchase unit key Dim Purchaser code key Shared LINKED TO: Age Band table (dim_age_band) - Shared Dimension Agency Facility table (dim_agency_facility) - Shared Agency Facility table (dim_agency_facility) - Shared HCU Identifiable table (dim_hcu_identifiable) - Healthcare User table (dim_healthcare_user) - Health Specialty table (dim_health_specialty) - Location table (dim_location) - Shared NAP Codes table (dim_nap_codes) Global time table (dim_global_time) - Shared Global time table (dim_global_time) - Shared Purchase Unit table (dim_purchase_unit) - Shared Purchaser Code table (dim_purchaser_code) - Relational rules Refer to Guide for Use Data content Version 2.47 MoH 16

17 NNPAC event fact table ACC claim number This is a separate field to record the M46/45, ACC45 or AITC claim number for the event. acc_claim_number fact_nap_event varchar2(64) Injury resulting from an accident. X(12) Optional. Valid only if accident flag = 'Y' This is a free-text field to allow historical claim numbers, which come in a variety of formats, to be provided. Should match associated NMDS event of patient admitted and treated following Emergency Department NNPAC event. Accident flag Principal health service purchaser Accident Compensation Corporation Version 2.47 MoH 17

18 NNPAC event fact table Accident flag A flag that denotes whether a person is receiving care or treatment as the result of an accident. accident_flag fact_nap_event varchar2(64) A Y The health event/treatment is assumed to be or is assessed as the result of an accident N The health event/treatment is the result of an illness. U Unknown. For this to be 'Y', the healthcare user should be admitted as a result of an accident. This would be either an acute case or someone returning for treatment (in which case an ACC Claim Number would be required). Mandatory field. Must match flag in NMDS dimension for admissions from the Emergency Department with Purchase Unit Codes like 'ED%A' ACC claim number Version 2.47 MoH 18

19 NNPAC event fact table Affiliation dimension key Generated artificial key for the dim_affiliation table. dim_affiliation_key fact_nap_event integer '0' means undefined. Links NHI submitted to ethnicity and domicile information via the dim_hcu table Ministry of Health system-generated. Version 2.47 MoH 19

20 NNPAC event fact table Age at time of visit Age at time of visit. age_at_visit fact_nap_event integer NNN Derived field. Date of Service - Date of birth from dim_hcu Version 2.47 MoH 20

21 NNPAC event fact table Age band dimension key Generated artificial key for the dim_age_band table. dim_age_band_key fact_nap_event integer Derived from the person's age at the time of service. Used to construct reports based on age bands Version 2.47 MoH 21

22 NNPAC event fact table Agency code A code that uniquely identifies the agency contracted directly with the Ministry of Health to provide the service agency_code fact_nap_event varchar2(64) Health agency code, DHB code XXXX See the Agency code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Historically, also known as CHE (Crown Health Enterprise), HHS (Hospitals and Health Services) and AHB (Area Health Board). Must be a valid code in the code table. The code table is continually updated by the Ministry of Health as hospitals open and close. See the Ministry of Health web site for the most recent version. Ministry of Health Version 2.47 MoH 22

23 NNPAC event fact table Agency dimension key Generated artificial key for the dim_agency_facility table based on the funding agency. dim_agency_key fact_nap_event integer System generated artificial key Version 2.47 MoH 23

24 NNPAC event fact table Attendance code Attendance code for the Health Care User event. attendance_code fact_nap_event varchar2(64) AAA ATT (attended) DNA (did not attend) DNW (did not wait) ATT (Attended) An attendance is where the healthcare user is assessed by a registered medical practitioner or nurse practitioner. The healthcare user received treatment, therapy, advice, diagnostic or investigatory procedures. DNA (Did Not Attend) Where general outpatient did not arrive, this is classed as did not attend. DNW (Did Not Wait) Used for ED where the patient did not wait. Also for use where general outpatient arrives but does not wait to receive service. Mandatory Version 2.47 MoH 24

25 NNPAC event fact table Batch number A identifier for a group of records that have been processed together. batch_number fact_nap_event integer 1 to Version 2.47 MoH 25

26 NNPAC event fact table Client system identifier A unique Identifier for each source system client_system_identifier fact_nap_event varchar2(64) A unique Identifier for each source system will be defined by the DHB and notified to the Ministry of Health. Thus each DHB may have multiple CSIs. To enable individual records to be identified, this will be combined with the PMS unique ID. This means individual records for an individual DHB can be readily identified when source systems use the same number range. New client system identifiers need to be registered with the Ministry of Health and must be associated with an extract system identifier Extract system identifier Version 2.47 MoH 26

27 NNPAC event fact table Date of birth The date of birth of the Health Care User. date_of_birth fact_nap_event date CCYYMMDD Version 2.47 MoH 27

28 NNPAC event fact table Datetime of departure The date and time of the physical departure of the patient from ED datetime_of_departure fact_nap_event date CCYYMMDDhhmm Valid dates and times The date and time of the physical departure of the patient from ED to an inpatient ward, or the time at which a patient begins a period of formal observation (whether in ED observation beds, an observation unit, or similar), or the time at which a patient being discharged from the ED to the community physically leaves the ED. The datetime of departure is the time at which the patient is physically moved from ED to an inpatient ward, or the time at which a patient begins a period of formal observation, whether in ED observation beds, an observation unit, or similar. The physical move will follow, or be concurrent with, a formal admission protocol, but it is the patient movement that stops the clock on the emergency event, not associated administrative decisions or tasks. Inpatient wards include short stay units (or units with a similar function). Under certain circumstances, a `decant ward designed to deal with surge capacity will qualify as an inpatient ward. Key criteria are that patients should be in beds rather than on trolleys, and be under the care of appropriate clinical staff. A formal observation area generally has dedicated space, dedicated staffing, and fixed capacity (beds). In relation to transfers to an APU; if there is a clinical intervention and supervision by ED staff over and above triage, then the time from presentation to transfer should be counted in reporting against the ED LOS target. Otherwise, it should be excluded. Datetime of departure is the time at which a patient being discharged from the ED to the community physically leaves the ED. If a patient s treatment is finished, and they are waiting in the ED facilities only as a consequence of their personal transport arrangements for pickup, they can be treated as discharged for the purposes of this measure. If the patient goes home then returns to become an inpatient, then the clock stops at the point they leave the ED. If the patient goes home then returns to ED for further care, it is counted as another ED admission. If not supplied this field will be set to (i.e. 31/12/ :59) Mandatory for ED events with Datetime of service on or after 1 July 2010 and attendance code 'ATT'. If not supplied this field will be set to (i.e. 31/12/ :59) Must be on or after Datetime of Event End Version 2.47 MoH 28

29 NNPAC event fact table Version 2.47 MoH 29

30 NNPAC event fact table Datetime of event end The date and time on which the event ended. datetime_of_event_end fact_nap_event date For ED events this field records the change in administrative status. For ED patients who have an NMDS event recorded, this is the datetime the NMDS event is assumed to have commenced. For all other patients this is the same as datetime of departure. CCYYMMDDhhmm Valid dates and times Retired in July Introduced as date of event end in 2008 to record where an ED event went past midnight. Replaced with datetime of event end in 2010 to be consistent with other datetime field changes. Other datetimes now collected on ED events supercede the need to collect this date. This field recorded a change in a patient's administrative status rather than a change in physical location. It was used as follows: - For all events that had an NMDS event recorded, ED event end datetime was the date time that the NMDS event was assumed to have commenced. This may not have been the same as the datetime of departure from ED. - For all other patients the ED event end datetime was the same as the datetime of departure from ED. After 1 July 2011 this field will automatically be populated with 31/12/ :59 This was an optional field. From 1 July 2010 to 30 June 2011, if not submitted on an ED event it was populated with the Datetime of Departure. If not submitted on outpatient events it was populated with the date of service and time of 23:59. Datetime of Service, Datetime of Departure Version 2.47 MoH 30

31 NNPAC event fact table Datetime of first contact The date and time that the triaged patient's treatment starts by a suitable ED medical professional (could be the same time as the datetime of service if treatment begins immediately). datetime_of_first_contact fact_nap_event date CCYYMMDDhhmm Valid dates and times Mandatory for ED events with Datetime of Service on or after 1 July 2010 and attendance code of 'ATT'. If not supplied this field will be set to (i.e. 31/12/ :59) Must be on or after Datetime of Service Datetime of Service Version 2.47 MoH 31

32 NNPAC event fact table Datetime of presentation The date and time a patient presents/or is presented physically to the ED department; either the triage nurse or clerical staff, whichever comes first datetime_of_presentation fact_nap_event date CCYYMMDDhhmm Valid date and time. Mandatory for ED events with Datetime of service on or after 1 July If not supplied this field will be set to (i.e. 31/12/ :59) Datetime of service, Datetime of first contact Version 2.47 MoH 32

33 NNPAC event fact table Datetime of service The date and time on which the outpatient event took place for non ED events. For ED events it is the date and time the triage nurse/suitable ED medical professional starts the process of categorising the triage level of the incoming patient. datetime_of_service fact_nap_event date CCYYMMDDhhmm Valid date and time. The appropriate standard of care is for the first contact with staff in the ED to be with a triage nurse ('triage first'), so this datetime ideally should be the same as 'datetime of presentation.' However, it is understood that patients may present to a receptionist first in some departments, or may wait in a triage queue on some occasions. Hence 'datetime of presentation' and 'datetime of triage' are recorded separately. However, DHBs should endeavour to have 'triage first' and to ensure triage is undertaken immediately upon the patient's arrival. Note the 'datetime of triage' is from the start of triage. It is understood that many EDs record the time the triage nurse 'files' the electronic triage record for the patient and that this is often towards the end of the triage process. DHBs with EDs of this sort should endeavour to have a system which electronically records the start of triage. For outpatient visits the time of service should be the actual service start time if available. If not, then the booked appointment time may be used or a default time of 0000 may be sent. The format for this would be CCYYMMDD0000. Must be: a valid date; on or before the NNPAC processing date; not more than 20 years before the NNPAC processing date Must be on or before Datetime of First Contact Datetime of Presentation, Datetime of First Contact Version 2.47 MoH 33

34 NNPAC event fact table Dim funding agency code key dim_funding_agency_code_key fact_nap_event integer Version 2.47 MoH 34

35 NNPAC event fact table Dim purchaser agency key dim_purchaser_agency_key fact_nap_event integer Version 2.47 MoH 35

36 NNPAC event fact table Domicile code Domicile code retrieved from the patient's NHI record (the NHI address history that relates to the date of service). Used to determine the DHB of domicile only if the sent domicile code is invalid. domicile_code fact_nap_event varchar2(64) XXNN See the Domicile code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Statistics NZ Health Domicile Code representing a person's usual residential address. Also used for facility addresses. Usual residential address is defined as the address of the dwelling where a person considers himself or herself to usually reside. (Statistics NZ definition of 'usually resident'.) If a person usually lives in a rest home or a hospital, that is considered their usual residential address. This is used as a data quality test to compare with the sent domicile code and is also used for deriving the patient's DHB of domicile. Includes leading zeroes. Must be a valid code in the Domicile Code table. Sent domicile, IDF DHB source, Dim IDF DHB Version 2.47 MoH 36

37 NNPAC event fact table Encrypted HCU id Encrypted health care user ID encrypted_hcu_id fact_nap_event varchar2(64) Encrypted HCU identifier, Encrypted NHI, etc. See other names for the NHI number under. The NHI number uniquely identifies healthcare users, and allows linking between different data collections. It is encrypted to ensure privacy of individual records. The NHI number is the cornerstone of the Ministry of Health's data collections. It is a unique 7-character identification number assigned to a healthcare user by the National Health Index (NHI) database. The NHI number is also known as National Health Index, HCU identifier, NHI, HCU, HCU Number, Healthcare User identifier, HCU identification number, NMPI number, Hospital Number, Patient Number. When duplicate records for a healthcare user are merged, one of their NHI numbers will be deemed to be the master (or primary), and the others become event (or secondary) NHI numbers. This does not affect which NHI numbers are used in local systems. The NHI number that is sent in by the data provider is encrypted during the loading process. Only this encrypted NHI number is stored. For the analysis of healthcare information relating to a unique individual, the master NHI number should be used. Please contact Analytical Services for further information on how to obtain the master encrypted NHI number if you are performing your own data extraction. The Privacy Commissioner considers the NHI number to be personally identifying information (like name and address) so, if it is linked to clinical information, it must be held securely and the healthcare user's privacy protected. The Encrypted NHI number is not considered personally identifying. The Ministry of Health will return data containing unencrypted NHI numbers to providers who have sent it in. Information available to the general public is of a statistical and non-identifiable nature. Researchers requiring identifiable data will usually need approval from an Ethics Committee. VALIDATION The first three characters of an NHI number must be alpha (but not 'I' or 'O'). The 4th to 6th characters must be numeric. The 7th character is a check digit modulus 11. ENCRYPTION The NHI number is encrypted using a one-way encryption algorithm. The aim is to provide an encrypted number that can be sent across public (unsecured) networks. Must be registered on the NHI before use. There is a verification algorithm which ensures that the NHI number is in the correct format and is valid. Version 2.47 MoH 37

38 NNPAC event fact table NHI numbers are often included on patient notes and other patient documentation. New numbers can be allocated by health providers who have direct access to the NHI Register. for more information on the NHI number Ministry of Health Version 2.47 MoH 38

39 NNPAC event fact table Equivalent purchase unit Purchase unit indicates which contract the event is funded under. equivalent_purchase_unit fact_nap_event varchar2(64) X(8) For DNA (Did Not Attend) or DNW (Did Not Wait) is the Purchase Unit that would have allocated had they attended or waited. For ED attendances where only ED service is triage, the purchase unit is ED Purchase Unit Codes are defined by the Nationwide Service Framework Data Dictionary (see the Ministry website at They are updated annually and are subject to change according to financial year. For example 2006/07 financial year data should be compliant with v11 of the NSF Data Dictionary, 2007/08 financial year data should be compliant with v12 of the NSF Data Dictionary and so on. Purchase unit start and end date validation is based on date of service Version 2.47 MoH 39

40 NNPAC event fact table Ethnicity code 1 Ethnic affiliation ethnicity_code_1 fact_nap_event varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 40

41 NNPAC event fact table Ethnicity code 2 Ethnic affiliation ethnicity_code_2 fact_nap_event varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Ethnic code represents a social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 41

42 NNPAC event fact table Ethnicity code 3 Ethnic affiliation ethnicity_code_3 fact_nap_event varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 42

43 NNPAC event fact table Event end date submitted Whether the Event End Date Time was provided in an extract or set to the default during the load process. end_date_submitted_flag fact_nap_event char(1) 'Y' - the Datetime of Event End was submitted 'N' - the Datetime of Event End date was set to the Date of Service and time of 23:59 The default for Event End date was set to the Date of Service and time of 23:59 Derived during the NNPAC Load process. Datetime of event end Version 2.47 MoH 43

44 NNPAC event fact table Event end type code A code identifying how a healthcare event ended event_end_type_code fact_nap_event varchar2(64) AA See the Event End Type code table in Appendix E. DW may be used on events that are transferred from ED to an inpatient event. Mandatory for ED events with Datetime of service on or after 1 July Must be a valid code in the Event End Type code table. If not supplied, this field is set to 'UN' Datetime of departure Version 2.47 MoH 44

45 NNPAC event fact table Event type Code identifying the type of health event. event_type fact_nap_event varchar2(64) AA CR (community referred diagnostic) ED (emergency department) OP (outpatient) From 1 Jul 2008 to 31 June 2010, the Event Type was determined from the submitted Purchase Unit Code. From 1st July 2010 the direct reporting of Event type is mandatory as opposed to being derived from the Equivalent Purchase Unit. 'CR' was introduced on 1st July Version 2.47 MoH 45

46 NNPAC event fact table Extract system identifier The identifier of the system the data was extracted from. extract_system_identifier fact_nap_event varchar2(64) Unique identifiers for each combination of DHB and Extract system are defined by the DHB and notified to the Ministry of Health. Thus each DHB may have multiple ESI. This may not necessarily be the same as the source data system(s). It is recommended that the first three characters define the DHB. Version 2.47 MoH 46

47 NNPAC event fact table Facility code A code that uniquely identifies a healthcare facility. facility_code fact_nap_event varchar2(64) Health agency facility code, Hospital, HAF code, HAFC. The location of the event X(4) See the Facility code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A healthcare facility is a place, which may be a permanent, temporary, or mobile structure that healthcare users attend or are resident in for the primary purpose of receiving healthcare or disability support services. This definition excludes supervised hostels, halfway houses, staff residences, and rest homes where the rest home is the patient's usual place of residence. For purchase units that have events that may occur outside the hospital where a facility code is available in the facility code table then enter it but it must reflect the location of the event. If no facility code is available leave the field blank. Examples: For DOM101-Professional nursing services provided in the community which will occur in the patients home use location code 5 Private Residence and leave facility code blank For S00008 Minor Operations e.g. Skin Lesions provided in GP Practice use location code 12 Primary Care and the facility code of that GP Practice from facility code table Unit record information with Facility codes will not be provided to members of the public without the permission of the agency involved. See the Data Access Policy on the Ministry of Health web site at While a facility code may already exist in the facility code table on the Ministry of Health website, Data Management Services must take specific action to add a valid facility code to the data mart facility table to allow NNPAC events to be loaded with those facilities. DHBs must request facilities to be 'enabled' for use in NNPAC. Must be a valid facility code Mandatory if location type is a hospital facility Location type Version 2.47 MoH 47

48 NNPAC event fact table Facility dimension key Generated artificial key for the dim_agency_facility table based on the service facility. dim_facility_key fact_nap_event integer Version 2.47 MoH 48

49 NNPAC event fact table Funding agency code The agency/dhb of the principal purchaser. funding_agency_code fact_nap_event varchar2(64) XXXX For further information contact Analytical Services. Contact details are given at the front of this dictionary. Funding agency will be reported in the new version of the load file v5.0. Mandatory for events with a purchaser code of 20, 33, 34, 35, 55, A0. Must be a valid Agency Code and must align with the Purchaser Code. See Section 14.2 of the NMDS File Specification v015.5 Version 2.47 MoH 49

50 NNPAC event fact table Gender The sex of a person retrieved from the patient's NHI record. gender fact_nap_event varchar2(64) A M = Male F = Female U = Unknown I = Indeterminate Version 2.47 MoH 50

51 NNPAC event fact table Geo dimension key Generated artificial key for the dim_geo table. dim_geo_key fact_nap_event integer stage_nap_event.domicile_code=dim_geo.domicile_code '0' means undefined. Ministry of Health system-generated. Version 2.47 MoH 51

52 NNPAC event fact table Global time dimension key Generated artificial key for the dim_nap_event_end_date table dim_nap_event_end_date_key fact_nap_event integer Maps to dim_global_time for reports based on calendar year and financial year Version 2.47 MoH 52

53 NNPAC event fact table HCU identifiable dimension key Generated artificial key for the dim_hcu_identifiable table. dim_hcu_identifiable_key fact_nap_event integer Version 2.47 MoH 53

54 NNPAC event fact table Health care user dimension key Generated artificial key for the dim_health_care_user table. dim_health_care_user_key fact_nap_event integer '0' means undefined. Ministry of Health system-generated. Version 2.47 MoH 54

55 NNPAC event fact table Health provider type A description of the lead clinician for the event. health_provider_type fact_nap_event varchar2(64) Health practitioner type A M (doctor) N (nurse) O (other) Nurse practitioners are counted as nurses. Midwives are included in 'other'. Where an event is with a multi-disciplinary team, default to the lead clinician. Version 2.47 MoH 55

56 NNPAC event fact table Health specialty code A classification describing the specialty or service to which a healthcare user has been assigned, which reflects the nature of the services being provided. health_specialty_code fact_nap_event varchar2(64) Health specialty The health specialty managing a patient's care. ANN See the Health Specialty code table on the Ministry of Health web site at For further information or a printed copy of the code table, contact Analytical Services. Generalist and specialist subspecialty medical and surgical health specialty codes were retired from 1July Validation was introduced on 1 July 2007 to reject events with a Date Of Service outside the Health Specialty Codes' start and end date. Events with a Date Of Service before 1 July 2007 that is outside the Health Specialty Code's start and end date will not be rejected. Must be a valid code in the code table. Version 2.47 MoH 56

57 NNPAC event fact table Health specialty dimension key Generated artificial key for the dim_health_specialty table. dim_health_specialty_key fact_nap_event integer Version 2.47 MoH 57

58 NNPAC event fact table IDF DHB dimension key This is the IDF DHB although it is actually a key to the DHB Reference dimension table. IDF DHB source is used to determine which DHB code to use when getting the dim key for the IDF DHB dim_idf_dhb_key fact_nap_event integer The DHB code to be used is determined as follows: If Sent domicile rating = 'Current', the DHB code (retrieved from dim_geo) is the one that relates to Sent domicile code If Sent domicile rating is not 'Current' and NHI domicile code is present and not overseas or undefined (prefixed with 'BD'), the DHB code (retrieved from dim_geo) is the one that relates to the NHI domicile code. If neither of the above, the DHB code is derived from the Extract system identifier on the input file (ie. the DHB that submitted the file). Sent domicile code, Sent domicile rating, Domicile code Version 2.47 MoH 58

59 NNPAC event fact table IDF DHB source This is a derived field indicating the source field used to determine the IDF DHB. idf_dhb_source fact_nap_event varchar2(14) 'Sent domicile' when Sent domicile rating = 'Current' 'NHI domicile' when Sent domicile rating is not 'Current' and NHI domicile code is present and not overseas or undefined (ie. Prefixed with 'BD') 'Submitting DHB' when neither of the above apply IDF DHB, Sent domicile rating, Domicile code (NHI) Version 2.47 MoH 59

60 NNPAC event fact table Location/Activity Setting Where an event takes place location fact_nap_event integer Location type Location code Activity setting See the Location code table in Appendix E. Refer to Section in the File Specification document for NNPAC for events that occur outside a hospital. From 1 July 2014 to 30 June 2015, Mode of Delivery codes were collected in the Location column. However, with effect from 1 July 2015, Mode of Delivery is collected in a separate field in Version 6.0 of the NNPAC input file to enable the existing Location field to be used purely for the collection of location codes. All prior records wherein the mode of delivery code was collected in the location code field have been updated with a location value of 0 Unknown, and the existing value has been translated to the new mode of delivery code set and added to the mode of delivery column. Facility code Version 2.47 MoH 60

61 NNPAC event fact table Location dimension key Generated artificial key for the dim_location table. dim_location_key fact_nap_event integer Version 2.47 MoH 61

62 NNPAC event fact table Mode of Delivery Where an event takes place mode_of_delivery_code fact_nap_event varchar2(64) It is important for DHBs to be able to identify how healthcare is delivered to patients enabling trends and costs to be evaluated. A See the Mode of Delivery code table in Appendix E. Refer to Section in the File Specification document for NNPAC for events that occur outside a hospital. Please see Appendix E for the guidelines produced by the Common Counting Technical Advisory Group (CCTAG). From 1 July 2014 to 30 June 2015, this was collected in the same field as the Location Code. However, with effect from 1 July 2015, Mode of Delivery is collected in a separate field in Version 6.0 of the NNPAC input file to enable the existing location field to be used purely for the collection of location codes. All prior records wherein the mode of delivery code was collected in the location code field have been updated with a location value of 0 Unknown, and the existing value has been translated to the new mode of delivery code set and added to the mode of delivery column. Version 2.47 MoH 62

63 NNPAC event fact table Mode of Delivery dimension key Generated artificial key for the dim_mode_of_delivery table. dim_lmode_of_delivery_key fact_nap_event integer Version 2.47 MoH 63

64 NNPAC event fact table NAP codes dimension key Generated artificial key for the dim_nap_codes table. dim_nap_codes_key fact_nap_event integer Generated artificial key #,##0 Version 2.47 MoH 64

65 NNPAC event fact table NAP date of service dimension key Generated artificial key for the dim_nap_date_of_service table dim_nap_date_of_servic_key fact_nap_event integer Version 2.47 MoH 65

66 NNPAC event fact table NAP event end type dimension key Generated artificial key for the dim_nap_event_end_type table dim_nap_event_end_type_key fact_nap_event integer Version 2.47 MoH 66

67 NNPAC event fact table NAP time of service dimension key Generated artificial key for the dim_nap_time_of_service table dim_nap_time_of_servic_key fact_nap_event integer Version 2.47 MoH 67

68 NNPAC event fact table NAP triage level dimension key Generated artificial key for the dim_nap_triage_level table dim_nap_triage_level_key fact_nap_event integer Version 2.47 MoH 68

69 NNPAC event fact table NHI number A unique 7-character identification number assigned to a healthcare user by the National Health Index (NHI) database. nhi_number fact_nap_event varchar2(64) Health care user id, HCU id NHI numbers uniquely identify healthcare users, and allow linking between different data collections. AAANNNN The first three characters of an NHI number must be alpha (but not 'I' or 'O'). The 4th to 6th characters must be numeric. The 7th character is a check digit modulus 11. This may not be the master NHI. The master NHI should be used where it is known. There is a verification algorithm which ensures that the NHI number is in the correct format and is valid. Version 2.47 MoH 69

70 NNPAC event fact table NMDS unique identifier NMDS PMS unique event identifier nmds_unique_identifier fact_nap_event varchar2(64) X(14) The Ministry wants to be able to link NNPAC, NBRS and NMDS events for the same patient using the identifier fields reported in each record. - NMDS file spec: PMS unique identifier - NBRS file spec: Client system identifier - NNPAC file spec: NMDS PMS unique Therefore if an ED patient is admitted into a ward then the NNPAC identifier needs to be the same as the NMDS identifier code. Mandatory for emergency department events with Equivalent purchase unit code like ED%A and Attendance code like A for all events with a Datetime of service > 1 July 2010 Leading and trailing blanks will be trimmed off in the load process. Version 2.47 MoH 70

71 NNPAC event fact table PMS unique identifier A unique ID for the event generated by the source system. pms_unique_identifier fact_nap_event varchar2(64) X(14) Used to trace the source record Leading and trailing blanks trimmed during the load Version 2.47 MoH 71

72 NNPAC event fact table Purchase unit dimension key Generated artificial key for the dim_purchase_unit table. dim_purchase_unit_key fact_nap_event integer Version 2.47 MoH 72

73 NNPAC event fact table Purchaser code A code used to describe which organisation (purchaser) purchased the service. purchaser_code fact_nap_event varchar2(64) Principal purchaser, Health purchaser, Purchaser code, PHP, Purchase code See the Purchaser code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. See Appendix H: Guide for Use of Purchaser Code Must be a valid purchaser code. From 1 July 2007 the purchaser code must be active for the Date of Service. National Data Policy Group. Version 2.47 MoH 73

74 NNPAC event fact table Purchaser code dimension key Generated artificial key for the dim_purchaser_code table. dim_purchaser_code_key fact_nap_event integer Version 2.47 MoH 74

75 NNPAC event fact table Sent domicile code Domicile code submitted by the DHB. sent_domicile_code fact_nap_event varchar2(64) XXNN See the Domicile code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. The DHB should submit the domicile code from the NHI at the time of the event. If the address of the patient has changed, the new address should be entered into the NHI and the newly generated domicile code should be submitted to NNPAC. Data quality checks are made to ensure that the sent domicile code matches the NHI domicile code. Used to derive the IDF DHB. All codes are accepted but if they are invalid the IDF DHB is derived from the NHI domicile code. Must be a valid code in the Domicile code table Includes leading zeroes. Domicile code, Sent domicile rating Version 2.47 MoH 75

76 NNPAC event fact table Sent domicile rating This is a derived field that provides a data quality rating of the submitted domicile code. This rating is used when determining the IDF DHB source for the health care user. sent_domicile_rating fact_nap_event varchar2(7) 'Current' - the submitted domicile code is valid and is current 'Invalid' - the submitted domicile code is invalid (it cannot be found in the dim_geo table). 'Retired' - the submitted domicile code has been retired Sent domicile code, IDF DHB source Version 2.47 MoH 76

77 NNPAC event fact table Sent geo dimension key Generated artificial key for the dim_sent_geo table. dim_sent_geo_key fact_nap_event integer stage_nap_event.sent_domicile_code=dim_sent_geo.domicile_code Version 2.47 MoH 77

78 NNPAC event fact table Service type Type of service service_type fact_nap_event varchar2(64) X(8) 'First' 'Followup' 'Preadm' 'CRD' As defined in the Nationwide Service Framework Data Dictionary: FIRST Face-to-face client contact (including telemedicine) by registered medical practitioner or nurse practitioner for first assessment for that client for that condition for that specialty. This includes follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. FOLLOWUP Subsequent face-to-face client consultation by registered medical practitioner or nurse practitioner for the same condition in the same specialty. This does not include follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. Service is provided in a ward and/or at a designated outpatient clinic or other suitable setting. PREADM (Pre-admission) Attendance at a clinic where the purpose is to medically/anaesthetically assess prior to an elective procedure. CRD (Community Referred Diagnostic) The Community Referred Diagnostic Event should only be used when the diagnostic is independent of any FSA follow up or treatment procedure and has been ordered by the GP. Mandatory for all events with a Date of Service on or after 1 July 2010 Event type Version 2.47 MoH 78

79 NNPAC event fact table Submitting DHB dimension key Generated artificial key for the dim_submitting_dhb table dim_submitting_dhb_key fact_nap_event integer Version 2.47 MoH 79

80 NNPAC event fact table Triage level Scale of assessment of clinical urgency triage_level fact_nap_event integer N See the Triage Level code table in Appendix E. Mandatory for ED events with Datetime of service on or after 1 July 2010 and attendance code 'ATT' If not supplied, this field is set to zero Australasian Triage scale Australasian College for Emergency Medcine Version 2.47 MoH 80

81 NNPAC event fact table Volume Volume of purchase units volume fact_nap_event number NNNNN.NNN (floating point) Volume is dependent on the Unit of Measure of the purchase unit. If the IDF Unit of measure is 'Event' the volume should be 1. If the IDF Unit of measure is client the volume should be 0. If the IDF Unit of Measure is 'Volume' then the volume will reflect an amount relevant to the unit of measure. E.g. Community Radiology is purchased by relative value units (RVU) and the volume of RVU, which can be a fraction, should be recorded. All DNAs and DNWs should have a volume of 0. All purchase units with a purchase unit type = P preadmission should have a volume of 0. Note: This is defined as a number not an integer and will accept decimal places if required (valid volumes include, for example, 0, 0.25, 1, 5.5, 200). Purchase unit code, Unit of measure and IDF unit of measure, Attendance code, Purchase unit type Version 2.47 MoH 81

82 NNPAC event snapshot fact table NNPAC event snapshot fact table fact_nap_event_snapshot A snapshot of the fact_nap_event table for a particular finaincial year. Primary key Business key client_system_identifier, pms_unique_identifier, financial_year Used by MOH Funding & Performance to provide a historical record of what their calculations were based on. KEY: Dim Affiliation key Dim Age band key Dim Agency key Dim Alcohol Involved Key Dim Facility key Dim Geo key Dim Health care user key Dim Health specialty key Dim Mode of Delivery Dim NAP affiliation key Dim NAP codes key Dim NAP date of service key Dim NAP time of service key Dim Purchase unit key Dim Purchaser code key Dim Time of the day key LINKED TO: Affiliation table (dim_affiliation) - Shared Dimension Age band table (dim_age_band) - Shared Agency Facility table (dim_agency_facility) - Shared Alcohol Involved talb (dim_alcohol_involved) - Shared Agency Facility table (dim_agency_facility) - Shared Geo table (dim_geo) - Shared Healthcare User table (dim_healthcare_user) - Shared Health Specialty table (dim_health_specialty) Shared Mode of Delivery table (dim_mode_of_delivery) - Shared Affiliation table (dim_affiliation) - Shared NAP Codes table (dim_nap_codes) Global time table (dim_global_time) - Shared Global time table (dim_global_time) - Shared Purchase Unit table (dim_purchase_unit) - Shared Purchaser Code table (dim_purchaser_code) - Shared Time of day table (dim_time_of_day) - Shared Relational rules Refer to Guide for Use Data content Version 2.47 MoH 82

83 NNPAC event snapshot fact table ACC claim number This is a separate field to record the M46/45, ACC45 or AITC claim number for the event. acc_claim_number fact_nap_event_snapshot varchar2(64) X(12) This is a free text field to allow historical claim numbers, which come in many formats, to be provided. Valid only if accident flag = 'Y' Optional Should match associated NMDS event of patient admitted and treated following Emergency Department NNPAC event. Version 2.47 MoH 83

84 NNPAC event snapshot fact table Accident flag A flag that denotes whether a person is receiving care or treatment as the result of an accident. accident_flag fact_nap_event_snapshot varchar2(64) A Y The health event/treatment is assumed to be or is assessed as the result of an accident N The health event/treatment is the result of an illness. U Unknown. For this to be 'Y', the healthcare user should be admitted as a result of an accident. This would be either an acute case or someone returning for treatment (in which case an ACC Claim Number would be required). Mandatory field. Must match flag in NMDS for admissions from the Emergency Department with Purchase Unit Codes like 'ED%A' ACC claim number Version 2.47 MoH 84

85 NNPAC event snapshot fact table Affiliation dimension key Generated artificial key for the dim_affiliation table. dim_affiliation_key fact_nap_event_snapshot integer '0' means undefined. Links NHI submitted to ethnicity and domicile information via the dim_hcu table Version 2.47 MoH 85

86 NNPAC event snapshot fact table Age at time of visit Age at time of visit. age_at_visit fact_nap_event_snapshot integer NNN Derived field. Date of Service - Date of birth from dim_hcu Version 2.47 MoH 86

87 NNPAC event snapshot fact table Age band dimension key Generated artificial key for the dim_age_band table. dim_age_band_key fact_nap_event_snapshot integer Derived from the health care user's age at the time of visit. Used to construct reports based on age bands Version 2.47 MoH 87

88 NNPAC event snapshot fact table Agency code A code that uniquely identifies the agency contracted directly with the Ministry of Health to provide the service agency_code fact_nap_event_snapshot varchar2(64) Health agency code, DHB code XXXX See the Agency code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Version 2.47 MoH 88

89 NNPAC event snapshot fact table Agency dimension key Generated artificial key for the dim_agency_facility table based on the funding agency. dim_agency_key fact_nap_event_snapshot integer System generated artificial key Version 2.47 MoH 89

90 NNPAC event snapshot fact table Alcohol Involved alcohol_involved_flag fact_nap_event_snapshot varchar2(64) Alcohol Involved Flag In order to better understand the impact of alcohol consumption on emergency department resources, five pilot DHBs are required to submit a value for emergency department presentations with effect from 1 July These DHBs are Capital & Coast, Whānganui, Lakes, Southern and Waikato. The collection of this information is being piloted to assist determining the trends and rates of patients presentations to emergency departments and inform the decision to roll out to all emergency departments nationally. A Y Yes (agreement with the Alcohol Involved question) N No (disagreement with the Alcohol Involved question) U Not known S Secondary (presentation is as a consequence of others alcohol consumption) The Alcohol Involved field are mandatory for the pilot DHBs with effect from 1 July Non pilot DHBs are not required to submit values. Emergency Department Advisory Group (EDAG). Version 2.47 MoH 90

91 NNPAC event snapshot fact table Alcohol Involved dimension key Generated artificial key for the dim_alcohol_involved table. dim_alcohol_involved_key fact_nap_event_snapshot integer Alcohol Involved Flag Version 2.47 MoH 91

92 NNPAC event snapshot fact table Attendance code Attendance code for the Health Care User event. attendance_code fact_nap_event_snapshot varchar2(64) AAA ATT (attended) DNA (did not attend) DNW (did not wait) ATT (Attended) An attendance is where the healthcare user is assessed by a registered medical practitioner or nurse practitioner. The healthcare user received treatment, therapy, advice, diagnostic or investigatory procedures. DNA (Did Not Attend) Where general outpatient did not arrive, this is classed as did not attend. DNW (Did Not Wait) Used for ED where the patient did not wait. Also for use where general outpatient arrives but does not wait to receive service. Mandatory Version 2.47 MoH 92

93 NNPAC event snapshot fact table Batch number An identifier for a group of events that have been processed together. batch_number fact_nap_event_snapshot integer Version 2.47 MoH 93

94 NNPAC event snapshot fact table Client system identifier A unique Identifier for each source system client_system_identifier fact_nap_event_snapshot varchar2(64) A unique Identifier for each source system will be defined by the DHB and notified to the Ministry of Health. Thus each DHB may have multiple CSIs. To enable individual records to be identified, this will be combined with the PMS unique ID. This means individual records for an individual DHB can be readily identified when source systems use the same number range. New client system identifiers need to be registered with the Ministry of Health and must be associated with an extract system identifier New client system identifiers need to be registered with the Ministry of Health and must be associated with an extract system identifier Extract system identifier Version 2.47 MoH 94

95 NNPAC event snapshot fact table Date of birth The date on which the person was born. date_of_birth fact_nap_event_snapshot date CCYYMMDD Valid dates Partial dates are permissible. At a minimum the century and year must be supplied. If day is provided but month is omitted then the day will not be recorded. Incomplete dates are stored as 'CCYY0101' or 'CCYYMM01' and a partial date flag associated with the date is set to the appropriate value. Version 2.47 MoH 95

96 NNPAC event snapshot fact table Datetime of departure The date and time of the physical departure of the patient from ED datetime_of_departure fact_nap_event_snapshot date CCYYMMDDhhmm Valid dates and times The date and time of the physical departure of the patient from ED to an inpatient ward, or the time at which a patient begins a period of formal observation (whether in ED observation beds, an observation unit, or similar), or the time at which a patient being discharged from the ED to the community physically leaves the ED. The datetime of departure is the time at which the patient is physically moved from ED to an inpatient ward, or the time at which a patient begins a period of formal observation, whether in ED observation beds, an observation unit, or similar. The physical move will follow, or be concurrent with, a formal admission protocol, but it is the patient movement that stops the clock on the emergency event, not associated administrative decisions or tasks. Inpatient wards include short stay units (or units with a similar function). Under certain circumstances, a `decant ward designed to deal with surge capacity will qualify as an inpatient ward. Key criteria are that patients should be in beds rather than on trolleys, and be under the care of appropriate clinical staff. A formal observation area generally has dedicated space, dedicated staffing, and fixed capacity (beds). In relation to transfers to an APU; if there is a clinical intervention and supervision by ED staff over and above triage, then the time from presentation to transfer should be counted in reporting against the ED LOS target. Otherwise, it should be excluded. Datetime of departure is the time at which a patient being discharged from the ED to the community physically leaves the ED. If a patient s treatment is finished, and they are waiting in the ED facilities only as a consequence of their personal transport arrangements for pickup, they can be treated as discharged for the purposes of this measure. If the patient goes home then returns to become an inpatient, then the clock stops at the point they leave the ED. If the patient goes home then returns to ED for further care, it is counted as another ED admission. If not supplied this field will be set to (i.e. 31/12/ :59) Mandatory for ED events with Datetime of service on or after 1 July 2010 and attendance code 'ATT'. If not supplied this field will be set to (i.e. 31/12/ :59) Must be on or after Datetime of Event End Version 2.47 MoH 96

97 NNPAC event snapshot fact table Version 2.47 MoH 97

98 NNPAC event snapshot fact table Datetime of event end The date and time on which the event ended. datetime_of_event_end fact_nap_event_snapshot date For ED events this field records the change in administrative status. For ED patients who have an NMDS event recorded, this is the datetime the NMDS event is assumed to have commenced. For all other patients this is the same as datetime of departure. CCYYMMDDhhmm Valid dates Retired in July Introduced as date of event end in 2008 to record where an ED event went past midnight. Replaced with datetime of event end in 2010 to be consistent with other datetime field changes. Other datetimes now collected on ED events supersede the need to collect this date. This field recorded a change in a patient's administrative status rather than a change in physical location. It was used as follows: - For all events that had an NMDS event recorded, ED event end datetime was the date time that the NMDS event was assumed to have commenced. This may not have been the same as the datetime of departure from ED. - For all other patients the ED event end datetime was the same as the datetime of departure from ED. After 1 July 2011 this field will automatically be populated with 31/12/ :59 This was an optional field. From 1 July 2010 to 30 June 2011, if not submitted on an ED event it was populated with the Datetime of Departure. If not submitted on outpatient events it was populated with the date of service and time of 23:59. Datetime of Service, Datetime of Departure Version 2.47 MoH 98

99 NNPAC event snapshot fact table Datetime of first contact The date and time that the triaged patient's treatment starts by a suitable ED medical professional (could be the same time as the datetime of service if treatment begins immediately). datetime_of_first_contact fact_nap_event_snapshot date CCYYMMDDhhmm Valid dates and times Mandatory for ED events with Datetime of Service on or after 1 July 2010 and attendance code of 'ATT'. If not supplied this field will be set to (i.e. 31/12/ :59) Must be on or after Datetime of Service Datetime of Service Version 2.47 MoH 99

100 NNPAC event snapshot fact table Datetime of presentation The date and time a patient presents/or is presented physically to the ED department; either the triage nurse or clerical staff, whichever comes first datetime_of_presentation fact_nap_event_snapshot date CCYYMMDDhhmm Valid date and time. Mandatory for ED events with Datetime of service on or after 1 July 2010 If not supplied this field will be set to (i.e. 31/12/ :59) Datetime of service Version 2.47 MoH 100

101 NNPAC event snapshot fact table Datetime of service The date and time on which the outpatient event took place for non ED events. For ED events it is the date and time the triage nurse/suitable ED medical professional starts the process of categorising the triage level of the incoming patient. datetime_of_service fact_nap_event_snapshot date CCYYMMDDhhmm Valid date and time. The appropriate standard of care is for the first contact with staff in the ED to be with a triage nurse ('triage first'), so this datetime ideally should be the same as 'datetime of presentation.' However, it is understood that patients may present to a receptionist first in some departments, or may wait in a triage queue on some occasions. Hence 'datetime of presentation' and 'datetime of triage' are recorded separately. However, DHBs should endeavour to have 'triage first' and to ensure triage is undertaken immediately upon the patient's arrival. Note the 'datetime of triage' is from the start of triage. It is understood that many EDs record the time the triage nurse 'files' the electronic triage record for the patient and that this is often towards the end of the triage process. DHBs with EDs of this sort should endeavour to have a system which electronically records the start of triage. For outpatient visits the time of service should be the actual service start time if available. If not, then the booked appointment time may be used or a default time of 0000 may be sent. The format for this would be CCYYMMDD0000. Must be: a valid date; on or before the NNPAC processing date; not more than 20 years before the NNPAC processing date Must be on or before Datetime of First Contact Datetime of Presentation, Datetime of First Contact Version 2.47 MoH 101

102 NNPAC event snapshot fact table Dim funding agency code key dim_funding_agency_code_key fact_nap_event_snapshot integer Version 2.47 MoH 102

103 NNPAC event snapshot fact table Domicile code Domicile code retrieved from the patient's NHI record (the NHI address history that relates to the date of service). Used to determine the DHB of domicile only if the sent domicile code is invalid. domicile_code fact_nap_event_snapshot varchar2(64) AAAA See the Domicile code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Statistics NZ Health Domicile Code representing a person's usual residential address. Also used for facility addresses. Usual residential address is defined as the address at which the person has been, or plans to be, living for 3 months or more. (Statistics NZ definition of 'usually resident'.) If a person usually lives in a rest home or a hospital, that is considered their usual residential address. This is used as a data quality test to compare with the sent domicile code and is also used for deriving the patient's DHB of domicile. Must be a valid code in the Domicile Code table. Includes leading zeroes. Sent domicile, IDF DHB source, Dim IDF DHB Version 2.47 MoH 103

104 NNPAC event snapshot fact table Equivalent purchase unit Purchase unit indicates which contract the event is funded under. equivalent_purchase_unit fact_nap_event_snapshot varchar2(64) X(8) For DNA (Did Not Attend) or DNW (Did Not Wait) is the Purchase Unit that would have allocated had they attended or waited. For ED attendances where only ED service is triage, the purchase unit is ED Purchase Unit Codes are defined by the Nationwide Service Framework Data Dictionary (see the Ministry website at They are updated annually and are subject to change according to financial year. For example 2006/07 financial year data should be compliant with v11 of the NSF Data Dictionary, 2007/08 financial year data should be compliant with v12 of the NSF Data Dictionary and so on. Purchase unit start and end date validation is based on date of service Version 2.47 MoH 104

105 NNPAC event snapshot fact table Ethnicity code 1 Ethnic affiliation. ethnicity_code_1 fact_nap_event_snapshot varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 105

106 NNPAC event snapshot fact table Ethnicity code 2 Ethnic affiliation ethnicity_code_2 fact_nap_event_snapshot varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. Ethnic code represents a social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 106

107 NNPAC event snapshot fact table Ethnicity code 3 Ethnic affiliation ethnicity_code_3 fact_nap_event_snapshot varchar2(64) See the Ethnicity code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A social group whose members have one or more of the following four characteristics: - they share a sense of common origins - they claim a common and distinctive history and destiny - they possess one or more dimensions of collective cultural individuality - they feel a sense of unique collective solidarity. Version 2.47 MoH 107

108 NNPAC event snapshot fact table Event end date submitted Whether the Event End Date Time was provided in an extract or set to the default during the load process. end_date_submitted_flag fact_nap_event_snapshot char(1) 'Y' - the Event End Date Time was submitted 'N' - the Event End date was set to the Date of Service and time of 23:59 The default for Event End date was set to the Date of Service and time of 23:59 Derived during the NNPAC Load process. Datetime of event end Version 2.47 MoH 108

109 NNPAC event snapshot fact table Event end type code A code identifying how a healthcare event ended event_end_type_code fact_nap_event_snapshot varchar2(64) AA See the Event End Type code table in Appendix E. DW may be used on events that are transferred from ED to an inpatient event. Mandatory for ED events with Datetime of service on or after 1 July Must be a valid code in the Event End Type code table. If not supplied, this field is set to 'UN' Datetime of departure Version 2.47 MoH 109

110 NNPAC event snapshot fact table Event type Code identifying the type of health event. event_type fact_nap_event_snapshot varchar2(64) AA CR (community referred diagnostic) ED (emergency department) OP (outpatient) From 1 Jul 2008 to 31 June 2010, the Event Type was determined from the submitted Purchase Unit Code. From 1st July 2010 the direct reporting of Event type is mandatory as opposed to being derived from the Equivalent Purchase Unit. 'CR' was introduced on 1st July Equivalent purchase unit Version 2.47 MoH 110

111 NNPAC event snapshot fact table Extract system identifier The identifier of the system the data was extracted from. extract_system_identifier fact_nap_event_snapshot varchar2(64) Unique identifiers for each combination of DHB and Extract system are defined by the DHB and notified to the Ministry of Health. Thus each DHB may have multiple ESI. This may not necessarily be the same as the source data system(s). It is recommended that the first three characters define the DHB. Client system identifier Version 2.47 MoH 111

112 NNPAC event snapshot fact table Facility code A code that uniquely identifies a healthcare facility. facility_code fact_nap_event_snapshot varchar2(64) Health agency facility code, Hospital, HAF code, HAFC. The location of the event X(4) See the Facility code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. A healthcare facility is a place, which may be a permanent, temporary, or mobile structure that healthcare users attend or are resident in for the primary purpose of receiving healthcare or disability support services. This definition excludes telehealth, supervised hostels, halfway houses, staff residences, and rest homes where the rest home is the patient's usual place of residence. The facility code for use with telehealth is that of the facility where the service is being delivered from. For purchase units that have events that may occur outside the hospital where a facility code is available in the facility code table then enter it but it must reflect the location of the event. If no facility code is available leave the field blank. Examples: For DOM101-Professional nursing services provided in the community which will occur in the patients home use location code 5 Private Residence and leave facility code blank For S00008 Minor Operations eg Skin Lesions provided in GP Practice use location code 12 Primary Care and the facility code of that GP Practice from facility code table Unit record information with Facility codes will not be provided to members of the public without the permission of the agency involved. See the Data Access Policy on the Ministry of Health web site at While a facility code may already exist in the facility code table on the Ministry of Health website, Data Management Services must take specific action to add a valid facility code to the data mart facility table to allow NNPAC events to be loaded with those facilities. DHBs must request facilities to be 'enabled' for use in NNPAC. Must be a valid facility code Mandatory if location type is a hospital facility Location type Ministry of Health Version 2.47 MoH 112

113 NNPAC event snapshot fact table Facility dimension key Generated artificial key for the dim_agency_facility table based on the service facility. dim_facility_key fact_nap_event_snapshot integer Version 2.47 MoH 113

114 NNPAC event snapshot fact table Financial year The financial year derived from the Date of Service, which starts from 1 July and finishes 30 June. financial_year fact_nap_event_snapshot varchar2(64) Datetime of Service Version 2.47 MoH 114

115 NNPAC event snapshot fact table Funding agency code The agency/dhb of the principal purchaser. funding_agency_code fact_nap_event_snapshot varchar2(64) XXXX See the Agency code table on the Ministry of Health web site at For further information or a printed copy of the code table, contact the Analytical Services. Funding agency will be reported in the new version of the load file v5.0. Mandatory for events with a purchaser code of 20, 33, 34, 35, 55, A0. Must be a valid Agency Code and must align with the Purchaser Code. See section on funding agency code NNPAC File Specification. Version 2.47 MoH 115

116 NNPAC event snapshot fact table Gender The sex of a person retrieved from the patient's NHI record. gender fact_nap_event_snapshot varchar2(64) A M = Male F = Female U = Unknown I = Indeterminate Version 2.47 MoH 116

117 NNPAC event snapshot fact table Geo dimension key Generated artificial key for the dim_geo table. dim_geo_key fact_nap_event_snapshot integer stage_nap_event.domicile_code=dim_geo.domicile_code Version 2.47 MoH 117

118 NNPAC event snapshot fact table Global time dimension key Generated artificial key for the dim_nap_event_end_date table dim_nap_event_end_date_key fact_nap_event_snapshot integer Maps to dim_global_time for reports based on calendar year and financial year Version 2.47 MoH 118

119 NNPAC event snapshot fact table Health care user dimension key Generated artificial key for the dim_health_care_user table. dim_health_care_user_n_key fact_nap_event_snapshot integer Version 2.47 MoH 119

120 NNPAC event snapshot fact table Health provider type A code for the registration body of the provider. health_provider_type fact_nap_event_snapshot varchar2(64) Health practitioner type A M (doctor) N (nurse) O (other) Nurse practitioners are counted as nurses. Midwives are included in 'other'. Where an event is with a multi-disciplinary team, default to the lead clinician. Version 2.47 MoH 120

121 NNPAC event snapshot fact table Health specialty code A classification describing the specialty to which a healthcare user has been assigned, which reflects the nature of the healthcare being provided. health_specialty_code fact_nap_event_snapshot varchar2(64) ANN See the Health Specialty code table on the Ministry of Health web site at Generalist and specialist subspecialty medical and surgical health specialty codes were retired from 1July Validation was introduced on 1 July 2007 to reject events with a Date Of Service outside the Health Specialty Codes' start and end date. Events with a Date Of Service before 1 July 2007 that is outside the Health Specialty Code's start and end date will not be rejected. Version 2.47 MoH 121

122 NNPAC event snapshot fact table Health specialty dimension key Generated artificial key for the dim_health_specialty table. dim_health_specialty_key fact_nap_event_snapshot integer Version 2.47 MoH 122

123 NNPAC event snapshot fact table IDF DHB dimension key This is the IDF DHB although it is actually a key to the DHB Reference dimension table. IDF DHB source is used to determine which DHB code to use when getting the dim key for the IDF DHB dim_idf_dhb_key fact_nap_event_snapshot integer The DHB code to be used is determined as follows: If Sent domicile rating = 'Current', the DHB code (retrieved from dim_geo) is the one that relates to Sent domicile code If Sent domicile rating is not 'Current' and NHI domicile code is present and not overseas or undefined (prefixed with 'BD'), the DHB code (retrieved from dim_geo) is the one that relates to the NHI domicile code If neither of the above, the DHB code is derived from the Extract system identifier on the input file (ie. the DHB that submitted the file) Sent domicile code, Sent domicile rating, Domicile code Version 2.47 MoH 123

124 NNPAC event snapshot fact table IDF DHB source This is a derived field indicating the source field used to determine the IDF DHB. idf_dhb_source fact_nap_event_snapshot varchar2(14) 'Sent domicile' when Sent domicile rating = 'Current' 'NHI domicile' when Sent domicile rating is not 'Current' and NHI domicile code is present and not overseas or undefined (ie. Prefixed with 'BD') 'Submitting DHB' when neither of the above apply IDF DHB, Sent domicile rating, Domicile code (NHI) Version 2.47 MoH 124

125 NNPAC event snapshot fact table Location/Activity Setting Where an event takes place location fact_nap_event_snapshot integer Location type Location code Activity setting See the Location code table in Appendix E. Refer to Section in the File Specification document for NNPAC for events that occur outside a hospital. Facility code Version 2.47 MoH 125

126 NNPAC event snapshot fact table Location dimension key Generated artificial key for the dim_location table. dim_location_key fact_nap_event_snapshot integer Version 2.47 MoH 126

127 NNPAC event snapshot fact table Mode of Delivery Where an event takes place mode_of_delivery_code fact_nap_event_snapshot varchar2(64) It is important for DHBs to be able to identify how healthcare is delivered to patients enabling trends and costs to be evaluated. A See the Mode of Delivery code table in Appendix E. Refer to Section in the File Specification document for NNPAC for events that occur outside a hospital. Please see Appendix E for the guidelines produced by the Common Counting Technical Advisory Group (CCTAG). From 1 July 2014 to 30 June 2015, this was collected in the same field as the Location Code. However, with effect from 1 July 2015, Mode of Delivery is collected in a separate field in Version 6.0 of the NNPAC input file to enable the existing location field to be used purely for the collection of location codes. All prior records wherein the mode of delivery code was collected in the location code field have been updated with a location value of 0 Unknown, and the existing value has been translated to the new mode of delivery code set and added to the mode of delivery column. Version 2.47 MoH 127

128 NNPAC event snapshot fact table Mode of Delivery dimension key Generated artificial key for the dim_mode_of_delivery table. dim_mode_of_delivery_key fact_nap_event_snapshot integer Version 2.47 MoH 128

129 NNPAC event snapshot fact table NAP codes dimension key Generated artificial key for the dim_nap_codes table. dim_nap_codes_key fact_nap_event_snapshot integer Generated artificial key #,##0 Version 2.47 MoH 129

130 NNPAC event snapshot fact table NAP date of service dimension key Generated artificial key for the dim_nap_date_of_service table dim_nap_date_of_servic_key fact_nap_event_snapshot integer Version 2.47 MoH 130

131 NNPAC event snapshot fact table NAP event end type dimension key Generated artificial key for the dim_nap_event_end_type table dim_nap_event_end_type_key fact_nap_event_snapshot integer Version 2.47 MoH 131

132 NNPAC event snapshot fact table NAP time of service dimension key Generated artificial key for the dim_nap_time_of_service table dim_nap_time_of_servic_key fact_nap_event_snapshot integer Version 2.47 MoH 132

133 NNPAC event snapshot fact table NAP triage level key Generated artificial key for the dim_nap_triage_level table dim_nap_triage_level_key fact_nap_event_snapshot integer Version 2.47 MoH 133

134 NNPAC event snapshot fact table NMDS unique identifier NMDS PMS unique event identifier nmds_unique_identifier fact_nap_event_snapshot varchar2(64) X(14) The Ministry wants to be able to link NNPAC, NBRS and NMDS events for the same patient using the identifier fields reported in each record. - NMDS file spec: PMS unique identifier - NBRS file spec: Client system identifier - NNPAC file spec: NMDS PMS unique Therefore if an ED patient is admitted into a ward then the NNPAC identifier needs to be the same as the NMDS identifier code. Mandatory for emergency department events with equivalent purchase unit code like ED%A and attendance code like A for all events with a datetime of service > 1 July 2010 Version 2.47 MoH 134

135 NNPAC event snapshot fact table PMS unique identifier A unique ID for the event generated by the source system. pms_unique_identifier fact_nap_event_snapshot varchar2(64) X(14) Used to trace source the record Leading and trailing blanks trimmed during the load Version 2.47 MoH 135

136 NNPAC event snapshot fact table Purchase unit dimension key Generated artificial key for the dim_purchase_unit table. dim_purchase_unit_key fact_nap_event_snapshot integer Version 2.47 MoH 136

137 NNPAC event snapshot fact table Purchaser code A code used to describe which organisation (purchaser) purchased the service. purchaser_code fact_nap_event_snapshot varchar2(64) Principal purchaser, Health purchaser, Purchaser code, PHP, Purchase code See the Purchaser code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. See Appendix H: Guide for Use of Purchaser Code Must be a valid purchaser code. From 1 July 2007 the purchaser code must be active for the Date of Service. Version 2.47 MoH 137

138 NNPAC event snapshot fact table Purchaser code dimension key Generated artificial key for the dim_purchaser_code table. dim_purchaser_code_key fact_nap_event_snapshot integer Version 2.47 MoH 138

139 NNPAC event snapshot fact table Sent domicile code Domicile code submitted by the DHB. sent_domicile_code fact_nap_event_snapshot varchar2(64) AAAA See the Domicile code table on the Ministry of Health web site at For further information contact Analytical Services. Contact details are given at the front of this dictionary. The DHB should submit the domicile code from the NHI at the time of the event. If the address of the patient has changed, the new address should be entered into the NHI and the newly generated domicile code should be submitted to NNPAC. Data quality checks are made to ensure that the sent domicile code matches the NHI domicile code. Used to derive the IDF DHB. All codes are accepted but if they are invalid the IDF DHB is derived from the NHI domicile code. Must be a valid code in the Domicile code table Domicile code, Sent domicile rating Version 2.47 MoH 139

140 NNPAC event snapshot fact table Sent domicile rating This is a derived field that provides a data quality rating of the submitted domicile code. This rating is used when determining the IDF DHB source for the health care user. sent_domicile_rating fact_nap_event_snapshot varchar2(7) 'Current' - the submitted domicile code is valid and is current 'Invalid' - the submitted domicile code is invalid (it cannot be found in the dim_geo table). 'Retired' - the submitted domicile code has been retired Sent domicile code,, IDF DHB source Version 2.47 MoH 140

141 NNPAC event snapshot fact table Sent geo dimension key Generated artificial key for the dim_sent_geo table. dim_sent_geo_key fact_nap_event_snapshot integer Version 2.47 MoH 141

142 NNPAC event snapshot fact table Service type Type of service service_type fact_nap_event_snapshot varchar2(64) X(8) 'First' 'Followup' 'Preadm' 'CRD' As defined in the Nationwide Service Framework Data Dictionary: FIRST Face-to-face client contact (including telemedicine) by registered medical practitioner or nurse practitioner for first assessment for that client for that condition for that specialty. This includes follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. FOLLOWUP Subsequent face-to-face client consultation by registered medical practitioner or nurse practitioner for the same condition in the same specialty. This does not include follow-up of a post-discharge patient who received their inpatient treatment in a different DHB unless seen in an outreach clinic from that service. The client receives treatment, therapy, advice, diagnostic or investigatory procedures at a healthcare facility, is not admitted, does not receive a general anaesthetic, and the specialist's intent is that they will leave that facility within 3 hours from the start of the consultation. Service is provided in a ward and/or at a designated outpatient clinic or other suitable setting. PREADM (Pre-admission) Attendance at a clinic where the purpose is to medically/anaesthetically assess prior to an elective procedure. CRD (Community Referred Diagnostic) The Community Referred Diagnostic Event should only be used when the diagnostic is independent of any FSA follow up or treatment procedure and has been ordered by the GP. Mandatory for all events with a Date of Service on or after 1 July 2010 Event type Version 2.47 MoH 142

143 NNPAC event snapshot fact table Submitting DHB dimension key Generated artificial key for the dim_submitting_dhb table dim_submitting_dhb_key fact_nap_event_snapshot integer Version 2.47 MoH 143

144 NNPAC event snapshot fact table Triage level Scale of assessment of clinical urgency triage_level fact_nap_event_snapshot integer N See the Triage Level code table in Appendix E. Mandatory for ED events with Datetime of service on or after 1 July 2010 and attendance code 'ATT' If not supplied, this field is set to zero Australasian Triage scale Australasian College for Emergency Medicine Version 2.47 MoH 144

145 NNPAC event snapshot fact table Volume Volume of purchase units volume fact_nap_event_snapshot number NNNNN.NNN (floating point) Volume is dependent on the Unit of Measure of the purchase unit. If the IDF Unit of measure is 'Event' the volume should be 1. If the IDF Unit of measure is client the volume should be 0. If the IDF Unit of Measure is 'Volume' then the volume will reflect an amount relevant to the unit of measure. Eg Community Radiology are purchased by relative value units (RVU) and the volume of RVU, which can be a fraction, should be recorded. All DNAs and DNWs should have a volume of 0. All purchase units with a purchase unit type = P preadmission should have a volume of 0. Note: This is defined as a number not an integer and will accept decimal places if required (valid volumes include, for example, 0, 0.25, 1, 5.5, 200). Purchase unit code, Unit of measure and IDF unit of measure, Attendance code, Purchase unit type Version 2.47 MoH 145

146 NNPAC event snapshot fact table Triage level dimension table dim_nap_triage_level Holds values that define the triage level associated with an ED event Primary key Business key This table has one row per triage level Relational rules Data content Version 2.47 MoH 146

147 NNPAC event snapshot fact table Full description Full description of triage level FULL_DESCRIPTION dim_nap_triage_level varchar2(256) See the Triage Level code table in Appendix E. Version 2.47 MoH 147

148 NNPAC event snapshot fact table Short description Short description of triage level SHORT_DESCRIPTION dim_nap_triage_level VARCHAR2(100) Used when there is limited space for displaying description See the Triage Level code table in Appendix. Version 2.47 MoH 148

149 NNPAC event snapshot fact table Triage level Scale of assessment of clinical urgency TRIAGE_LEVEL dim_nap_triage_level NUMBER(3) See the Triage Level code table in Appendix E. Australasian Triage scale Australasian College for Emergency Medcine Version 2.47 MoH 149

150 Appendix A: Logical to Physical Table Mapping Appendix A: Logical to Physical Table Mapping The following list shows the mapping of the logical, or business, table name to the actual physical table name. Logical (Business) Table Name NNPAC codes dimension table dim_nap_puc_perday_scd Triage level dimension table NNPAC event fact table NNPAC event snapshot fact table Physical Table Name dim_nap_codes dim_nap_puc_perday_scd dim_nap_triage_level fact_nap_event fact_nap_event_snapshot Version 2.47 MoH 150

151 Appendix B: List of Shared Dimensions Appendix B: List of Shared Dimensions Dimension tables are the descriptive or lookup-type tables that link to fact tables. This data mart has a number of shared Dimension tables. The definitions for these dimensions are held in a separate data dictionary called "SHARED Dimensions". The table below lists the shared dimensions within this data mart. Dimension Table Affiliation table (dim_affiliation) Age Band table (dim_age_band) Agency Facility table (dim_agency_facility) Description This table is a matrix of gender and ethnicity code combination. Each row denotes the gender and ethnicity combination applicable to a person at the time of a transaction, i.e. it does not change over time. This dimension table contains a record for each age from 0 to 115 years. The ages are also grouped into 5 and 10 year age bands, the GMS age bands and the PHO CBF Bands This table stores detail of organisations, institutions or groups of institutions that contract directly with the principal health service purchaser to deliver healthcare services to the community. An agency may have a number of facilities (eg, hospita Geo table (dim_geo) Global Time table (dim_global_time) HCU Identifiable table (dim_hcu_identifiable) Health Care User table (dim_health_care_user) Health Specialty table (dim_health_specialty) Location table (dim_location) Purchase Unit table (dim_purchase_unit) Purchaser Code table (dim_purchaser_code) This reference table contains a geographical breakdown of New Zealand at the level of Domicile Code. Each row of the table describes a single Domicile Code, and locates it within broader geographical definitions eg DHB. This table contains a record for every day between 1900 and 2050, with descriptive attributes for each day. This dimension table holds identifiable details of Health Care Users e.g.name, address, ethnicity, date of birth, NHI. This reference table contains information about all people who have received healthcare directly from healthcare providers. A classification describing the specialty or service to which a healthcare user has been assigned, which reflects the nature of the services being provided. This table holds details of the location of the facility where the outpatient event took place. The purchase unit (PU) indicates what contract the event is funded under. PUs are in fact a classification system. PUs are a means of quantifying (volume) and valuing (price) a service. This table holds values that define the organisation or body that purchased the healthcare service provided. Version 2.47 MoH 151

152 Appendix C: List of Views Appendix C: List of Views The table views used in this datamart are shown below. View Name Dim IDF DHB table (dim_idf_dhb) Dim NAP Affiliation table (dim_nap_affiliation) Dim NAP Date of Service table (dim_nap_date_of_service) dim_nap_ed_event_end_type (dim_nap_ed_event_end_type) Dim NAP Event End Date table (dim_nap_event_end_date) Dim NAP Funding Agency table (dim_nap_funding_agency) Dim NAP Service Facility table (dim_nap_service_facility) Dim NAP Time of Service table (dim_nap_time_of_service) Dim Sent Geo table (dim_sent_geo) Dim Submitting DHB table (dim_submitting_dhb) Fact NAP Event id table (fact_nap_event_id) Fact NAP Event ni table (fact_nap_event_ni) Description A view of shared DIM DHB Reference dimension table that contains a list of DHB codes and names. A view of the shared Affiliation table that holds combinations of all possible ethnic codes and gender. A view of the shared Dim Global Time dimension table. View of dim_event_end_type containing only the valid values valid for ED event End. A view of the shared Dim Global Time dimension table. A view of the dim_agency_facility table. Funding Agency would be the purchaser of the Health Cate User event. A view of the dim_agency_facility table that shows those facilites where outpatient or accident and emergency events take place. A view of the shared Dim Global Time dimension table. A view of the shared Dim Geo dimension table. A view of shared DIM DHB Reference dimension table that contains a list of DHB codes and names. A view of the Fact NAP Event table (fact_nap_event) that has an identifiable HCU ID / NHI number. The Fact NAP Event table (fact_nap_event), is not directly visible to end users. A view of the Fact NAP Event table (fact_nap_event) that has neither encrypted or unencrypted HCU ID / NHI number. The Fact NAP Event table (fact_nap_event), is not directly visible to end users. Version 2.47 MoH 152

153 Appendix D: Data Dictionary Template Appendix D: Data Dictionary Template Introduction This appendix explains how data element attributes are organised in the data dictionary template. Order of elements Within the dictionary, elements are organised by table, and then alphabetically. An alphabetical index at the back of the data dictionary is provided to assist the user in finding specific elements. Template Administrative status Reference ID Version number Version date The operational status (e.g. CURRENT, SUPERSEDED) of the data element. No SUPERSEDED data elements will be included in the Dictionaries. A code that uniquely identifies the data element. If the data element is used in more than one collection, it should retain its Reference ID wherever it appears. A version number for each data element. A new version number is allocated to a data element/concept when changes have been made to one or more of the following attributes of the definition: name definition data domain e.g. adding a new value to the field. Elements with frequently updated code tables, such as the Facility code table, will not be assigned a new version for changes to data domain. The date the new version number was assigned. Identifying and defining attributes Name A single or multi-word designation assigned to a data element. This appears in the heading for each unique data definition in the Dictionaries. Previous names for the data element are included in the Guide for Use section. Data element type (optional) DATA ELEMENT a unit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes. DERIVED DATA ELEMENT a data element whose values are derived by calculation from the values of other data elements. COMPOSITE DATA ELEMENT a data element whose values represent a grouping of the values of other data elements in a specified order. A statement that expresses the essential nature of a data element and its differentiation from all other data elements. A designation or description of the application environment or discipline in which a name is applied or from which it originates. This attribute may also include the justification for collecting the items and uses of the information. Relational and representational attributes The type of field in which a data element is held. For example, character, integer, or numeric. Field size The maximum number of storage units (of the corresponding data type) to represent the data element value. Field size does not generally include Version 2.47 MoH 153

154 Appendix D: Data Dictionary Template characters used to mark logical separations of values e.g. commas, hyphens or slashes. (optional) (optional) Guide for providers (optional) (optional) The representational layout of characters in data element values expressed by a character string representation. For example: - CCYYMMDD for calendar date - N for a one-digit numeric field - A for a one-character field - X for a field that can hold either a character or a digit, and - $$$,$$$,$$$ for data elements about expenditure. The permissible values for the data element. The set of values can be listed or specified by referring to a code table or code tables, for example, ICD-10-AM 8th Edition. Additional comments or advice on the interpretation or application of the data element (this attribute has no direct counterpart in the ISO/IEC Standard but has been included to assist in clarification of issues relating to the classification of data elements). Includes historical information, advice regarding data quality, and alternative names for this data element. The rules and/or instructions applied for validating and/or verifying elements, in addition to the formal edits. Comments and advice concerning the capture of data for the particular data element, including guidelines on the design of questions for use in collecting information, and treatment of not stated or non-response (this attribute is not specified in the ISO/IEC Standard but has been added to cover important issues about the actual collection of data). A reference between the data element and any related data element in the Dictionary, including the type of this relationship. Examples include: has been superseded by the data element, is calculated using the data element, and supplements the data element. Administrative attributes (optional) The document from which definitional or representational attributes originate. Source organisation (if available) The organisation responsible for the source document and/or the development of the data definition (this attribute is not specified in the ISO/IEC Standard but has been added for completeness). The source organisation is not necessarily the organisation responsible for the ongoing development/maintenance of the data element definition. An example of a source organisation is the National Data Policy Group (NDPG). Version 2.47 MoH 154

155 Appendix E: Code Table Index Appendix E: Code Table Index Code table Admission Type code table Agency Type code table Domicile code table Ethnic Group code table Event End Type code table Facility Type code table Health Specialty code table Location code table Principal Health Service Purchaser code table Purchase Unit list Triage Level code table Location See the Ministry of Health web site. See the Ministry of Health web site. See the Ministry of Health web site. See the Ministry of Health web site. See below. See the Ministry of Health web site. See the Ministry of Health web site. See below. See the Ministry of Health web site. See Appendix H: Guide For Use of NNPAC Purchaser Codes. See below. Code tables on website For code tables on the Ministry of Health web site go to For further information or a printed copy of the code table, contact the Publications Officer. Contact details are listed at the front of this dictionary. Event End Type code table Event End Type Event End Description DW Discharge to other service within same facility EA Discharge from ED acute to specialist facility (neonates & burns only) ED Died while still in Emergency department acute facility EI Self discharge from an ED acute facility with indemnity signed ER Routine discharge from an Emergency department acute facility ES Self discharge from an ED acute facility without indemnity ET Discharge from ED acute facility to another healthcare facility Version 2.47 MoH 155

156 Appendix E: Code Table Index Location code table Location code Location description 1 Public Hospital - A DHB-owned and operated general hopital facility (includes day hospitals and the surgical bus) 2 Private Hospitals - Non DHB owned general hospital facility 3 Psychiatric Hopitals - Dedicated psychiatric hospital 4 Other Institution - Not for use in phase 1A Private Residence - A private dwelling includes independent retirement village 5 units and supported independent living units 6 Other Residential Care - Residential care facilities including rest homes and 10 residential care hospitals for under and over Marae Primary Care - PHO or GP owned/operated facilities (includes special Medical 12 Area GP facilities) 13 Other Community - Not for use in phase 1A Mode of Delivery code table 1 Face to Face (1 patient to 1 clinician) Individual face to face at the same location. Where tests are performed the mode of delivery is face to face 2 Face to Face (1 patient to many Multi disciplinary meeting with patient clinicians) 3 Face to Face (1 clinician to many patients) present at the same location and time Group of patients being seen by one or more clinicians at the same location and time 4 Remote patient monitoring monitoring of patient s biometric health information communicated from a remote patient medical device 5 Telephone Voice only contact between patient and clinician using telephone 6 Videoconference Communication via technology enabling remote visual and audio contact between patient and clinician(s) 7 Non-contact (virtual) An event where decisions about patient health care are made without the patient being present. *Where tests are performed the mode of delivery is face to face - because at some point the patient was there - e.g. bloods were taken etc. Version 2.47 MoH 156

157 Triage Level code table Triage Short Description Full Description Valid Valid To Level From 1 Immediately life-threatening Immediately life-threatening 1/01/ /12/ Imminently life-threatening Imminently life-threatening, or important time-critical 1/01/ /12/ Potentially life-threatening Potentially life-threatening, potential adverse outcomes from delay > 30 min, or severe discomfort or distress 1/01/ /12/ Potentially serious Potentially serious, or potential adverse outcomes from 1/01/ /12/9999 delay > 60 min, or significant complexity or severity, or discomfort or distress 5 Less urgent Less urgent, or dealing with administrative issues only 1/01/ /12/9999 Development and implementation of NPF data services Development and implementation of NPF data services Integration Works Integration Works NPF Ph 1 Design and Development Theta Version 2.47 MoH

158 Appendix F: NNPAC Data Model Appendix F: NNPAC Data Model Version 2.47 MoH 158

159 Appendix G: Collection of Ethnicity Data Appendix G: Collection of Ethnicity Data Introduction This appendix contains information about collecting and coding ethnic group code data. To help with correct allocations of ethnicities, it includes a detailed list of ethnicities and their corresponding codes. Points to remember Ethnicity is self-identified and can change over time. MOH can record up to three ethnic group codes for a healthcare user. An algorithm is used to automatically prioritise ethnic group codes if more than one is reported. If a person chooses not to specify their ethnicity, it should be recorded using a residual code such as 94 (Don t Know), 95 (Refused to Answer) or 99 (Not specified), not as 61 (Other). The NHI database should be updated if a healthcare user provides a more specific or different specific ethnicity than that already held for that person. About ethnicity The term ethnic group is defined as a group of people who have culture, language, history or traditions in common. Ethnicity is not the same as race, ancestry, or country of birth. Because ethnicity is self-identified, it can change over time. This is why MOH collects ethnicity data whenever information is collected for different datasets, rather than relying on the National Health Index (which does not include historical data). Collecting ethnicity data has always been problematic because of the reluctance of some data providers to collect the information, the unwillingness of some healthcare users to label themselves, and the confusion between ethnicity, nationality, citizenship, and race. Purpose Information about ethnicity is used extensively in planning and resourcing health services, developing and monitoring health policies, and measuring health outcomes. Collection of data It is very important that the ethnicity data from the health sector is collected in the same way as the data in the Census because rates of hospitalisation are calculated by comparing the two datasets (to determine proportions of the population). The 2001 Census question is provided below as a guide. Important: For MOH collections, up to three ethnic group codes can be collected for a healthcare user. Providers should make sure that healthcare users are aware of this. MOH stores all reported ethnic group codes, and also prioritises them based on a Statistics NZ algorithm. Version 2.47 MoH 159

160 Appendix G: Collection of Ethnicity Data Coding data Use the Classification of Ethnicity table below to code the healthcare user s ethnic group. If they have ticked one or more specific ethnicities, or if they have ticked other and written in an ethnicity, look on the table to find the code. If they have written an invalid ethnicity, such as Kiwi or Mainlander, which does not map to any item on the code table, or if they have ticked other but not stated an ethnicity, you can: discuss this with them and encourage them to choose a valid ethnic group ignore it if one or more other ethnicities are provided, or code as 99 (Not specified). If they write New Zealander, this can be coded as 11 (New Zealand European) If they have written pakeha, this can be coded as 11 (New Zealand European). Not Specified and Other If a person chooses not to answer the ethnicity question, record their ethnicity response with an appropriate residual code such as 95 (Refused to Answer) or 99 (Not specified). Important: The code '61' (Other) applied to only 0.037% of the New Zealand population in the 2006 census. It is limited to about 5 ethnic groups (such as Inuit/Eskimos, North, Central or South American Indians, Seychelles Islanders, and Mauritians). It must not be used as a generic 'other' code. Recording ethnicity as Other or Not specified skews statistics on rates of hospitalisation and this affects health policy. Where possible, encourage healthcare users to choose a valid ethnic group. Version 2.47 MoH 160

161 Appendix G: Collection of Ethnicity Data Prioritisation of ethnicity Many National Data Collections include Prioritised ethnicity. This is the most highly prioritised ethnicity where multiple ethnicity responses have been recorded for the healthcare user (either submitted with the health event/service or extracted from the NHI as part of the data load process). Priorisation is determined according to a Statistics NZ Algorithm and prioritising ethnic codes simplifies analysis. Each of the ethnic group codes is prioritised using the mappings in the table below. ethnic_code ethnic_code_description priority 10 European not further defined New Zealand European / Pakeha Other European Māori 1 30 Pacific Peoples not further defined 9 31 Samoan 7 32 Cook Island Māori 6 33 Tongan 5 34 Niuean 4 35 Tokelauan 2 36 Fijian 3 37 Other Pacific Peoples 8 40 Asian not further defined Southeast Asian Chinese Indian Other Asian Middle Eastern Latin American / Hispanic African (or cultural group of African origin) Other Other Ethnicity Don t Know Refused to Answer Response Unidentifiable Not stated 99 Detailed code table The codes used to report ethnicity to MOH are taken from the Statistics NZ Statistical Standard for Ethnicity This classification is a very detailed 5-digit code: only the first two digits (shown in the table below) are reported to MOH. Use this table to code healthcare user s self-identified ethnicities. MOH Ethnicity code Country of Ethnicity Affiliation 37 Admiralty Islander 44 Afghani 53 African American 53 African nec 53 African nfd 12 Afrikaner 32 Aitutaki Islander MOH Ethnicity code Country of Ethnicity Affiliation 12 Albanian 51 Algerian 12 American (US) 51 Arab 52 Argentinian 12 Armenian 44 Asian nec Version 2.47 MoH 161

162 Appendix G: Collection of Ethnicity Data MOH Ethnicity code Country of Ethnicity Affiliation 40 Asian nfd 51 Assyrian 32 Atiu Islander 37 Austral Islander 12 Australian 37 Australian Aboriginal 12 Austrian 37 Banaban 44 Bangladeshi 37 Belau/Palau Islander 12 Belgian 12 Belorussian 43 Bengali 37 Bismark Archipelagoan 52 Bolivian 12 Bosnian 37 Bougainvillean 52 Brazilian 12 British nec 12 British nfd 12 Bulgarian 12 Burgher 41 Burmese 12 Byelorussian 41 Cambodian 42 Cambodian Chinese 12 Canadian 37 Caroline Islander 12 Celtic nfd 61 Central American Indian 37 Chamorro 12 Channel Islander 52 Chilean 42 Chinese nec 42 Chinese nfd 52 Colombian 32 Cook Island Māori nfd 12 Cornish 12 Corsican 52 Costa Rican 52 Creole (Latin America) 53 Creole (US) 12 Croat/Croatian 12 Cypriot nfd 12 Czech 12 Dalmatian 12 Danish 12 Dutch/Netherlands 37 Easter Islander 52 Ecuadorian 51 Egyptian MOH Ethnicity code Country of Ethnicity Affiliation 12 English 53 Eritrean 12 Estonian 53 Ethiopian 44 Eurasian 10 European nfd 12 Falkland Islander/Kelper 36 Fijian (except Fiji Indian/ Indo-Fijian) 43 Fijian Indian/Indo-Fijian 41 Filipino 12 Finnish 12 Flemish 12 French 12 Gaelic 37 Gambier Islander 12 German 53 Ghanian 12 Greek (incl Greek Cypriot) 12 Greenlander 37 Guadalcanalian 37 Guam Islander/Chamorro 52 Guatemalan 43 Gujarati 52 Guyanese 37 Hawaiian 52 Honduran 42 Hong Kong Chinese 12 Hungarian 12 Icelander 37 I-Kiribati/Gilbertese 43 Indian nec 43 Indian nfd 41 Indonesian (incl Javanese/ Sundanese/Sumatran) 61 Inuit/Eskimo 51 Iranian/Persian 51 Iraqi 12 Irish 51 Israeli/Jewish/Hebrew 12 Italian 53 Jamaican 44 Japanese 51 Jordanian 42 Kampuchean Chinese 37 Kanaka/Kanak 53 Kenyan 41 Khmer/Kampuchean/ Cambodian 44 Korean 51 Kurd 41 Lao/Laotian Version 2.47 MoH 162

163 Appendix G: Collection of Ethnicity Data MOH Ethnicity code Country of Ethnicity Affiliation 52 Latin American/Hispanic nec 52 Latin American/Hispanic nfd 12 Latvian 51 Lebanese 51 Libyan 12 Lithuanian 12 Macedonian 37 Malaitian 41 Malay/Malayan 42 Malaysian Chinese 12 Maltese 52 Malvinian (Spanishspeaking Falkland Islander) 32 Mangaia Islander 32 Manihiki Islander 37 Manus Islander 12 Manx 37 Marianas Islander 37 Marquesas Islander 37 Marshall Islander 32 Mauke Islander 61 Mauritian 52 Mexican 51 Middle Eastern nec 51 Middle Eastern nfd 32 Mitiaro Islander 51 Moroccan 37 Nauru Islander 44 Nepalese 37 New Britain Islander 12 New Caledonian 37 New Georgian 37 New Irelander 11 New Zealander 11 New Zealand European 21 New Zealand Māori 52 Nicaraguan 53 Nigerian 34 Niuean 61 North American Indian 12 Norwegian 99 Not Specified 37 Ocean Islander/Banaban 51 Omani 12 Orkney Islander 53 Other African nec 44 Other Asian nec 12 Other European 61 Other nec 61 Other nfd 41 Other Southeast Asian nec MOH Ethnicity code Country of Ethnicity Affiliation 37 Pacific Peoples nec 30 Pacific Peoples nfd 44 Pakistani 51 Palestinian 32 Palmerston Islander 52 Panamanian 37 Papuan/New Guinean/Irian Jayan 52 Paraguayan 32 Penrhyn Islander 52 Peruvian 37 Phoenix Islander 37 Pitcairn Islander 12 Polish 12 Portuguese 52 Puerto Rican 32 Pukapuka Islander 43 Punjabi 32 Rakahanga Islander 32 Rarotongan 12 Romanian/Rumanian 12 Romany/Gypsy 37 Rotuman/Rotuman Islander 12 Russian 31 Samoan 37 Santa Cruz Islander 12 Sardinian 12 Scottish (Scots) 12 Serb/Serbian 61 Seychelles Islander 12 Shetland Islander 43 Sikh 42 Singaporean Chinese 44 Sinhalese 12 Slavic/Slav 12 Slovak 12 Slovene/Slovenian 37 Society Islander (including Tahitian) 37 Solomon Islander 53 Somali 61 South African coloured 12 South African nec 61 South American Indian 12 South Slav (formerly Yugoslav groups) nfd 12 South Slav (formerly Yugoslav) nec 41 Southeast Asian nfd 12 Spanish 44 Sri Lankan nec 44 Sri Lankan nfd Version 2.47 MoH 163

164 Appendix G: Collection of Ethnicity Data MOH Ethnicity code Country of Ethnicity Affiliation 44 Sri Lankan Tamil 12 Swedish 12 Swiss 51 Syrian 42 Taiwanese Chinese 37 Tahitian (including Society Islander) 43 Tamil 41 Thai/Tai/Siamese 44 Tibetan 35 Tokelauan 33 Tongan 37 Torres Strait Islander/Thursday Islander 37 Tuamotu Islander 51 Tunisian 51 Turkish (incl Turkish Cypriot) 37 Tuvalu Islander/Ellice MOH Ethnicity code Country of Ethnicity Affiliation Islander 53 Ugandan 12 Ukrainian 52 Uruguayan 37 Vanuatu Islander/New Hebridean 52 Venezuelan 41 Vietnamese 42 Vietnamese Chinese 37 Wake Islander 37 Wallis Islander 12 Welsh 53 West Indian/Caribbean 37 Yap Islander 51 Yemeni 12 Zimbabwean nfd = Not further defined nec = Not elsewhere classified Version 2.47 MoH 164

165 Appendix H: of NNPAC Purchaser Codes Appendix H: of NNPAC Purchaser Codes of Purchaser Codes Initiate Initiate Decision Decision Who Who arranged arranged Code Code Is the patient an NZ resident? Yes What type of event is this? Acute Use code 35 DHB contract Use code 35 Treated on the Mobile Bus Use code 34 Non acute Funded by Elective Services to reduce booking lists Use code 35 Funded by the MoH directly Use code 34 No Organisation arranged through Funded through a pilot screening programme Use code 33 ACC Use code A0 Breast-Screen Aotearoa Use code 35 Accredited Employer Use code 17 Patient s own Health Insurance Use code 06 Is this for an accident? Patient paying for their own costs Use code 06 No Yes Use code 35 Does the patient meet Eligibility Criteria? (e.g. Reciprocal Agreement) Yes Use code 20 No Use code 19 Version: 2.4 MoH 175

166 Appendix I: Guide for Use of Emergency Department (ED) Event End Type Codes Appendix I: Guide for Use of Emergency Department (ED) Event End Type Codes Arrive at Emergency Department (ED), Observation Unit, Acute Assessment Unit (AAU), Short Stay Unit (SSU) Is the patient treated in ED and admitted to an inpatient ward? No Is the patient treated in ED/AAU/SSU for three hours or more (>3hrs) or did they die*? *All deceased patients are to be admitted and discharged in your PMS regardless of treatment time and reported to the NMDS. Yes Yes Admit patient and report to both NNPAC and NMDS NNPAC EVENT ED attendance with PUC ED0x001A NMDS EVENT No Report ED attendance to NNPAC ONLY Patient discharged home, self discharged, died or transferred to another facility from your ED/AAU/SSU? Patient transferred to an inpatient ward Patient discharged home, self discharged, died or transferred to another facility from your ED/AAU/SSU? Patient transferred to an inpatient ward Use ED event end type codes starting with E, eg, ER, ED, EI, ES, EA ET with PUC ED0x001 Use ED event end type codes starting with E, eg, ER, ED, EI, ES, EA, ET Use event end type code DW Use ED event end type codes starting with E, eg, ER, ED, EI, ES, EA, ET Use inpatient event end type codes starting with D, eg, DR, DD or DT etc PUC = Purchaser Unit Code NNPAC = National Non Admitted Patient Collection NMDS = National Minimum Dataset Version: 2.4 MoH 176