Skip to end of metadata
Go to start of metadata




1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?

No

1e. Today's Date

1f. Name of standard being reaffirmed

n/a

1g. Project Artifact Information

1h. ISO/IEC Standard to Adopt

1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?

1j. Unit of Measure

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

Patient Empowerment

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2e. Other Interested Parties (and roles)

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

2l. Other Facilitators

2m. Implementers

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

Attachments

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3d. External Drivers

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3g. Lineage

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

4c. FHIR Profiles Version

4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Externally developed IG is to be (select one)

5a. Specify external organization

n/a

5a. Revising Current Standard Info

5b. Project Ballot Type

Informative, STU to Normative, Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.

no

6a. External Project Collaboration

6b. Content Already Developed

0%

6c. Content externally developed?

No

6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6g. Other Vendors

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

7c. Co-Sponsor 2 Approval Date

7c. Co-Sponsor 3 Approval Date

7c. Co-Sponsor 4 Approval Date

7c. Co-Sponsor 5 Approval Date

7c. Co-Sponsor 6 Approval Date

7c. Co-Sponsor 7 Approval Date

7c. Co-Sponsor 8 Approval Date

7c. Co-Sponsor 9 Approval Date

7c. Co-Sponsor 10 Approval Date

7e. CDA MG Approval Date

7f. FMG Approval Date

Aug 25, 2021

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

7j. TSC Approval Date

Oct 18, 2021


Version

18

Modifier

Anne Wizauer

Modify Date

Nov 04, 2021 17:28

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Informative, STU to Normative, Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

7f. FMG Approval Date

Aug 25, 2021

7j. TSC Approval Date

Oct 18, 2021

Version

17

Modifier

Anne Wizauer

Modify Date

Oct 21, 2021 16:13

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

7f. FMG Approval Date

Aug 25, 2021

7j. TSC Approval Date

Oct 18, 2021

Version

16

Modifier

Anne Wizauer

Modify Date

Oct 08, 2021 14:20

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

7f. FMG Approval Date

Aug 25, 2021

Version

15

Modifier

Lynn Laakso

Modify Date

Oct 04, 2021 13:27

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

7f. FMG Approval Date

Aug 25, 2021

7j. TSC Approval Date

Aug 30, 2021

Version

14

Modifier

Gary Dickinson

Modify Date

Oct 01, 2021 09:27

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson FHL7

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan MD, Charles Burger MD, Lincoln Weed JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

Version

13

Modifier

Gary Dickinson

Modify Date

Oct 01, 2021 09:26

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

7c. Co-Sponsor Approval Date

Sep 02, 2021

Version

12

Modifier

Mark Janczewski

Modify Date

Sep 30, 2021 21:26

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2b. Co-Sponsor WG

40

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

11

Modifier

Dave Hamill

Modify Date

Aug 24, 2021 21:10

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1728 (Project Proposal was Jira PSS-1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

10

Modifier

Mark Janczewski

Modify Date

Aug 23, 2021 21:19

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

FHIR STU4

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

9

Modifier

Mark Janczewski

Modify Date

Aug 23, 2021 21:14

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://jira.hl7.org/browse/PSS-1831 ; https://confluence.hl7.org/pages/viewpage.action?pageId=120752354

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10
CPT

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

n/a

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

8

Modifier

Mark Janczewski

Modify Date

Aug 23, 2021 21:13

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://jira.hl7.org/browse/PSS-1831 ; https://confluence.hl7.org/pages/resumedraft.action?draftId=120752356&draftShareId=5d04b395-10e7-433b-8cd4-f322c1db5b8c&

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10
CPT

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

n/a

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

7

Modifier

Anne Wizauer

Modify Date

Aug 20, 2021 18:24

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://jira.hl7.org/browse/PSS-1831

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10
CPT

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

n/a

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

6

Modifier

Anne Wizauer

Modify Date

Aug 20, 2021 18:22

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://jira.hl7.org/browse/PSS-1831

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10
CPT

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile, FHIR Implementation Guide, White Paper

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

n/a

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

5

Modifier

Mark Janczewski

Modify Date

Aug 20, 2021 13:46

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

2k. Conformance Facilitator

Gary Dickinson FHL7

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3h. Project Dependencies

None

3i. HL7-Managed Project Document Repository URL:

https://jira.hl7.org/browse/PSS-1831

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

3l. Reason for not using current V3 data types?

n/a

3m. External Vocabularies

Yes

3n. List of Vocabularies

SNOMED
ICD-10
CPT

3o. Earliest prior release and/or version to which the compatibility applies

n/a

4a. Products

Electronic Health Record (EHR) Functional Profile

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

n/a

5a. Project Intent

Create new standard, Implementation Guide (IG) will be created/modified

5a. White Paper Type

Non-balloted WG White Paper

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Specify external organization

n/a

5b. Project Ballot Type

Normative (no STU)

5c. Additional Ballot Info

None

5d. Joint Copyright

No

6b. Content Already Developed

0%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers (inpatient, outpatient, ED)

6i. Realm

Universal

7b. Sponsoring WG Approval Date

Aug 20, 2021

Version

4

Modifier

Mark Janczewski

Modify Date

Aug 18, 2021 23:45

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

3a. Project Scope

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 each provider’s EHR system. This PSS does not otherwise address either of these alternatives to the scattered model, but the Focus Team might decide to take these alternatives into account.

3b. Project Need

Medicine has few generally accepted standards of care for organizing data entries in health records and determining the content of those entries. As a result, recordkeeping depends heavily on idiosyncratic choices by clinician users. Likewise, design of electronic health records (EHRs) depends heavily on choices made by EHR vendors based on variable inputs from their customers. The primary customers of EHR vendors are not clinicians but executives of provider organizations. The outcome is that many regard EHRs as clinically dysfunctional in their design and usability.

In particular, the National Academy of Medicine (NAM) 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 reason-ing 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 (The 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.” Moreover, “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 processes of care, scrutinizing care quality, and supporting clinical research.

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, varia¬bility 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 problem-oriented medical record (POMR), which we refer to as the problem-oriented health record (POHR), was developed as a standard of care to govern organization and content of patient records.

In the 1990s, during the era of paper records, a committee of the NAM (f/k/a Institute of Medi-cine) 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 and that the mere translation of current record formats, data, and habits from paper to computer-based systems will not alone produce the range of improvements in care potentially achievable in a truly reformed patient record system. Current systems include behaviors and record forms that produce substantial waste, imprecision, and complexity in a care system less and less able to tolerate that burden. …
The committee did not reach unanimity regarding the choice of a single preferred record format to support improved clinical care. A majority maintained that no clearly superior alternative existed to warrant specific recommendation …
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. Moreover, two of the POHR’s core components — problem lists and SOAP notes — are part of almost all EHRs, but problem lists are often incomplete and variable in how well they are used and main¬tained. Similarly, EHRs almost always include a core POHR capability — linking record entries (encounter notes, care plans, orders, etc.) to specific problems on the problem list — but clinicians do not consistently use this capability. Recently, an alternative approach to such linkage has been developed, but it is too new to have become widely known or used. See https://problemlist.org and Semanik, M, Buchanan J, et al., Impact of a problem-oriented view on clinical data retrieval. J. Am. Med. Inform. Assoc. (March 2021).

In light of the above history, there is (i) a clear need for industry-wide standards to bring consistency and clarity to EHR design and use, and (ii) a clear basis for HL7 to treat the POHR as an organizing principle for the needed standards.

The POHR’s central component is the problem list. The problem list should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research. All these uses for the problem list might be enhanced by expanding patient input into creating and maintaining the problem list. See generally Porter A, et al., Problems with the problem list: challenges of transparency in an era of patient curation. J Am Med Inform Assoc. 2020;27(6):981-984. doi:10.1093/jamia/ocaa040. The POHR Focus Team has not yet considered whether it could develop useful vendor guidance to enable enhancing the patient’s role in problem-oriented EHRs.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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 - will likely be balloted JAN 2022
3) POHR User’s Guide - for implementers and end users (including clinicians) - will likely be a balloted white paper JAN2022

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3j. Backwards Compatibility

No

4a. Products

Electronic Health Record (EHR) Functional Profile

5a. Project Intent

White Paper

5a. White Paper Type

Non-balloted WG White Paper

5b. Project Ballot Type

Normative (no STU)

6c. Content externally developed?

Yes

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers

6i. Realm

Universal

Version

3

Modifier

Mark Janczewski

Modify Date

Aug 17, 2021 21:45

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

3b. Project Need

The Problem-Oriented Health Record project is part of the HL7 Reducing Clinician Burden (RCB) effort. Its core purpose is to develop problem-oriented standards for organizing EHR data. Central to the POHR is the problem list, which should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

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 - will likely be balloted JAN 2022
3) POHR User’s Guide - for implementers and end users (including clinicians) - will likely be a balloted white paper JAN2022

3f. Common Names / Keywords / Aliases:

Problems "Problem List"

3j. Backwards Compatibility

No

4a. Products

Electronic Health Record (EHR) Functional Profile

5a. Project Intent

White Paper

5a. White Paper Type

Non-balloted WG White Paper

5b. Project Ballot Type

Normative (no STU)

6c. Content externally developed?

Yes

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers

6i. Realm

Universal

Version

2

Modifier

Mark Janczewski

Modify Date

Aug 12, 2021 15:50

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

1f. Name of standard being reaffirmed

n/a

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

2f. Modeling Facilitator

n/a

2g. Publishing Facilitator

Michael van Der Zel

2h. Vocabulary Facilitator

n/a

2i. Domain Expert Representative

Joel Buchanan, MD; Charles Burger, MD; Lincoln Weed, JD

2j. Business Requirements Analyst

Mark G.Janczewski MD MPH

3b. Project Need

The Problem-Oriented Health Record project is part of the HL7 Reducing Clinician Burden (RCB) effort. Its core purpose is to develop problem-oriented standards for organizing EHR data. Central to the POHR is the problem list, which should identify known patient problems, not just problems relevant to a particular user or institution. A complete problem list assures that: (i) all problems are addressed and not overlooked; (ii) all problems are taken into account when addressing any one problem. In these ways, a complete problem list facilitates comprehensive care and coordination of activities by multiple parties. Accordingly, the initial focus of the POHR project is problem list management.

In addition to its core purpose of identifying patient problems, the problem list can serve as a table of contents for navigating the EHR, enabling ready access to the data and documentation related to particular problems. Other important secondary uses include clinical decision support, quality improvement, registry maintenance and clinical research.

3c. Security Risk

No

3j. Backwards Compatibility

No

4a. Products

Electronic Health Record (EHR) Functional Profile

5a. Project Intent

White Paper

5a. White Paper Type

Non-balloted WG White Paper

5b. Project Ballot Type

Normative (no STU)

6c. Content externally developed?

Yes

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Other

6f. Other Stakeholders

Clinical providers (physicians, nurses, PAs, etc.)

6g. Vendors

Health Care IT

6h. Providers

Other

6h. Other Providers

Individual clinical providers

6i. Realm

Universal

Version

1

Modifier

Mark Janczewski

Modify Date

Aug 12, 2021 15:42

1a. Project Name

Problem Oriented Health Record (POHR)

1b. Project ID

1831

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Electronic Health Record

2d. Project Facilitator

Gary Dickinson

3j. Backwards Compatibility

No

2 Comments

  1. TSC approval included appeal for missed PSS deadline at https://confluence.hl7.org/x/voacB

    FMG review included reminder that an IG proposal is still needed. Draft started at https://confluence.hl7.org/x/3IGcB

  2. Based on the TSC decision, we will ballot the POHR/Problem List Management Functional Profile in January 2022.  We are still evaluating next steps for the FHIR IG but do not plan to ballot it in January.