PatientView began as Renal PatientView in 2005, and though we gave advice to several others thinking about doing similar things, it was only in 2012 that we began to look seriously at offering PatientView to other specialties (history). In 2018, the PatientView mobile application was launched on the Google Play and Apple app stores, thereby further enhancing the user experience and opening up many new possibilities in the realms of convenience and richer record sets.
You can now become a PatientView partner either
- As a specialty – PV2 in Feb 2016 offered Diabetes, Heart Failure, and IBD PatientView. Current partners and locations. Options are to commence with only generic features (quick and simple), adding specialty-specific features later if needed; or to develop some specialty-specific features from the outset.
- As a location – from August 2016, patients can be added to a ‘generic’ specialty. We present information relevant to any diagnosis or specialty that you can send as a code. Alternatively these can be picked manually by the patient themselves, or by an Admin at the time of sign-up.
Where other developed, trusted systems for patient access exist, we may be able to set up shared authentication.
You need to be able to send the right data, and agree to our terms and conditions. These cover broadly:
- For All organisations,
- Able to provide local administration to verify and add patients and staff users, answer queries about data availability, direct other enquiries and issues to the appropriate place locally, or contact our central help desk.
- Able to send data automatically on registered patients from your information systems. We have an API for this, for which there is also guidance about frequency and content. An older system employed by many renal units uses transmission of XML files. This can be adapted, but the API is likely to be simplest and most flexible. Please follow this link and read ‘Information for local IT system suppliers’ for guidance and links to latest documentation.
- Patients value the inclusion of clinical correspondence very highly, though this is optional.
- For specialties
- Ability to supply and keep under review appropriate information links for the diagnoses you are coding. (See our info links policy)
- Agree specialty-wide policy on development, project policy and steering
- Support adequate staff time to support your specialty centrally
- Give input to the PatientView Partnership Board as required
- For locations joining an existing specialty
- Ability to send diagnostic codes automatically (and if relevant also treatment codes) is highly desirable
- Able to issue logins safely as above
- Capacity to manage staff users locally. We estimate that there is no net increase in admin work from implementation as there is a reduction in queries. There may be some work redistribution.
- For locations joining as Generic Patientview (any or no specialty) – as for joining an existing specialty except for these differences:
- Diagnoses may be sent as list in simple text, uncoded, and/or
- Patients may add diagnoses manually if it is not possible to send coded diagnosis. This will pull relevant info links. Diagnoses are shown as selected by patient. And/or,
- An administrator may pick diagnoses from a list at the point of adding the patient (takes more staff time).
We are a non-profit organisation that has grown out of the NHS in the UK (Ethos). Our costs are low. For specialties, cost of set-up will depend on whether or how much extra development is wanted, but you can probably start with minimal extra. There are no development costs for Generic PatientView.
Setting up data transmission must be addressed locally (with our help).
We favour costing models that relate to the population served by each unit, rather than the number of users, but our costs may fall with very high volume. This is charged as an annual fee which in the first financial year is replaced by a set-up fee per centre. There is an additional cost to setting up a new specialty. There are no extra charges for implementing any of the current features.
Symptom score entering, patient-reported outcomes, clinical dashboards etc can be developed or interfaced using APIs.