SMR Submission Requirements
(Scottish Morbidity Record)
Date Published: June 2008
Updated: October 2014/Hazel Rielly
Version: 2.0
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------1.
INTRODUCTION ......................................................................................................................... 3
2.
MIGRATION ................................................................................................................................ 4
3.
SPECIFIC SITE REQUIREMENTS .......................................................................................... 4
4.
TIMESCALE ................................................................................................................................ 4
5.
EXPECTATIONS ........................................................................................................................ 5
6.
TRANSMISSION OF TEST DATA ........................................................................................... 5
7.
BATCH HEADER RECORD LAYOUT .................................................................................... 6
8.
CONTROL CHARACTERS ....................................................................................................... 7
9.
BATCH SEQUENCING ............................................................................................................. 7
10.
DATA ACCREDITATION, QUALITY AND VALIDATION ................................................... 7
11.
TRANSACTION TYPES ............................................................................................................ 9
11.1
11.2
11.3
11.4
11.5
11.6
COMPILATION OF BATCHES IN TERMS OF TRANSACTION TYPES
EPISODE RECORD KEY MANAGEMENT
IDENTIFICATION OF TRANSACTION TYPES
INSERT TRANSACTIONS
REPLACEMENT TRANSACTIONS
DELETION TRANSACTIONS
9
9
9
10
10
10
12.
CONTACTS ............................................................................................................................... 12
13.
APPENDIX 1 - SMR INPUT RECORD (FILE LAYOUT)
D:\106756629.doc
2
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------1.
Introduction
The information as detailed in this document is not intended as a definitive
specification for systems.
It is intended to inform discussions which
necessarily will have to take place between healthcare providers and hospital
patient system suppliers to facilitate the submission of SMR central returns. At
any point when such discussions are underway, NSS ISD and IT Customer
Support Desk will be happy to supply further advice and clarification.
As soon as a decision to move from one hospital patient system OR Patient
Management/Administration System (PMS/PAS) to another has been made, it
is important to notify the NSS, IT Customer Support Desk and ISD’s Data
Support and Monitoring Team so that early discussions can take place to
allow a planned approach. We can then provide customers with advice and
guidance to assist with a smooth migration from their current system in terms
of the SMR extract and submission functionality. Testing of the SMR extract
functionality is required before live submissions can take place.
It is important that all parties are involved in the consultation process to gain
understanding of the requirements and expectations and also so that we can
advise customers in all aspects of the testing and submission processes.
This would usually take the form of a meeting/liaison with NSS, IT Customer
Support Desk, the Data Support and Monitoring Team and the customer. It
may also be useful for the system supplier to be represented, however this
would be at the discretion of the user and perhaps following initial discussions
with NSS.
In brief the process of submitting SMR records requires the following:
 SMR datasets are collected in the hospital patient system
 An SMR record is generated as per current rules
 SMR records are validated and extracted for submission to ISD
 Extracted records have a unique identifier attached to each record
 The unique identifier is made up of a Sending Location (SL), SMR type
and a sequential number known as an Episode Record Key (ERK)
 Hospital systems are able to submit new records (inserts),
amendments to existing records (replacements) and deletion records
(deletes)
 The SL, SMR type and ERK unique identifier attached to each insert
record allows any subsequent replacement / delete record to amend
/delete the original inserted record
D:\106756629.doc
3
SMR Submission Requirements
--------------------------------------------------------------------------------------------------------
2.
Migration
Migration is the transition from the existing system to the new one.
points to be addressed here are:







3.
Typical
What current sending locations & locations are affected?
Will the site be migrating the historical data?
It is usually not possible to amend migrated historical data using the
new system. Therefore we need to ask and consider are there any
outstanding errors within the historical data that need to be corrected.
It is advisable for these to be cleaned up prior to migration.
Is there an opportunity to update data items currently mapped by ISD?
e.g. provider code
Has a cut off date for data entry to the old system been established?
Has a start date for data entry to the new system been established?
This date is sometimes referred to as ‘going live’ however this may not
mean the SMR extract submissions have gone live yet.
Has a residents list been requested from ISD – SMR04 Mental Health
only. As SMR04 is a 2 part form (part 1 admission, part 2 discharge) a
residents list showing what part 1 admission records we have on file is
needed to migrate over to the new system.
Specific Site Requirements
Requirements of the site need to be discussed.



4.
Is a new sending location required?
If a new sending location is required, NSS IT Customer Support Desk
will allocate a suitable one on request. The format is ANNNA.
What will the Episode Record Key (ERK) start at?
Usually
00000000012 if a new sending location is allocated. A prefix may be
required if an existing sending location is being used. NSS can carry
out analysis of the existing sending location and (ERK) range(s) in use
to assist with this.
Timescale
Estimated timescales for SMR testing and implementation need to be
discussed with consideration to any planned system ‘go live’ date previously
mentioned in the migration plan and also resources available both at the site
and NSS.
To avoid a backlog of submissions to ISD, testing should be scheduled to be
completed as near as possible to the cut off date for data entry to the old
system.
Live submissions from the new system cannot take place until
successful testing is complete.
Along with these guidelines, NSS IT Customer Support Desk will provide you
with the correct SMR type Test Strategy documents.
Testing must be
D:\106756629.doc
4
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------performed on a test system to avoid corruption of live data and / or systems.
This test system should replicate as much as possible the live system
scenarios.
5.
Expectations
Processing and format testing is carried out by IT Customer Support Desk.
Validation testing is carried out by the Data Support and Monitoring Team. IT
Customer Support Desk will coordinate the testing and provide feedback for
both aspects at the same time. We aim to test files as soon as we can and
where possible will provide feedback within one week of receipt of a test file.
If unable to do this, we will inform the customer of a timescale for testing
feedback. At each stage, we will give clear information on what test criteria
has been addressed and what items are still outstanding. It is stressed that
users may contact us at anytime with any questions or concerns that they may
have.
6.
Transmission of Test Data
The preferred method of receiving test files is to use the SWIFT application.
NHS net access is required to use SWIFT.
If you already have an account,
we will add the ‘ESMRTEST’ application as an option within SWIFT. If you do
not have an account, we’ll set one up.
Test files can be transferred via any NHS e-mail account if patient names are
fictitious and therefore non confidential. If NHS Net access is not available,
confidential files can be encrypted and password protected using WINZIP
version 9, saved to floppy or CD or saved to an approved data stick (with
encryption software) and then double wrapped and mailed as Recorded
Delivery to:
National Services Scotland
IT Customer Support Desk
Gyle Square
1 South Gyle Crescent
Edinburgh
EH12 9EB.
D:\106756629.doc
5
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------7.
Batch Header Record Layout
The first record in every SMR input file submitted to ISD must be a standard
Batch Header Record. The information held in this record is crucial and any
anomaly in this information will exclude the batch from routine processing.
Details of the layout of the Batch Header Record are set out below.
1
3
5
10
2
4
9
14
System Record ID
SMR Record Type
Sending Location
Hospital Location
2
2
5
5
= 'AA’ if accredited
= 00, 01, 02, 04
must be present
If PMS/PAS, must be blank
15
20
Batch Number
6
21
27
26
32
Batch Total
Validation Version
Number
6
6
33
662
or
838
or
709
Filler (00 and 01)
630
Format PMS/PAS - either two alpha
characters followed by a 4 digit
number or 6 digit number
NOTE that the batch is rejected if not
in sequence.
max 999999
Format = YYMMLL where
YY = year of introduction (eg. 00 =
2000)
MM = month of introduction (eg. 04 =
April)
LL = for local use
Spaces
Filler (02)
806
Filler (04)
677
Points to note regarding the data items which comprise the Batch Header
Record include:
Those items marked in bold are mandatory. Hospital Location and Validation
Version Number, if not completed, should be space-filled.
It is essential that the information held in the “Batch Number” field represents
a value which is one greater than the previous batch submitted to ISD for the
Sending Location / SMR Record Type involved, this is fully explained in
“Batch Sequencing” below.
The “Validation Version Number” field is intended to hold a value which
describes the version of national SMR validation which was used to validate
the data prior to its submission to ISD. This number is taken from the
current Data Change Notice(s) issued by the Data Advice Team within
the ISD, Data Management Service.
D:\106756629.doc
6
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------It is advisable to limit the number of records in each batch to less than 20,000.
8.
Control Characters
Each batch of SMR input data submitted to ISD comprises a single Batch
Header Record followed by a number of SMR input records as detailed above.
All of these records, the Batch Header Record and every SMR input record
should be terminated by a “CARRIAGE RETURN” character then a
“LINEFEED” character. No other control characters whatsoever should be
included in any batch (as a general rule, fields should be completed with
alphanumeric characters, with some exceptions – please refer to the ISD Data
Dictionary www.datadictionary.scot.nhs.uk for details of individual data fields)
9.
Batch Sequencing
One of the ways in which ISD ensures that no batches fail to be processed or
conversely are processed more than once, is by strict batch sequence
checking.
The six character “Batch Number” field in the Batch Header Record facilitates
such checking. For each Sending Location / SMR Record Type, it is
absolutely essential that batches are submitted strictly in sequence. For
example, if the last SMR00 batch for Sending Location G513H which was
submitted to ISD was number “000045” then, the next batch submitted for this
Sending Location and SMR Record Type combination could not be processed
unless it was numbered as “000046”.
10.
Data Accreditation, Quality and Validation
Data Accreditation requires healthcare providers to submit error free SMR
data to ISD. To facilitate this, SMR validation software is provided to
healthcare providers to allow them to validate locally to national standards,
before submitting their SMR data to ISD.
SMR data has been used for many years to inform planning, research and
management decisions and it is important that the quality of SMR data is
maintained to ensure the accuracy and integrity of the national database.
Validation can be carried out in a number of ways:
Some data providers have required that their system suppliers develop their
own validation process which conforms to national standards, as an integral
component of the system involved.
Some system suppliers use the ISD developed CLoVE system (COPPISH
Local Validation Engine) in “stand alone” mode to validate batches which have
been extracted from the source information hospital system.
Most data providers get their system supplier to integrate CLoVE into their
system using the CORECT.dll version.
D:\106756629.doc
7
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------ISD are available to provide advice on any matter regarding validation.
As test files are not required to be of large volume, test data may not be
considered suitable to complete a comprehensive validation check. If this is
the case, validation can be tested as part of the testing of the first live file, on
condition that this file is of a sufficient volume. This can only be carried out
when format and processing tests are completed successfully.
However, if this method of validation testing is adopted, it must be noted
that if the validation of this first live file is unacceptable to ISD it will be
necessary to rollback the system in order to correct data and re-submit
in the correct batch sequence order. The validation process and/or the
system (PMS/PAS) may also need to be revised/changed.
D:\106756629.doc
8
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------11.
Transaction Types
When SMR input records (Appendix 1) are submitted to ISD, that submission
can be made utilising any one of the three following transaction types:
Insertion
Replacement
Deletion
When making such submissions, it is essential that transaction types are
managed properly. Failure to do so will result in rejection of records during
routine processing.
11.1
Compilation of Batches In Terms Of Transaction Types
Any given batch of SMR input data submitted to ISD can comprise records
which utilise any combination of the three transaction types detailed above.
However, for any specific episode of care, it is advisable that any given batch
only holds a single transaction. For instance, a batch of SMR input records
should not contain an “insert” transaction and a “replacement” transaction for
the same episode of care or, contain multiple “replacement” transactions for
the same episode of care.
11.2
Episode Record Key Management
“Insert” transactions involve the addition of a record to the national database.
Therefore, such transactions should always utilise an Episode Record Key
value which has never before been used for the Sending Location / SMR
Record Type involved.
“Replacement” and “deletion” transactions carry out an operation on a record
which already exists on the national database. For this operation to be carried
out successfully, such transactions must use the Episode Record Key value
used in the initial “insert” transaction.
11.3
Identification of Transaction Types
For any given SMR input record (Appendix 1), its transaction type is controlled
by its fifth character (the Episode Record Status field). This character should
hold a value of “I”, “R” or “D” to respectively denote that the record involved is
an “Insert”, “Replacement” or “Delete” transaction.
D:\106756629.doc
9
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------11.4
Insert Transactions
A unique, new Episode Record Key relative to the Sending Location / SMR
Record Type involved should be utilised.
All appropriate data items should be completed (the input file layout document
gives details of which items are mandatory – Appendix 1).
Character five of the SMR input record should hold a value of “I”.
ISD Processing Functionality
Insert transactions result in the record involved being added to the national
SMR database.
11.5
Replacement Transactions
The Episode Record Key used in each Replacement transaction should match
the Episode Record Key used in the original Insert transaction with which the
record was added to the national SMR database.
All appropriate data items should be completed (the input file layout document
gives details of which items are mandatory Appendix 1).
Character five of the SMR input record should hold a value of “R”.
ISD Processing Functionality
Replacement transactions result in the unique identification of a particular
record which is held on the national SMR database. This record is then
completely overwritten by the “Replacement” record.
11.6
Deletion Transactions
The Episode Record Key value used in each Deletion transaction should
match the value of this data item used in the original Insert transaction which
added the record involved to the national database.
Only the first fifteen characters, up to and including the Episode Record Key
value should hold meaningful data, the remainder of the record should be
padded to the correct length for the SMR Record Type involved, with space
characters.
Character five of the SMR input record should hold a value of “D”.
ISD Processing Functionality
“Deletion” transactions result in the identification of a particular record which is
held on a national database however, this record is not removed from the
database; it is flagged as ‘Deleted’ and as such is excluded from analysis. (If
records are to be removed from the database please contact ISD Data
Support and Monitoring Team, who will arrange for this.)
D:\106756629.doc
10
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------This rationale allows an audit trail to be maintained in respect of Deleted
records. Because removal does not take place however, this means that it is
essential that the system does not consider the Episode Record Key value,
which was the subject of the Deletion transaction, available for use in a
separate and subsequent Insert transaction.
D:\106756629.doc
11
SMR Submission Requirements
-------------------------------------------------------------------------------------------------------12.
Contacts
Although this document provides details of the requirements healthcare
providers must meet when submitting SMR national returns it will be
necessary to liaise with IT Customer Support Desk and the ISD Data Support
and Monitoring Team - contact details are given below.
Chris Jones, Information Manager
Gyle Square
1 South Gyle Crescent
Edinburgh
EH12 9EB
0131 275 6429
c.jones11@nhs.net
nss.isdDMT@nhs.net
Hazel Rielly, IT Customer Support Desk Manager
Gyle Square
1 South Gyle Crescent
Edinburgh
EH12 9EB
0131 275 6718
hazel.rielly@nhs.net
nss.csd@nhs.net
D:\106756629.doc
12
APPENDIX 1
SMR INPUT RECORD (File Layout)
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
Fro
m
1
3
5
6
To
17
37
57
77
97
105
106
107
117
127
36
56
76
96
104
105
106
116
126
130
131
141
151
159
161
167
140
150
158
160
166
174
175
185
190
193
194
196
199
202
184
189
192
193
195
198
201
209
210
210
211
212
217
222
228
234
240
241
242
266
272
281
282
283
284
290
296
297
210
210
211
216
221
227
233
239
240
241
265
271
280
281
282
283
289
295
296
298
2
4
5
16
Data Item
System Record Id
SMR Record Type
Episode Record Status
Episode Record Key
Patient ID Data
Surname
1st Forename
2nd Forename
Previous Surname
Date of Birth
Sex
Marital Status
CI/CHI Index Number
NHS Number
Health Records System
Identifier
Patient Identifier
Alternative CRN
Postcode
Ethnic Group
GP Practice Code
Referring GP/GDP GMC
Number
Episode Management Data
Care Package Identifier
Location
Specialty
Local Code
Significant Facility
Clinical Facility Start
Clinical Facility End
Consultant/HCP
Responsible for Care
Management of Patient
Mode of Contact
Patient Category
Provider Code
Purchaser Code
Serial Number
GP Referral Letter No
Date Referral Received
Referral Source
Referral Type
Referral Reasons
Clinic Date
Clinic Code
Attendance Status
Attendance Follow Up
Availability Status Code
Waiting List Date
Admission Date
Waiting List Type
Admission Type
D:\106756629.doc
Data Item
2
2
1
11
= AB
= 00, 01, 02, 04
= I, D or R
sequential number generated by PAS identifying the
episode with modulus 11 check digit
20
20
20
20
8
1
1
10
10
4
Minimum of 2 characters
Minimum of 1 character
10
10
8
2
6
8
Minimum of 6 characters left justified
10
5
3
1
2
3
3
8
1
1
1
5
5
6
6
6
1
1
6x4
6
9
1
1
1
6
6
1
2
14
ddmmccyy
right justified if 5 char
right justified if 7 char
left justified
not mandatory for SMR00
right justified if 7 char
not SMR00
SMR00 only (not mandatory until April 2016)
ddmmyy, SMR00 only, mandatory for new referrals only
SMR00 only, mandatory for new referrals only
SMR00 only
ICD10 code, SMR00 only
ddmmyy, SMR00 only
SMR00 only
SMR00 only
SMR00 only
Field no longer in use
ddmmyy, not SMR00, SMR02
ddmmyy, not SMR00, SMR02 Home Births
not SMR00, SMR02
not SMR00
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
Data Item
Data Item
299
300
Admission Reason
2
301
303
302
307
2
5
308
314
313
319
Admission/Transfer From
Admission/Transfer From Location
Ready for Discharge Date
Discharge Date *
320
322
324
321
323
328
2
2
5
329
335
341
347
353
359
365
373
379
334
340
346
352
358
364
372
378
386
6
6
6
6
6
6
8
6
8
ICD10 code, not mandatory for SMR00
ICD10 code
ICD10 code
ICD10 code
ICD10 code
ICD10 code
OPCS4 code (single or pair)
ddmmyy
right justified if 7 char
387
395
401
409
417
423
431
439
445
453
394
400
408
416
422
430
438
444
452
468
469
470
469
475
476
500
524
548
572
499
523
547
571
579
Discharge Type *
Discharge/Transfer To *
Discharge/Transfer To Location
General Clinical Data
Main Condition
Other Condition 2
Other Condition 3
Other Condition 4
Other Condition 5
Other Condition 6
Main Operation
Date Main Operation
Clinician Responsible for
Main Operation
Other Operation 1
Date Other Operation 1
Clinician - Other Op 1
Other Operation 2
Date Other Operation 2
Clinician - Other Op 2
Other Operation 3
Date Other Operation 3
Clinician - Other Op 3
Error Report Comments
Common Development Data
Chronically Sick/Disabled
Clinical Problem Identifier for
Spell/Care Package
Lifestyle Risk Factors
Severity Measures
Dependancy Measures
Outcome Measures
Development Data 1
ddmmyy, not SMR00
ddmmyy, not SMR00, SMR02 Home Births
For SMR04, Discharge Date should be present if other
discharge details are present
not SMR00
not SMR00
not SMR00
580
587
Development Data 2
1x8
588
636
642
635
641
645
Development Data 3-8
Contract Service No
Iso-Resource Group
6x8
6
4
D:\106756629.doc
6
6
8
6
8
8
6
8
8
6
8
4x4
not SMR00, optional for SMR04 and SMR01 (where
significant facility not = 1E)
not SMR00
not SMR00
OPCS4 code (single or pair)
ddmmyy
right justified if 7 char
OPCS4 code (single or pair)
ddmmyy
right justified if 7 char
OPCS4 code (single or pair)
ddmmyy
right justified if 7 char
1
6
6x4
6x4
6x4
6x4
1x8
15
This data item is to be used to record the first 8
characters of the Unique Care Pathway Number
(UCPN).
This data item is to be used to record the last 5
characters of the Unique Care Pathway Number
(UCPN).
It is envisaged that where a PAS system is not
specifically amended to allow entry of the UCPN in a
block, when editing the last 5 characters into data
Development Data 2, ensure this field is left justified so
that the extract places the 5 characters into positions
580 – 584.
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
646
652
655
651
654
662
663
665
664
666
667
668
669
670
671
673
672
674
675
676
677
683
Data Item
6
3
8
682
687
Contract Invoice No
Contract Invoice Line
Contract Invoice Charge
SMR 02 Specific Data
Total Previous Pregnancies
Total Previous
Spontaneous Abortions
Total Previous Therapeutic
Abortions
Total Previous Caesarean
Sections
Total Previous Still Births
Total Previous Neonatal
Deaths
Previous Admissions this
Pregnancy
Booking Date
Original Booking
688
688
Delivery Plan - Place
1
689
689
Delivery Plan - Management
1
690
690
Booking Change - Place
1
691
691
1
692
695
698
694
697
698
Booking ChangeManagement
Height
Weight of Mother
Type of Abortion
699
699
Management of Abortion
1
700
706
705
707
LMP
Estimated Gestation
6
2
708
708
1
709
710
709
710
Certainty of Gestation (based
on scan)
Antenatal Steroids
Diabetes
711
712
713
714
715
723
724
711
712
713
714
722
723
725
1
1
1
1
2x4
1
2
726
726
Smoking History
Smoker During Pregnancy
Condition on Discharge
Drug Misuse
Drugs Used
Ever Injected Illicit Drugs
Typical Weekly Alcohol
Consumption
Induction of Labour
727
728
Duration of Labour
2
729
729
1
730
730
Analgesia During
Labour/Delivery
Episiotomy
D:\106756629.doc
Data Item
2
2
2
2
2
2
2
6
5
3
3
1
1
1
1
1
16
ddmmyy
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Mandatory from Apr 2011
Mandatory from Apr 2011
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
ddmmyy
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Mandatory from Apr 2011
First position Mandatory from Apr 2011
Mandatory from Apr 2011
Mandatory from Apr 2011
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
Data Item
731
731
Tears
1
732
732
Sterilization after Delivery
1
733
738
Date of Delivery
6
739
739
1
740
740
Number of Births this
Pregnancy
Doctor Present at Delivery
741
741
Midwife Present at Delivery
1
742
742
1
743
748
749
749
Midwife to Consultant
Transfer
Indication for Operative
Delivery
Presentation Baby 1
750
750
Presentation Baby 2
1
751
751
Presentation Baby 3
1
752
752
Delivery Mode Baby 1
1
753
753
Delivery Mode Baby 2
1
754
754
Delivery Mode Baby 3
1
755
755
1
756
756
757
757
758
761
Outcome of Pregnancy Baby
1
Outcome of Pregnancy Baby
2
Outcome of Pregnancy Baby
3
Birthweight Baby 1
762
765
Birthweight Baby 2
4
766
769
Birthweight Baby 3
4
770
770
Resuscitation Baby 1
1
771
771
Resuscitation Baby 2
1
772
772
Resuscitation Baby 3
1
773
774
Apgar @ 5 Min Baby 1
2
775
776
Apgar @ 5 Min Baby 2
2
777
778
Apgar @ 5 Min Baby 3
2
779
779
Sex Baby 1
1
D:\106756629.doc
1
6
1
1
1
4
17
Data Item
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
ddmmyy. Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Condition on Discharge
ICD10 code. Whether or not may/must not/must be
present dependant on Condition on Discharge
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Number of Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
Data Item
780
780
Sex Baby 2
1
781
781
Sex Baby 3
1
782
784
OFC Baby 1
3
785
787
OFC Baby 2
3
788
790
OFC Baby 3
3
791
792
Crown Heel Baby 1
2
793
794
Crown Heel Baby 2
2
795
796
Crown Heel Baby 3
2
797
797
Neonatal Indicator Baby 1
1
798
798
Neonatal Indicator Baby 2
1
799
799
Neonatal Indicator Baby 3
1
800
800
Baby 1 Discharged To
1
801
801
Baby 2 Discharged To
1
802
802
Baby 3 Discharged To
1
803
812
Baby 1 CHI Number
10
813
822
Baby 2 CHI Number
10
823
832
Baby 3 CHI Number
10
833
833
Feed on Discharge Baby 1
1
834
834
Feed on Discharge Baby 2
1
835
835
Feed on Discharge Baby 3
1
836
836
First Feed Given Baby 1
1
837
837
First Feed Given Baby 2
1
838
838
First Feed Given Baby 3
1
D:\106756629.doc
18
Data Item
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Outcome
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
Whether or not may/must not/must be present
dependant on Condition on Discharge and Number of
Births
SMR INPUT RECORD April 2015
Maximum Record Size = 838
Position
From To
Size
663
664
665
663
664
665
666
671
672
677
678
683
684
689
690
690
691
697
696
698
699
703
704
702
703
709
Data Item
SMR 4 Specific Data
Status on Admission
Admission/Referral From
Previous Psychiatric
Inpatient Care
Admission - Main
Condition
Admission - Other Condition
2
Admission - Other Condition
3
Admission - Other Condition
4
Type of Psychiatric Care
Provided
ECT 1st Treatment Date
ECT Treatments - Number
this Episode
Arrangements for Aftercare
Care Programme Approach
Date last included in MHLS
Census
1
1
1
6
ICD10 code
6
ICD10 code
6
ICD10 code
6
ICD10 code
1
discharge item
6
2
ddmmyy, discharge item
discharge item
1x4
1
6
Note: Mandatory fields are in bold.
D:\106756629.doc
Data Item
19
Must be an entry in code(1) if discharge unless died
discharge item
ddmmyy, on discharge only