Problem List EHR-FP FHIR Implementation Guide
0.2 - CI Build
Problem List EHR-FP FHIR Implementation Guide - Local Development build (v0.2). See the Directory of published versions
This implementation guide illustrates how to build FHIR resources to create an EHR-S FM or FP.
Statement: Create and maintain patient-specific problem lists.
Description: A problem list may include, but is not limited to chronic conditions, diagnoses, or symptoms, injury/poisoning (both intentional and unintentional), adverse effects of medical or dental care (e.g., drugs, surgical), functional limitations, visit or stay-specific conditions, diagnoses, or symptoms. When a dentist creates a problem list, that list will focus on conditions clinically relevant to oral health care. Problem lists are managed over time, whether over the course of a visit or stay or the life of a patient, allowing documentation of historical information and tracking the changing character of problem(s) and their priority. The source (e.g., the provider, the system id, or the patient) of the updates should be documented. All pertinent dates are stored, including date noted or diagnosed, dates of any changes in problem specification or prioritization, and date of resolution. This might include time stamps, where useful and appropriate. The entire problem history for any problem in the list is viewable. For dentistry, only a limited medical history is often recorded; however, this limited medical history must not be represented as a comprehensive medical history.
| Criteria | FHIR Resource/Element | Comment |
|---|---|---|
| Bundle | ||
| Condition.category | problem-list-item | |
| 3. The system SHALL provide the ability to manage the status of each problem (e.g., active, inactive, resolved). | Condition.clinicalStatus | active, recurrence, relapse, inactive, remission, resolved |
| 4. The system SHALL provide the ability to manage relevant dates including the onset date and date(s) of problem status change (e.g., inactivation or resolution date). | Condition.onset[x] Condition.recordedDate Condition.abatement[x] |
|
| 5. The system SHALL provide the ability to manage information about the chronicity duration (e.g., chronic, acute/self-limiting) of a problem. | Condition.??? extension | |
| 6. The system SHOULD provide the ability to manage information regarding the information source (i.e. informant) of the problem. | Condition.asserter | |
| 11. The system SHOULD provide the ability to link one or more problem(s) in the Problem list to encounters | Condition.encounter | |
| 12. The system MAY provide the ability to link one or more problem(s) in the Problem List to medications. | MedicationStatement.reasonReference | Is this dueTo? Or the other way around. This medication is for this Problem? |
| 13. The system MAY provide the ability to link one or more problem(s) in the Problem list to orders. | ServiceRequest.reasonReference | |
| 14. The system MAY provide the ability to link one or more problem(s) in the Problem list to medical equipment. DeviceUseStament.reasonReference | How is this different from 15? | |
| 15. The system MAY provide the ability to link one or more problem(s) in the Problem list to prosthetic/ orthotic devices | DeviceUseStament.reasonReference | |
| 16. The system MAY provide the ability to link one or more problem(s) in the Problem list to notes. | Condition.note Binary… |
What are note? A binary? Progress note or discharge note. |
| 17. The system SHALL provide the ability to link orders, medical equipment, prosthetic/orthotic devices, and medications to one or more codified problems. | Is this not the same as the other way around 12, 13, 14, 15, 16 |
Additional detail/context setting for those who have significant background in the domain. (Try to make as understandable as you can, but set important context).
The main sections of this IG are: