×

To enhance security, Multi-Factor Authentication (MFA) is mandatory for all HL7 users. More information

 

Problem Oriented Health Record (POHR) (Jira PSS-2684)

Basics

Problem Oriented Health Record (POHR) (Jira PSS-2684)

1728
Ballot - Informative


FHIR Implementation Guide

White Paper (Non-Balloted WG Approved Only)

Details

Updated 2026 Description:

The Problem-Oriented Health Record (POHR) Project was established by the EHR WG as a Functional Profile (FP) within the existing ISO/HL7 10781 EHR System Functional Model (EHR- S FM). See Release 2.1.1, 2025. The portions of EHR-S FM to which the POHR FP relates are primarily Sections 2 and 3 (Care Provision and Care Provision Support). The original PSS for the Problem-Oriented Health Record (POHR) Functional Profile (FP) Project reflected the project's first phase, which was limited to problem list management. The original PSS thus no longer reflects the current phase, which covers not only the problem list component but the full scope of the POHR, including its CDS component.

The discussion in the Project Need field below refers to the POHR and problem-oriented care as “standards of care” for clinicians. This concept of problem-oriented care standards differs from the HL7 concept of IT standards. Problem-oriented standards of care were conceived as principles for reform of medical practice. This concept overlaps with, but goes well beyond, the scope of, HL7’s role and expertise in health IT standards.

Specifically, Health IT standards provide guidance (including incorporation of FHIR) to vendors and users for design and use of EHRs and related CDS tools. By comparison, problem-oriented standards of care govern design and use of EHR and CDS tools in patient care, including organization of EHR content, the scope of patient data collection, applying medical knowledge to patient data, the use of traditional software tools and AI tools relative to human intelligence, the use of EHR and CDS tools for care coordination and quality improvement in patient care, and the harvesting of new medical knowledge from real-world data in problem-oriented records. These elements implicate FHIR, and the POHR Project's scope may thus include recommendations for changes and expansions to the current FHIR version.

Some participants in the POHR Focus Team are also members of the Health Record Banking Alliance (HRBA). The HRBA advocates a one-patient-one-record model for EHRs, rather than the prevailing “scattered model” with fragmentary patient records held by multiple providers. The POHR Project team is considering issuance its output the form of FHIR-based standards for the one-patient-one-record model, which could simplify and reduce the scope of its output. EHR and CDS vendors could then adapt the Project's output for their current customers who operate within the scattered model. More importantly in the long run, the POHR Project's output would provide guidance for building a problem-oriented EHR/CDS infrastructure in the cloud for the one-patient-one-record model.?

Original 2021 Description:

The Problem-Oriented Health Record Focus Team has been formed as part of the HL7 Reducing Clinician Burden (RCB) effort. The POHR is relevant to current concerns of the HL7 EHR WG, not only RCB but medication list reconciliation and integrating different specialty areas. RCB is the most urgent of these concerns, however, because of the prohibitive burdens currently imposed on clinicians in terms of cognitive load, time demands, and poor EHR usability.

The POHR Focus team has been considering problem-oriented standards for organizing EHR data. The team has determined that proposed standards should be drafted and balloted as a Functional Profile within the existing ISO/HL7 10781 EHR System Functional Model (EHRS-FM). See Release 2.1, June 2020. Sections 2 and 3 (Care Provision and Care Provision Support) of that document enumerate the portions of EHRS-FM to which the POHR Functional Profile would relate.

The discussion in section 3b below refers to the POHR as a 'standard of care' for clinicians. This term differs from the concept of 'standards' as typically used in health IT. Health IT standards govern such technical matters as terminology, coding, structural design, user interfaces, and application program interfaces for EHRs and other health IT.

A POHR Functional Profile would provide health IT standards, i.e. guidance to vendors for EHR design, including changes to existing EHRs. How those standards are implemented is determined not by HL7 or EHR vendors but by local users (individual and institutional). This means that POHR Functional Profile standards are prescriptive as applied to EHR vendors that seek to offer conforming products. How those vendors' products are used by their provider customers would determine whether the POHR Functional Profile is prescriptive as applied to EHR users.

Ultimately, POHR principles were conceived as new standards of care for reform of medical practice. This dimension of the POHR is related to, but goes beyond the scope of, HL7's role and expertise. The POHR's organizational scheme is intended to make the record a guidance tool, not just a repository. For example, the POHR defines detailed data categories (e.g. the various elements of a problem, of a care plan, of a SOAP note) for data entries in the record. Users, by simply populating the categories, are automatically guided to assemble data and make decisions in a highly organized, standardized, and clinically functional way. A POHR Functional Profile can facilitate this guidance. Whether users follow this guidance is a matter of quality control and enforcement beyond the scope of HL7 standards.

Some members of the POHR Focus Team are also members of the Health Record Banking Alliance (HRBA). The HRBA advocates a one-patient-one-record model for EHRs, rather than the prevailing 'scattered model' with patient records scattered among multiple providers. A related concept, although not specifically advocated by HRBA, might be a one-patient-one-problem-list model whereby each provider EHR on a patient incorporates a single, frequently updated problem list. All providers and the patient would feed into this common problem list, which would be transmitted to and interoperable with e


2026 Updated Need:

Medicine has few generally accepted standards of care for organizing data entries in EHRs and determining the content of those entries. As a result, the design of EHRs depends heavily on idiosyncratic choices by EHR vendors and their customers, while the content entered in EHRs depends heavily on the idiosyncratic, on-the-fly judgments of clinician users during patient care. Yet those users are not equipped with problem-specific CDS tools designed to guide inputs to EHRs and lessen dependence on clinician knowledge and judgment. Moreover, the primary customers of EHR/CDS vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and utility.

In particular, the National Academy of Medicine (NAM, formerly the Institute of Medicine) has found that EHRs are defective as records of clinical reasoning and information usage: "… much of the content of the record depends on what the clinician chooses to include, and thus there may be variations in the extent to which clinical reasoning is documented (e.g., what alternative diagnoses were considered, the rationale for ordering [or not ordering] certain tests, and the way in which the information was collected and integrated)." NAM, Improving Diagnosis in Health Care (National Academies Press, 2015), p. 102. The reference to “clinical reasoning” is significant, because the NAM report elsewhere observes that “proficiency in clinical reasoning” is “the clinician’s quintessential competency.” Yet, “clinical reasoning processes are difficult to assess because they occur in clinicians’ minds and are not typically documented in medical records.” Ibid., pp. 53, 94. These realities make EHRs defective as tools for guiding and documenting processes of care, scrutinizing care quality, supporting clinical research, and improving the economics of care.

Although record keeping standards are lacking, “there are some common conventions for structuring medical records (both in paper and electronic formats),” as the NAM report observes (p. 102). But those conventions are not treated as enforceable standards of care, nor are they optimized for clinical functionality. Moreover, variability results from “regulatory and local rules affect[ing] which members of the diagnostic team contribute to the documentation in a medical record and how they contribute,” ibid. Those rules vary by jurisdiction. Variability of that kind is clinically random.

To address these failings, the POHR (formerly referred to as the problem-oriented medical record (POMR)), was developed as a standard of care to govern organization, content and use of patient records. For example, the POHR defines detailed data categories (e.g. the various elements of a problem, of a care plan, of an encounter note) for data entries in the record. Users, by simply populating the categories, are automatically guided to assemble data and make decisions in a highly organized and clinically functional way.

In the 1990s, during the era of paper records, a committee of the NAM considered the POHR and wrote about it in favorable terms (under the heading “Guidance of Clinical Problem Solving”):

"The committee unanimously believes that patient records should guide and reflect clinical problem solving … "Although it did not specifically recommend use of the POMR, the committee did consider certain components of the POMR to be highly desirable in any computer-based record system. Those components include (1) a structured, systematically collected database; (2) an easily reviewed and updated problem list; and (3) routine recording of clinical formulations and plans for care and follow-up. … A minority of committee members maintained that one patient record format —the problem-oriented medical record first described by Weed—offers a superior alternative in guiding and supporting scientific reasoning and clear communication in medical practice. Those who favored the POMR format argued that it is a general model that rests on a firm theoretical foundation …" The Computer-Based Patient Record: An Essential Technology for Health Care (National Academy Press, 1991, rev. 1997), p. 91.

Subsequently, no clear alternative to the POHR has emerged (although some advocate "goal-oriented" records, which in fact are compatible with POHRs). Moreover, no institution has adopted and enforced truly problem-oriented records at scale. For example, problem lists are often incomplete and variable in how well they are used and maintained. Similarly, although EHRs usually include a core POHR capability — linking record entries (encounter notes, care plans, orders, results, etc.) to relevant problems on the problem list — clinicians do not consistently use this linkage capability. Automating such linkage has been the subject of research, but no automated approach has been generally accepted, and in any event fully automating such linkage may interfere with essential "human-in-the-loop" involvement. Most important, there is little understanding or use of a fundamental element of problem-oriented care: "knowledge coupling" CDS tools designed to identify needed patient data and couple the collected data with medical knowledge to reveal what the data mean. The output of these tools displays options for diagnostic and therapeutic decisions with the pros and cons of each option, all individualized to the patient. This knowledge coupling approach makes inputs to the record less dependent on human judgment and far more transparent than AI alternatives to human judgment. AT the same time, AI tools can be used to help build knowledge coupling tools in advance of their use and then to supplement those tools during or after their use in patient care.

In light of the above, there is a clear basis for HL7 to apply the POHR/knowledge coupling approach as as an organizing principle for standards to bring clinical functionality, consistency and clarity to EHR/



1) POHR Functional Profile - system functional requirements - universal, normative - will be balloted JAN2022. 2) POHR FHIR implementation Guide and/or FHIR Resource Profile(s) - data requirements - 2022 3) POHR User’s Guide - for implementers and end users (including clinicians) - JAN2022 4) Informative White Paper to be balloted September 2026


https://confluence.hl7.org/pages/viewpage.action?pageId=120752354 https://jira.hl7.org/browse/PSS-2684 Original PSS: https://confluence.hl7.org/display/EHR/Problem+Oriented+Health+Record+%28POHR%29+2 https://confluence.hl7.org/pages/viewpage.action?pageI



Other (specify in Misc. Notes below)



Problems 'Problem List'




No

2025 October: Updated PSS created and circulated for consensus review due to major scope change. Original TSC approval date: 10/18/2021 2024 September: GDickinson: Next Milestone Date is Jan 2026 - Draft in Progress 2023 July: TSC approved Informative Publication Request for HL7 EHR-S FM R2.1 Functional Profile: Problem-Oriented Health Record (POHR) for Problem List Management (PLM), Edition 1 2022 August: GDickinson: is active, first deliverable (POHR Functional Profile) has been balloted and reconciled, ready to publish
Organization & Realm


People

Lincoln Weed



Electronic Health Records Work Group

Patient Empowerment Work Group

Status & Dates

Active

Active Project (Resources assigned to pjt)

08/20/2021

05/01/2027

2027 May WGM/Ballot

09/01/2026

2026 Sept WGM/Ballot

2022 Jan Ballot Cycle Info: INFORMATIVE Ballot results: Met basic vote requirements. 13 Negatives to reconcile Document Name: HL7 EHR-System Problem-Oriented Health Record (POHR) Functional Profile, Release 1 (See Jira Ballot Dashboard)
Approvals

10/18/2021


Not Needed


All Received




System Info

267068

PSS-2684



02/02/2026

Jira Project Service