Problems
Problems - Data Model
Patient Facing Services incorporates the GP Connect data model, this contains guidelines on how Providers need to populate each of the FHIR resources. It is advised to read the data model first, to understand how this is being populated by GP clinical systems.
The relevant profiles in the data model are as follows:
However, not all clinical information stored on GP systems may be safe to display for the end user (patients / citizens). This guide is intended to help Consumers understand what is clinically safe and useful to display via PFS from the GP Connect data model. Please see the PFS recommendations below.
The full understanding of a Problem is not the Problem itself but using it as a way to navigate a problem-oriented record. In order to navigate a problem-oriented record, it is advised to understand other clinical areas the Problem may reference. For more information on representing the different clinical areas, click on the link provided.
PFS Recommendation
Safe to display to patient / citizen - With a safety rating of 'High', 'Medium' or 'Low'.
Useful to display to patient / citizen - With a recommendation of 'Recommended' or 'Not recommended'.
For example, the element 'Id’ has a safety rating of ‘High’, meaning it can be shown via Patient Facing Services (PFS). However, we believe it may not be useful to display 'Not Recommended' for the patient / citizen. It’s worth noting, there are elements that will have no meaning or have any merit in being displayed such as ‘Id’. For example, some elements are just entities that link data together.
For further information on the labelling please visit Data model labels used within this guidance.
| Element | Safe to display to patient / citizen | Useful to display to patient / citizen |
|---|---|---|
| id | ||
| meta.profile | ||
| extension[actualProblem] | ||
| extension[relatedProblemHeader] | ||
| extension[relatedProblemHeader.type] | ||
| extension[relatedProblemHeader.target] | ||
| extension[relatedClinicalContent] | ||
| extension[problemSignificance] | ||
| identifier | ||
| clinicalStatus | ||
| category | ||
| code | ||
| subject | ||
| context | ||
| onset | ||
| abatement | ||
| assertedDate | ||
| asserter | ||
| note |
Further Information
Note - Not every element will have further information. Further information is to simply give additional context and perspective to the element.
extension[actualProblem]
Further information
There could be additional information in the resource referenced by ‘extension[actualProblem]’. For example, if the problem was high blood pressure, this may link to a record which has the original blood pressure reading, which may lead to the problem being identified. (The full information of the originally recorded problem that this header represents, is to also read the content of the referred to actual problem.) This all depends on the use case. If the Consumer is only listing Problems, they might only want the original term (with some metadata associated). In this case ‘extension[actualProblem]’ may not be necessary. If Problems are wanted to be displayed in detail, its highly likely ‘extension[actualProblem]’ will be applied.
Displaying the element alone will have no meaning to the patient. This is not advised and may cause more confusion than benefit to the user. If a clear business case is portrayed, then this can be utilised in conjunction with other information to represent information free from ambiguity or confusion to the patient / citizen.
extension[problemSignificance]
Further information
This can be useful in a grouped scenario, separating the major and minor Problems (major first followed by minor). It may also be displayed in a condensed summary view. For example, the element may be clearly visible on the user interface without searching or expanding for further information.
clinicalStatus
Further information
If Consumers are going to present both active and inactive Problems. Then it is advised to utilise this element.
To clearly and unambiguously distinguish between the active and the inactive Problems being presented to the patient / citizen. This can be done either by separation into separate tables clearly labelled, or clearly labelling each individual Problems.
code
Use with caution for PFS
Further information
This element is a CodeableConcept, it is advised to use the original term text as your primary clinical term. For more information on 'Processing data from a CodeableConcept', specifically section 'Original term text' then please visit -
context
Further information
This element is a reference to the encounter where the Problem was initially created. Displaying the element alone will have no meaning to the patient. This is not advised and may cause more confusion than benefit to the user. If a clear business case is portrayed, then this can be utilised in conjunction with other information to represent information free from ambiguity or confusion to the patient / citizen.
abatement
Further information
If populated ('abatement' is only relevant to inactive Problems).
assertedDate
Use with caution for PFS
Further information
The element states the date it was recorded, not when it occurred / happened. If 'onset' date is missing, then use the 'assertedDate'.
The 'assertedDate' element is the date the symptom became classified as being a problem (when the clinician became aware of the symptom). Whereas the ‘onset’ element states the beginning of the symptom.
asserter
Further information
The elemenet is a reference to the profile for the practitioner who recorded the Problem. Displaying the element alone will have no meaning to the patient. This is not advised and may cause more confusion than benefit to the user. If a clear business case is portrayed, then this can be utilised in conjunction with other information to represent information free from ambiguity or confusion to the patient / citizen.