Fdasia taxonomy subgroup
Download
1 / 44

FDASIA Taxonomy Subgroup - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

FDASIA Taxonomy Subgroup. HIT Policy Committee FDASIA Workgroup On Site Meeting 30 May 2013. Subgroup Co-Chairs. Patti Brennan Meghan Dierks. 1. Charge 1 Charge, Anticipated Output of Subgroup. Taxonomy Sub group.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' FDASIA Taxonomy Subgroup' - mandell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Fdasia taxonomy subgroup
FDASIA Taxonomy Subgroup

HIT Policy Committee

FDASIA Workgroup On Site Meeting

30 May 2013


Subgroup co chairs
Subgroup Co-Chairs

  • Patti Brennan

  • Meghan Dierks


Charge 1 charge anticipated output of subgroup

1

Charge 1Charge, Anticipated Output of Subgroup


Taxonomy sub group
Taxonomy Subgroup

To identify the scope of Health IT that should be consideredor included in deliberation by the full workgroup

… as the full workgroup develops strategy and recommendations on an appropriate, risk-based regulatory framework for health IT that promotes innovation, protects patient safety, and avoids unnecessary and duplicative regulation.

Charge – Anticipated Output


Taxonomy sub group1
Taxonomy Subgroup

To identify the scope of Health IT that should be consideredor included in deliberationby the full workgroup

Taxonomy subgroup scope not to be interpreted as being the final recommendation for what is to be regulation

Charge – Anticipated Output


Charge 2 statutory definitions

2

Charge 2Statutory Definitions


Statutory definitions
Statutory Definitions

The term “health information” means any information, whether oral or recorded in any form or medium, that—

(A) is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and

(B) relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual.

Health Information [ SSA § 1171(4); 42 U.S.C. 1320d]


Statutory definitions1
Statutory Definitions

“The term ‘health information technology’ means hardware, software, integrated technologies or related licenses, intellectual property, upgrades, or packaged solutions sold as services that are designed for or support the use by health care entities or patients for the electronic creation, maintenance, access, or exchange of health information.”

Health Information Technology [ HITECH Act (2009) ]


Statutory definitions2
Statutory Definitions

” … an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,

intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes."

Medical Device [ Federal Food, Drug and Cosmetic Act 21 CFR 800 -1299 ]


Scope options

3

Scope Options


Scope options considered
Scope Options Considered

EXISTING TECHNOLOGY FOCUS: Explicitly limit scope to existing, named types or categories of Health IT

EXCLUSIONARY FOCUS: Explicitly exclude named types of Health IT as Not-in-Scope; assume all else is In-Scope

PRESCIPTIVE/INCLUSIONARY FOCUS: Explicitly include named types of Health IT as In-Scope, assume all else is Out-of-Scope


Scope options considered1
Scope Options Considered

STATUTORY DEFINITION FOCUS: Explicitly state the scope as any software useable by patients or providers to create, maintain, access, or exchange health information

Explicitly exclude from scope products that meet definition of medical device, hence fall under existing regulatory framework


Scope options considered2
Scope Options Considered

USER TYPE FOCUS: Create a scope based on user type

FUNCTIONALITY/INTENDED USE FOCUS: Create a scope where scope driven by Health IT’s functionality and intended use

RISK-HARM FOCUS: Create a scope based on potential for injury or harm with failures, malfunctions, foreseeable misuse


Organizing principles

4

Organizing Principles


Organizing principles1
Organizing Principles

  • Platform agnostic

    • e.g., Scope is not defined by

      • ‘Wireless’/wired

      • Mobile/fixed

      • Installed versus Software as a Service (SaaS)

  • Avoid creating list of specific examples

    • Attempt to define generically

    • For product categories – focus on functions/intended use


Organizing principles2
Organizing Principles

  • Part-Whole:

    • If ‘component’ or part is in-scope, the whole is in scope


Scope dimensions considered
Scope Dimensions Considered

  • Product Categories

  • User Type

  • Developer/ ‘Manufacturer’ Type

  • Phases of product lifecycle

  • Conditions of use


  • Scope dimensions considered1
    Scope Dimensions Considered

    • Product Categories

  • User Type

  • Phases of product lifecycle

  • Developer/ ‘Manufacturer’ Type

  • Distribution Model

  • Conditions of use


  • Scoping

    5

    Scoping


    User types
    User Types

    In Scope

    Potentially Out of Scope

    • Health Care Providers – institutional and individual

    • Clinical Researchers using on human subjects

    • Patients under care by a provider

    • General public user/consumer under own use/health management


    Product lifecycle
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase: use of risk-mitigating design controls, standards, requirements, documentation, labeling

    • Implementation-Installation: Configuration mgmt, interfacing with other systems, interoperability as systems-of-systems


    Product lifecycle1
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase

    • Implementation-Installation

    • Maintenance: Routine updates/upgrades, performance tuning, defect and safety-related corrective, enhancements and Δbase functionality, customers who


    Product lifecycle2
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase

    • Implementation-Installation

    • Maintenance

    • Recall: Managing entire install base (vs. index customer), maintaining configuration log


    Product lifecycle3
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase

    • Implementation-Installation

    • Maintenance

    • Recall

    • End-of-Life Support: De-installation of out-dated or standards non-conforming product


    Product lifecycle4
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase

    • Implementation-Installation

    • Maintenance

    • Recall

    • End-of-Life Support

    • Cybersecurity: Control of PHI, assuring protection against malware-based risks


    Product lifecycle5
    Product Lifecycle

    In Scope

    Potentially Out of Scope

    • Design phase

    • Implementation-Installation

    • Maintenance

    • Recall

    • End-of-Life Support

    • Cybersecurity

    • Methods and modes of end-user training


    Developer manufacturer types
    Developer/ ‘Manufacturer’ Types

    In Scope

    Potentially Out of Scope

    • Entity who develops/markets/licenses/distributes products with commercial interest

    • Healthcare provider (institutional or individual provider) who develops products de novo for use on patients, even if no direct or indirect commercial interest

    • Healthcare provider (institutional or individual provider) who modifies functionality of previously licensed, ‘finished’ products


    Developer manufacturer types1
    Developer/ ‘Manufacturer’ Types

    In Scope

    Potentially Out of Scope

    • Independent entity who develops/ advertises/distributes via public channel products intended for general public users, even if no commercial interest


    Developer manufacturer types2
    Developer/ ‘Manufacturer’ Types

    In Scope

    Potentially Out of Scope

    • Entity who develops/markets/licenses/distributes products with commercial interest

    • Healthcare provider (institutional or individual provider) who develops products de novo for use on patients, even if no direct or indirect commercial interest

    • Healthcare provider (institutional or individual provider) who modifies functionality of previously licensed, ‘finished’ products

    • Independent entity who develops/ advertises/distributes via public channel products intended for general public users, even if no commercial interest

    • Individuals who develop for personal private use

    • Individual who develops/distributes via private channel to limited individuals without commercial interest

    • Independent non-commercial developers who advertise/distribute via public channel products intended for general public users


    Distribution model
    Distribution Model

    In Scope

    Potentially Out of Scope

    • Marketed/licensed/distributed/sold in a restricted manner, with credentialing requirements

    • Marketed/licensed/distributed/sold in a restricted manner, without credentialing requirements

    • Made available for download via an unrestricted public channel, with or without credentialing requirements

    • Available under a SaaS model


    General conditions of use
    General Conditions of Use

    In Scope

    Potentially Out of Scope

    • Intended use

    • Foreseeable misuse

    • Non-foreseeable, willful misuse

    • Use clearly beyond labeled intended use


    General conditions of use1
    General Conditions of Use

    In Scope

    Potentially Out of Scope

    • By prescription, recommendation or under direction of licensed/credentialed healthcare provider

    • Independently by general public consumer/user

    • For management of defined illness or chronic condition

    • ? For health maintenance


    Specific product types categories
    Specific Product Types - Categories

    In Scope

    Potentially Out of Scope


    Decision tree approach
    Decision Tree Approach

    Functionality – Intended Use – Potential for Harm


    Diagram
    Diagram

    Does product currently meet FDA (Act 21 CFR) definition of Medical Device (including MDDS)

    ?

    NO

    Potentially in-scope

    YES

    Out-of-scope …

    defer to existing regulatory framework


    Diagram 2
    Diagram 2

    • Does malfunction, foreseeable misuse have

    • potential to cause patient injury, via:

    • Delay or failure to present clinical data/

    • information at time of need

    • Presentation of outdated information

    • Patient-data mismatch ?

    YES

    Potentially in-scope

    NO

    Potentially out-of-scope


    Diagram 3
    Diagram 3

    Is the data/information that is managed by system the sole or 1o source of data at point of care (i.e., no alternate sources of data /info that can be used for confirmation) ?

    YES

    Potentially in-scope

    NO

    Potentially out-of-scope


    Diagram 4
    Diagram 4

    Through design and intended use, is patient or provider reliant on data/information to initiate or modify prescribed intervention or tx ?

    YES

    Potentially in-scope

    NO

    Potentially out-of-scope


    Diagram 5
    Diagram 5

    Through design and intended use, is patient or provider reliant on alerting or function about a change in clinical status and/or a need to initiate or modify tx ?

    YES

    Potentially in-scope

    NO

    Potentially out-of-scope


    Products types categories
    Products Types - Categories

    In Scope

    Out of Scope

    • Claims processing

    • Health benefit eligibility

    • Practice management / Scheduling / Inventory management

    • Healthcare provider communication tools (e.g., email, paging)

    • Population management tools

    • Software using historical claims data to predict future utilization/cost of care

    • Cost effectiveness analytic software


    Products types categories1
    Products Types - Categories

    In Scope

    Out of Scope

    • Diseases severity scoring algorithms

    • Electronic guideline distribution

    • Disease registries


    Products types categories2
    Products Types - Categories

    In Scope

    Out of Scope

    • EHRs (installed, Saas)

    • Hospital Information Systems-of-systems

    • Decision support algorithms

    • Visualization tools for anatomic, tissue images, medical imaging and waveforms

    • ? Health Information Exchanges

    • Electronic/robotic patient care assistants

    • Claims processing

    • Health benefit eligibility

    • Practice management / Scheduling / Inventory management

    • Healthcare provider communication tools (e.g., email, paging)

    • Population management tools

    • Software using historical claims data to predict future utilization/cost of care

    • Cost effectiveness analytic software

    • Diseases severity scoring algorithms

    • Electronic guideline distribution

    • Disease registries



    Words of caution
    Words of Caution

    To meet future undefined needs, avoid the list, and favor the decision tree approach


    ad