Hi All,
The central region is considering the implementation of Orion’s Problems List as part of the clinical portal.
Can I ask members of the forum who are using this product for feedback on how you use it , how valuable or otherwise it has been, and what measures you have put in place to ensure the information is both relevant and succinct?
We want to use is as a tool to facilitate handover and ward wounding.
A number of concerns have been raised, principally around:
Practical insights on how you avoid problems list becoming an ever growing collection of uncurated junk of questionable relevance: who is responsible for curating the list?
use of ICD10 (V.s SnoMed or unstructured data.)
“solidification” of problems, rather than a reflection of the process of coming to a diagnosis. (i.e. people present with symptoms, and then there will be series of differential diagnoses, followed by a working diagnosis, a definitive diagnosis and then sometimes a revision of that diagnosis. Listing “abdominal pain” is unhelpful once a diagnosis of pancreatitis has been made)
Who should be allowed to edit the list? all users, doctors only, hospital docs only etc…
Agree with your points and hence we have asked for a number of enhancements from vendor to reach a minimum viable product before we go-live
The vendor can rename it to something else and our working name is “Curated Issues List” to avoid the word “Problem” (but name can still be better)
Re workflow and updating cadence - that most staff will never curate it straight from the list and hence we may need to use their Care Pathways/CWS product to do Admission, Discharge Summaries, Clinic Letters, etc and populate it so clinicians look at and curate the list at the ideal points of workflow (our pharmacists already do this with medication reconciliation using SMT at admission and discharge, so getting other staff to do ‘issues reconciliation’ is theoretically possible)
Our Geriatrics/ARHOP junior docs already do electronic Ward round and handover notes using MS Word sadly and they love to update the PMH, dx, plan/progress, then copy it into the Discharge Summary and it saves them heaps of time/improves accuracy so the behavior and use case is definitely there
Also being very careful with UI design and minimizing clicks/fields and making it easier for them to search and find the correct SNOMED term (this product seems to have some flexibility with colors, contrast and icons)
At the moment we are thinking to separate it into 3 ‘tables’ or ‘windowlets’, 1 each for:
diagnoses
medications allergies/ADRs (might combine allergies and ADR)
other alerts e.g. social
The list will probably still grow over time and hence it is all about building incentivizing guidelines into the product and workflow so that users see value and continue to curate it
Access - at some point this will become the source of truth so at some point probably needs to be everyone, including patients
Yes there are a lot of pitfalls and gotchas but if done right we still see massive value from finally having the ‘single source of truth’ that is shared across DHB, PHO and patients
I know Dr Nigel Millar calls it an opinion list and that is part of what it is but there will be classifications like sexual orientation or social history (lives with dad) that also make this name a challenge. We have stuck with classification list but in HealthOne it is the even more incorrect “diagnoses”
Curation is indeed the issue and primary care is the place for that being more holistic. The way to go would be to have a SST which serves other record systems. FIHR API would resolve that perhaps. Bring down the list modify it or not and return it when finished. Audit (as in the list at a certain time) is important. Call it My List of Classifications perhaps.
I don’t know - but I see value in a national workshop on this with invited clinical and technical reps. It would be pretty awesome to have agreement on a name and user guidance at the minimum. Do you think this is achievable? @rowena@sax@martin.wilson@joline.wilson@hilary.exton
Hey Derek,
I don’t know either! I suspect that without financial recompense this will be highly variable both at individual and institutional levels. My experience from developping an “ICU problems list” for my own department has been that the interst in curating is almost exclusively among the registrars, and is very individual dependant. Some of my staff find the notion of over-writing “somebody else’s work”, nomatter how out of date or incorrect that work may be, quite difficult to accept…
Hey Rebecca
I was really just hoping to steal as much of the work that the South Island had already done on the matter as I could!
A National workshop could be interesting.
From my perspective, I am trying to work out what we should do to roll out a MVP of this product in our region, so the outputs I would hope to achieve from such a discussion would be something like:
What a minimum viable product needs to do
Good and bad config setups
Ways to extract maximum value for maximum users from the list
ways to encourage curation of this list.
Such a discussion could well go wider than that though.
What do you reckon? Worth setting up a chat sometime? Perhaps at HiNZ?!?
I never know when I am in scope so happy to be chastised.
So in the south Island “stuff about me” (H1) includes:
“Opinion lists” from primary care wherever a classification gets added in the SI it joins the list, medicines prescribed and dispensed in primary care SI wide, district nurse activity lists, some health measurements, all south island labs and radiology, and we are working on encounter notes from ChCh 24HS. The latter is a prelude to perhaps collecting care records from other HCP’s. Then the whole thing is made available out of your GP PMS or Concerto with one click access in patient context. It is all routed in a strong privacy framework where each access is pro actively monitored.
There is lots more to do. for example we could do my list of medicines (or opinions) to allow curation of the “stuff” at every point of care.
the GP’s I have talked to believe curation of “stuff about me” is a primary care role but I cant see why with the right tools it cant be the role of every HCP.
.
We’ve been having similar discussions in the Midland Region but don’t have any final answer. Mostly we intend to use it as a “Past Medical History” of chronic conditions, significant acute illnesses, major surgeries, etc (all coded in SNOMED). Of course the ADEs and social things are in there too, but likely displayed in different windowlets like @brian.yow mentioned. We give the opportunity to update the list in the eTransfer of Care (eTOC) form (discharge summary), but that is a seperate action than assigning the diagnosis for the encounter in that form. Don’t know yet what the actual clinical workflow around the list will be.
I’d love to see an interface that can start using the SNOMED relationships to browse a patient’s record; e.g. if they have “COPD” in their problem list then you can click there to see what eTOC forms have “COPD exacerbation” as a diagnosis, their chest x-rays, PFTs, etc, all linked together on the fly from SNOMED relationships.
But it sounds like you’re wanting to use it as more of an acute problem list for an encounter; e.g. “anaemia, septic shock, AKI” and so on. Makes documenting a hospitalisation effective as well. I’ve asked Orion about having a seperate problem list to be encounter specific but the product doesn’t do that.
I’d be up for a national workshop to sort out what to do because it would be great if we all do the same thing.
So Orion is in partnership CDHB which is in partnership with Pegasus Health to do HealthOne. I cant understand why we are not all working on improving the thing together to turn it from a South Island system containing 1,000,000 patients to a national system containing 4 times as many. when you think about it, it has been scalable across 5 DHB’s and 1M patients and is accessed (off the top of my head) 160,000 times a month.
I completely understand your SNOMED CT thoughts. H1 has read codes which are compatible with SNOMED CT. Alistair K says we could change without difficulty…but if you entered Diabetes mellitus (C10.00) into an easily designed search engine on an individual patient it would spit it out but why not just look over the stuff about me because it should be there. searching the CDV tree in Concerto (our HCS) is where you need the search and Orion are looking to partner on that. For me I would start with the primary care stuff and work to the CDV tree if is a bit slack in its content.
Just saying
This is something that we need to address as a group, urgently. Without good national clinical leadership and approach, this is going to produce a disaster.
We clearly need to work together on this list and agree on the terminology and purpose of it for all. This is a real opportunity to use the power of CiLN for good.
@Mat - are you in a position to lead this? We can make a more private space on Discourse to work on it once you pull the people together.
Please include me in this work. We use Orion’s “problem list” within our electronic patient record in our 14 hospitals in the Southern Cross Hospitals network
– albeit from a nursing focus at this stage. It currently serves us well in our specific context (as we have moulded it to suit our needs – and moulded our practice around its functionality) but acknowledge it needs development to serve a wider purpose and
user base.
I’d like to be involved in this - mostly from the perspective of the data model and API access to such a list (via FHIR) in support of the healthcare ecosystem including - and especially - patient/consumer access to such a list.
There’s little doubt, though, that SNOMED is the coding system that should be used…
cheers
Disclosure: I used to work for Orion Health (though not on the Problem List product) though not any more.
Martin. The short answer is that we have suffered from synonyms and homonyms with each regional slowly convincing themselves what are the core component functions of an EHR.
At the same time, we have a vendor market that is encouraged to sell time and materials rather than a consolidated feature and release cycle with a roadmap. Then there is the capital project machine when we should be moving to subscriptions services.
When I did a national survey comparing the 4 ICT health islands, it is amazing how we have managed to create the underlying silos to be so different but also with bespoke un organised interfaces.
eg something seemingly so simple as joining DHB to log in, ( despite great effort on my part to ask "what have the other regions done) we have had to build a bespoke, unique login system into this regions Concerto 8. And I have been told giving GP access to this is “not possible” until I really pushed. When our architects asked about a road map to do this … ummmm.
but with Zoom all AD joined as a IAM federated securely with telehealth to all four AD just like that… boom.
Don’t get me wrong I am not getting at orion over this, just saying the legacy of how we have procured and paid for ICT as 21 DHB and many more PHOs, all in an uncoordinated way means we have alot of rationalization to do.
Healthone does a great job at leading the way around what core functions can look like at a presentation UI layer. However the linking into from an API and Data layer per region with IAM working off HPI would be ideal - but such a big job to get this “underneath” sorted I think it would be logical to do it once and allow for agnostic presentation layer apps. This allows for more agility in presentation and process layers that would access an organised API layer. Also, this allows for business rules to be called on (like specials authority numbers) in the background to inform your clinical process inside that chosen presentation layer.
The democratisation of data, freedom for microservices, free market for the presentation layer
All, A very lively discussion and this is something we should work on, getting it right at the base layer . Core to this I think is getting consensus of what we call this and how we use it are talking about “Opinion lists” "classification list " “diagnoses” or “Curated Issues List”.
There is also a need to specify whether the issue on the list is time bound or ongoing, with the potential to review whether it is an issue next time people are seen. Otherwise you stand the risk of this becoming something that is just copied and pasted from admission to admission.
In dietetics we have Nutrition care process with defined nutrition diagnoses these are used to help crystalise the purpose of our work or interventions with patients and are also used to help monitor progress. They are evaluated at each visit and can change depending on the patient. Now I appreciate these may not be exactly the same as a problem list to some other people but in a way is something we do need to standardise. We are talking about a list of issues we are working with patients on, it needs to be something we monitor over time and work towards improving.
Look happy to be involved in the wider discussion and found some good articles as a starter for ten that get may help surface some of the prickly points we need to address and come to consensus over.
Look forward to helping do this in a way that would work for the whole MDM team i.e. a stock take of what everyone may be working on with a patient that could be of use to Doctors, Nurses , Dietitians and other allied health staff.
Great conversations. What I am hearing (reading) is that:
1- This isn’t about a particular vendor’s product e.g. Orion’s problem list, it is more we all have a “problem” consistently documenting and more importantly integrating - a trusted list of a patient’s “problems”- I like the following description from OpenEHR problem list archetype A persistent and managed list of any combination of diagnoses, problems and/or procedures that may influence clinical decision-making and care provision for the subject of care.
2- Many of us across the country are thinking about this issue and some have created local solutions, some of which use standards and some don’t. This makes it really difficult to aggregate and form a longitudinal/persistent view of a patients’ ‘problems’. It is also expensive from a vendor and implementation perspective as we are all recreating local solutions
There are international organisations/groups that have looked at this and defined the minimum or maximum data sets for a ‘problem list’- This includes HL7 functional EHR model and OpenEHR Problem List Archetype. SNOMED terminology should form part of data terminology but doesn’t give us a complete model e.g as Nathan mentions part of the data model may include active/ inactive status etc
There may be differences between what a Dr, Nurse or Allied Health Professional would deem a ‘problem’
There is an need to define the data model but also some of the business rules around curation and maintenance of the data
There is lots of energy to collaborate together to come up with a National standard. @BeckyGeorge I think your idea of a workshop is a great one as I think if we did a little bit of online collaboration prior then we could have a really productive session to try start a national standard on Problem Lists
I’m happy to be involved in an organising capacity if a few other people want to kick this off? I was thinking we could start with a shared folder for literature, international models and current examples of problem lists. I’m happy to start a google drive folder unless @NathanK there is some sort of functionality within this platform?
On another note I’m about to start another thread on a piece of work I’m doing in the Northern Region with @karl and @karenblake to start to define the key data elements of a persistent longitudinal patient summary. Problem list is one of the core data concepts in such summary/view. I’m sure others have done such thinking as well, and believe this is also something that needs a national standard.
We should definitely be thinking API (Services based) rather than the user interface, as there’s more than one way this data could be presented - to different audiences on different devices in different contexts. Start small - don’t try to conquer the universe at once. Looking at what healthOne have done wouldn’t be a bad place to start…
Standards like SNOMED and FHIR are the agreed ones to use in NZ
David the problem is standards is that we love them so much we have so many of them. The issue I am having trouble dealing with is the functional requirements in the procurement process.
We, the converted, can agree all day long but unless we have a consistent way to describe the requirements done by Business analyses, in the business case and procurement stage. However we continue to go to market as we do now, with little or no reference to a target operating model and markedly different ways to describe the same thing.
I now am convinced we need new type of business analysis, clinically experienced business analysis and architects, as a strong workforce, to be working from a common terminology set at data, requirement, functional and process levels, who are the translators for our front line clinicians. Quite an ask.
The discussion on problem list is a good one focused on learning from what has been done, applying/agreeing standards (SNOMED, FHIR etc) and access to the data, and collaborating to help implementation.
In terms of the question of whether we should move to a single system the Ministry view is that we should definitely leverage and build on what we have but that the key is trusted access to data from multiple sources rather than a single system. There are multiple problems/opportunities and one system will never be able to solve them all.
Delivering on opening up access to data will require technology components (data sources, integration platforms, applications for example) but also other enablers such as standards, national services such as for identity, commercial frameworks, enabling policy etc… That is the scope of nHIP. We are hopeful that we get Cabinet approval later this month to proceed to develop the investment case and I want this network to be a key contributor to that process.
I like the thinking…solve the identity/access challenge, open up access to the data through APIs, let the market innovate and the customer choose the systems that solve their problems best.
@karl@amscroggins@david.hay agree that we need the standards and that the challenge is not the lack of them but translating them into practical implementation. A couple of thoughts -
We need to be prepared to pick a reference standard (FHIR and SNOMED are good places to start) and then use implementation/POCs/MVPs to inform how it needs to be refined to work here (@BeckyGeorge is the allied health experience a good one here?). HISO is there to enable that to happen.
Implementation requires more than just the standard - clinical and business leadership, good quality data, commercial frameworks, aligned product roadmaps etc… That will be the hard part but you have to start to understand how significant those barriers are.
