Problems List - NZ National Specification

Hi everyone. All great conversations and I wonder how we can move forward with getting a consensus on the problem we are trying to solve first?

Do we have some problem statements at the beginning of the Wiki? Would it be good to narrow our initial scope to 1-2 use cases? I not sure I agree with the statement of a centralised repository of clinically relevant issues as I was seeing a more modern API/ query based approach. What are other’s thoughts?

To wade in on the discussion is this a master list to rule them all or a dynamic list that can be persisted at any time based on your business rules about what you want to visualize. I would strongly urge us to consider the later. In this way we can move away from debate about what one clinician wants to see versus another and we are not suggesting clinicians have to go out of their BAU systems to enter/ update data in a master list.

In order for the later to work we do need a minimum data set that each system can confirm to and modern EMR/PMS systems that can use APIs. I think it is important to remember that not all data needs to be surfaced for everyone- again business rules can help deal with this complexity.

I personally think a problem list is a view of patient’s current health issues and by simply having end date we can use the same data model for past health history as well as current.

For example consistently capturing the following would be a great start to a minimum data set.

Data of onset
Diagnosis or Procedure (SNOMED )
Stage or severity (e.g. grade of cancer)
Clinicians (Name, Role, Specialty, Professional Identifier (HPI)
End date
?Provenance (source of the diagnosis)

2 Likes