| 1 | Stats – in progress
| .... |
| 2 | Complete ‘Unit results combined’ – with colour coding or other way of differentiating. Refinement as discussed based on new and previous: Your record has received data from (dates for each or just for ‘last’ as below?) This should be on landing page, see item 4. Presentation: need a label or a colour, or both?? - later thinking - maybe label better than colour for usability and appearance. Will need to define a unit's Short Name. | Last data received 12.03.2008 0540h from York | Base unit is determined by the origin of the login that the patient is using. It sets which unit’s contact info, demographic info and ‘problem list’ (‘other diagnoses’) is used. Drugs are shown from both units with origin identified. | .... |
| 3A | Minor 1. Improve formatting in Letters (paragraphs not working) 2. Info about Results panels on hover over '1', '2' etc – make it possible for Admin to enter text in place of those numbers to indicate the tests or test types. Change ">" to ‘more results’ in bold or make more obvious similar label. 3. Improve system for contacting unit/system admins to be a form linked from the top of the Contacts page rather than the bottom [because webmail users not able to use existing links]. Make a clear extra field in Contact info for unit admins to populate a specific ‘RPV enquiries email address’. Some explanatory text required to explain to user which destination is appropriate, e.g.: - Local unit admin – any queries about results not appearing or being wrong, or about diagnosis or contact details. These all need to be corrected in your local unit’s electronic records. Non-urgent changes can be notified at your next visit.
- RPV System Administrators – if you want to make any comments about the system as a whole, or the information links suggested.
4. Add link ‘forgotten login/password’ under the login box (see APPENDIX, page 5) 5. Fix text overlaps on heading in some screens in Firefox: the two info screens, results. | ... (format done) |
| 3B | More minor 6. Move all links under ‘Medical Info’ to a separate heading under Patient Info (now to be called just Info) below Further Info – call it “Further medical information”. This will release a 7. ?Javascript or similar to do checksum on final digit of NHS number when registering a new patient and bring up alert ‘This is not a valid NHS number. Are you sure it is correct?’ We have established that the checksum method is identical in England, Scotland and Northern Ireland. Rob has javascript for checksum. 8. Widen pages to facilitate 5 above and more. This plus deleting Med Info will leave space for 'interactive' or however we want to highlight Discussion board, things under item 5. | ... |
| 3C | Units of measurement and ranges
Current XML includes units of measurement but we don't show it.
- we probably need to show it - how?
- this could be implemented soon, but ...
- issues around varying normal range too, and we don't collect that
- might also show originating renal unit at same time
- pop up over individual data items OR last column of each row could be "i" icon (show info),
- alternative 1: "From Cardiff (=Unit Short Name). Normal range x-y"
- Alternative 2: "From Cardiff. Show normal ranges for Cardiff" - this way, normal ranges could be configured on RPV server by a local admin for each unit. - make mockup pages of alternatives to show to patient test group | ... |
| 3D | Info linked to rollovers on Results table headings
Info that is linked from the top of each column heading is at the moment held on a different server (www.renal.org) and only linked from the RPV server. Move this to being editable on the server - need to be able to enter html or use simple text editor (e.g. FCK editor) on these 'pages' (which are currently formatted to appear in new small window over the main page, but this doesn't work properly in Firefox, where it goes to new tab instead and resizes everything). | ... |
| 4 | Security suite and login screen – A login lands you on a once-only landing screen/page (not pop-up) that includes
1. message saying something like 'go away if you aren't entitled to read this record'. 2. info about last login, and when/where data received from – “Your record last received data on …… from ….” 4. Javascript (e.g.) indicator of password strength 5. You have a login from [Unit A] and a login from [Unit B]. Use the one that is your regular unit so that your details will be correct. (we may not need this if this problem is fixed ... item xx)
6. We have this email address for you: xxxxx@yyy Click here if you need to change this. (Item 9) - new address must be verified with automated link - see 9 below B limit number of consecutive failed login attempts without putting large burden on Admins; initially, limit to 15 before a lockout for that username requiring local admin intervention. | .... |
| 5 | Patient enters data – Items 5-7 all involve user interaction. 7 could come before 5 if easier. Some thoughts on presentation of 5 and 6 in Appendix (download from foot of page)
1. Blood pressure (as example of numerical data from a new source). [Note: no intention to return this data to unit datasystem] See Appendix. Colour (and/or other) coding for patient-entered data. 2. Comment – blog linked to dates by symbol at R of results tables 3. ‘About me’ page - info about me, profile … questions I’d like answered - based e.g. on care plan We discussed how to present some of the ‘Interaction’ issues in 5 and 6, may need to look further when these are made. | .... |
| 5a | Anonymous feedback to unit about performance (a letterbox with anonymous messages that will be received by unit admin). Again we need to discuss presentation and explanation of this in some further detail. | .... |
| 6 | Discussion board – private to view, with login identical to RPV login but username concealed (in future – ?profile for patient … how you want name to show … photo … a few lines of biog that others could read etc | .... |
| 7 | Quality checks – unit admins have some kind of listing or messaging of failed file reading, and other issues as discussed, including; - Cessation of file transfer – if no files from a unit for 36h.
- Valid dates – e.g. future dates are not permitted for tests (but OK for drugs)
- Testcodes sent that aren’t defined in schema
- Invalid XML
- Failed decryption/load
- Server unavailability
- Reality check on some tests (e.g. value limits)
| .... |
| 8 | Graphics – users can generate a graph of any two data items versus time. Default time 1y, default range max to min, but with the ability to alter both, including to future time periods so that there is a large blank section on the right hand end of the graph – helpful in predicting timecourse of deterioration of kidney function.
Consider using tools at www.amcharts.com | .... |
| 9 | Collect user emails and improve ability to communicate elecronically – on the one-off landing page after login, ask patient to check email address shown for them and tell them how to confirm/change it.
Include a box ‘We would like to contact you occasionally by email with information about Renal PatientView. We will never include confidential information in emails and we will never pass on this address to anyone else apart from your renal unit. Please only check this box if you do not want us to contact you in this way’. I do not want to receive occasional emails from Renal PatientView Accept change in email address only after they click on a link in an automatically sent email. Store ‘verified when’ next to email addresses. The verification email ‘How to get help from Renal PatientView’ should be addressed to them by name and include a summary of how to email their unit’s RPV admin – this will enable them to access that info when they’ve forgotten their login as well as simplifying data alterations. It should therefore end … “Keep this message safely so that you have these contact details if you forget your login.” Should also permit a unit admin or superadmin to extract emails, with option to email them outwith or message them directly from the system. (Individual messages on login not in remit of current story) | .... |
| 10 | Printed output – A method of generating a printable file that includes all recent info and a summary of info links that are available on diagnosis, treatment, etc. This html file will also be usable by others, e.g. HealthSpace. Should include last 5 items under each table heading (configurable?) | ... |
| 11 | Reconcile multiple NHS/CHI etc numbers – A method to permit creation of unitary record for patient with NHS and CHI and HCN number (NI; Eilish Meehan’s info), or any combination (not intended to reconcile two numbers in a single domain, eg two CHI numbers, but I guess it could). Need to discuss safety issues around operation. | ... |
| 12 | Universal login. At the moment, logins are unit-based and this can cause problems when data comes only from other units (problem for patient is largely restricted to units where one IT system covers multiple units). Needs to retain ability for a local admin to add a patient to 'their' list of patients on RPV - I think. | .... |
| 13 | Upload pdf files – repository for files where format matters. Needs further discussion – how do they get there. Examples: Care plan …. For further discussion. | ... |
| 14 | Open source – Code is published in an appropriate place for others to share. It would be possible to adapt RPV to be a primary healthcare record in a simple healthcare environment. | ... |
| 15 | Page by page analysis of usage – Analysis of page usage as well as logins. | ... |
| 16 | Comorbid conditions – Other Conditions are coded in an analagous manner to primary diagnosis and linked to appropriate info links. Possibility of providing each with up to 3 information links (patient info only) | |
| 17 | Admin emails – Superadmin can alter address to which admin@renalpatientview emails go | ... |
| 18 | RPV for all – Patient chooses Renal/Diabetes/HIV/ View (etc; possibly eventually including 'My View' which is user-configurable)
- This is remembered by the system as the default on login, but view can be switched by user at any time.
- Each specialty view shows its own primary diagnosis and therefore each new specialty is required to define its own diagnostic codes
- There needs to be a different set of Admin types for each specialty
- Comorbidity coding is likely to be integral to some specialties, adding a third coding level to the system.
| ... |