Problem Oriented Health Record (POHR) 2

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