Well, that’s generally true - though in this case there are really only 2 (health related) ones that count.
Given the number of times that this kind of question has come up on various forums I’m reminded of this: https://www.youtube.com/watch?v=m_MaJDK3VNE
Just as well that the banking industry doesn’t have the same affliction…
Hey All
Thanks for the thoughts, comments and general contribution.
What I’m hearing is at least some desire to be create a kind of unified way forwards with regards how a problem list is managed.
I propose that we convene a group for a face to face at HINZ of those who are interested in advancing some kind of direction on this at a national level. (I’m out of the country for 2 months). The names I’ve heard for folks who want to put their hand up so far are:
Rebecca george, Anne-Marie Scroggins, Nathan Billing, David Hay, Carey Campbell, Matthew Valentine,
Are there others who would like to put their hand up to be a part of this? I think it would be very helpful to have a MoH representative as part of this group.
I reckon a face to face at HiNZ would be good, with a bit of on-line prep work prior…
Cheers
Mat
Afternoon all,
Picking up on comments several comments and themes raised. Interested to be part of on-going conversations around this.
In Canterbury we have found the implementation of agreed shared business rules or principles for use in these type of platforms challenging.
My observation has been that staff across our organisation have found the culture shift in ownership of information hard to overcome when the data sits with the patient and remains with them rather than with a service or episodic intervention.
Happy to share what information we have for what value it may add.
As part of RNZCGP fellowship assessment and cornerstone quality for practices, an up to date ‘problem list’ is required in the notes review section
In our practice we code pretty much everything, and keep the important stuff ticked as ‘longterm’ or ‘highlighted’. In the UI the longterm floats at the top - the URTIs, UTIs and UPSIs float under and are not referenced so often, though it may be useful to search the record for all times someone has presented with say, a sore ear.
Sadly not all GPs are as good at doing the basic essential - code important ‘stuff that matters’
Would be helpful IMO to separate the classic ‘social and family history’ (smoking, occupation, alcohol) from the ‘problem list’
Hi all,
For my sins, I’ve been watching this thread not knowing where to start because:
Answers to the initial questions from @Mat
Who’s responsible for curating the list? I’m of the opinion that national clinical leadership groups (eg. CiLN) should be collaborating to determine what’s expected based on specific use-cases which can be supported by corresponding domain experts and industry partners via a co-funded connectathon. I think this could happen through MoH support of getting the right clinical leaders, clearly defined use-cases, industry community (software vendors) and domain experts together to properly understand what the problem is and how best to solve this using the best approach with the best standards and making the most of the data collected, from clinical care to population health policy development.
There is a common myth of either using ICD-10 or SNOMED-CT. They are complementary and should be used for different purposes. They can and should be used in combination with other standards (eg. the simpler FHIR, the more complex openEHR).
Diagnosis progression and process (ie. symptoms → differential → working/provisional → definitive → revision…etc). This is a difficult one because many regions/DHBs/PHOs operate slightly differently but are ultimately doing the same thing. I think there should be national collaboration to inform a more standardised direction of the products development. In an ideal world, clinicians should be able to seamlessly transition between PHOs/DHBs without needing to re-learn system processes. There are also limitations of the product and how flexible/clear it is when changing the status/progress of the diagnosis. eg. multiple symptoms may result in a single and/or multiple diagnoses over the course of the episode/encounter presentation.
@MValentine - I completely agree with you. Being able to see conditions based on related clinical concepts in reports, documents, results etc was something I was keen to work on. I don’t know of any system that’s capable of this but, in theory, it is possible.
Who should be able to edit the list. Interested in other perspectives on this. My opinion is that read-write-edit rules need to adapt and change as the health systems change (both as technology and policy develops). I believe that, on the condition that effective clinical auditing tools and processes exist and these are standardised, all clinical users should be able to view, add to and edit the list. I’m also of the opinion that regarding break-the-seal features in any systems should be considered as a last resort and control should sit with informed, consented patients. Until that time, I think we should trust clinicians to do the right thing and access the records appropriately based on the scope of their practice and utilise tools and processes to audit proper access. This also opens up the discussion of provenance of information which may result in some interesting debates
Further comments:
@BeckyGeorge it may be helpful to host another ‘On Our Terms’ presentation at HiNZ, this could lead into a collaborative discussion and options moving forward. Interested in your thoughts here.
@darren.douglass, I agree with everything you’ve stated above; pick appropriate reference standard/s and support the ‘how to implement’ including bold leadership, collaboration and commitment at all levels. An exciting challenge!
@Mat, I would be keen to join, support and provide input with the group listed above at HiNZ. I’m keen to collaborate and debate various approaches from short-term solution to a more sustainable and sustaining approach. That said, I don’t want to join and then the group become ineffective with too many members.
Cheers,
Michael
I remain struck by the relative size of the New Zealand healthcare informatics ecosystem (small), the degree of fragmentation, the
ongoing belief in a neoliberal/capitalist philosophy that the market will be responsive to needs, the disconnect between purse strings and front end users, and lack of any sort of centralized mandated standards/data sharing/etc.
This applies from the level of MoH down to DHBs and PHOs.
Illustrative of this – CDHB is one of the early adopter/beta sites for a lot of Orion products – I’ve heard about the Problem list
being discussed for several years. In spite of this relationship – it is worth pointing out that CDHB is on the road to adopting Cortex as an EHR, with a competing “problem list” approach, which will then generate an nth direct clinical interface system,
competing within a single software ecosystem for the same intellectual/business real estate.
Realistically, the market forces have already declared national standards are not meaningful (if there are national standards), when
we are discussing ideas like this at the tail end of the dev process. The best we can hope for at this time would be an API from Orion that would possibly shoe horn some sort of minimum data set into a national query-able repository.
I despair in having moved from a single healthcare system in the 3rd world that used a single set of solutions to allow
interoperability across primary to tertiary care, data visibility, and centralized analytics to inform healthcare system change covering ~6 million population, to a 1st world setting with such a fragmented ecosystem that a 30 minute drive in any
direction virtually ensures any healthcare data is lost between siloed healthcare information systems.
At the national and regional level, this degree of fragmentation is frankly an abdication of leadership.
My list of medicines.pptx (290.2 KB)
Don’t just think we should only be talking about Orion problem list. The solution is federated and any PMS should be able to handle it. So in this presentation if you take the word medicines and replace it with “stuff about me” AKA problem list and talk about FIHR API’s connecting the one list to other systems then this ancient PowerPoint of Shayne Hunter’s describes at high level what I believe we need to make the patient journey more efficient and effective don’t you think?
Given HealthOne already has FIHR API’s we could be half way there?
Hey Martin,
You might be right - provided we can convince the disparate groups around NZ to submit to Health One as the “One list to Rule them All” (Shayne’s words) then we may already have a solution.
My question for you: I outlined what I see as the barriers to adoption of Problems list in my DHB earlier in this thread. What barriers do you see for Health One to go beyond the south island?
Hey Rowena,
please share what information you have around the Canterbury experience - this is exactly the kind of info I am looking for before we move ahead with something similar!
What follows is very high level probably a bit simplistic but here goes:
So there are 2 parts to the question as I see it and I am going to replace the word Impediments with requirements, I hope you don’t mind:
Requirements for HealthOne H1 adoption in the North Island (NI)
Requirements required for doing My List of “opinions” (MLOO) as part of H1 in the NI and SI
Requirements required for doing “My list of Medicines (MLOM) as part of H1 in the NI and SI.
Its what we do sure is
Alastair Kenworthy would be a good MOH rep (assuming the clinical aspect of this is covered by the other participants)
@matthew.strother I agree that the current environment is frustrating and we are all motivated to fix it.
The Ministry view is that the current environment isn’t proof that standards are invalid and therefore a single system must be the only/best option - but it is proof that our current approach isn’t effective for a variety of reasons.
The Ministry is advocating a more hands-on approach (not a neo-liberalist/capital philosophy!) where we understand the levers you need to support standards implementation, create the environment for success, and are very clear that standards aren’t optional. We aren’t a lone voice in that regard - other jurisdictions are taking the same approach, our advantage is our size and potential ability to move faster.
In some specific use cases single systems will make sense, for example we only want one NHI. We are clear though that a single system for NZ isn’t the answer; it would inhibit innovation, write off a lot of existing investment and send NZ down a cul-de-sac.
The open discussion is important as we need to keep challenging each other particularly on what it is that prevents us from delivering value, or solving real clinical problems.
All,
Really lively debate
The issue here is consistency and understanding of requirements for things like lists and other core functionality. Hopefully we will be able to work some of this out in the problem list working group .
However, I have also found that even when you do have the requirements defined at the outset things change as soon as you start rolling it out in User Acceptance testing because you have subtly changed the workflow, and hopefully improved process.
Dr. Eliyahu M. Goldratt, in his lecture titled Beyond the Goal: Theory of Constraints , describes the necessity of answering the following questions when adopting a technology:
The biggest issue with focusing solely on the requirements you have now, is that you have not factored in how processes will/ may change when you start using the new technology as a result of the new implementation.
As an example, We are transitioning towards electronic records that are easily shareable (1) and can be used by many including the patient (2) to keep a list of problems or concerns. We have normally been focused on the main issues during the current encounter, in secondary care at least, and there is no need to maintain this list and each profession has their own(3). When we do get a solution and start using it we need to consider how to curate it. I.e who added it, when was it added to the list , when was it last reviewed, what are we doing to address it. (4). etc
With this discussion forum we finally have people talking out of their respective silos. This is part of the solution. But let’s not forget about factoring in how we will need to act once we do have a widely adopted solution in place. By building something simple that has utility for all staff, nuses, allied health, doctors ,and patients we may move to a situation like this https://youtu.be/nel8S0sbkVY.
Cat herding sorted 
Thanks - I had a conversation with nathan - and indicated my prior response was in no way directed at anyone - but that it was a threading issue (responding in line via email as opposed to logging onto the site for a response) that seemed to direct it at you. I apologize if that seemed the intent.
I do think that there are potential solutions, but I have a sense that a lot of the parts involved in making those solutions feasible loco-regionally and nationally are silo’d, come under differing administrative structures, and differing budgets.
I would love to see some sort of minimum standards at the level of the national discussion for definitions and dictionaries - while adoption of SNOMED, LOINC, HL7 is helpful, devolved decision-making to individual DHBs insofar as software selection, local development and definition standards is replicating the chaos of the US, but on a microcosm. Several academics have pointed out that in the US, the predicted benefits of the HITECH act have been unmet largely because of the lack of centralized process, a market-based approach leading to commercial interests overriding the public good, and creating a circumstance where there is immense difficulty in creating health information exchanges at any sort of loco-regional level.
A great example of dysfunction has been the adoption of MOSAIQ as the SI solution for oncology prescribing. While we all operate on a common platform, different site level definitions and protocol variation has led to an inability to share data, without extensive pre-processing, mapping, and the loss of information associated with that process.
I would love to participate in national discussions of this - particularly because my interest (an interest in ML/AI use) which in the current environment will make any developed software only applicable to a small population in which model training occurred - and would require extensive duplication of work between localities, or significant intrinsic risks of cross application of trained models across jurisdictions.
2 posts were split to a new topic: Matt and Nathan
@NathanK can we rename this thread to NZ Problems List or National problems List.
This piece of work needs to be vendor agnostic and consider interoperability as an underpinning principle.
A couple of thoughts-
-Consider the patient centric view- symptoms may be different from the diagnosis, how can patient access and contribute to this- or can only clinicians. diagnose and edit the problem list
Dear all,
Thanks once again to all who have contributed to a robust discussion thusfar.
I think Nathan has touched on an interesting series of questions, and take this discussion significantly wider than it initially started out…
I started this thread seeking advice on implementation of a problems list focussed primarily on secondary care, and during the discussion it has become clear that there is a diverse range of uses and needs.
The areas I have identifed thusfar relate to the breadth, depth and “meta-problems”
I believe that if we are going to make any national or ministerial recommendations, then we would need to be very clear about what we want in domains 1 + 2. Issues 3 + 4 will largely be defined by what we believe is important in 1+ 2.
While Alastair Kenworthy has had his name put forward as a MoH good person to inolve, I’d rather somebody who self selected if possible.
I look forwards to the discussion at HINZ. I ask that those who have put up their hand think about these issues, as well as any others they have identified.
I am a simple soul, and in the interim will propose to our region that we implement an instance of Orion’s problem list to solve the issue we have locally. I say this because I want it to interface reasonably seamlessly with the portal, and it makes financial sense in our region. I’m going to take Brians advice and roll with “curated issues list” until somebody comes up with a better name 
Yes, GPs as the ‘usual’ primary care provider would be the right person to curate/reconcile, as long as after doing this work, it will be considered and respected the next time the patient has a care transition. At any point in time over a life-span, the patient should be nominating who their primary ‘curator/reconcillor’ of information is. This should be flagged and indicated as part of the UI of a product. So, when you are undergoing cancer treatment, and not seeing your GP much, your oncologist because your primary curator. Then, you are returned to GP care. Attached is a storyboard that depicts this. Whomever does this curation, it must be recognized as vital activity in medical care, like CVD screening . . . or, crafting a referral letter or ACC report. Poor curation of the ‘single source of reconciliation’ of all the core data sets (Common Clinical Data Set) is a source of medical error. I dream of a day there is a UI that automatically brings up a ‘merged’ problem list/medication list when accepting/importing a care transition document (RSD, etc) . . .where, a discrepancy is displayed in a way I can then select which is accurate, which then overrides lists on all places where a patient’s record lives (e.g., from patient portal to all services in the person’s ‘circle of care’). MS4385_storyboard_FINAL.pdf (1.5 MB) (working as GP, spending far too long reconciling discharge and outpatient problem lists/medication lists with PMS . . . knowing that the list I sent in at referral/transfer may, or maynot, have been considered).
Hi Matt,
For what value it adds. Principles for use crafted for another piece of work but we are exploring how learning’s from doing this approach may apply to Problem list at the moment too.
Thanks, Rowena
5. Principles for Collaborative Use.pdf (438.6 KB)
Thanks Rowena, as you say, it’s made for something different, but good to think about the principles