NOTE: To use Track Changes, turn off “protection” by clicking on (pre-MS Word 2007) Tools > Unprotect Document or (MS Word 2007 and higher) Review > Protect Document.

PSS-Lite/Investigative Projects: Sections surrounded by a BOLD OUTLINE must be completed for approval of "Investigative Projects" (a.k.a PSS-Lite).

1.  Project Name and ID

Unique Device Identifier (UDI) Implementation Guidance Requirements / Project ID:
TSC Notification Informative/DSTU to Normative Date : September 3, 2015
Investigative Project Date :

2.  Sponsoring Group(s) / Project Team

Primary Sponsor/Work Group (1 Mandatory) / Orders and Observations Work Group
Co-sponsor Work Group(s)
Co-Sponsor Group Approval Date / Healthcare Devices Work Group – 17-Dec-2015
Structured Documents Work Group – 12-Nov-2015
Financial Management Workgroup
Healthcare Standards Integration Workgroup – 17-Dec-2015
Mobile Health Workgroup
Attachment Workgroup
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period: / To be determined by workgroup
Other Involvement. Specify details here:
Project Team:
Project facilitator (1 Mandatory) / MaryKay McDaniel, Cognosante
Hans Buitendijk, Cerner
Other interested parties and their roles / Mary (from GS1)
Multi-disciplinary project team (recommended)
Modeling facilitator / Patrick Loyd
Publishing facilitator
Vocabulary facilitator
Domain expert rep / John Rhoads, Todd Cooper, Terrie Reed, Behnaz Minaei, Durwin Day, Laurie Burckhardt, Gay Dolin, Martin Rosner
Business requirement analyst / Paul Knapp, Knapp Consulting
Conformance facilitator (for IG projects)
Other facilitators (SOA, SAIF)
Implementers (2 Mandatory for DSTU projects)
FHIR Project Note: The implementer requirement will be handled by the “balloting” project. Therefore work groups do not fill out the above section. However, feel free to list implementers specific to your work group’s resources if you know of any.
1)
2)

3.  Project Definition

3.a. Project Scope

With the introduction of the Unique Device Identifier (UDI) it is important to enable health IT to exchange the UDI with or without individual components to provide access to implantable device lists, support post market surveillance, perform recalls, provide clinical decision support, and analysis/research. Exchange across the device ecosystem needs to be enabled for manufacturing, utilization, implanting, monitoring, reporting and other administrative and clinical uses (e.g., inventory, invoicing, pricing, and/or other financial transactions).
HL7 embarked on an effort to ensure the UDI string, at a minimum, is represented in V2, V3, and FHIR such that implementation guide and profile developers can provide the necessary guidance for the specific use cases of how to apply the standards. This resulted in a white paper, dated November 13, 2014, published by HL7 as “Harmonization Pattern for Unique Device Identifiers”.
HL7 needs to develop further guidance as well, in coordination with other parties, to ensure there is clarity when to communicate UDI information, and if so, how given that use case.
This project aims to develop the implementation guidance that HL7 is best suited to provide in the following areas:
Phase I
·  Clarify the interpretation of barcodes used for device identification for parsing:
o  There are a number of formats used globally, that contain device identification information.
o  Provide input into the consideration of the development of a canonical format that can improve consistency of representation across the variety of AIDC or HRF formats (derived from, e.g., a barcode or RFID) currently in play. (Phase II)
o  Establish or reference already developed parsing profiles
·  Update the Harmonization Pattern for Unique Device Identifier with the latest understanding of what string and UDI components to communicate.
o  Publish the update according to HL7 processes appropriate to this kind of document.
·  Address the emerging requirement to send individual UDI components along within the barcode’s data string to enable downstream applications to not have to parse the data string.
o  Determine whether and, if so, how to address this in a C-CDA document that currently does not provide explicit support for that.
Phase II
·  Establish and document use cases for those interactions in the diagram below, that address monitoring, procedural, therapeutic, diagnostic, implantable, and personal device use, that are best suited using HL7 messages, documents, resources.
o  Coordinate with IHE, X12, and JIC as appropriate through the appropriate liaisons.
·  Establish an inventory of available standards/guidance, as well as gaps, to determine where we need to make choices, clarify rationale to use one or another, or create new standards/guidance.
o 

·  Prioritize use cases and create one or more projects to develop the implementation guidance that is agreed to.
o  Guidance may take the form of targeted instructions on how to convey the UDI that others may incorporate in their guides and/or full implementation guides for the use case at hand.
o  Of special consideration is the need to provide guidance that is both C-CDA R2.1 valid and that also meets the emerging UDI requirements to convey individual UDI elements.
·  Harmonize V2, V3, and FHIR implementation guides across HL7 and IHE.
o  When to send string vs. discrete fields, particularly in reporting.
o  Consistent use of fields.
Known data requirements to consider for transmission: Move to working document.
·  Implantable Devices
o  Indication that procedure involves implant/explant
o  Implant List
§  Full List
§  Items/Procedural as they occur
§  Historical / Partial
o  Information beyond UDI that is needed.
§  Implanted by: The provider system of record who originally reported the Implant (where the procedure to implant happened) (Perhaps the NPI of the provider should be included as well)
§  Device Model – Part of UDI
§  Brand name
§  Labeler/manufacturer
§  Device Type (GMDN and/or SNOMED)
§  Device Description
§  Catalog (optional)
§  Explant Data
§  Implant Date
§  Etc. (this list subject to change)
·  What MRI safety information does the labeling contain?; and
·  Device required to be labeled as containing natural rubber latex or dry natural rubber
o  Error handling
§  If information applied incorrectly.
·  Monitoring Devices
·  Procedural Devices
·  Therapeutic Devices
·  Diagnostic Devices including FDA definition of 510K diagnostic devices
Personal Devices

3.b. Project Need

As the FDA and other national authorities mandate the labeling of devices to include UDI and are actively promoting the use of UDI in the information chain to enable recalls, CDS, postmarket surveillance and research in general, there is an increased need to communicate UDI to enable downstream stakeholders to access that information for their purposes. A subset of that information exchange needs to be consistently defined at a national if not global level to ease exchange.

3.c. Success Criteria

Creation of a Domain Analysis Model and documentation of the scope, use cases, and requirements for a UDI to be used in subsequent projects to update the HL7 Standards to meet these requirements.

3.d. Project Risks

Risk Description: / Industry does not convergence on identifiers
Impact: / Critical / Serious / Significant / Low
Likelihood: / High / Med / Low
Risk Type: / Requirements / Resources / Social-Political / Technology
Risk To HL7: / Internal to HL7 / External to HL7
Mitigation Plan: / Remain engaged with relevant parties such as X12, ONC, and FDA.

3.e. Security Risks

Will this project produce executable(s), for example, schemas, transforms, stylesheets, executable program, etc. If so the project must review and document security risks. / Yes / No / Unknown

3.f.  External Drivers

Describe any external schedules or calendars which may not be known outside of the project team that are driving target dates for this project.

3.g. Project Objectives / Deliverables / Target Dates

Target Date
Establish project team under OO to meet regularly to develop requirements / January 2016
Submission of initial DAM to OO for review / 2016 January
Submit for Informative Ballot / 2016 May Ballot
Project End Date / 2016 September Ballot

3.h. Common Names / Keywords / Aliases

UDI

3.i.  Lineage

Not applicable.

3.j.  Project Requirements

Project is for the creation and documentation of the requirements for a unique device identifier.

3.k. Project Dependencies

None.

3.l.  Project Document Repository Location

http://wiki.hl7.org/index.php?title=UDI&action=edit&redlink=1

3.m.  Backwards Compatibility

Click here to go to Appendix A for more information regarding this section and FHIR project instructions.

Are the items being produced by this project backward compatible? / Yes / No / Unknown / N/A
For V3, are you using the current data types? / Yes / No
If you check 'No' please explain the reason:

3.n. External Vocabularies

Click here to go to Appendix A for more information regarding this section.

Will this project include/reference external vocabularies? / Yes / No / Unknown / N/A
If yes, please list the vocabularies:

4.  Products

Non Product Project- (Educ. Marketing, Elec. Services, etc.)
/ V3 Domain Information Model (DIM / DMIM)
Arden Syntax
/ V3 Documents – Administrative (e.g. SPL)
Clinical Context Object Workgroup (CCOW)
/ V3 Documents – Clinical (e.g. CDA)
Domain Analysis Model (DAM)
/ V3 Documents - Knowledge
Electronic Health Record (EHR) Functional Profile
/ V3 Foundation – RIM
Logical Model
/ V3 Foundation – Vocab Domains & Value Sets
V2 Messages – Administrative
/ V3 Messages - Administrative
V2 Messages – Clinical
/ V3 Messages - Clinical
V2 Messages - Departmental
/ V3 Messages - Departmental
V2 Messages – Infrastructure
/ V3 Messages - Infrastructure
FHIR Resources
/ V3 Rules - GELLO
FHIR Profiles
/ V3 Services – Java Services (ITS Work Group)
New/Modified/HL7 Policy/Procedure/Process
/ V3 Services – Web Services (SOA)
New Product Definition
New Product Family
Other products may be included as the DAM clarifies what messages, documents, and FHIR profiles need further guidance.

5.  Project Intent (check all that apply)

Create new standard
Revise current standard (see text box below)
Reaffirmation of a standard
New/Modified HL7 Policy/Procedure/Process
Withdraw an Informative Document
N/A (Project not directly related to an HL7 Standard)
/ Supplement to a current standard
Implementation Guide (IG) will be created/modified
Project is adopting/endorsing an externally developed IG: Specify external organization in Sec. 6 below;
Externally developed IG is to be (select one):
Adopted - OR - Endorsed / Endorsed
Specific standards/implementation guides to be supplemented will be discovered during the project.

5.a. Ballot Type (check all that apply)

Comment Only
Informative
DSTU to Normative
/ Normative (no DSTU)
Joint Ballot (with other SDOs or HL7 Work Groups)
N/A (project won’t go through ballot)

5.b. Joint Copyright

Check this box if you will be pursuing a joint copyright. Note that when this box is checked, a Joint Copyright Letter of Agreement must be submitted to the TSC in order for the PSS to receive TSC approval.

Joint Copyrighted Material will be produced

6.  Project Logistics

6.a. External Project Collaboration

IHE, FDA, GS1, X12, NCPDP, JIC, IEEE. HSI will help facilitate/coordinate with these organizations.
For projects that have some of their content already developed:
How much content for this project is already developed? / 0%
Was the content externally developed (Y/N)?
Date of external content review by the ARB?
Is this a hosted (externally funded) project? (not asking for amount just if funded) / Yes / No

6.b. Realm

Universal
/ Realm Specific
Check here if this standard balloted or was previously approved as realm specific standard
Team will represent device requirements globally.

6.c. Project Approval Dates

Affiliate/US Realm Task Force Approval Date
(for US Realm Specific Projects) / USRTF 2015-12-15
Sponsoring Work Group Approval Date / 2015-11-19
FHIR Project: FHIR Management Group Approval Date / FMG Approval Date CCYY-MM-DD
Steering Division Approval Date / SD Approval Date CCYY-MM-DD
PBS Metrics and Work Group Health Reviewed? (required for SD Approval) / Yes / No
Technical Steering Committee Approval Date / TSC Approval Date CCYY-MM-DD
TSC has received a Copyright/Distribution Agreement (which contains the verbiage outlined within the SOU), signed by both parties. / Yes / No

6.d. Stakeholders / Vendors / Providers

This section must be completed for projects containing items expected to be ANSI approved, as it is an ANSI requirement for all ballots

Stakeholders / Vendors / Providers
Clinical and Public Health Laboratories / Pharmaceutical / Clinical and Public Health Laboratories
Immunization Registries / EHR, PHR / Emergency Services
Quality Reporting Agencies / Equipment / Local and State Departments of Health
Regulatory Agency / Health Care IT / Medical Imaging Service
Standards Development Organizations (SDOs) / Clinical Decision Support Systems / Healthcare Institutions (hospitals, long term care, home care, mental health)
Payors / Lab / Other (specify in text box below)
Other (specify in text box below) / HIS / N/A
N/A / Other (specify below)
N/A

6.e. Synchronization With Other SDOs / Profilers

Check all SDO / Profilers which your project deliverable(s) are associated with.
ASC X12 / CHA / LOINC
AHIP / DICOM / NCPDP
ASTM / GS1 / NAACCR
BioPharma Association (SAFE) / IEEE / Object Management Group (OMG)
CEN/TC 251 / IHE / The Health Story Project
CHCF / IHTSDO / WEDI
CLSI / ISO / Other (specify below)
HL7 Project Scope Statement v2015_template_only / 2015 Release / Page 1 of 7

© 2016 Health Level Seven® International. All rights reserved