Have created some headings and ask if folks could maybe contribute… we’ll see how it works.
For the discussion that has kicked this off see https://ehealthforum.nz/t/orion-problems-list/9470
What is the principle purpose of a problems list?
- Provide centralized repository of clinically relevant issues (definition of clinically relevant TBD)
- Up to date - defined as updated as new clinically relevant issues arise
- Curated - routinely reviewed and “cleaned” to ensure the list is capturing
optimal data
- Visible - should be visible for care providers at times of clinical interface with
patient
What secondary requirements should we attempt to consider?
- codifiable for research, QI, Administration, etc
- Captured as part of user-intuitive clinical workflow
- Able to capture incoming clinical terms (SNOMED) from e.g. eReferrals and incorporate into clinical workflow e.g. ED admission → Dx diagnoses → Ward admission → additional / changing Dx → Dx summary
- Potential to have the list of problems linked to interventions and monitoring of progress to enable review ####requires specification of intent - how does this pertain to content and format of the list ####
- Potential to prioritise the list to show the issues your speciality is working on but also ability to see the list of what everyone is working on, important to enable teamwork and ensure synergy
What is out of scope for a problems list? (e.g. allergies)
- allergies, alerts (e.g. domestic violence)
*Noting at least one proprietary ‘Problem List’ includes ADR / Allergy
*medications
*Tasks - time limited minor issues (e.g. a laceration)
Who are the users/target audience?
- All clinicians with appropriate access and training and ability for patients to communicate a query or error
- Clinicians initially through conscious interaction with the Problem list
- Objective - incorporation of Problem list within differing ‘frames of operation’ e.g. visible within an admission or OPD document with workflow enabled population of Problem list via the workflow form / tool
- Patient access via a Portal ideally once the GP, DHB and any other problem lists (e.g. Out of area) are unified
- Patient editing via several staged capabilities
Initially via messaging to relevant clinician if they have a comment / issue / addition
Automatic inclusion of ‘Goals of Care’ or other key aspects of eShared Care Plans
Patient initiated problem addition via Portal
- Version 1 of this should be for clinicians within secondary and some primary care, GP’s may already have lists and
What is the minimum number of lists required?
The data should be the same but the presentation layer needs to be *different in various settings e.g. patient centric view, primary, outpatient, inpatient, etc
*Needs careful consideration: Key diagnoses / ‘Problems’ (short-term or ongoing) wherever added (IP / OP / 1ry - Community) should form a common core view. Other (Needs definition) entries e.g. multiple minor SNOMED-coded procedures during a hospital admission should be hidden unless tagged as important e.g. Angiography. There will be ‘mid-level’ entries (e.g. Pneumonia - admitted) that should be visible below the ‘core’ list
Chronic, in hospital, procedure, diagnosis, functional limitations, Other?
Nice to have sort and order features depending on the care setting and use case, especially to drill down into specific problems e.g. NLP to link spirometry for COPD
There would all be filters e.g. Procedures, Operations, Illnesses or ‘Associated with COPD’ e.g. Spirometry / CXR
- The answer to this question depends on how many lists there are and whether the focus for the list is on what you are doing working on as a health professionals. We all have our part to play and if this is used by all will need to be able to filter views.
What features would optimise utility, curation and uptake?
Usability, visibility, transparency (interoperability).
Ability to easily view and edit as part of normal clinical workflow e.g. clinics and hospital admission. We have an admission summary that populates certain info to discharge summary and clinicians intuitively started closing the loop because it saved them time and the patient didn’t have to be asked the same thing multiple times
- This list needs to be linked to a SNOMED onto server so users can search for terms using synonyms. this may be cumbersome at first but over time should get better as common search terms are surfaced quicker
- List should be able to be sent to other documents like discharge summaries or clinic letters when being created
What other data fields/metadata would be needed? (date, user/ role uploading, tracking of changes, severity etc)
Ability to flag - using metadata/ SNOMED associations if a similar diagnosis / entry already exists. E.g. DVT to enable confirmation of ? New ? Continuation of existing.
Need rules for the above to ensure (e.g. for a DVT review visit) that the original date of occurrence is retained AND then all associated visits can be linked to that initial date / diagnosis (like for a PAS, a series of OPDs can be linked to a specific referral). IF the Clinical term is incorporated into say an OPD eWorkflow form, the above process will be automated with the CLinical Term link mirroring the PAS referral link.
- Following fields may be of use (User CPN number, SNOMED problem code, Date time added, Potential severity details (free text tweet length), action plan to address item ( Text but again succinct maybe two tweets), status (i.e. for review, ongoing etc) if for review planned time to next review if needed
What standards are relevant?
SNOMED-CT, FHIR, openEHR
Non-traditional standards like UI heuristics to employ colors, symbols, contrast and other subtle cues to guide and prompt users, making it easy to do the right thing
What should we call it?
Curated Clinical Summary (* Who is the curator?!)
- Ongoing Clinical Conditions under Active Management (OCCAM’s) List
- Diagnoses and procedures
