The personal health record (PHR) may be represented via multiple approaches including a personally-maintained paper record or via electronic means; also, the PHR may be represented within different contexts, for example, a minimal history of major health-related events versus a record of daily health and wellness activities. The functions with this PHR-S FM are a superset of functionality that detail certain functions that might be present in various PHR System implementations. The functions provide for both personal observations and health management, as well as by the PHR Account Holder’s healthcare providers. The PHR should present a view to the PHR-S Account Holder that is tailored to their level of health literacy and language ability. Many realms already support a PHR Account Holder’s ability to withhold health information from providers and other persons at the PHR Account Holder’s discretion. Personal Health functions accommodate those realms by providing the PHR Account Holder the ability to withhold such information. Some realms may require, through jurisdictional law, rules, or regulations, clear indications in the record that some information has been withheld. When jurisdictional law requires such indications, the system can display such indications. If the jurisdiction provides individuals with an option to indicate or not indicate that information has been withheld, the PHR Account Holder can exercise that option (e.g., turn on a flag or not turn on a flag). In the PHR-S FM, there are times when the actions/activities related to the PHR Account Holder may also apply to the PHR Account Holder Proxy. External data sources might include: an EHR system; a pharmacy; a care team member; a medical device; a paper scan of birth certificate; a wiki; a family member; a public health organization; a laboratory; a clinical trial study; a local high school health department. The external data could be structured or non-structured. The context for the arriving data could be due to a single event (such as an immunization) or due to a set of associated events (such as occurs during a transition of care). Example(s): The PHR Account Holder may desire to see a summary-of-care record or an ad hoc view of the health record (e.g., the list of medications that is referenced by providers or pharmacists.

The person that is the subject of the personal health record is referred to as the PHR Account Holder. The PHR Account Holder may also be represented by the parent/guardian, or a designated representative (proxy) assigned by the PHR Account Holder or otherwise authorized entity. The PHR includes relevant demographic information and other administrative statements necessary to provide care such as Advance Directives or consents for care. Example(s): Display and maintain demographics or preferences such as the PHR Account Holder’s preferred first name or religious preferences.

The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S).

The system should maintain the current demographic data set that unambiguously defines the PHR Account Holder including personal attributes and contact information (including emergency contact, next-of-kin information, and insurance information sufficient to meet the information needs required to provide health care services, and if applicable, facilitate the need to locate family members in the event of an emergency or to expedite next-of-kin notification). Example(s): Maintain current contact information, emergency contact information/next-of-kin information, and registration information including physical addresses, telephone numbers, and email addresses.

PHR Account Holders may hold certain religious or philosophical views that impact how they wish to be treated or how they might respond to treatment choices. These preferences should be captured, prominently displayed, and made available during the care process. For example, a person may hold certain preferences regarding eating certain foods (e.g., avoidance of meats; preference for vegetables); taking certain therapeutic serums derived from animals; use of a pig-valve for valve replacement; use of human or animal tissues (e.g., skin tissue or bone). Example(s): A religiously-based proscription of blood transfusion is a commonly encountered example of a PHR Account Holder preference.

The PHR Account Holder along with their immediate family should periodically assess their health status and formally state in writing how they wish to be cared for in different circumstances. This is particularly useful when the end of life is predictably near to avoid inappropriate or undesired care.

A variety of consent directives and authorizations are needed to provide healthcare services. Each institution such as an emergency room, each provider, or each health care service such as an operative procedure may require its own informed consent be captured, displayed, and verified before care can be provided. The consent directives may be externally sourced with copies made available for the PHR Account Holder to capture and store. Some consent directives or authorizations may be authored by the PHR Account Holder granting authorizations such as a parent granting ad hoc authorization for emergency care for a child. Note: The system FM is agnostic to any specific consent/authorization approach. For example, consent/authorization directives may apply to the data in the PHR itself or could integrate with an external access control service. Note: A consent and privacy framework is best described in a functional profile (i.e., a subset) of the PHR-S FM and ought to be specified in accordance to organizational policy and/or jurisdictional law. Therefore, it is assumed that a consent and privacy model will be specified by the functional profile. Example(s): Maintain current authorizations in relation to specific health record functions. The PHR Account Holder may desire to see the authorizations associated with a specific clinical activity, such as treatment or surgery, along with that event in the PHR Account Holder’s PHR-S.

A PHR Account Holder may possess one or more PHR accounts over a lifetime, and may have multiple PHR accounts open simultaneously. The PHR system, therefore, needs to provide the ability to open or close a PHR account on a PHR Account Holder’s behalf, and to transmit a copy of PHR account data to other PHR systems.

To obtain historical information to populate the PHR, the PHR Account Holder may use strategies that include entering historical information directly or importing at least part of this data from outside electronic data sources. An outside service such as an employer, insurance plan, provider or care delivery organization may sponsor a particular PHR and add data to the record from their data sources. The PHR Account Holder may use similar strategies to populate their current state information.

PHR data, including personal observations and most specific data elements (such as allergies and intolerances or problems), may be entered directly by the PHR Account Holder. The source of all data is captured and, in this case, self-entered data, should be so labeled. These data elements may possess more or less credibility when entered by the PHR Account Holder. When appropriate, patient-entered data should be structured and codified. Paper-based information (such as a health card or a laboratory report) may be captured in the form of a scanned image and kept in the record, organized, and/or indexed for retrieval. Example(s): When a problem in the problem list is entered by the PHR Account Holder, it is labeled as such in order to distinguish this problem from others that resulted from a provider’s clinical diagnosis.

PHR Account Holder data can be collected from many sources (including administrative sources). For example, the PHR Account Holder’s health insurance plan may directly offer health-related information or may enable the PHR system to derive selected clinical information from financial transactions to the extent that health insurance claims include relevant data. Similarly, selected medication records may be available from Pharmacy Benefits Management services.

The system shall capture structured and unstructured documents and data from outside clinical sources, index, and store them. Data and Documentation from External Clinical Sources may be indexed by contained structured attributes (such as the name of the source laboratory, or the date that the document was created), or manually by the PHR Account Holder (or proxy) by annotating those documents or data with a standard or custom indexing tag. Example(s): Clinical information may include: laboratory results, radiographic images, EKG, or scanned documents that are captured, annotated and stored, as coded and structured documents or unstructured documents.

The PHR system may offer a standard set of views of the PHR Account Holder’s data. One such view may be a summary screen or “dashboard” that allows the PHR Account Holder to monitor his or her healthcare progress. The system should also provide the ability for the PHR Account Holder to assemble custom views to meet their needs such as adding a glucose monitoring module to their dashboard view. Example(s): “The system MAY provide the ability to create customized views of summarized information based on sort and filter controls for custom or other parameters.” “Display all clinical documents containing the word “thyroid”.”

The current state data set is a data model of the PHR Account Holder that is useful to the PHR Account Holder, but is particularly useful to any healthcare provider who is asked by the PHR Account Holder for help. These data characterize the PHR Account Holder in current time and is useful in the evaluation of new conditions and predictive of how they might respond to treatments and/or therapies. Receiving these data in the PHR in an electronic and automated fashion may obviate having to recreate the data manually with every new encounter. For many of these elements, the PHR Account Holder is the primary authority. The following data elements are examples of information that is managed over time, across encounters with providers, and for particular health conditions:

• Problems (including Diagnoses)
• Medications
• Test Results
• Allergies and intolerances
• Medical history
• Surgical history
• Immunizations
• Family history
• Genetic information
• Social history, including family relationship and work information.
• Providers’ notes Work information could be defined using the Occupational Data for Health (ODH) data elements:
• Current employment status (e.g., employed for wages);
• Current job data: job employment type (e.g., self-employed), occupation and industry with the start and end dates, employer name and location, job duties, work schedule;
• Usual, or longest-held, occupation and industry, with duration and start date. Specific complaints, history of present illness, review of systems, and the physical examination are more episodic and encounter specific. Example(s): Current Problems, Medications taken, allergies, immunizations, past medical illnesses, surgeries, family history, and social history including habits along with recent diagnostic studies provide data useful for directing care.

Problems are a core feature of the patient record that provides structure and direct management. Problems may include diagnoses. The PHR Account Holder, along with his or her (medical) advisors, may wish to establish their own guidelines regarding who can add or change self-entered problems on the primary list. The PHR Account Holder may wish to maintain his or her own list of problems authored themselves or from non-traditional providers that have no correlation in allopathic medicine. As in other criteria, all data must have source attribution so as to distinguish patient-entered data from provider-entered data. The PHR Account Holder could have problems (or conditions) could be short-term or long-term. An example of a short-term condition is a febrile seizure or a single head injury; an example of a long-term condition is a genetic condition such as seizure-disorder (epilepsy) or repeated head trauma (e.g., professional boxing). Problem List information needs to be communicated to the care team because problem history information could influence the way that medications and therapies are prescribed. Regardless of the duration of the condition, the way that medications and therapies are prescribed by clinicians, as well as nutrient intake considerations, ought to be part of the PHR system. For example, a person who has a history of seizure(s) needs to share that information with relevant members of the care team throughout that person’s lifetime. Information about problems (or conditions) could be verified by diagnostic studies or collected via self-assessments. The PHR Account Holder’s problems (or conditions), either genetic or acquired, might cause contraindications with respect to medications, nutrients, or therapies. As a result, members of the care team may need to be informed during decision making activities. Members of the care team may also need to receive education regarding certain problems or conditions. Example(s): Problem list items may include: chronic conditions, diagnoses, allergies or intolerances, or symptoms, both past and present, as well as disability status or functional status and all pertinent dates, including date of onset, diagnosis, changes and resolution.

Medication lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. All pertinent dates, including medication start, modification, and end dates can be stored. Medication histories, (for example, alternative supplements, over-the-counter medications, and herbal medications) may be relevant for review. Medication lists are not limited to medication orders recorded by providers, but may include, for example, pharmacy dispense/supply records, patient-reported medications, and additional information such as age-specific dosage. Example(s): The system maintains a medication list that may be followed by the PHR Account Holder and referenced by his or her providers and pharmacists. Copies of the PHR medication list may be kept by their providers in their EHRs.

Recent diagnostic studies further define the PHR Account Holder’s current state. The system should capture, display, and maintain the results of tests and diagnostic studies, as limited by legal requirements or organizational policy. These will include laboratory tests with multiple line items such as test panels. Each individual item of a panel result should allow individual annotation. Other studies including diagnostic imaging studies should be included. Some tests such as colonoscopy or coronary artery catheterization will be derived from an encounter in PH.1.6 but the test results should be listed here. A useful display will show brief test titles with dates and a simple flag to denote an abnormal component of the test. This gives the reviewer a quick understanding on which tests have been done, which tests were abnormal and which tests are out of date and may need to be repeated. The EHR system is considered to be a more proper repository for a provider’s orders than the PHR system. However, the PHR system may be the proper repository for “Direct-To-Consumer” laboratory tests that are ordered by the PHR Account Holder. Also, standing, recurring, or lifetime orders may be kept in the PHR (perhaps as part of a Care Plan). PHRs should be able to capture the fact that orders were made (either by a clinician or by a consumer) and link given test results to their corresponding orders. Example(s): The results reporting list should inform the PHR Account Holder of the date of the most recent EKG or prostate cancer screening test and indicate the existence of abnormal findings.

Allergies, intolerances, sensitivities, and adverse reactions must be reviewed with every new prescription to avoid an allergic reaction. Environmental and food allergens should be listed and maintained here, as well as allergies to bee sting, sunlight, or substances (e.g., latex, metal, or contrast media (such as dye). Example(s): The system SHALL provide the ability to enter, store, update and display information related to allergic and adverse reactions or intolerances to drug and non-drug allergens or substances.

Immunization records can be maintained in the PHR-S. The list of immunizations can be associated with the health maintenance care plans in PH.1.3.3 maintaining a prospective immunization schedule for routine recommendations. In addition, vaccinations in preparation for foreign travel and episodic public health outbreaks such as bird flu vaccinations can be maintained here. Also, some jurisdictions accept titers or specific dates of infection as proof of adequate protection. Immunization information can be shared with national registries in order to support public health / population health stakeholder requirements. Example(s): The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.

Significant or serious past medical illnesses and hospitalizations can be referenced in this list with a brief description and date. The past medical history list can also display standard life event reporting such as birth history used in pediatrics, for example: NVD at 36 weeks APGAR 7 and 9 (Normal vaginal delivery after 36 weeks gestation with APGAR scores of 7 and 9 at one and three minutes) and reproductive history used primarily by gynecologists: G4, P3, Ab1, postmenopausal (4 pregnancies, 3 live deliveries, 1 lost pregnancy, now postmenopausal). Medical Histories are typically created by healthcare professionals to summarize aspects of a given healthcare event, diagnosis, or condition (for example, appendectomy or diabetes). Example(s): The system SHOULD provide the ability to annotate the medical history.

The list of past procedures is a useful summary of what has been done in the past and anatomic changes have occurred that might influence current assessments and treatments. It is important to capture any surgical implants and associated lot/serial numbers for tracking/reporting purposes. For example, the consumer might desire to inform the provider that surgery was performed on the left arm (which was broken), not the right arm.

The family history traditionally imparts the PHR Account Holder with certain risks and probabilities of illnesses that have a familial component. The major illnesses and cause of death of primary family members should be captured and displayed. For some illnesses of the PHR Account Holder a negative family history is also pertinent such as for cancer.

Limited personal genetic information is becoming available and it is anticipated that a much richer actionable data set will derive from current research. This function serves as a placeholder to take advantage of the scientific breakthroughs as they become available.

The social history provides a profile with a number of characteristics that help define the PHR Account Holder’s background and health risks. This information can be collected in, or related to, a health risk assessment. The PHR Account Holder is the primary author and authority of these topics commonly included in the social history:

• Education
• Work information such as:
• • current employment status (e.g., employed for wages);
• • current job data: job employment type (e.g. self-employed), occupation and industry with the start and end dates, employer name and location, job duties, work schedule;
• • usual, or longest-held, occupation and industry, with duration and start date.
• Family relationship (e.g., parent or sibling)
• Marital status, care giver resources at home
• Disability status or functional status
• Living arrangement such as private home, adult family home, nursing home, or homelessness
• Habits including smoking, alcohol, recreational drugs, use of seatbelts, helmets, hazardous sports, sexual practices
• Travel history
• Hazardous exposure such as asbestos, radiation exposure, sun exposure. Example(s): The system SHALL provide the ability to for the PHR Account Holder to maintain an accurate and current view of his or her health habits and risks.

Nutrition is related to health and wellness as well as chronic diseases. People want to record and monitor their food and nutrient intake including any nutritional supplements because they are trying to manage their weight, maintain their fitness level, or demonstrate progress towards the goals in their nutrition care plan. Diet and nutrient histories, (e.g., diet, nutritional supplements, enteral and parenteral feedings, vitamin and mineral supplements, history of breastfeeding, and other intake) may be relevant for review. Diet and nutrient lists are not limited to diet, enteral feeding, and vitamin and mineral supplement orders recorded by providers, but may include, for example, food and nutrient intake records, diet recommendations provided by a registered dietitian/nutritionist, and additional information such as weight, height, and Body Mass Index (BMI). Example(s): The system maintains a food and nutrition history list that may be followed by the PHR Account Holder and referenced by his or her providers and Registered Dietitians. Copies of the PHR food and nutrition history list may be kept by their providers in their EHR systems. Example(s): The system maintains a list of nutrition and diet-related information including food intake records, nutrient analysis summary records, energy balance data and nutrition care recommendations that may be followed by the PHR Account Holder and referenced by his or her providers including a Registered Dietitian.

A competency of the personal health record is to encourage thoughtful, prospective management of our own health maintenance and conditions. Example(s): The system should maintain a life-long schedule for surveillance evaluations, clinical trials, and other healthcare information-related research studies.

The system should provide various ways for the PHR Account Holder to record self-generated health observations. Example(s): The system SHALL capture Account Holder’s self-reported physical symptoms and daily functioning as structured or unstructured data.

A PHR system can help a PHR Account Holder capture and maintain self-generated health observational information. That observational information can appear in structured and unstructured formats and/or as several media types. of observational methods could include structured or unstructured text documents, audio files from telephone devices, calendar entries, text messages, scanned or digital images (including photographs), and personal drawings. Example(s): The system SHALL capture Account Holder’s self-reported health observations such as symptoms, vital signs and other physical conditions.

A variety of commercial devices are being developed to help monitor health conditions and compliance with care plans. Some of these commercial devices may offer standard electronic interfaces including wireless connectivity that may be captured by the system and integrated into the PHR. Simple examples include a pedometer recording walking activity, a continuous glucose monitor, a sleep apnea monitor and CPAP (Continuous Positive Airway Pressure) machine, and a pill dispensing device that prompts and records medication compliance. Medical Devices collect health information about an individual which may be exported to the PHR system, the EHR system, or another system. Depending on the purpose and capabilities of a given medical device, the device may be able to share its data with these systems in various formats, ranging from raw (unformatted) data, to coded / mapped values, to fully summarized and formatted reports. Furthermore, the systems may need to collect the data from the medical device in multiple formats. For example, a diabetic PHR Account Holder may use a PHR system to see a summary report from a blood pressure device that states, “Your blood pressure is very high today. Contact your physician immediately”, while an EHR system may require raw blood pressure data values from the past two weeks for the cardiologist. The same medical device may generate glucose values that are of interest to the PHR Account Holder’s registered dietitian/nutritionist. These values may be combined with values from other medical devices to create synthesized reports that are richer in content and value than those reports resulting from devices whose information cannot be synthesized. This level of power requires that the PHR system interact with medical devices in sophisticated ways, including: the ability to configure the medical device data input according to granularity, type, format, frequency, etc. of data collected; the ability to code or map data; the ability to summarize, filter, or merge data; the ability to route data to pre-designated role-types; the ability to tailor the data according to role-types; and the ability to transform the data into alerts or notifications. As the ability of the PHR system to manage medical device data increases, so does the value of the medical device data – and of the PHR system itself. Medical device -related gains made by the PHR system can, and should, be shared with EHR (and other) systems. The PHR system ought to be able to respond to a rules-engine request from an EHR (or other) system so that the PHR system can tailor its interactions with medical devices. For example, if the patient’s weight has increased more than 2% in the last week, the EHR system could recommend that the PHR system request blood pressure reports once an hour from a medical device, rather than once a day. Configuration of Medical-Device-Reports (exchanged between EHR and PHR systems) may be necessary (e.g., to cover, raw data, formatted data, summarized data, or filtered data). Reports may also be processed according to frequency or tailored by role (e.g., a daily report regarding weight sent to a registered dietitian/nutritionist, versus a weekly summary sent to a cardiologist). These reports may be merged with other reports and shared with multiple recipients. Example(s): The Account Holder may download blood sugar monitor data and transmit it to a healthcare provider.

The PHR Account Holder may develop care plans related to health and wellness (such as training programs for sports) as well as to ameliorate a health condition. Self-developed care plans can be integrated into a comprehensive health and wellness plan. Example(s): Develop and implement an exercise program for optimizing cardiac fitness based on age, gender, and other health risks.

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.

Medications are a key modality of care plans. They provide significant benefit but also a risk of harm if not used appropriately. The original selection of medications as well as obtaining refills and renewals take up much of the PHR Account Holder’s time. They can use their PHR-S to help manage their medications prescriptions, refills, and renewals. Example(s): The system should provide the ability to communicate the refills/renewals requests to the pharmacy and the health care provider(s) or applications in a secure fashion.

The healthcare activities required of the Account Holder may be minimal and manageable. For some they may be complex, confusing, and overwhelming. Keeping track of multiple overlapping problems, providers, and care plans will take organization to manage successfully. Using the commonly understood desktop tools can aid the Account Holder to break down complicated processes into more manageable tasks and organize them. These tools may include:

• The health calendar
• The task list
• The contact list
• Reminders
• Alerts
• Recommendations Example(s): Implement a complex care plan in the form of tasks, reminders, alerts, and calendar entries.

A health calendar provides a method to view time related healthcare activity both in the future as scheduled events and in the past as historic events. It is a handy and well understood format. The calendar can also be used as a data input device, mimicking the paper calendar where clinical observations (such as gallbladder attacks or menstrual periods) can be written directly onto a calendar and captured as a timed note. This idea was put forward from usability studies with lay people how they would like to interact with their PHR. Example(s): IF a health calendar function is provided, THEN future appointments and other timed events SHOULD be displayed on the health calendar.

Care plans and other health care activities can be broken down into specific steps or tasks and organized on a task list that may be sorted by priority, date and time, problem, provider, and so forth. The task list entries should serve as an index to their supporting documents. Example(s): Directions for a dressing change at a specific time of day can be displayed as an entry on the task list.

The PHR Account Holder should have control of who has access to his or her PHR-S. All entities that send information to or request information from the PHR-S should be identified for proper authentication and authorization. The PHR Account Holder may establish specific access rights for each actor or groups such as all emergency room physicians. The list of actors may be used to capture contact information for those without digital capability as well. Potential actors may include but are not limited to:

• PHR Account Holder Proxy
• Trusted relatives, friends, and caregivers.
• Healthcare providers that are part of the Account Holder’s team.
• Former providers and new providers not yet seen.
• Insurance plans.
• Pharmacy Benefits Manager, Pharmacies.
• Public health registries.
• Other registries including cancer, transplant and research.
• Hospitals, laboratories and diagnostic imaging centers. All PHR data is associated with a source and all sources should be identified and maintained as long as the data is maintained. All entities making a request for information or receiving information should be identified. Example(s): Each provider should be registered before being granted access rights to the PHR-S.

The PHR Account Holder will want to manage reminders sent by external sources (such as the PHR Account Holder’s provider(s)) or generated from information in the PHR (such as guideline-based reminders, prescription refills, or appointment reminders). A reminder is a notification of an upcoming event or activity that usually requires an action by the PHR Account Holder. Reminders may be displayed on a view in the PHR (such as the summary dashboard) and may also be displayed by other electronic means (such sent to an e-mail account). Example(s): The system SHOULD send a reminder of an upcoming appointment as a text message to the PHR Account Holder’s cellular telephone.

Alerts may be generated by processes both internal to the PHR-S and external from outside sources such as a provider or governmental authority. Alerts may be issued in real time or may be used after an event is past due, when a situation may require a response. Alerts are also used to notify of potentially dangerous situations such as drug interaction alerts or public health alerts. Example(s): Notify the Account Holder with alerts to a public health emergency situation.

In many care activities, recommendations are made for specific future activities. They are easy to let slip by and lose track of them. A thoughtful and documented reason for not following a particular recommendation should be captured to help manage liability risk. Some recommendations may be controversial and there are reasons not to follow them. It is useful to keep a list of recommendations as a separate check on future care to be managed with the help of the PHR Account Holder’s provider. Example(s):

• The radiologist recommends a repeat mammogram in six months rather than the usual twelve months.
• The Primary Care Provider recommends seeing a surgeon for occasional gallbladder attacks.
• A screening colonoscopy is recommended after age fifty.
• Annual screening or tests based on the PHR Account Holder’s occupational risk factors.

A formal and well-defined communication channel between public health agencies and the PHR Account Holder’s PHR-S is useful. It provides for monitoring public health threats through data and observations captured within the PHR-S. Additionally, it alerts the PHR Account Holder to take corrective actions in response to public health threats. Example(s): The system SHOULD provide the PHR Account Holder the ability to subscribe to population health web site information.

Government authorities with the mandate of preserving the health of the population have a need for early detection of public health threats such as identifying the early stages of an avian flu pandemic. This may require periodic reporting of certain de-identified personal health information (PHI). Other epidemiological studies for public health issues as well as public or private medical research studies may also request de-identified PHI. Certain public health reporting requires identified PHI and contact information for urgent epidemiologic investigations and countermeasures (such as for a resistant Tuberculosis outbreak). Note: When transmitting de-identified bio-surveillance data to a Public Health system, the receiver should understand the possibility that a single case may be inadvertently counted twice: once as an identified case from an EHR system, and once as a de-identified case from a PHR system. Example(s): The system SHALL conform to function S.3.3.1 (Manage Consents and Authorizations) regarding epidemiological investigations of clinical health within a population.

Alerts of a public health threat can be delivered by a Health Authority through a variety of channels, one of which can be to PHR Account Holders who provided prior consent for this service. The advantage of this modality is that the alerts can be prioritized to any special vulnerabilities of the PHR Account Holder based upon the Health Authority’s pre-existing claims data. More comprehensive background information and an action plan can then be included (such as alerts from government agencies regarding medications or devices). Example(s): Poor air quality alerts from governmental authorities are electronically sent to the registered PHR-S of a PHR Account Holder with a sensitive lung condition to take countermeasures.

A wide variety of educational materials are available and the problem is to identify authoritative sources that provide relevant information for the PHR Account Holder’s age, sex, job, medical conditions, wellness goals, and health literacy. The system should be able to take a request for information and screen the available libraries of educational materials against clinical information in the PHR-S (including social history such as work information) without inadvertently or unknowingly divulging personal health information to those other systems. Example(s):

• Provide breast feeding instructions in alternate languages for a new mother.
• Provide educational material on asbestos or pesticide exposure, or healthy habits for workers on a rotating shift, based on data about a person’s job.

The PHR Account Holder may wish to seek assistance from diagnostic decision support tools, drug interaction checking, or published guidelines at the appropriate level of health literacy. The intent of this function is to provide the PHR Account Holder with education regarding sophisticated (or clinically complex) problems and also for more common (or more easily understood) problems, as well as support for assuming care of minor conditions. This function should also support the need for professional caregivers to govern, manage, respond to, or override self-care decisions made by the PHR Account Holder regarding acute or chronic conditions. The PHR System could support the PHR Account Holder’s need to understand particular medication- and nutrition- related handling and intake/administration requirements. These considerations could appear during drug-interaction checking, decision making educational investigations, care plan communications, and identification of duplicate therapies. Example(s): The system should provide assistance to select an appropriate Internet based decision support tool to provide guidance in managing a young child with vomiting and fever.

Guidelines help provide general direction to manage specific health risks or problems. They may be used by the PHR Account Holder to research a specific condition to verify that appropriate care is being provided. They may also be used to help self-manage minor conditions. Example(s): Capture guidelines from the Internet for non-operative management of lower back pain.

Drug interaction and drug interference checking is a responsibility of the prescribing provider. However, the PHR Account Holder may be taking new over-the-counter medications or new prescription medications from providers without access to e-prescribing and may want to check for interactions and/or interferences. A complete interaction and interference check would take into consideration other prescribed medications, over-the-counter medications, allergies, relevant health conditions, age, weight, gender, diet and nutrition (e.g., mineral supplements, grapefruit juice, or pomegranate juice), environmental factors (e.g., phototoxic skin reactions to sunlight), absorption considerations (e.g., calcium interference with drug absorption), timing considerations (e.g., take immediately before sleeping), activity considerations (e.g., take before performing physical exercise), and relevant laboratory values such as creatinine clearance and liver function tests. Example(s): Each time a new medication or a new allergy is entered into the PHR, perform an automated check for potential interactions among all of the current medication and allergy entries in the PHR.

The system should aid the PHR Account Holder with making his or her self-assessments and treatment plans for self-care. Some decision support algorithms are straightforward and can be provided as part of the PHR-S service. Others may be more complex and are detailed in function PH.5.4 (Integration with Third Party Clinical Decision Support Services). For example, a child’s weight and height can be plotted on a growth curve chart which graphically displays growth progress. Another example, is the ability for a pregnant woman to plot weight changes over time against a norm.

A variety of clinical decision support services are currently available for professional use; a growing number of these services are becoming available for lay use. The primarily focus of these services is to assist with making an assessment and then recommending a treatment protocol. Example(s): Provide access to clinical decision support services that provide differential diagnoses and advice for further management for common complaints such as sore throat or cough.

The PHR Account Holder may desire to configure specific alerts, reminders, notifications, and/or notices (e.g., to promote compliance with physician orders, manage chronic conditions, perform routine health care measurements, or meet personal wellness goals). Note that the quantity, timing, or priority of such notices might also need to be configured. Example(s): The system SHOULD provide the ability to present medication recommendations based on findings related to a physician’s diagnosis.

The PHR Account Holder might need to receive updated orders or recommendations from care team members; or receive alternative care plan recommendations as the PHR Account Holder’s conditions (or goals) change or when different modalities-of-care are recommended or chosen; or as elements of the PHR Account Holder’s care plan change. For example, a physician might recommend an alternate drug if the physician notices that the price of the currently-prescribed drug increases dramatically or that the current drug is proving to be less effective than previously experienced. By accepting this new drug, the PHR Account Holder might then need to reconfigure the PHR system to present reminders for the PHR Account Holder to take the medication every third day instead of once-a-week.

Each interaction with a provider, including office visits, virtual visits, hospitalizations, telephone conversations, or diagnostic procedures, comprise an encounter. Some encounters are non-discretionary such as emergent admission to a level 1 trauma center. Many encounters are initiated by providers in the course of care such as a scheduled chemotherapy treatment. Some encounters are initiated by the PHR Account Holder requiring additional steps facilitated by their PHR-S. Example(s): The Account Holder makes a self-assessment that his or her chest pain warrants urgent evaluation and telephones an ambulance service. Access to the PHR Account Holder’s PHR information is provided to the ambulance crew and emergency room staff. The resulting assessments, updates to the current data set including problems, procedures, and medications, and new care plans from the hospital evaluation are then incorporated into the PHR Account Holder’s PHR-S during or shortly after the encounter concludes. The Primary Care Provider receives an alert to the changes.

Tracking the personal costs of healthcare can be complex. Charges are typically discounted by the insurance plan to allowed charges. They will pay a portion of allowed charges with the PHR Account Holder being responsible for the rest. A given encounter such as a hospitalization will have multiple charges from several providers. Capturing the Explanation Of Benefits from the insurance plan can help monitor the expenses. Example(s): The system should capture charge information and payment data from the Explanation Of Benefits (EOB) and associate it with the encounter records stored in the PHR-S.

The PHR Account Holder may make a self-assessment regarding certain symptoms they may be experiencing, concluding that they need an encounter with a provider. This self-assessment should include a specific reason or reasons for the encounter (referred to as the chief complaint(s)) and personal observations or measurements that might be germane to the encounter. Example(s): The system SHALL provide the ability to document self-assessments using standard self-assessments germane to the age, gender, developmental state, and health condition as appropriate.

The PHR Account Holder may fulfill specific requests for data or obtain requested diagnostic studies prior to the formal encounter. This may include providing PHR-S access to the new provider. The provider could also communicate with various members of the PHR Account Holder’s care team. Example(s): The PHR Account Holder MAY fill out a current Review Of Systems (ROS) template questionnaire and specific chief complaint related questions as part of the History of Present Illness (HPI) prior to the encounter.

Most encounters generate documentation that can be captured in the PHR-S. Additional supporting data such as diagnostic reports or consultations may be included. A prolonged hospitalization encounter may encompass numerous structured or unstructured documents. Example(s): The system should capture, index, and store encounter information, including the encounter document or summary, laboratory results, radiographic images, PACS, EKG, and scanned documents.

The provider may make assessments (observations, working hypotheses, differential diagnoses, or definitive diagnoses) derived from the new clinical information obtained during the encounter supplemented by additional PHR information including the current state data set. These assessments will direct further diagnostic, therapeutic, and health maintenance care. Example(s): The system MAY provide the ability to compare assessment data entered during the encounter and the accessed health evidence-based guidelines and best practices.

For many referrals to other provider organizations, the PHR Account Holder must manage data, approvals, and appointments related to the referral. The PHR Account Holder may need to ensure that relevant data are received by the provider for the referral encounter. The PHR Account Holder may need to interact with his or her insurance company to secure authorization for payment for a referral to a provider. Examples of methods of transmittal include: secure email or enhanced data sharing. Examples of target referrals includes: referral service organization processing referrals on behalf of multiple healthcare providers that could be regional or jurisdictional. Example(s): The system SHOULD provide the ability to include test and procedure results with a referral.

The provider may develop and recommend a specific care plan and/or treatment plan that is tailored to the PHR Account Holder’s particular circumstances including information in his or her PHR-S. The care plan and/or treatment plan may require input from several providers developed over multiple encounters. This includes enabling authorized Health Care Provider(s) to generate, communicate and record specific instructions, including discharge instructions, instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, and other related instructions. Types of providers that may offer instructions include: medical provider, social worker, physical therapist, respiratory therapist, occupational therapist, pharmacist, or a nurse.

Once a care plan is developed it should be incorporated into the PHR-S. The care plan may be limited in scope or comprehensive involving multiple providers, encounters, institutions, and years of time. Example(s): A comprehensive breast cancer treatment plan may include multiple diagnostic imaging staging studies, surgical procedures, a chemotherapy protocol, details of the radiation therapy plan, plastic surgery reconstruction and long-term post therapy surveillance plan to be posted in the PHR-S and referenced by the cancer care team.

In seeking healthcare, the system should support the PHR Account Holder being able to obtain a list(s) of providers by geographic area and/or within a dental or medical plan panel. Further, the PHR Account Holder should be able to sort providers by attributes including, but not limited to:

• specialty;
• office hours;
• telehealth-oriented encounters;
• sex;
• language;
• methods of information selection;
• methods of information sharing;
• and (possible) payment information. The PHR Account Holder should be able to maintain, or provide access to, current provider information. A PHR Account Holder may desire to research (because of a planned household relocation to another geographic area) a diagnosis requiring highly specialized care by healthcare providers and or healthcare facilities that are in limited availability. The system should be flexible on alternative sources of information allowing the PHR Account Holder to review providers who might best meet the individual’s needs. Consider also, that if various types of providers, care-team members, or social-affinity groups might be involved with the PHR Account Holder’s health, then various methods of information selection, information sharing, and (possible) payment information might also need to be accommodated within the PHR system. As a result, the PHR system ought to support a rich, extended set of caregivers such as:
• Social Networking Groups that are oriented towards health maintenance and recovery, wellness, and health goals;
• Personal Health Support Groups (e.g., weight, drugs, behavioral health, mental health, or diabetes support)
• Exercise and Physical Training specialists
• School Nurses
• Nutritionists/Dietitians
• Care managers (e.g., in-home therapists, or discharge planners)
• Community health worker (either professional or volunteer) (e.g., neighbors, public health workers, health representatives, health screeners, or non-traditional healthcare workers)
• A mobile health clinic provider Note: Some of these extended caregivers might offer PHR data entry services on behalf of the PHR Account Holder.

A system should maintain both current and past contact information about a provider. The system may also collect and maintain background information about a provider such as academic credentials, certifications and specialties. Healthcare providers may be individuals, teams, or organizations such as clinics. The system should allow the PHR Account Holder to manage information regarding teams of providers. A team of providers may be a group of healthcare physicians practicing in the same healthcare facility. For example, a primary care provider, an orthopedic specialist, physiatrist and physical therapy may comprise a team at a facility during an acute hospitalization. A team of providers could also be designated by the PHR Account Holder based on a disease process. For example, in the case of extended care after a motor vehicle accident with extreme facial injury, the team may be comprised of a dentist, an orthodontist, a maxilla-facial specialist, and orthopedist, a reconstructive specialist and a chiropractor. These healthcare providers may not be part of a healthcare facility, but all may be instrumental in the complete care of the individual, requiring coordination by the PHR Account Holder. Note: It is likely true that information about a given provider (or provider organization) might be difficult for the PHR Account Holder to obtain, curate, and validate. However, such information might prove to be useful, for example, for historical or research purposes.

This information will assist the PHR Account Holder in contacting a provider to schedule appointments and ask health-related questions. The provider roles include, but are not limited to, physician, nurse and physical therapist.

A variety of stakeholders offer consumers the ability to evaluate the credentialing, quality, performance, and cost. Having ready access to the information will assist the consumer in their evaluation and selection of providers. Note: Healthcare provider transparency information that has been received or imported from external sources must not be altered by the PHR Account Holder.

This information will assist the PHR Account Holder in identifying where a facility is located and in contacting a facility to schedule appointments. These facilities may be local or remote from the PHR Account Holder. The facility types include, but are not limited to, hospitals, clinics, same day surgery centers.

A variety of stakeholders offer consumers the ability to evaluate the quality, performance, and cost. Having ready access to the information will assist the consumer in their evaluation and selection of healthcare facility. Note: Healthcare facility transparency information that has been received or imported from external sources must not be altered by the PHR Account Holder.

This feature would enable providers, payers and PHR Account Holders to assess and provide feedback on areas such as the perceived patient-centeredness of care, satisfaction and performance, and the transparency efforts to improve quality of care. The receipt of a health survey does not imply that the member must participate in the survey. The system may simply direct the PHR Account Holder to a separate, external survey tool, or may provide the capacity to manage the entire survey process in which a member chooses to participate.

PHR Account Holders may want to centralize administrative information related to the insurance accounts that he/she participate in. Administrative information such as group, group number, policy number, member identification number, effective and termination dates, probationary periods, pre-existing condition constraints, prior authorization or referral requirements and others are important data for provider offices for billing purposes. Current and prior insurance coverage information is important for correct billing and payment. Detail of multiple coverages allows for coordination of benefits information to be easily provided. The ability to capture information of separate riders such as extra major medical coverage or cancer specific coverages in addition to routine benefit plans assists the PHR Account Holder in better knowledge and utilization of the financial resources available for payments. The system should allow the PHR Account Holder to display patient responsibility and benefit plan covered costs – both estimated and final – for a given event (e.g., test, procedure, surgery, or provider appointment). In newer plan types such as Consumer Directed Health Plans (CDHP), this information will help the PHR Account Holder determine the financial implications of his/her treatment options, alternative treatment options and provide information that may be needed by the provider.

Robust management features allow the PHR Account Holder to actively maintain their health insurance benefits information for selected benefits related to PHR Account Holder coverage needs. Over an extended period of time, with the likelihood of multiple insurance providers, it may be important for there to be information management capability for the varied payer sources, varied levels of benefit information, and varied levels of coverage including allowed coverages, exclusions, and limitations on specific coverages. Information management capabilities may include analytics regarding the PHR Account Holder’s desired care such as: the selection of the most appropriate insurance plan for the current disease or injury; or the amount of deductibles that can be expected under varying insurance plans. Out-of-date or non-current insurance plan and benefit information can be used to compare different benefit packages, costs, and/or expenses over time resulting in a better understanding of health care as it pertains to health insurance coverage.

PHR Account Holders may request standard, pre-configured, packaged reports. The purpose is not for PHR interchange but rather for PHR Account Holder’s analysis of his/her health related financial and administrative data, and for sharing (if desired).

PHR Account Holders may request ad hoc, non-standard reports. The purpose is not for PHR interchange but rather for PHR Account Holder’s analysis of his/her health related financial and administrative data, and for sharing (if desired).

The PHR Account Holder demographic data set is needed to support identification and to enhance the prospect for interoperability. The PHR Account Holder should be able to request or make changes to their demographic data and allow for export of all or parts of the demographic data to other systems.

The terms and conditions outline the sponsor requirements in using the application. The terms and conditions may include items such as copyright information, trademarks and intellectual property, third party links, indemnification, privacy, limitation of liability, term and termination and other miscellaneous provisions. The PHR Account Holder should be notified of the expectations of the sponsor and have the opportunity to agree to the requirements and any changes to the requirements. The Conditions of Use document also helps indemnify the PHR sponsor against certain misuse of the data. For example, a published article on diabetes may contain a copyright notice that forbids the storage of that article on a computer without first paying for the article. The Conditions of Use document would inform the PHR Account Holder that the sponsor does not support copyright infringement.

The PHR system should allow for the entry of documents related to the use or disclosure of the PHR Account Holder’s information. These documents may include scanned images or electronic images sent via attachment. The system does not judge the authenticity of the document. The PHR Account Holder should ensure they have the original document or approved copy of a document or other images. The system allows for multiple instances of the same document (e.g., multiple authorizations). The system allows document to be retired (for example, by moving the documents to an archival service and deleting those documents locally). Retired documents may continue to be tracked. The system allows for the removal of documents at the PHR Account Holder’s discretion.

The PHR Account Holder may have Consents and/or Authorization directives that allow or prohibit certain entities from access to part or all of the PHR. Directives may take different forms including documents or system flags on Consent Authorization. The Consent or Authorization requirements would be maintained in accordance with user role, organizational policy and/or jurisdictional law. Based on that, the Consent or Authorization might contain the details of the entity that may be authorized to use, or may be prohibited from using the PHR-S. The Consent or Authorization may detail to the record, field or class, the data available to be used or disclosed. The entities that the Consent or Authorization applies to may or may not be current PHR Account Holders of the PHR-S.

The PHR Account Holder may want to capture and maintain documents that pertain to end-of-life care and to capture and maintain other types of Advance Directives. End-of-life documents include but are not limited to: Advance Directive for Healthcare; Power of Attorney for Healthcare and Physician Order for Life Sustaining Treatment. The system should allow for multiple occurrences of a document and the ability to archive documents. The documents maintained will depend on the jurisdictional law. The documents may or may not reside in the PHR-S. The document may be scanned images, structured documents or simply a notation on the location of the original (hardcopy or original).

The PHR Account Holder may want to capture and maintain documents that pertain to designating those authorized to act on behalf of PHR Account Holder for healthcare. Examples include but are not limited to: Guardianship, Legal Custodial Parent, Executor or Trustee. The system should allow for multiple occurrences of a document and the ability to archive documents. The documents maintained will depend on the jurisdictional law. The documents may or may not reside in the PHR-S. The document may be scanned images, structured documents or simply a notation that specifies the location of the original (hardcopy or original).

The PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information. Example(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious.

The PHR Account Holder may request PHR output which may include standard and ad hoc reports in hardcopy or electronic formats. This output may be for the PHR Account Holder’s analysis of his/her health related financial and administrative data, and for sharing of the PHR information for any purposes the PHR Account Holder deems appropriate.

A PHR Account Holder needs to prescribe how data is exchanged with other systems including how data is imported to the PHR-S, and the parameters for data export (e.g., who, when, or the extent of data). Some import and export functions may be one-time events; other exchanges, for example, may occur at regular intervals (such as via a subscription service). The PHR Account Holder should be able to determine the information or data that he/she will accept into the PHR. The system should record the acknowledgement or refusal of data sent to the Account Holder’s PHR-S. Use of exported data should be constrained according its intended and permitted purpose of use (e.g., as described in the PHR-S manufacturer’s Terms of Service and Terms of Use agreements). Example(s): The PHR Account Holder may desire to inform her General Practitioner that the PHR Account Holder has received a proposed dietary regimen from a Registered Dietitian / Nutrition specialist. The PHR Account Holder may also desire to send a copy of the proposed nutrition care plan to the General Practitioner.

Provide hardcopy and electronic output that supports the needs of a variety of new, additional, or other uses such as: annual immunization requests from schools/camps, application processing for disability requests, validation of compliance with treatment regimens. This mechanism should be provided for both chronological and specified record element output. An auditable record of these requests and associated exports may be maintained by the system. The system has the capability of providing a report of accounting of disclosures of the secondary PHR Account Holders in accordance with user role, organizational policy and/or jurisdictional law.

Either the PHR Account Holder or the authorized designee may receive formal requests to release some or all of the PHR information. These requests may be ad hoc, or may also be routine, recurring requests that may be episodic or longer term. These requests may be related to patient care, administrative process, law enforcement or legal action. An auditable record of these requests and associated fulfillment(s) should be maintained by the system. The system should provide an accounting of PHR disclosures of the Release of Information Requests in accordance with user role, organizational policy and/or jurisdictional law.

Views of information can be tailored for or by the PHR Account Holder (PHR Account Holder, caregiver or other authorized PHR account user) for their presentation preferences and to support personal or role-based workflows and purpose-of-use / intention-of-use requirements. Example(s): A PHR Account Holder may prefer to see summary information about medications, while a provider’s view may include detailed information about current dosage and the PHR Account Holder’s response to the medication over time.

In seeking healthcare, the system should support the PHR Account Holder being able to obtain a list(s) of available clinical trials/research. The PHR Account Holder should be able to refine trials by geographic area, by disease, by treatment, by sponsor and maintain, or provide access to, current clinical trial/research information. The system should also support the PHR Account Holder’s participation in, and support of, appropriate new, additional, or other uses of their PHR information for clinical research which could include quality and performance analysis.

Mechanisms for incorporating external genomic/proteomic data and documentation (including identification of source) such as image documents, reports and other clinically relevant electronic data are available.

When the PHR Account Holder desires to share his/her information in a de-identified state, the PHR Account Holder can export the data in a fashion that meets requirements for de-identification in that locale or realm. Example(s): If a person wants to participate in a study that will utilize de-identified data, then the system should provide the ability to de-identify this data according to the requirements of the study. In Germany, when a PHR Account Holder’s subscription is cancelled, the PHR data may be maintained. But if the data is maintained, it must be maintained in a de-identified state or be pseudonymized (similar to the limited data set in the U.S. Privacy Rule).

A PHR Account Holder should be notified of clinical trials in which they have an interest. The individual may obtain clinical trial information based on general description or specific description such as diagnosis or trial phase. A PHR Account Holder should be able to make their clinical and demographic data available for clinical trials and/or research matching.

The system should support a PHR Account Holder having the ability to enroll in clinical trials or research, The system should be able to capture administrative and consent requirements, trial or research questionnaires, data submissions and all alerts associated with a program. The PHR Account Holder should also have the ability to choose which programs they desire to participate in when notified of trial availability and high quality PHR Account Holder match.

Support the automated transfer of formatted demographic and clinical information to disease-specific registries (and other notifiable registries) to enable PHR Account Holder to participate, if and as desired, in provider and public health monitoring and subsequent epidemiological analysis. The PHR Account Holder can export personal health information to disease-specific registries, other notifiable registries such as immunization registries, through standard data transfer protocols or messages. The PHR Account Holder can update and configure communication for new registries, or delete communication with an existing registry.

The PHR Account Holder is able to capture and share donor information (for products such as blood, organs, eggs, sperm, or stem cells). The PHR Account Holder can make this information available to donor matching agencies. This information may be in multiple formats, hardcopy output, standard messaging, display for authorized PHR Account Holders.

Materials may include information about a diagnosis, recommended diets, associated PHR Account Holder health organizations, international vaccinations needed for travel, or web links to similar educational information. These materials would be provided electronically and may require validation prior to inclusion in the system.

Information from outside groups, such as immunization groups or public health organizations, may periodically have and send updates of value to PHR Account Holders. The system should be capable of generating reminders based on the recommendations of these organizations. Reminders could be provided to PHR Account Holders by a number of means, including alerts or system generated email. A record of such reminders may become part of a PHR Account Holder’s record. Example(s): Reminders could include a recommended immunization, prophylactic guidelines for treating Mitral Valve Prolapse disorder, or PHR Account Holder self-testing for disease.

Public health updates may be applicable to entire geographic regions or specific to a specific locale or diagnosis. The system should allow the PHR Account Holder to identify the types of public health updates that are of interest. The system should also allow a PHR Account Holder to be notified of other public health occurrences which may affect an entire population.

PHR Account Holder shall have access to public health information resources. Example(s): A PHR Account Holder may want to receive general news releases from specific local, state and federal agencies. A PHR Account Holder may want to access information regarding public health resources for specific areas of interest such as birth control or hepatitis prevention.

PHR Account Holder shall have access to public health knowledge bases. Example(s): A PHR Account Holder may want to access up to date information from local, state and federal agencies regarding diabetes outcomes.

The systems should support the ability of a PHR Account Holder to enroll in all available local, state and federal public health programs. Example(s): A PHR Account Holder would like to enroll in a local or regional maternal health program to receive care for pregnancy.

A PHR Account Holder should have the ability to subscribe to local, state or federal public health notifications and alerts. Example(s): The PHR Account Holder enrolls to receive public health alerts from a local or regional health department that has recently issued an alert for meningitis.

A PHR Account Holder will have the ability to participate in public health surveys and store their responses to those surveys. Example(s): The World Health Organization offers a survey to research the number of smokers who also have a specific related disease.

Actions are taken to support patient health. Actions are taken in provision of healthcare to individuals. Actions are taken as the result of rules-based PHR System algorithms. Actors (i.e., patients, providers, users, systems) take Actions. (Actions broadly encompass tasks, acts, procedures or services performed or provided.) The PHR System captures Actions taken and creates corresponding Record Entries. Record Entries provide persistent evidence of Action occurrence, context, disposition, facts, findings and observations. From the point of Record Entry origination to the end of its lifespan, the PHR System manages each Entry consistent with and according to scope of practice, organizational policy, and jurisdictional law. In support of individual health and in provision of healthcare to individuals, Actors perform Actions and Actions have corresponding Entries in the PHR Record, (i.e., Action instances are documented by Record Entry instances). Record Entries may be captured during the course of the Action or sometime thereafter. The Actor (author/source) of the Record Entry may be the same as an Actor performing the Action or not. The PHR-S Functional Model does not specify a particular relationship of Actions and corresponding Record Entries. It may be one to one, many to one or even one to many. Actions have associated metadata (e.g., who, what, when, where, why, how, under what conditions, in what context). The corresponding Record Entry captures this metadata along with other Action and Record Entry related information. Each Record Entry also includes its own provenance metadata such as who (authoring Actor) and when (documented). Record Entries may be encapsulated to bind Actor (individual, organization, and/or system) signatures to data and metadata content and data/time of occurrence. Actions and related Record Entries capture a chronology of patient health and healthcare and also a chronology of operations and services provided in/by a healthcare enterprise. Record Entries reflect changes in health information from the time it was created, to the time it was amended, sent, received, etc. In this manner, each Record Entry serves as persistent evidence of an Action taken, enabling providers to maintain comprehensive information that may be needed for legal, business, and disclosure purposes. To satisfy these purposes, Record Entries must also be retained and persisted without alteration. Record Entries have both a lifecycle and a lifespan. Lifecycle Events include originate, retain, amend, verify, attest, access/view, de-identify, transmit/receive, and more. Lifecycle Events occur at various points in a Record Entry lifespan, always starting with a point of origination and retention (i.e., when the Entry is first created and stored). A Record Entry may have a pre and post Event state if content is modified. In this case, the original Record Entry is preserved (with signature binding) and a new Entry is created (with new signature binding). A Record Entry contains data and metadata, in multiple formats, following various conventions and standards. Included data may be tagged, and/or delimited, structured (concise, encoded, computable), or unstructured (free form, non-computable). Data may be encoded as text, document, images, audio, waveforms, in ASCII, binary or other encoding. Structured data may be characterized as being concise, encoded, computable, and may be divided into discrete fields. Examples of structured health information include:

• patient residence (non-codified, but discrete field)
• diastolic blood pressure (numeric)
• coded laboratory result or observation
• coded diagnosis
• patient risk assessment questionnaire with multiple-choice answers. Unstructured data may be characterized as being free form, and/or non-computable. Unstructured health record information is information that is not divided into discrete fields AND not represented as numeric, enumerated or codified data. Examples of unstructured health record information include:
• text (text message to physician)
• word processing document (a letter from a family member)
• image (photograph of a patient or a scanned image of insurance card)
• multimedia (dictated report or a voice recording). Context may determine whether data are structured or unstructured. For example, a progress note might be standardized and structured in some systems (e.g., Subjective/Objective/Assessment/Plan) but unstructured in other systems. The PHR System manages Record Lifecycle Events for each Record Entry, including pre and post Event record states, continuity, persistence and related Record Audit Logs.

As above References:

• ISO 21089: Health Informatics – Trusted End-to-End Information Flows
• HL7 EHR Interoperability Model DSTU
• HL7 Electronic Health Record Lifecycle Model DSTU

Occurs when an agent causes the system to: a) initiate capture of potential record content, and b) incorporate that content into the storage considered a permanent part of the health record. Reference: ISO 21089-2018, Section 15.1.

Evidence of Record Entry Originate/Retain Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent makes any change to record entry content currently residing in storage considered permanent (persistent). Reference: ISO 21089-2018, Section 15.2.

Evidence of Record Entry Amendment Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to change the form, language or code system used to represent record entry content. Reference: ISO 21089-2018, Section 15.3.

Evidence of Record Entry Translate Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to capture the agent’s digital signature (or equivalent indication) during formal validation of record entry content. Reference: ISO 21089-2018, Section 15.4.

Evidence of Record Entry Attestation Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to obtain and open a record entry for inspection or review. Reference: ISO 21089-2018, Section 15.5.

Evidence of Record Entry View/Access Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to produce and deliver record entry content in a particular form and manner. Reference: ISO 21089-2018, Section 15.6.

Evidence of Record Entry Output/Report Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to release, transfer, provision access to, or otherwise divulge record entry content. Reference: ISO 21089-2018, Section 15.7.

Evidence of Record Entry Disclosure Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to send record entry content from one (EHR/PHR/other) system to another. Reference: ISO 21089-2018, Section 15.8.

Evidence of Record Entry Transmit Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to a) initiate capture of data content from elsewhere, and b) incorporate that content into the storage considered a permanent part of the health record. Reference: ISO 21089-2018, Section 15.9.

Evidence of Record Entry Receive/Retain Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to scrub record entry content to reduce the association between a set of identifying data and the data subject in a way that may or may not be reversible. Reference: ISO 21089-2018, Section 15.10.

Evidence of Record Entry De-Identification Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to remove record entry content to reduce the association between a set of identifying data and the data subject in a way that may be reversible. Reference: ISO 21089-2018, Section 15.11.

Evidence of Record Entry Pseudomynization Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to restore information to data that allows identification of information source and/or information subject. Reference: ISO 21089-2018, Section 15.12.

Evidence of Record Entry Re-Identification Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to selectively pull out a subset of record entry content, based on explicit criteria. Reference: ISO 21089-2018, Section 15.13.

Evidence of Record Entry Extraction Events includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to create and move archive artifacts containing record entry content, typically to long-term offline storage. Reference: ISO 21089-2018, Section 15.14.

Evidence of Record Entry Archive Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to recreate record entries and their content from a previous created archive artefact. Reference: ISO 21089-2018, Section 15.15.

Evidence of Record Entry Restore Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to permanently erase record entry content from the system. Reference: ISO 21089-2018, Section 15.16.

Evidence of Record Entry Destruction Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to tag record entry(ies) as obsolete, erroneous or untrustworthy, to warn against its future use. Reference: ISO 21089-2018, Section 15.17.

Evidence of Record Entry Deprecation/Retraction Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to recreate or restore full status to record entries previously deleted or deprecated. Reference: ISO 21089-2018, Section 15.18.

Evidence of Record Entry Re-Activation Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to combine or join content from two or more record entries, resulting in a single logical record entry. Reference: ISO 21089-2018, Section 15.19.

Evidence of Record Entry Merge Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to reverse a previous record entry merge operation, rendering them separate again. Reference: ISO 21089-2018, Section 15.20.

Evidence of Record Entry Unmerge Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to connect related record entries. Reference: ISO 21089-2018, Section 15.21.

Evidence of Record Entry Link Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to disconnect two or more record entries previously connected, rendering them separate (disconnected) again. Reference: ISO 21089-2018, Section 15.22.

Evidence of Record Entry Unlink Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to tag or otherwise indicate special access management and suspension of record entry deletion/destruction, if deemed relevant to a lawsuit or which are reasonably anticipated to be relevant or to fulfill organizational policy under the legal doctrine of “duty to preserve”. Reference: ISO 21089-2018, Section 15.23.

Evidence of Record Entry Legal Hold Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Occurs when an agent causes the system to remove a tag or other cues for special access management had required to fulfill organizational policy under the legal doctrine of “duty to preserve”. Reference: ISO 21089-2018, Section 15.24.

Evidence of Record Entry Legal Hold Removal Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Verify Record Lifecycle Event - occurs when an agent causes the system to confirm compliance of data or data objects with regulations, requirements, specifications, or other imposed conditions based on organizational policy. Reference: ISO 21089-2018, Section 15.25.

Evidence of Record Entry Verification Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Encrypt Record Lifecycle Event - occurs when an agent causes the system to encode record entry content in a cipher. Reference: ISO 21089-2018, Section 15.26.

Evidence of Record Entry Encryption Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Decrypt Record Lifecycle Event - occurs when an agent causes the system to decode record entry content from a cipher. Reference: ISO 21089-2018, Section 15.27.

Evidence of Record Entry Decryption Event includes key metadata, ensures health record integrity (and trust) and enables record audit.

Record Lifecycle Events (Function [[RI.1.1]]) are those required to manage Record Entries in persistent storage over the full course of Record Lifespan (Section [[RI.1.2]]). See Section [[RI.1.1]], Record Lifecycle, for further description.

Occurs upon Record Entry origination/retention and thereafter on a continuous and uninterrupted basis for lifespan of each Record Entry.

• Ensures long-term retention and preservation of EHR Record Entries, without alteration. Reference: ISO 21089, Section 12.2.2

Occurs when a set of Record Entries is designated to be held for legal purposes or proceedings.

• Ensures preservation of a set of Record Entries for a designated time, held without alteration.

Record Entries may reside in various states that must be managed. An important underlying principle for managing record states is the need to retain Record Entries that have been viewed for patient care purposes even if the Entry has not been completed or attested. This principle has important legal impact because it provides an account of what the provider viewed and relied on for clinical decision-making. For example, if Record Entry content was available in pending state and a clinician used the information to make decisions, it is important to retain the pending version even after the final version was available. Determining if Record Entry content was used for patient care may be challenging. Access logs could provide a mechanism to determine if the information was used.

Record Entries may reside in various states that must be managed. An important underlying principle for managing record states is the need to retain Record Entries that have been viewed for patient care purposes even if it has not been completed or attested. This principle has important legal impact because it provides a record of what the provider relied on for clinical decision-making. For example, if a Record Entry was available in pending state and a clinician accessed the information to make decisions, it is important to retain the pending version even after the final version was available. Determining if the Record Entry was accessed for patient care may be challenging. Access logs should show if the information was accessed/viewed.

Clinicians need the ability to correct, amend or augment Record Entries once they have been completed. When an amendment, correction or augmentation has been made, principles for documentation practices require that the original documentation must be accessible, readable, and unobliterated. A user must have a clear indication that modifications have been made to an Record Entry. There is optionality in how a system may identify a Record Entry that has been corrected or amended – a flag or indicator could be displayed, the text could be in a different font, etc. The original Record Entry is not required to be displayed, but can be linked or traced back. The original Record Entry and each successive amendment, correction or augmentation should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and/or jurisdictional law.

The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time. A version may be one of: 1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times; 3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author; 4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test); 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example:

• Laboratory results (preliminary and final)
• Dictated reports
• Work ups (over course of days) The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.

Record retraction is used to reverse changes that have been made to existing Record Entries. Once a Record Entry has been retracted, it is no longer visible in standard queries, though it remains accessible in PHR audit records, should evidence ever be required for legal or other exceptional circumstances. Canada Health Infoway provides the following definition for retraction: This mechanism allows an existing record to be “removed” from the PHR if it is deemed erroneous. It can also be used to reverse changes that have been made to an existing record. Once a record has been retracted, it is no longer visible in standard queries, though it remains accessible in PHR audit records should evidence ever be required for legal or other exceptional circumstances. After retracting an erroneous record, a user has the ability to resubmit a corrected record with no visible indication that there was ever a previous version. Retract generally has significant constraints upon its use because of the risks of removing data from a patient’s record that might have been used by others in making decisions. The specifics will vary by jurisdiction, and potentially even by type of data. There are times that a PHR Record Entry is created then found to be erroneous, i.e., the record may belong to another individual. In these cases, it is necessary to remove that record from view (storing it in case it may be needed for litigation or investigation purposes, etc.). After retracting an erroneous record, a user has the ability to resubmit a corrected record with no visible indication that there was ever a previous version.

The PHR-S must provide the ability for an organization to define minimum elements and timeframes for completion at the report level and at the record level. Provide a report that identifies completion and timeliness status by patient/ health record number or other specified parameters. Prior to disclosure for legal proceedings or other official purposes, an organization analyzes the health record for completeness. PHR systems must provide the ability to define a minimum set of content to be analyzed for timeliness and completeness and provide a report of the status.

A PHR-S may consist of a set of components or applications; each application manages a subset of the health information. Therefore it is important that, through various interoperability mechanisms, a PHR-S maintains all the relevant information regarding the health record in synchrony. For example, if a physician orders an MRI, a set of diagnostic images and a radiology report will be created. As a result, the patient demographic information, the order for MRI, the diagnostic images associated with the order, and the report associated with the study must all be synchronized in order for the clinicians to receive a synchronized view the complete record (with respect to time and geographic location).Date and time need to be consistent across the applications that are part of the PHR system. Synchronization demonstrates a sequence and chain of events for reconstruction and is relevant during a legal proceeding. Maintenance of synchronization activities could be relevant during a legal proceeding. Note: Standards exist for Consistent Date and Time.

PHR Record Entries must be transitioned over its lifecycle from online data structures to near-line or off-line data structures. The archive function performs this transition of Record Entries from an online, production PHR-S to offline storage for information that is not being purged/destroyed. The system must provide such archive and restore functions to extract and preserve indefinitely, Record Entries selected to be removed from the live production PHR-S database and retained. Record Entries must be archived and restored in such a manner as to permit them to be returned to their original or similar information structures. Archived Record Entries must also include corresponding metadata to ensure logical and semantic consistency of the information for subsequent access upon restoration. The archive function should provide both an automated, configurable capability as well as a user-invoked archival function to enable selected Record Entries to be preserved, or flagged for preservation. In the first instance, rules are specified to enable the system to conduct archiving in an unattended fashion. This is often the case for periodic system maintenance requirements (e.g., nightly processing where archival, data summarization and possibly purging of information occurs). In the second instance the system should provide the ability to select Record Entries to be preserved for future reference and access, such as in the case where selected Entries need to be preserved and retained for litigation. In restoring information, it may occur that Record Entries being restored are a subset of the Entries originally archived. For example, when all Record Entries for a patient encounter were archived and only a particular set of Record Entries related to a study or result are to be restored. The system may provide for such finer granularity of restoration. Archiving and restoring of Record Entries must be performed in a timely fashion, consistent with the operational requirements of both PHR users and system and technology capabilities. The system must enable compliance with records retention according to scope of practice, organizational policy or jurisdictional law.

PHR-S security consists of entity authentication, entity authorization, entity access control, patient access management, secure data exchange, attestation, patient privacy and confidentiality. PHR audit functions are described in [[TI.2]].

All entities accessing the PHR-S are subject to authentication. Examples of entity authentication, with varying levels of authentication rigor, include:

• username/password;
• digital certificate;
• secure token;
• biometrics.

Entities are authorized to use components of a PHR-S in accordance with their scope of practice within local policy or legal jurisdiction. Authorization rules provide a proper framework for establishing access permissions and privileges for the use of a PHR system, based on user, role or context. A combination of these authorization categories may be applied to control access to PHR-S resources (i.e., functions or data), including at the operating system level.

• User based authorization refers to the permissions granted to access PHR-S resources based on the identity of an entity (e.g., user or software component).
• Role based authorization refers to the permissions granted to access PHR-S resources based on the role of an entity. Examples of roles include: an application or device (tele-monitor or robotic); or a nurse, dietitian, administrator, legal guardian, and auditor.
• Context-based Authorization refers to the permissions granted to access PHR-S resources within a context, such as when a request occurs, explicit time, location, route of access, quality of authentication, work assignment, patient consents and authorization. See ISO 10181-3 Technical Framework for Access Control Standard. For example, a PHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision.

To ensure access is controlled, a PHR-S must authenticate and check authorization of entities for appropriate operations.

The intent of Emergency Access Control is to mitigate the potential for impeding the provision of care in an emergency situation in accordance with organizational policy. For example, emergency access may include:

• Single record entry (e.g., single laboratory results, single document, single view);
• Single patient;
• Single login session, multiple patients;
• Site mode allowing simultaneous emergency access to all users. Logging of a user’s activities should occur in the audit record/metadata. Reports of emergency access use for follow up are critical for compliance and monitoring.

A healthcare delivery organization will be able to manage a patient’s ability to view his or her PHR based on organization policy or jurisdictional law. Typically, a patient or their legal representative (e.g., guardian, surrogate) has the right to view his or her PHR.

A PHR-S allows data entry to a patient’s electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:

• Digital signature, which serves as a unique identifier for an individual (much like a written signature);
• Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received);
• Timestamp, which proves that a document existed at a certain date and time;
• The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).

Whenever an exchange of PHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation as well as both destination and source authentication when necessary. For example, it may be necessary to encrypt data sent to remote or external destinations.

A PHR-S needs to ensure that it is exchanging PHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in a PHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP (Internet Protocol) addresses or recordings of DNS (Domain Name System) names. For dynamic determination of known sources and destinations, systems can use authentication mechanisms as described in TI.1. For example, the sending of a laboratory order from the PHR-S to a laboratory system within the same organization usually uses a simple static setup for routing. In contrast, sending a laboratory order to a reference laboratory outside of the organization will involve some kind of authentication process. Provision of a secure network infrastructure is beyond the scope of a PHR-S.

Patients’ privacy and the confidentiality of PHRs are violated if access to PHRs occurs without authorization. Violations or potential violations can impose tangible economic or social losses on affected patients, as well as less tangible feelings of vulnerability and pain. Fear of potential violations discourages patients from revealing sensitive personal information that may be relevant to diagnostic and treatment services. Rules for the protection of privacy and confidentiality may vary depending upon the vulnerability of patients and the sensitivity of records. Strongest protections should apply to the records of minors and the records of patients with stigmatized conditions. Authorization to access the most sensitive parts of a PHR is most definitive if made by the explicit and specific consent of the patient. Please see the definition of masking in the glossary. Organizational practices related to privacy and security jurisdictional laws could be called into question during a legal proceeding. Adherence to applicable laws supports the credibility and trustworthiness of the organization.

A number of systems implement large tracking screens, common displays or dashboards to support workflows. In these applications, there is a need to create de-identified views for broadcast in common areas.

Create a flag to indicate to all providers caring for the patient, as well as administrative staff who may receive phone calls from family members or others, the need to protect the identity of patients at risk of harm, or requesting similar anonymity. Despite best efforts of confidentiality, display should identify patients at particular risk of harm during stay (e.g., domestic violence).

A health care delivery relies on services provided by other external facilities such as laboratories or Long Term Care facilities. The status of those facilities is subject to change for example: power outage, flooding or overcapacity. Therefore, the PHR system needs to capture the status of the external facilities, notify appropriate individuals / organizations or even change the workflow based on established business rules. Change of the status of an external facility is patient safety concern because a provider may need to adjust patient care or care workflows accordingly. For example, changes of status of external facility include: laboratory no longer accredited, laboratory power outage, Long Term Care facility at overcapacity. If laboratory loses accreditation an administrator needs to be notified to adjust the workflow. If status change is anticipated on regular basis, the system may automatically trigger workflow adjustment according to established business rule that take in consideration the status of the external facility. The example for later, the local Long Term Care facility may routinely exceed the capacity on the weekends; therefore, the business rule will accommodate for automatic workflow adjustments.

A provider may need to be aware of certain Service Level Agreement information in order to mitigate patient safety-related risks that depend on system availability or system performance.

A Trusted Information Exchange environment facilitates protected health information exchange by employing common user authentication across multiple systems, and/or organizations. A Trusted Information Exchange environment can help decrease risk and liability for participating members of the Trusted Information Exchange environment by ensuring that protected health information is consistently managed by all participants.

PHR Systems have built in audit triggers to capture key events in real-time, including events related to record management, security, system operations or performance or clinical situations. Event details, including key metadata (who, what, when, where), are captured in an Audit Log. Audit Review functions allow various methods of critical event notification as well as routine log review. Audit functions implement requirements according to scope of practice, organizational policy, and jurisdictional law.

PHR Systems have built in audit triggers to capture key events in real-time. Audit triggers signal key:

• Record management and lifecycle events;
• Security events related to system and data safeguards, both routine and exceptional;
• System events related to performance and operations, both routine and exceptional;
• Clinical events with special log requirements.

Record Entries are managed throughout their lifespan at various points in their lifecycle. Record Entry Audit Triggers are designed to capture Record Entry related events including key metadata (who, what, when, where, why). See Function [[RI.1]], Record Lifecycle.

Security Audit Triggers are designed to capture security related events, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture security events, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user authentication to the system (start user session), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user authentication (system prompt for password change), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user request to change password, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user log out (end user session), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user access (successful), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user attempts to access data (unsuccessful – access denied), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture extraordinary user access (break the glass), both routine and exceptional, including key metadata (who, what, when, where, why).

Capture user permissions (authorization), both routine and exceptional, including key metadata (who, what, when, where, why).

System Audit Triggers are designed to capture system related events, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system events, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system started event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture back-up started event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture back-up completed event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture back-up recovery started event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture back-up recovery completed event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system batch job started event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture batch job completed event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture maintenance started event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture maintenance completed event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture resource usage event, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system maintenance events -local access, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system maintenance events -remote access, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system maintenance - PHR or clinical software, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture system maintenance of codes, vocabulary, knowledge and rules - both routine and exceptional, including key metadata (who, what, when, where, why).

Capture data corruption event, including key metadata (who, what, when, where, why).

Clinical Audit Triggers are designed to capture certain clinical events, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture clinical alerts, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture acknowledgement of clinically significant report changes, both routine and exceptional, including key metadata (who, what, when, where, why).

Capture disabling of decision support alerts, both routine and exceptional, including key metadata (who, what, when, where, why).

Audit Triggers create Audit Log entries. Audit Log entries are typically managed as persistent evidence of events occurring over time, including events pertaining to record management, security, system operations and performance, key clinical situations. Audit log entries capture event details, including key metadata (who, what, when, where).Audit log functions fulfill log maintenance and persistence requirements according to scope of practice, organizational policy, and jurisdictional law.

Audit logs must be maintained in a persistent and indelible form according to scope of practice, organizational policy, and jurisdictional law.

PHR system functions allow various methods of critical event notification (from audit triggers) as well as routine log review. Audit log notification and review functions implement requirements according to scope of practice, organizational policy, and jurisdictional law.

Registry and directory service functions are critical to successfully managing the security, interoperability, and the consistency of the health record data across a PHR-S. These services enable the linking of relevant information across multiple information sources within, or external to, a PHR-S for use within an application. This applies to directories/registries internal to the PHR-S as well as directories/registries external to the PHR-S. Transmission may occur automatically or manually and may include small or large amounts of data. Directories and registries support communication between PHR Systems and may be organized hierarchically or in a federated fashion. For example, a patient being treated by a primary care physician for a chronic condition may become ill while out of town. The new provider’s PHR-S interrogates a local, regional, or national registry to find the patient’s previous records. From the primary care record, a remote PHR-S retrieves relevant information in conformance with applicable patient privacy and confidentiality rules. An example of local registry usage is a PHR-S application sending a query message to the Hospital Information System to retrieve a patient’s demographic data.

The purpose of supporting terminology standards and services is to enable semantic interoperability. Interoperability is demonstrated by the consistency of human and machine interpretation of shared data and reports. It includes the capture and support of consistent data for templates and decision support logic. Terminology standards pertain to concepts, representations, synonyms, relationships and computable (machine-readable) definitions. Terminology services provide a common way for managing and retrieving these items, including historically correct version interpretation. Terminology services need to support legal requirements for retrospective health record information and system data.

Semantic interoperability requires standard terminologies combined with a formal standard information model. An example of an information model is the HL7 Reference Information Model. Another example is the ISO/EN 13606 Electronic Health Record Communication. A terminology provides semantic and computable identity to its concepts. Examples of terminologies that a PHR-S may support include: LOINC, SNOMED, ICD-9, ICD-10, and CPT-4.Terminologies are use-case dependent and may or may not be realm dependent. The key is that the standard be approved by all stakeholders. For example, terminologies for public health interoperability may differ from those for healthcare quality, administrative reporting, research, etc. Formal standard terminology models enable common semantic representations by describing relationships that exist between concepts within a terminology or in different terminologies, such as exemplified in the model descriptions contained in the HL7 Common Terminology Services specification. The clinical use of standard terminologies is greatly enhanced with the ability to perform hierarchical inference searches across coded concepts. Hierarchical Inference enables searches to be conducted across sets of coded concepts stored in a PHR-S. Relationships between concepts in the terminology are used in the search to recognize child concepts of a common parent. For example, there may be a parent concept, ‘penicillin containing preparations’ which has numerous child concepts, each of which represents a preparation containing a specific form of penicillin (Penicillin V, Penicillin G, etc.). Therefore, a search may be conducted to find all patients taking any form of penicillin preparation. Clinical and other terminologies may be provided through a terminology service internal or external to a PHR-S.

Version control allows for multiple sets or versions of the same terminology to exist and be distinctly recognized over time. Standard terminologies are usually periodically updated, and concurrent use of different versions may be required. Ideally, the meaning of a concept never changes over time, but a concept can be deprecated, and replaced with a new concept in a new version. However, in some terminologies, the meaning of a concept can change over time. In any case, it is important that retrospective analysis and research maintains the ability to relate to the appropriate conceptual meaning. If the terminology encoding for a concept changes over time, it is also important that for legal health records, as well as for retrospective analysis and research, the different encodings can be correlated to ensure the permanence of the concept as originally captured. This does not necessarily imply that complete older versions of the terminology be kept in the PHR-S, only access to the changes needs to be maintained.

The ability to map or translate one terminology to another is fundamental to an organization in an environment where several terminologies are in play to meet different purposes. It is a common occurrence that data is captured using one terminology, but is shared using another terminology. Example: Within a healthcare organization there may be a need to map terminology concepts with the same semantic meaning to meet different purposes (e.g., between a PHR-S and an external laboratory system, or between a PHR-S and a billing system). Standard terminologies are evolving and maps will need to be adjusted to support this evolution and more sophisticated use of standard terminologies and maps over time. Realm specific (including local, regional, national or international) interoperability requirements can also determine the need for terminology mapping, and in many cases terminology mapping services (internal or external) can be used to satisfy these requirements. The interaction and mapping of terminologies may be called into question in a legal proceeding, when clinical decisions were documented or when semantic meaning could be misinterpreted. It is important to seek guidance, document and retain all mapping decisions for all types of terminology mapping, and to recognize when mapping may not be possible from one concept to another. The quality of mapping is dependent upon the skills and interpretation of standard terminologies and clinical information by mapping experts.

Interoperability standards enable certain applications to be shared among PHR systems, resulting in a unified (logical) view of a given PHR system where several disparate systems may actually be participating transparently. Interoperability standards also enable certain information to be shared among PHR systems (including information that resides in regional, national, or international information exchanges). Interoperability standards also promote timely and efficient information capture, use, and re-use, often reducing the cumulative workload of the broad set of stakeholders. When health-related information is exchanged – or when external applications are used to extend a PHR system – the interoperability methods and underlying standards that were used in the process may need to be disclosed during a legal proceeding (especially when the resulting information becomes part of the patient’s medical record).

Since a health care organization typically has various external and internal interoperability requirements, it must use a set of corresponding interoperability or interchange standards that will meet its connectivity and information structure, format, and semantic requirements. Information should be exchanged – and applications should provide functionality – in a manner that appears to be seamless to the user. To be specific, if data is received from an external source that requires a user to manually copy-and-paste that data into multiple parts of the system, the exchange is not considered to be ‘seamless’. Examples of standards-based PHR information content and exchange methods include: standards-based data extracts, standards-based messages, standards-based documents (e.g., HL7 Clinical Document Architecture (CDA) documents), standards-based healthcare transactions, and standards-based images (e.g., Digital Imaging and Communication in Medicine (DICOM) documents). Support for multiple interaction modes is needed to respond to differing levels of immediacy and types of exchange. For example, messaging is effective for many near-real time, asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting an immediate response from a remote application. A variety of interaction modes are typically supported such as:

• Unsolicited Notifications (e.g., Adam Everyman has arrived at the clinic for his scheduled appointment);
• Query/Response (e.g., Query: Is Adam Everyman known to the system? Response: Yes, Adam’s medical record number is 12345678);
• Service Request and Response (e.g., Request: Laboratory Order for “Fasting Blood Sugar”. Response: the results of the test);
• Information Interchange between organizations (e.g., in a regional health exchange or in a national health system);
• Structured/discrete clinical documents (e.g., a structured clinical note);
• Unstructured clinical document (e.g., dictated surgical note). Standard terminology is a fundamental part of interoperability and is described in function [[TI.4]]. Using a formal explicit information model further optimizes interoperability. An example of an information model is the HL7 Reference Information Model (RIM). Organizations typically need to deal with more than one information model and may need to develop a mapping between information models, a meta-model (that helps to explain and organize the various information models), or both.

Placeholder - Not Defined at this time

Structured documents are an important method of facilitating the exchange of information to support care. Documents are often considered to be more permanent in nature; messages are often considered to be more transitory in nature. Examples of structured documents include: a referral from a primary care physician to a specialist; a medical summary; a discharge instruction for the patient.

Structured messages are an important method of facilitating the exchange of information to support care. Messages are often considered to be more transitory in nature; documents are often considered to be more permanent in nature.

Interchange standards characteristically change throughout their lifecycles; those changes are often tagged with ‘version’ numbers. PHR systems need to control the various versions of interchange standards that are used within a PHR implementation and accommodate changes that arise with each version. For example, if an organization migrates to version 2.5 of HL7’s messaging standard, it may choose to utilize that version’s specimen or blood bank information capabilities. The organization may also find that certain fields have been retained for backwards compatibility only or withdrawn altogether. The PHR-S needs to be able to handle all of these possibilities. Standards typically evolve in such a way as to protect backwards compatibility. On the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3. Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly. Version control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time. Since interchange standards are usually periodically updated, concurrent use of different versions may be required. Large (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements. For example, the enterprise-wide standard might use HL7 v2.5 for laboratory messages, but some regions of the enterprise might be at a lower level. It should be possible to retire deprecated interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim’s life cycle. When interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions’ information structures to support the permanence of concepts over time.

A PHR-S often consists of multiple applications. Some of those applications may be within the PHR-S; others may be external to the PHR-S. The user of the PHR-S often benefits when those applications are integrated. Application integration can be accomplished in an ad-hoc fashion or in a standards-based fashion. The method(s) by which applications may be integrated within an organization depends on that organization’s approach to application integration. A given organization could conceivably employ multiple application integration approaches to meet various application integration requirements.

Systems that wish to communicate with each other must agree on certain parameters/criteria that will govern an information exchange process. Interchange agreements enable partnering systems to discover, negotiate, and utilize those parameters/criteria. A PHR-S can use this information to define how data will be exchanged between the sending and the receiving partners. Interchange services and capabilities can be discovered in an automated fashion. Entity directories can be used to determine the address, profile, and data exchange requirements of known, and/or potential Interchange Agreement partners. Entity registries can be used to determine the security, addressing, and reliability requirements between potential Interchange Agreement partnering systems.

Within a given organization (for example, an institution, facility , or integrated care-delivery network), a PHR system may be directly integrated with other systems (for example, a laboratory Information System, Radiology System, Pharmacy System, or Hospital Information System). Conversely, a PHR system may access these other systems indirectly by integrating with a system that serves as the central routing mechanism for the organization. For example, the PHR system may be integrated with the Hospital Information System which then routes the PHR system’s orders to a laboratory , pharmacy, or radiology service. Depending on the type of information that is exchanged within an integrated-system environment, certain heuristics may be needed that will help govern the information exchange process.

PHR-S business rule implementation functions include decision support, diagnostic support, workflow control, and access privileges, as well as system and user defaults and preferences. A PHR-S supports the ability of providers and institutions to customize decision support components such as triggers, rules, or algorithms, as well as the wording of alerts and advice to meet realm specific requirements and preferences.

Workflow management functions that a PHR-S supports include:

• Distribution of information to and from internal and external parties;
• Support for task-management as well as parallel and serial task distribution;
• Support for notification and task routing based on system triggers; and-Support for task assignments, escalations and redirection in accordance with business rules. Workflow definitions and management may be implemented by a designated application or distributed across a PHR-S.

To enable the preservation of the PHR database and its data, functionality needs to be present to record a copy of the database and its contents to offline media as well as the recovery of the system from a backup copy and resumption of normal system operation. The backup must preserve both data as well as database structure and definition information sufficient to recover a complete functional PHR system. Database components may include, but not be limited to application data, security credentials, log/audit files, and programs; ultimately all PHR components necessary to provide a full and complete operating environment. Finally, the backup must be capable of being used during recovery processing to restore an exact copy of the PHR system as of a particular instant in time. This is a requirement to be able to preserve logical consistency of information within the recovered PHR system. In providing for this capability the system may include multiple backup, and/or redundancy solutions such as fail-over architecture, database journaling, transaction processing, etc. The backup and recovery function must address both physical system failure (i.e., failure of PHR system hardware) as well as logical system failure (e.g., database corruption). To support the requirement that the PHR system be available whenever it is needed within the design parameters of the system and provide reliability and redundancy of the PHR database and its data, the backup function shall not impact user functionality or appreciably impact user performance. The backup function may include features which permit multiple processes and technologies to perform its task. This may include multiple backup technologies such as tape, disk, cloud, etc. Also, multiple architectures such as redundancy, online, near-line and off-line media.

A health care delivery relies on services provided by other external facilities such as laboratories or Long Term Care facilities. The status of those facilities is subject to change for example: power outage, flooding or overcapacity. Therefore, the PHR system needs to capture the status of the external facilities, notify appropriate individuals / organizations or even change the workflow based on established business rules. Change of the status of an external facility is patient safety concern because a provider may need to adjust patient care or care workflows accordingly. For example, changes of status of external facility include: laboratory no longer accredited, laboratory power outage, Long Term Care facility at overcapacity. If laboratory loses accreditation an administrator needs to be notified to adjust the workflow. If status change is anticipated on regular basis, the system may automatically trigger workflow adjustment according to established business rules that take into consideration the status of the external facility. The example for later, the local Long Term Care facility may routinely exceed the capacity on the weekends; therefore, the business rule will accommodate for automatic workflow adjustments. A provider may need to be aware of certain Service Level Agreement information in order to mitigate patient safety-related risks that depend on system availability or system performance.

Clinical Model specification. Semantic interoperability requires in addition to standard terminologies that give the meaning to concepts in the PHR also the structural format of data elements, code bindings, relationships, and data types, and their units and value sets where applicable. To allow the vast clinical variations to be facilitated in a PHR system, clinical model specifications are used. Such clinical models adhere to formal standard information models such as templates adhering to the HL7 Reference Information Model, or archetypes according the ISO/EN 13606 Electronic Health Record Communication. However, recently additional clinical models are expressed independent of such standard information models. Examples include models from the Clinical Information Modeling Initiative and ISO TS 13972 based Detailed Clinical Models. A clinical model typically specifies the required data element(s) for one or more clinical concepts. The data elements will get unique identifying codes from terminologies as is explained in TI 4. Examples of clinical models include blood pressure, body weight, Apgar score, Glasgow Coma Scale, physical exam, and laboratory result. Clinical Model Services specification. The use of clinical models in a PHR system can vary. The clinical models can be used to specify which data elements should be visible in the user interface, which values should be allowed to select from pull down menus or check boxes. For record keeping, clinical models can define which data elements should be stored (for instance besides the values the user sees on the screen) and which terminology codes should in addition be stored with the data to maintain the meaning. Also, the clinical models can be used to specify the data exchange for a given use case. Clinical models may be provided through a clinical model service internal or external to a PHR-S. Typical functions of clinical model services include the runtime provisions of the single clinical model or sets of clinical models. It is also possible to provide specifications for single data elements, and where applicable (versions) of value sets used to populate the data in the PHR-S in a standard manner. In addition, the clinical model service could provide mappings between values from different value sets, e.g., between different versions of value sets, or alternatively mappings between data elements, e.g., from source to target.

Healthcare is shifting from supply-oriented care to more demand / patient-oriented integrated care. The focus is the patient and the integrated care he needs executed by one or more healthcare provider(s) in one or more organizations. Information on the patient must be shared by these healthcare providers and organizations. The PHR system must be focused on a problem-oriented recording in an integrated PHR system. This recording should take place in the care process and seamlessly fit in the workflow of the healthcare professional. When the information is properly recorded in the PHR, these information can be reused: by other healthcare providers, for deriving quality information, financial information and for research. For this purposes the use of widely accepted international standards is necessary. Clinical Models are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process. The purpose of the standardization is that this information from the care process is reused for other purposes such as quality registration, transfer or patient-related research. A Clinical Model is an information model in which a care-based concept is described in terms of the data elements from which that concept exists, the data types of those data elements, the binding to a (standard) terminology, etc. Clinical models are information models of minimal clinical concepts, each containing multiple data with agreed content, structure and mutual relationship. The binding to a terminology provides semantic and computable identity to its concepts. Examples of terminologies that a PHR-S may support include: LOINC, SNOMED, ICD-9, ICD-10, and CPT-4. See also Function TI.4 Standard Terminology and Terminology Services. The key is that the standard be approved by all stakeholders. For example, a standard Clinical Model for ‘Problem’. The information that is recorded in the PHR according to the Clinical Model can be reused for other purposes as quality registration, transfer or patient-related research.

Version control allows for multiple sets or versions of the same clinical model to exist and be distinctly recognized over time. Standard clinical models can be updated, and concurrent use of different versions may be required. Ideally, the meaning of a clinical model never changes over time, but a clinical model can be deprecated, and replaced with a new clinical model in a new version. It is important that retrospective analysis and research maintains the ability to relate to the appropriate clinical model. If the meaning of a clinical model changes over time, it is also important that for legal health records, as well as for retrospective analysis and research, the different meaning can be correlated to ensure the permanence of the information as originally captured. This does not necessarily imply that complete older versions of the clinical model be kept in the PHR-S, only access to the changes needs to be maintained.

The ability to map or translate one clinical model to another is fundamental to an organization in an environment where several clinical models are in play to meet different purposes. It is a common occurrence that data is captured using one clinical model, but is shared using another clinical model.

Personal Health PHR-S functions are the subset of PHR-S functions that enable an individual to manage information about his or her healthcare. These functions provide direction as to the individual’s ability to interact with a Personal Health Record in such a way so as to individualize the record and maintain a current and accurate record of his or her healthcare activities. The functions include activities such as managing wellness, prevention and encounters. These functions are designed to encourage and allow an individual to participate actively in their healthcare and better access the resources that allow for self-education and monitoring. All functions within the Personal Health Section have an identifier starting with “PH”.

Supportive PHR-S functions are the subset of PHR-S functions that assist with the administrative and financial requirements associated with the delivery of healthcare. Supportive PHR-S functions also provide input to systems that perform medical research, promote public health, and seek to improve the quality of healthcare delivered. All functions within the Supportive Section have an identifier starting with “S”.

The Record Infrastructure Section consists of functions common to EHR System record management, particularly those functions foundational to managing record lifecycle (origination, attestation, amendment, access/use, translation, transmittal/disclosure, receipt, de-identification, archive…) and record lifespan (persistence, indelibility, continuity, audit, encryption). The RI and TI Sections are identical between the PHR and EHR System Functional Models, reflecting the need for common and compatible record management and trust infrastructures. Note that there may be some functions more directly applicable to EHR systems than PHR systems. RI functions are core and foundational to all other functions of the Model (PH, S). RI functions may be implemented within the architecture of a single system or across a tightly coupled suite of systems (applications). All functions within the Record Infrastructure Section have an identifier starting with “RI”.

The Trust Infrastructure (TI) Section consists of functions common to a PHR System infrastructure, particularly those functions foundational to system operations, security, efficiency and data integrity assurance, safeguards for privacy and confidentiality, and interoperability with other systems. TI functions are core and foundational to all other functions of the Model (Care Provision, Care Provision Support, Population Health, Administrative Support and Record Infrastructure). Note extensive reference to TI functions in Overarching Criteria. TI functions may be implemented within the architecture of a single system or across a tightly coupled suite of systems (applications).All functions within the Trust Infrastructure Section have an identifier starting with “TI”. The RI and TI Sections are identical between the PHR and EHR System Functional Models, reflecting the need for common and compatible record management and trust infrastructures. Note that there may be some functions more directly applicable to EHR systems than PHR systems.

This StructureDefinition represents the basis EHR-S FM Function type

This StructureDefinition represents the basis EHR-S FM Header type