HL7 Personal Health Record System Functional Model, Release 2
2.0.1 - Normative

HL7 Personal Health Record System Functional Model, Release 2, published by EHR WG. This guide is not an authorized publication; it is the continuous build for version 2.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phrsfm-ig/ and changes regularly. See the Directory of published versions

Requirements: PH.3.3 Manage Provider-Initiated Care Plans (Function)

Official URL: http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-PH.3.3 Version: 2.0.1
Standards status: Normative Computable Name: PH_3_3_Manage_Provider_Initiated_Care_Plans

Enable the PHR Account Holder to capture, record, and display Account Holder specific care plans received from authorized health care providers. An authorized health care provider's care plan(s) are typically provider-initiated, provider-defined, provider-rendered, and provider-implemented.

Description I: Care plans may encompass a wide variety of styles, goals, and complexities, grouped into three categories: health maintenance, health restoration, and chronic disease management. Examples of the three categories of care plans include: - Health Maintenance: The base care plan is a lifelong wellness plan that may specify age- and/or gender- specific health surveillance, an immunization schedule, and a diet and exercise program. It can be customized to accommodate specific health risks (such as hazardous exposures or genomic indicators). - Health Restoration: Natural conditions (such as pregnancy) or acute illnesses may occur that require the management of specific diagnostic and/or therapeutic measures. - Chronic Disease Management: Chronic disease care plans cover long term conditions (e.g., Type 1 diabetes). Multiple care plans, treatment plans, or health activities (including those that are self-generated) need to be managed/reconciled in order to enable the prioritization/reconciliation of care plans: based on relative health outcomes and risk, based on a timewise ordering of care plans, based on a condition-related ranking of care plans, based on changes to insurance coverage of health care plan services, or based on potential contraindications that arise from conflicting care plans goals or methods. There might also be certain restrictions against sharing health information in the case of infants or teenagers who might require special health information exchange protections. Example(s): Capture and maintain a diabetic treatment plan that contains the pertinent staging details and multimodality plans in one place that can better coordinate the care by the diabetes-support team including the PHR Account Holder's Primary Care Provider.
Criteria N:
PH.3.3#01 SHOULD The system SHOULD provide the ability to capture provider-generated PHR Account Holder -specific care plan regimens and/or treatments (e.g., information regarding orders, therapies, wound care, or habit changes). Satisfied by:
  1. https://www.hl7.org/fhir/careplan.html
PH.3.3#02 SHOULD The system SHOULD provide the ability to track updates to the PHR Account Holder's care plans, regimens, and treatments (e.g., including information regarding authors, creation date, version history, references, and sources as available).
PH.3.3#03 SHOULD The system SHOULD provide the ability to present care and treatment plans captured from providers in their original format.
PH.3.3#04 SHOULD The system SHOULD provide the ability to present a list of care plans and instructions indexed by provider, problem, and date.
PH.3.3#05 SHOULD The system SHOULD provide the ability to manage care and treatment plans captured from provider(s) with tasks, alerts, reminders, and calendar entries.
PH.3.3#06 MAY The system MAY capture compliance with provider-generated care plans and render notifications or alerts to the PHR Account Holder when the PHR Account Holder is out of compliance.
PH.3.3#07 MAY The system MAY transmit out-of-compliance notifications or alerts to the originating provider and/or to a person who is acting in the role of a provider (e.g., a registered dietitian/nutritionist who creates and signs a diet-order).
PH.3.3#08 SHOULD The system SHOULD provide the ability to maintain decision support recommendations for care plans and treatment protocols that are sensitive to the context of PHR Account Holder data (e.g., peak flow, weight, blood pressure, food preferences).
PH.3.3#09 MAY The system MAY provide the ability to analyze potentially conflicting decision support recommendations for care plans and treatment protocols (including self-generated care-plans) and present those potentially conflicting decision support recommendations for care plans and treatment protocols (e.g., if a provider-generated diabetic foot treatment plan recommends 20 days between formal examinations and an automated PHR system decision support module recommends 90 days between formal examinations, then the provider should be informed of the conflicting recommendations).
PH.3.3#10 MAY conditional IF the systemhas determined that potentially conflicting decision support recommendations for care plans and treatment protocols, THEN the system MAY provide the ability to transmit a request to a provider to harmonize those potentially conflicting decision support recommendations for care plans and treatment protocols.
PH.3.3#11 MAY The system MAY provide the ability to capture order details for the PHR Account Holder in a manner that promotes understanding and compliance with an order.
PH.3.3#12 SHOULD The system SHOULD provide the ability to capture externally-sourced (care plan -related) instructions or references to documents containing those instructions.
PH.3.3#13 SHOULD The system SHOULD provide the ability to capture details on further care such as follow up, return visits, and appropriate timing of further care.
PH.3.3#14 MAY The system MAY provide the ability to manage multiple care plans, treatment plans, or health activities (including those care plans, treatment plans, or health activities that are self-generated) according to user preferences and/or consents, organizational policy, and/or jurisdictional law.