Page tree
Skip to end of metadata
Go to start of metadata

DRAFT
Development will be led by Jan Oldenburg. Virginia will shepherd transforming into new HL7 template.

Vital signs, PGHD, observations, anything originating from the patient universe vs provider generated.

Health concerns, goals, preferences


1a. Project Name

ARCHIVE VERSION:  Patient Contributed Data

1b. Project ID

1640

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

There is a 'PSS-Lite' process to define minimal information to initiate an 'investigative' project in HL7. Investigative projects will have two trimesters to either fully develop a project scope statement, or determine there is no need to advance the investigative project.

What is our goal here? Could we qualify as a PSS-Lite? (VL - yes we might.  Trying to see the downside of this)  (TR-Are we augmenting the headers in PGHD? see below)

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

The Health Level Seven Version 3 (V3) Normative Edition—a suite of specifications based on HL7’s Reference Information Model (RIM)—provides a single source that allows implementers of V3 specifications to work with the full set of messages, data types, and terminologies needed to build a complete implementation. The 2015 Normative Edition represents the complete suite of V3 specifications. Each of these specifications has been balloted to formal approval as either a Normative Standard or a Draft Standard for Trial Use. It includes standards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. As such, it is a foundational part of the technologies needed to meet the global challenge of integrating healthcare information, in areas such as patient care and public health

Do we think we will end up as a Normative project? What is our goal here? To create a set of guidelines? To update a set of standards? Do we think these will be standards for EHRs or standards that sit outside of EHRs?  

Note there is already this as part of the Clinical Document Architecture; it's an implementation guide for patient-generated data (headers only, I think): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=316  

TR - From PGHD IG - "Even though the vision is for a new set of non-clinician generated consolidated document types, the new document types are NOT in scope for this implementation guide."   Is this what a recommendation to make in white paper?

Also a white paper on PGHD integration into EHRs with Ken Mandl: https://www.nature.com/articles/s41746-020-0218-6  (VL-I think you should leave this field blank.  Your contents here belongs in the white paper created by the project)

1e. Today's Date

4/27/2020

1f. Name of standard being reaffirmed


1g. Project Artifact Information

Do we think we will create a project artifact? What would it look like or need to contain?  (VL - a white paper to be used to define patient contributed data and the work done to standardize interoperability in the field up to this point as well as consideration of gaps and needs and recommendations) (TR- Would it be possible to use findings in white paper to make recommendations to add to the PGHD implementation guide?

1h. ISO/IEC Standard to Adopt


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


1j. Unit of Measure

Metric

2a. Primary/Sponsor WG

Patient Empowerment Workgroup

2d. Project Facilitator

Jan Oldenburg & Maria D. Moen, Virginia Lorenzi (VL - pick one person for this.  Its like the PM role)

2e. Other Interested Parties (and roles)

EHR Vendors, Providers (VL- this is the wrong form.  Need to identify cosponsors and interested parties - two different things.  Should be the names of workgroups only.  Recommend at least CBCP)  (TR - Digital Health vendors and researchers?). Data analytics groups

2f. Modeling Facilitator

Abigail Watson; Lloyd McKenzie

2g. Publishing Facilitator

Lloyd McKenzie, John Moe

2h. Vocabulary Facilitator

Abigail Watson

2i. Domain Expert Representative

EPatientDave

2j. Business Requirements Analyst


2k. Conformance Facilitator

Required for Implementation Guide projects

2l. Other Facilitators

Virginia Lorenzi

2m. Implementers

Debi Willis (MyPatientLink); Abigail Watson (Symptomatic)  (I do not know if this applies because its a white paper)

3a. Project Scope

This is important

Attachments


3b. Project Need

Patients and their caregivers are the closest observers of their own health and typically have information available to document their health status. Data related to this information includes observations; surveys; vital signs; readings from devices, wearables, and sensors; implanted device identification information, patient's own assessment of their health status; goals, preferences, priorities for care; mental health status; and non-prescription and prescription medication history including supplements, vitamins, OTC medications, prescribed medications, side effects, and actual patterns of medication ingestion. This data can be vital for physicians to have available in order to avoiding exposure to patient harm (MRI).  understand the patient's health condition between visits and during episodes of care, as part of understanding patterns and correlations in that critical information, and as a facilitator for empowering the collaboration between patients and their care teams. There are few standards governing how this data is collected, stored, transmitted, trended, or used, limiting the effectiveness of this genre of data. The standards that do exist are underused, potentially out-dated, and not well known.  (VL - Need toclearly define the types of patient contributed data,  understand what standards and implementation guides are already out there, and develop a plan based on what is discovered to provide recommendations on a way forward to ensure patient contributed data is communicated in a robust standard manner)

3c. Security Risk

No

3d. External Drivers

Patient contributed health data is supported by ONC and is incorporated (very generally) in requirements for EHR vendors.

3e. Objectives/Deliverables and Target Dates

Define Patient Contributed data

Conduct an environmental scan to identify and review standards and implementation guides that exist in this space.

Define a way forward based on result of the scan (this may include recommending using some existing standards, enhancing them, creating new implemntation guides, etc)

Publish white paper containing all of the above

Review standards that exist. Identify whether the existing standards require update. Identify any additional standards that are required, if appropriate. Also identify what data needs context and trending.  

3f. Common Names / Keywords / Aliases:

Patient Generated Data (PGD), Patient Reported Data (PRD), Patient Reported Outcomes (PRO)

3g. Lineage


3h. Project Dependencies

This project depends on clear consent for use of this data by patients or their caregivers/proxies, the ability to dictate who has access to it which will touch on "trust" issues in a technical sense, and clear definition as to intent of use.  It also requires providence tracking

3i. HL7-Managed Project Document Repository URL:


3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

N/A

3l. Using Current V3 Data Types?

CCD, CDA, N/A for v3 RIM  (VL - Do not need to list specific standards - its a white paper)

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

Using FHIR instead. 

3m. External Vocabularies

SNOMED, LOINC, USCORE, 

3n. List of Vocabularies

SNOMED, LOINC, USCORE

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


4a. Products


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

R4.

4c. FHIR Profiles Version

R4; USCore

4d. Please define your New Product Definition

Patient Contributed Data Implementation Guide  (TR - do we want to creata

4d. Please define your New Product Family

Patient Generated Data Products

5a. Project Intent

Exercising rights under the 21st Century Cures Act.

5a. White Paper Type

Gap Analysis, Implementation Guide

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

Patient Reported Outcomes (PRO), Personal Health Record Server (PHR-S)

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


5a. Specify external organization

MyPatientLink, Symptomatic

5a. Revising Current Standard Info


5b. Project Ballot Type


5c. Additional Ballot Info


5d. Joint Copyright


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

no

6a. External Project Collaboration


6b. Content Already Developed

Patient Reported Outcomes (PRO)

6c. Content externally developed?


6d. List Developers of Externally Developed Content


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


6f. Stakeholders

Patient Advocacy Groups, Electronic Health Records, Clinicians, Practitioners. Researchers

6f. Other Stakeholders

Patient Families, Allied Healthcare, Medical Homes, Healthcare Supply chain, Digital Health

6g. Vendors


6g. Other Vendors


6h. Providers


6h. Other Providers


6i. Realm


7d. US Realm Approval Date


7a. Management Group(s) to Review PSS


7b. Sponsoring WG Approval Date


7c. Co-Sponsor Approval Date


7c. Co-Sponsor 2 Approval Date


7c. Co-Sponsor 3 Approval Date


7c. Co-Sponsor 4 Approval Date


7c. Co-Sponsor 5 Approval Date


7c. Co-Sponsor 6 Approval Date


7c. Co-Sponsor 7 Approval Date


7c. Co-Sponsor 8 Approval Date


7c. Co-Sponsor 9 Approval Date


7c. Co-Sponsor 10 Approval Date


7e. CDA MG Approval Date


7f. FMG Approval Date


7g. V2 MG Approval Date


7h. Architecture Review Board Approval Date


7i. Steering Division Approval Date


7j. TSC Approval Date































1 Comment

  1. SDOH-CC IG includes use of QuestionnaireResponse and Consent information authored by the patient and Use Case 1 in that IG covers including that information into the patient's medical record.

    Patient identity is a security risk.  It is essential to be able to know that the digital user is IN FACT the patient. Certificate-backed identities should be discussed in the Security section, IMO.