Thanks @Mat, happy to be involved in this for standards. I work for @darren.douglass at the Ministry and chair the HISO standards committee. If the clinical community can reach consensus on what the problem (or opinions) list should be then we can back that up with data standards. Comments from HISO members @BeckyGeorge, @karenblake, @david.hay and others including @michael.hosking give a flavour of this. The base international standards are all there, it’s a matter of how we localise and apply them to meet the needs
Hi Alastair,
Hey Alastair, It would be great to have your contributions to this! I see the big picture goal here of development of a nationally visible list of problems. The challenges appears to be what that list should include (and shouldn’t) and how the list should be kept up to date.
There is a “personal message” discussion list for those who have indicated an interest in becoming part of working group on how to progress this topic. I have invited you to that, and welcome your contributions.
Welcome!
Just to re-iterate from the above post.
The “personal message” component is not an attempt to be exclusive, rather to gather a group of folk who wanted to come together (at HINZ, it looks like) and sort out the nuts and bolts of how something like this could happen… If you want to be a part, and are not in the group, speak up!
Hi there
Yes I am very happy to be involved and think a meeting at HINZ is a good idea.
Just a few points to note
- I think once we have had some online conversations (I was thinking we could start a Wiki) and meet in person, I think we should approach HISO about this work becoming a national approach
- I really want to keep away from conversations about vendor’s initially (your 5th point) I think it is much more helpful to start from a vendor agnostic perspective and focus on the data and process layer.
- Let’s capitalise on what has been done already nationally and internationally around this and agree that starting with SNOMED and FHIR is the right approach .
Thanks
Anna-Marie
Mat,
I agree with Anna-Marie in that is should be vendor neutral. I also do not think we need to boil the ocean.
- Lets focus on the simple stuff i.e what are the minimum data fields we would need to provide the greatest utility to the most.
- Lets focus on how we can leverage FHIR resources and SNOMED to make this easier to share and practical to use in many systems
This focus on getting the basics right would be our minimal viable product and will help overcome any initial inertia. It does not need to be perfect, just usable.
I also have some projects that may be starting in November and am not sure if I will be able around for the full health tech week. But let’s keep the discussion going
If you could pick a max of 5 fields for each row or problem to do this list all what would they be?
I think some of these could be metadata ( i.e. potentially captured by system list is in
- staff id HPI#(to give you staff type) ,
- date added (? with set review times for certain conditions),
- facility (primary secondary care, outpatient clinic).
- You would just need the problem (SNOMED ref set for each profession adding)
- a final status field (active, inactive, ongoing, for review)
Would that work? What would you take out or Add?
I also think we need to come up with a better name for this list other than “problem list”
All the best,
Nathan
1 Like
There’s a project in Aus run by CSIRO that I’m working with that is defining a GP summary dataset - similar to our GP2GP, but scoped as a summary rather than a complete record. This was determined by a group of clinicians and PMS vendors (about 30 people) over a number of sessions - both face to face and virtual. In particular, they determined that separating procedures and problems was problematic (due to the way that they were recorded in a PMS)
You can view the model directly here: http://csiro.clinfhir.com/ (it’s the common model) but the elements defined were:
- diagnosis
- name / site (coded)
- severity
- date clinically recognized
- comment
- status
- procedure
- name (coded)
- date performed
- comment
cheers…
···
On Thu, Jul 4, 2019 at 11:04 PM Nathan Billing via Digital Health Networks discourse-notifications@digitalhealth.net wrote:
[Nathan Billing ](https://u1980013.ct.sendgrid.net/wf/click?upn=KFL5ItWFbQhXGlA8EdfEZ7OjpLWhnuogorrzvtKUpwwB8KR3R-2FDc-2F-2BNYTH-2BW6llPFa4yzOzTJr80ODibDiLG3w-3D-3D_UZ-2Fw3Bg8EOda-2F-2BSazO07kev1gUT-2F4gCy5SRjJrFYxKmt6lB-2BjmMFycU6MiJqKpiIomSg6lefNp-2BK5g-2FX1fp4BWOlOxN-2FUt4pzNFW4DrDwPmwzw4bAZcGZNZtfj4Nm2dw8Ws4KJrxhPzvxGbMzk-2F6MEaDP9M-2B4L1vx0kTTvYvGnPd4Lk2gFAhrzYLvAI5G01KFgLxU7PO2SUXqJVKdYi5O678yT0gdzgQlkmj-2BZmC6JM-3D) NZ Clinical informatics Leadership Network Member July 4Mat,
I agree with Anna-Marie in that is should be vendor neutral. I also do not think we need to boil the ocean.
- Lets focus on the simple stuff i.e what are the minimum data fields we would need to provide the greatest utility to the most.
- Lets focus on how we can leverage FHIR resources and SNOMED to make this easier to share and practical to use in many systems
This focus on getting the basics right would be our minimal viable product and will help overcome any initial inertia. It does not need to be perfect, just usable.
I also have some projects that may be starting in November and am not sure if I will be able around for the full health tech week. But let’s keep the discussion going
If you could pick a max of 5 fields for each row or problem to do this list all what would they be?
I think some of these could be metadata ( i.e. potentially captured by system list is in
- staff id HPI#(to give you staff type) ,
- date added (? with set review times for certain conditions),
- facility (primary secondary care, outpatient clinic).
- You would just need the problem (SNOMED ref set for each profession adding)
- a final status field (active, inactive, ongoing, for review)
Would that work? What would you take out or Add?
I also think we need to come up with a better name for this list other than “problem list”
All the best,
Nathan
Visit Message or reply to this email to respond to mat, mvalentine, amscroggins, rkgeorge, michael, david.hay, carey, Gastrodiet.
To unsubscribe from these emails, click here.
Hey All
thanks for these comments.
With regards to the 5 top pieces of data I would associate with a problem - any particular reason you nominate 5, Nathan? I am a little circumspect that such a small dataset would unlikely meet what I think we need for the central region use case. As a start, we would want something with capacity to update a problem, and record update times and users. I think that alone would take us to more than 5 fields.
The issue of the right vendor is always an interesting one when there is an existing product in place, and it has been integrated to an existing version of Orions Portal. I personally think that we should all be moving towards a single instance of a data repository across the country, and attempts to converge are more desirable than attempts to diverge. There is also the very real issue of the manpower and time to do the build - any product that already has the setup work largely done is at a significant advantage. So while I am in no way wedded to any particular product, I’d say that unless we honestly believe we might influence a national procurement of a single product, I’d stick with one of the products currently in use and interfaced to a NZ clinical portal.
Cheers
Mat
HI all
I’m attending HINZ and will make myself available to meet as a group. As mentioned before, we use Orion’s problem list across our 14 hospitals and find it an
extremely useful tool (albeit not perfect). In the absence of implementing SNOMED (which is a whole project in itself for us) we have our own code set – which while it’s not ideal at all for wider use, we needed to get something off the ground or else we
wouldn’t be as far down the track with our EPR implementation as we are already. We aim to be as Agile as possible – we can enhance things later.
Agree with Nathan about a change in the name – we don’t call it ‘problem list’ as there are many items that our patients would not see as problems. We include
Allergies/ Adverse reactions, Conditions (generally these are medical conditions) and Alerts in our “problem list”.
Agree with Mat that more than 5 data fields are required. As a nurse user, it is helpful to have the information source included – a good example in our context
is that if the nurse is adding a medical condition onto the list, then this needs to be covered by where this information came from (as nurses do not make medical diagnoses).
We use the ‘problem list’ within our workflows as well specifically during department to department handover – an example of this is that on transfer into OR,
the OR check-in person ‘confirms’ or ‘edits’ each entry with the patient. This is great for audit purposes and also helps to ensure the list is as up-to-date as possible as the list is also ‘reconciled’ on admission as well as during the transfer to OR process.
I’ll stop now – as this is getting to be an epistle….I apologise, but ‘problem list’ is key to our EPR and it’s really helped us move forward with our implementation.
Carey
···
mat
Matthew Bailey
NZ Clinical informatics Leadership Network Member
July 4
Hey All
thanks for these comments.
With regards to the 5 top pieces of data I would associate with a problem - any particular reason you nominate 5, Nathan? I am a little circumspect that such a small dataset would unlikely meet what I think we need for the central region use case. As a start,
we would want something with capacity to update a problem, and record update times and users. I think that alone would take us to more than 5 fields.
The issue of the right vendor is always an interesting one when there is an existing product in place, and it has been integrated to an existing version of Orions Portal. I personally think that we should all be moving towards a single
instance of a data repository across the country, and attempts to converge are more desirable than attempts to diverge. There is also the very real issue of the manpower and time to do the build - any product that already has the setup work largely done is
at a significant advantage. So while I am in no way wedded to any particular product, I’d say that unless we honestly believe we might influence a national procurement of a single product, I’d stick with one of the products currently in use and interfaced
to a NZ clinical portal.
Cheers
Mat
** Visit
Message** or reply to this email to respond to
mat,
mvalentine,
amscroggins,
rkgeorge,
michael,
david.hay,
carey,
Gastrodiet.
To unsubscribe from these emails,
click here.
All,
No reason just an initial punt, I just wanted to get the ball rolling. It was the smallest number of data field i could come up with that would logically facilitate a list of problems within a system, i.e assuming you have already authenticated yourself in the system, have been provisioned read write access to the list, and the system you are using has a defined location (facility).
So as a user i would only have to worry about being able to add items to the list and change the status of things on the list.
It is interesting, looking at the subtle differences in the list there between a diagnosis and a procedure there is only the severity of diagnosis and the context of the date (i.e. date performed for procedures and date clinically recognized for diagnosis) .
Context is important, i agree. Would it be sufficient for that detail to fall under comments or should that be a field specifically?
Good to have got the ball rolling and have an idea of some of the fields we would have on the list.
I do think we need to get a better idea of how we all could use this list,
- do we need to have different views of the same list? e.g current problems working on this shift vs longer term challenges we are working to
- do we need it to be a list of diagnoses? or just a list of diagnosis responsible for this admission
- do we include “working diagnoses” in this list
Hi everyone
Great comments
- I very much agree that we need to identify the role of the person entering a ‘problem’. This can help validated if we ‘trust’ the data
- I personally don’t think adverse reactions or alerts should sit under a problem list as once you implement E-prescribing adverse reactions need to be coded specifically to enable drug to drug interaction alerts etc. Again, alerts have implications in terms of national medical warnings.
- @david.hay It is interesting that procedures were included in the model
I wonder if we can start a Wiki for this conversation so we can start to model the concepts? @nathan can you show me how?
1 Like
Hi Anne - the reason for including procedures was that in the GP systems, these are often held in the same place, and they would have issues ‘separating’ them…
cheers…
···
On Tue, Jul 9, 2019 at 11:12 AM Anna-Marie Scroggins via Digital Health Networks discourse-notifications@digitalhealth.net wrote:
[Anna-Marie Scroggins](https://u1980013.ct.sendgrid.net/wf/click?upn=KFL5ItWFbQhXGlA8EdfEZ7OjpLWhnuogorrzvtKUpwxEjatxERD3cq-2BQ9UyNrC8ThHa4lwi4lhWBR-2BLqAIwoLg-3D-3D_UZ-2Fw3Bg8EOda-2F-2BSazO07kev1gUT-2F4gCy5SRjJrFYxKnS2IUYjSiV8viSIpsJyHdL0EvhrvNMLNZx3hnUjEkzScZA5cbNq4g-2FlB7wDM7Q-2FgEBH-2Bfm6gypY3WMEOmnYOaAJurMPec3BdC-2FPJ1M5s3QIEFLt5vXz2-2F-2BcVk7b-2BYkNFcKDl3IHv-2FxI8CKjWoOJ2QvHwYPz-2FDYDGtuyRCsr0MEY4uBs5DUt3PvyoQscJzVhHs-3D) NZ Clinical informatics Leadership Network Member July 8Hi everyone
Great comments
- I very much agree that we need to identify the role of the person entering a ‘problem’. This can help validated if we ‘trust’ the data
- I personally don’t think adverse reactions or alerts should sit under a problem list as once you implement E-prescribing adverse reactions need to be coded specifically to enable drug to drug interaction alerts etc. Again, alerts have implications in terms of national medical warnings.
- @david.hay It is interesting that procedures were included in the model
I wonder if we can start a Wiki for this conversation so we can start to model the concepts? @nathan can you show me how?
Visit Message or reply to this email to respond to mat, mvalentine, amscroggins, rkgeorge, michael, david.hay, carey, Gastrodiet.
To unsubscribe from these emails, click here.
1 Like
It seems this conversation has moved quite quickly to the details of what is contained in a problem list - but I wonder if a discussion as to the functional requirements may be of values. As an SMO, I had a vision of this being a reliable list of medical diagnoses (akin to the past medical history/past surgical history of an admission note). However, I already see that allergy fields have been listed (which for those in hospital already have a poorly curated national feed, and for those using Medchart, have an often conflicting local non-curated listing as well. I imagine there are strong arguments for social or economic data, or nursing related fields to be in a list, but quickly the group will end up with an ill defined very long list of lots of potential data points whose sole relationship to one another is that they relate to a given record ID (patient).
I would argue that an agreement on the functional requirements (e.g. what do we want this list to achieve) is best defined by clinicians, with functional specification requirements defined by an overarching governance structure (e.g. MoH) to ensure interoperatibility/potential for centralized data exchanges, and the technical aspects that meet those requirements be devolved to vendors.
2 Likes
I completely agree, the ‘what’/problem (functional and content requirements) should be defined by clinicians, eg CiLN and clinical specialists. This can be supported by domain experts in interoperability standards to assist in solving the options of ‘how’ which can be worked in in collaboration with the industry network to implement.
I would challenge that the industry partner (vendor) community lacks critical skills, knowledge and expertise in understanding interoperability standards beyond just an information exchange paradigm. This is where I see great value in a digital academy to build a stronger workforce with broader understanding of the overarching implications. This is obviously a longer term approach, I believe we have a good initial set of people to discuss the immediate approaches with clinical leaders (CiLN), interp. standards experts, industry networks and MoH.
I need clarification of the “critical skills knowledge and and expertise in understanding interoperability standards beyond just an information exchange” lacking in vendors. I don’t understand the point of the challenge - could you clarify?
There are a range of recognised interoperability standards. HL7 FHIR, for example, is an information exchange standard. This is pretty well understood by most of the industry partner community. Another interoperability standard, SNOMED CT, is a clinical terminology standard. This is used within an information exchange standard (eg. FHIR) or a clinical information model (eg. openEHR) to represent granular meaning of a particular clinical concept. Deep knowledge of this, typically, is lacking in the industry partner community.
Industry partners that I’ve worked with/for, typically, often aren’t willing to commit any development/resources toward supporting this capability (standardised semantic interoperability for a problem list) until customers’ demand this as their highest priority and therefore justifies development. Even when this is deemed a priority and there is commitment to development, there is a general lack of deep understanding of how to effectively and consistently implement such semantic interoperability standards at both MoH and the vendor community. In addition to this MoH/HISO have, to date, been cash strapped to provide the sufficient resources or support to clinical groups such as this one to develop a clear way forward for developing, re-using, maintaining standardised code sets for things such as problem lists.
This is based on my own personal experience, I would be interested in hearing other peoples opinions/experiences.
@michael.hosking do we have any sense if other jurisdictions have developed effective strategies to this. I know from prior experience in data-intensive program based in subsaharan africa, most of development was internal, but the use of external vendors had incredibly tight contracting around data standards and APIs to ensure data could be merged with existing data sources. I believe the US partial solution is most healthcare systems purchase monolithic software ecosystems (e.g. the whole package is by one vendor), which can smooth data exchange within an organization, but at a cost of the ability to share information between organizations. I know my former state (Indiana)/employer (Indiana University/Regenstrief) have created the Indiana Health Information Exchange, which covers a fair amount of linked data within a population bigger than NZ, across a variety of software ecosystems. I wonder from the group what strategies have worked outside of NZ, and importantly, what hasn’t. At this point, it feels as though we are reinventing a wheel that assuredly has been rolling in other healthcare systems.
Look, we had started out trying to get an idea of what a table for the list would look like, how many columns it would have and how we could keep it as simple as possible.
It is clear that list is a servant to many masters and this is one of the reasons defining it is so tricky. Defining the “type" of list, is an issue of semantics, and to refine its actual purpose to ensure utility we need to be clear on a few things.
It would be great to get some clarity on how we would use it and what problem we are trying to solve. Because unless we have that clearly defined from the off set we will be going round in circles.
When I think of a * list, (*name still to be defined)
- This would be a list of active issues / concerns/ problems / that are Currently Active or ongoing for MY client/patient.
- This list would be based on dialogue with my client/patient and form the basis of what I am receiving consent to do undertake to treat my client/patient
- I would use this list to
- Keep me focused on the key purpose of my interventions as well as the interventions of others in the MDT team
- Help define the measures I need to monitor or review at follow up
- Let other members of the team know what the main problems I was working on
This List is not:
- Going to cover all confirmed diagnoses, and problems my client has - that is a medical history in part, list will only cover items that are relevant and currently active
- Going to be set in stone, it will be revisited and reviewed as things progress and reprioritized at each encounter. with and maybe in some cases without the patients input
- Intended to be a silo, it needs to be shared but in a way that provides utility to all
- just an Aide-mémoirer
So are we on the same page? Do we share the same similar objective?
If so the things that are needed would be the ability to capture a user type when adding an item to the list. Also a potential priority for the item added.
How do you safely filter/sort your view of the list so you get what you need but do not miss anything. This is where things get complicated because the items i may see as a priority e.g. knowledge and understanding of food labels to inform healthier food choices, would not be as important to everyone. But you would not want comments hidden because they may be relevant in some cases.
If done right it has the potential to help facilitate transdisciplinary practice where, you can check in on colleagues items on the list to check if there are any issues with progress.
Something we can work on in more detail once we land on the utility of this list and an appreciation of its function
Anyway hope that helps and look forward to reaching a bit more of a consensus of why we need the list and how we plan to use it. Once we do defining content and standards for that content should be a doddle.
Regards,
Nathan @Gastrodiet
I would differ in what I perceive as a “list” of problems.
This is highly influenced by a US training that emphasized the SOAP format of inpatient and outpatient documentation - with a problem-based assessment and plan.
I would tend to think of the list as akin to a dynamic version (over time) of current medical and possibly social factors, that I need at some level to be cognizant of in any interaction. I list the social factors as possibly, simply because I don’t know how uniform the ontology is across subspecialities for this area.
I use the term list specifically because I would think of it as an un-ordered, non-hierarchical vector of descriptors.
I would think it would have consistent language to describe clinical and social concepts, and would need to be curated as this list would vary over time, as some items on the list are time limited. E.g. Heart failure, would link by synonyms to congestive heart disease, cardiac failure, etc. Social - could be unemployed, links to not currently working, links to economic decile 10 (obviously making this 2nd one up, because I don’t know the language)
I would like dates for date-defined concepts. e.g. heart failure, diagnosed 2010.
I would like severity for concepts with degrees of severity. e.g. heart failure, diagnosed 2010, NYHA class 2.
It could have hierarchical structure for related concepts, but this quickly could become very difficult. If it did have this, there would likely need to be a prompt function to determine if this data is available, or not. Example being - heart failure (concept), diagnosed 2010, NYHA Class 2, prompt for last functional assessment (e.g. echocardiogram, 14 Dec 2018, LVEF 35%).
The list would have to be curated and have rules around it - otherwise you end up with lists that can go on for pages that include L great toe, contusion, mild, 2002 - so possibly a way of resolving items.
Similarly, very limited free text could be useful, but highly problematic to maintain. E.g. I think an indication that 6 admissions in the last 2 months for heart failure is pretty medically important, but as a free text field, would be difficult, and even with a time/date stamp, would lead to later ambiguity (e.g. was that 6 months from the time/date stamp, does it still apply. What if its now 10 times in the last 6 months).
I would favor, based on the above, shoot for a low-hanging fruit - e.g. a list of chronic conditions (medical or social), that have a duration/expected duration of greater than some time period. The list should be curated, but likely by the more generalist care providers (however, would need some sort of training, and frankly, fee for service). I argue the latter points, because I think as medicine has been more subspecialized, specialists tend to see patients as their organ system - e.g. cardiologist tend to see a heart with other things attached that get perfused by the heart.
The interesting thing is the question, “who is the list for”? Unlike lists of medications or allergies, the ‘perspective’ of the list change according to the person using it - the items of significance are different to a cardiologist, to a surgeon, to a GP or to the patient themselves. The term ‘concern’ is often mentioned, but again what is of concern to one viewer is different to another.
Does a person have a single problem list? Or are there many different ones…
···
On Sun, Jul 21, 2019 at 4:06 PM Nathan Billing @Gastrodiet via Digital Health Networks discourse-notifications@digitalhealth.net wrote:
[Nathan Billing @Gastrodiet ](https://u1980013.ct.sendgrid.net/wf/click?upn=KFL5ItWFbQhXGlA8EdfEZ7OjpLWhnuogorrzvtKUpwwB8KR3R-2FDc-2F-2BNYTH-2BW6llPFa4yzOzTJr80ODibDiLG3w-3D-3D_UZ-2Fw3Bg8EOda-2F-2BSazO07kev1gUT-2F4gCy5SRjJrFYxKkUn2fL9wfUdvJX2EOy15dKz28yV2B93lvwuFqAgehAhskZjrZG9I7zfbBek5Q6LEvbcP-2Bn9-2FMbPQbdiM84khJP-2FF35R20v-2FqPcG26WJjT7W5cZ-2FBVFZuSb74RM2kuL3QZroT4xM0sgtKKwasGsch3R7CqxoJiajz-2BpURCKOCS84V3eodLhruBL5h5a2LK7iwI-3D) NZ Clinical informatics Leadership Network Member July 21All,
Mat no sure if you were trying to get details from Nathan on how to configure this side discussion. I think the need for it to become a private conversation was in part as a result of the initial heading “Orion Problem list’
Look, we had started out trying to get an idea of what a table for the list would look like, how many columns it would have and how we could keep it as simple as possible.
It is clear that list is a servant to many masters and this is one of the reasons defining it is so tricky. Defining the “type" of list, is an issue of semantics, and to refine its actual purpose to ensure utility we need to be clear on a few things.
It would be great to get some clarity on how we would use it and what problem we are trying to solve. Because unless we have that clearly defined from the off set we will be going round in circles.
When I think of a * list, (*name still to be defined)
- This would be a list of active issues / concerns/ problems / that are Currently Active or ongoing for MY client/patient.
- This list would be based on dialogue with my client/patient and form the basis of what I am receiving consent to do undertake to treat my client/patient
- I would use this list to
- Keep me focused on the key purpose of my interventions as well as the interventions of others in the MDT team
- Help define the measures I need to monitor or review at follow up
- Let other members of the team know what the main problems I was working on
This List is not:
- Going to cover all confirmed diagnoses, and problems my client has - that is a medical history in part, list will only cover items that are relevant and currently active
- Going to be set in stone, it will be revisited and reviewed as things progress and reprioritized at each encounter. with and maybe in some cases without the patients input
- Intended to be a silo, it needs to be shared but in a way that provides utility to all
- just an Aide-mémoirer
So are we on the same page? Do we share the same similar objective?
If so the things that are needed would be the ability to capture a user type when adding an item to the list. Also a potential priority for the item added.
How do you safely filter/sort your view of the list so you get what you need but do not miss anything. This is where things get complicated because the items i may see as a priority e.g. knowledge and understanding of food labels to inform healthier food choices, would not be as important to everyone. But you would not want comments hidden because they may be relevant in some cases.
If done right it has the potential to help facilitate transdisciplinary practice where, you can check in on colleagues items on the list to check if there are any issues with progress.
Something we can work on in more detail once we land on the utility of this list and an appreciation of its function
Anyway hope that helps and look forward to reaching a bit more of a consensus of why we need the list and how we plan to use it. Once we do defining content and standards for that content should be a doddle.
Regards,
Nathan @Gastrodiet
Visit Message or reply to this email to respond to nathan, mat, mvalentine, amscroggins, rkgeorge, michael, matthew.strother, david.hay, carey, Gastrodiet, alastairk.
To unsubscribe from these emails, click here.
I would disagree - I think the relative importance of items on a list would change based on perspective - but the list itself would likely stay the same.
Its really about defining a cross disciplinary minimum data set.
A rehab specialist might note the item of poor social connection with a higher ranking than a surgeon, as a surgeon might note prior surgeries higher - in terms of using the list - but the list would remain the same.