Patient Generated Document Informative Document

From HL7Wiki
Jump to: navigation, search

Project Details

Overview

In the “era of patient empowerment”, we want to define a specification for patient-authored clinical documents. Medical practices are looking for ways to allow patients to electronically complete certain tasks online such as filling out registration forms, health history forms, consenting to certain practice policies, and other types of clinical documents yet to be defined. As electronic document interchange increases, we see a growing need to communicate documents created by patients (including those needed by providers and/or those document types defined by patients). Often, this is done through a secure web interface controlled by the patient such as a patient portal or a personal health record. As more and more practices incorporate EMR technology into their practice workflow, they want to be able to import patient provided structured information into their EMR’s. This is being driven by the need to meet Meaning Use 2 requirements for patient engagement as well as other needs to reduce manual processes managing patient-provided data.

The HL7 CDA Consolidation Documents types only address provider-initiated documents and do not incorporate guidance for patient-generated documents. It is necessary to create a new implementation guide describing how to incorporate patient-generated input. In many cases, existing templates within the current Consolidation Template Library can be re-used with minimal modification.

The scope of this project is to create an implementation guide, which will guide the users on using the elements of the C-CDA consolidation header for patient authored documents. New CDA document types for patient authored documents is NOT in scope for this project. The document described by this guide could be characterized as a parallel to Consolidated CDA, that would ultimately cover specific patient-authored document types. We anticipate that Consolidated CDA templates will be heavily reused. If required, we may extend the project scope or introduce another project for defining an implementation guide for a set of patient authored document types.

HL7 Project Scope

  • HL7 Project Scope Statement (approved June 07, 2012 by SDWG, pending review/approval by Steering Division and TSC):

http://wiki.hl7.org/images/4/4c/HL7_Project_Scope_Statement_v2012_Patient_authored_notes.docx

Subgroup Members

  • Virinder Batra, Intuit Health
  • Lisa Nelson, Life Over Time Solutions
  • Elaine Ayres, Academy of Nutrition and Dietetics, National Institutes of Health
  • Catherine Welsh, St. Jude Children's Research Hospital
  • Bob Dolin, Lantana Consulting
  • Emma Jones, Allscripts
  • Shawn Meyers, Healthwise
  • Brian Scheller, Healthwise
  • Chris Schultz, Child Health & Development Interactive System (Chadis)
  • Gordon Raup, Datuit
  • Vinayak Kulkarni, Siemens Healthcare
  • Jessi Formoe, Intuit Health
  • Leslie Kelly Hall, Healthwise
  • Kevin Harbauer,Healthwise
  • Allen Traylor, Child Health & Development Interactive System (Chadis)
  • Stephen Chu, National e-health Transition Authority (Nehta), Australia,
  • Vin Sekar, National e-health Transition Authority (Nehta), Australia

Meeting Logistics

Meeting Schedule

Meeting Agendas

Meeting Minutes











Deliverable Timelines

  • Notice of ballot in September 2012
  • Word document (Implementation Guide) by Dec 1, 2012
    • Ballot Package Submitted on December 07
  • Ballot in WG Meeting in Phoenix January, 2013
    • Reconciliation in Structure WG, Q4 in Phoenix

Use Cases

Discussion on Document LOINC Code

Discussion on Header Attributes

Discussion on Value Sets

  • Code System: HL7 ParticipationType 2.16.840.1.113883.5.90
    • ParticipationType Value Set: ParticipationType 2.16.840.1.113883.1.11.10901
  • CodeSystem: NUCC Health Care Provider Taxonomy 2.16.840.1.113883.6.101

Implementation Guide History of Development


Narrative Components Developed and Incorporated into the Implementation Guide

FINAL Implementation Guide and Sample Documents

  • Package Submitted for January 2013 Ballot: File:PAN Document Header IG.zip Includes IG and two (2) Patient Authored Note Document Samples
  • Package Submitted for January 2013 Ballot: File:PGD IGLineNum.zip Includes IG and two (2) Patient Authored Note Document Samples

Ballot Comments and Reconciliation

















Revised PGD Header IG to incorporate Ballot Comment Resolutions










Processing session 20130730 - versions to show incorporating of the revision to DocumentationOf/ServiceEvent

Revised PGD Header Sample Documents



  • Sample #2A - US Realm - Patient Relation for the Patient



  • Sample #1B - UV Realm - Patient for Self
  • Sample #2B - UV Realm - Patient Relation for the Patient

Other Documents



FINAL PACKAGE SUBMITTED TO SDWG

Open Issues & Tasks

  • Confirm associated Errata get addressed in C-CDA v2 (DSTU #227, #228)

Comments and Errata

NOTE: US Realm PGDH template is maintained in C-CDA. Only UV Realm errata issues are recorded here.


DATE CONF# Name Summary of Issue Existing Wording Proposed Wording Comments
Date reported 9045 Example Person Short problem statement This text is how the issue is currently documented in the IG This text is the proposal for how the issue could be documented differently in the IG This is why the issue is important or tells why the proposed wording is beneficial
10/25/2015 n/a Brian Reinhold Author Issue As discussed in today’s meeting here is a reminder about the issue of trying to move the following constraint from the ‘printed’ document to Trifolia.

The printed document has

1. When the author is a person, this assignedAuthor SHALL contain one [1..1] code (NEWCONF:xxxxx).
a. The code, SHALL contain exactly one [1..1] @code, which SHOULD be selected from the Personal And Legal Relationship Role Type 2.16.840.1.113883.11.20.12.1 (NEWCONF:xxxxx)

The item is a conditional and the only way it could be entered in Trifolia was to place the code requirement as a primitive of the assignedAuthor element, and the code@code requirement as a primitive of the primitive. To use the code element in Trifolia would require setting the code to either MAY, SHOULD, or SHALL. The closest match in content using the Trifolia code element would be the MAY.
The downside of using the primitive is that is occurs last in the hierarchy when printed and not in the sequence order as required by the schema.

Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.