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

Data Access Framework (DAF) FHIR Implementation Guide(s)-Research Project ID: TSC Notification Informative/STU to Normative Date :

Check this box when the project proceeds from Informative to Normative or STU to Normative status. Forward to the TSC for notification, as this triggers American National Standards Institute (ANSI) Project Initiation Notification (PINS) submission.

Investigative Project Date : Check this box when the project is investigative or exploratory in nature, which allows limited project scope definition. Sections in bold outline are mandatory for project approval of an investigative project; all other sections are optional. (Sections 1, 2, 3a, 3b, 3g [limited, 6b [if known], and 6c [applicable] are required). Investigative Project specific instructions are yellow highlighted.An investigative project must advance in two WGM cycles, requiring a full scope statement. Otherwise the project will be closed.

2. Sponsoring Group(s) / Project Team2.a.Primary Sponsor/Work Group

Primary Sponsor/Work Group (1 (And Only 1) Allowed)

FHIR Infrastructure WG

2.b.Co-sponsor Work Group(s) Co-sponsor Work Group(s)(Enter co-sponsor approval dates in Section 6.c Project Approval Dates)

To be Requested:*RCRIM (Regulated Clinical Research Information Management)/BRIDG (Biomedical Research Integrated Domain Group)*InM (Infrastructure and Messaging)* Interested Parties: CDS and CQI WGs

Indicate the level of involvement that the co-sponsor will have for this project:X Request formal content review prior to ballot

Request periodic project updates. Specify period: Monthly, at WGMs, etc. Other Involvement. Specify details here: Enter other involvement here

2.c.Project TeamProject facilitator (1 Mandatory) Jonathan Coleman (jc@securityrs.com)Other interested parties and their roles The Office of the National Coordinator for Health IT (ONC)

Standards & Interoperability (S&I) Framework POCs: Mera Choi (mera.choi@hhs.gov), United States Food and Drug Administration (FDA) POCs: Mary Ann Slack (maryann.slack@us.fda.gov), United States National Cancer Institute (NCI) POCs: Ed Helton (heltone2@mail.nih.gov), The Clinical Data Interchange Standards Consortium (CDISC) POCs: Lauren Becnel (lbecnel@cdisc.org) and Rebecca Kush (rkush@cdisc.org), International Standards Organization POCs: Mike Glickman (mglickman@cnainc.com)

Multi-disciplinary project team (recommended)Modeling facilitator Dragon (Nagesh) Bashyam (nagesh.bashyam@drajer.com),

document.docx 2016 Release Page 1 of 6© 2023 Health Level Seven® International.  All rights reserved

Brett Marquard (brett@riverrockassociates.com)Publishing facilitator Lloyd McKenzie (lloyd@lmckenzie.com)Vocabulary facilitator Rob Hausam (russellhamm@gmail.com); Julie James Domain expert rep Shelley Rusincovitch (shelley.rusincovitch@dm.duke.edu),

Daniella Meeker (dmeeker@usc.edu); Lauren Becnel (lbecnel@cdisc.org)

Business requirement analyst Dragon (Nagesh) Bashyam (nagesh.bashyam@drajer.com)Conformance facilitator (for IG projects) Lloyd McKenzie (lloyd@lmckenzie.com)Other facilitators (SOA, etc)

Implementers (2 Mandatory for STU 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) Regulated clinical researchers1) REACHNet CDRN for PCORnet2) Global regulatory electronic data submissionss2) pSCANNER CDRN for PCORnet3) REACHNet CDRN for PCORnet4) pSCANNER CDRN for PCORnet

3. Project Definition3.a.[2.d.] Project Scope

This updated DAF project scope statement is to 1. Update existing DAF IG based on feedback from Argonaut 2. Updates to account for FHIR STU changes[3.] Map for 2015 CCDS data elementsProvide a set of global resources for regulated clinical research and non-

regulated clinical and translational research[4.] Propose new resources or modifications to resources to enable clinical and translational rResearcher’s’ access to

data. 3. New resources are not limited to Patient centered Outcomes Research DAF pilots. New resources will

be harmonized with the BRIDG model. 4. New resources will be harmonized with the BRIDG Model.5.

This project aims to create Fast Healthcare Interoperability Resources (FHIR) Profiles for access to discrete ONC 2014 S&CC, ONC 2015 S&CC data elements data stored in electronic health records, administrative claims, registries and other systems as FHIR resource instances. The access will be for both care delivery and for research purposes. It is not the intention of this project to create new FHIR resource or content profile if one already exists for the various use cases, but work with resource profile owners if necessary. The project intends to use the defined FHIR security methods along with SMART on FHIR security protocols that are published.

Artifacts to be produced as part of this project include:1. Define/Update profiles on selected FHIR resources that define additional search criteria, supported flags, value

sets for retrieving those resources.2. Define a Conformance Resource instance that defines expected system behavior on server side and/or client side

for DAF conformant systems. Project expects multiple conformance resources based on the requirements for care delivery and clinical and translational research use cases.

3. Define DAF implementation guide(s) that organizes and provides context for the above artifacts.

3.b.[2.e.] Project NeedInternational regulated and non-regulated research increasingly relies upon data from electronic health records (e.g., medicalelectronic health records, patient reported outcomes databases, administrative claims, registries, etc.). Multiple standards model regulated clinical research, non-regulated clinical and translational research and their touchpoints to healthcare IT systems. The Clinical Data Interchange Standards Consortium (CDISC) has developed a portfolio of standards

document.docx 2016 Release Page 2 of 6© 2023 Health Level Seven® International.  All rights reserved

and terminologies that are required for electronic submissions to the US Food and Drug Administration (FDA) and Japan’s Pharmaceuticals and Medical Devices Agency (PMDA). The Biomedical Research Integrated Domain Group (BRIDG) model represents semantics of the entire biomedical domain and its stakeholders include CDISC, along with the FDA, US National Cancer Institute (NCI), Health Level Seven7 Inc (HL7) and the International Standards Organization (ISO). Other standard models from the community include FDA’s Sentinel Common Data Model, Observational Medical Outcomes Partnership (OMOP) Common Data Model, and Patient Centered Outcome Research (PCOR) Network’s model and Informatics for Integrating Biology and the Bedside (i2b2).

There is an increasing burden on researchers to consume and submit data in multiple formats, using different semantics to different federal agencies. As such there exists a major opportunity to harmonize standard biomedical and health models’ semantics to create a single, unified set of standard resources supporting semantic and syntactic interoperability among diverse research and health IT systems.

A unified approach will reduce barriers to adoption and serve myriad use cases ranging fromThe nation is reaching a critical mass of Health IT systems (EHRs, Data Warehouses etc.) that comply with data and vocabulary standards. The wide deployment of Health IT systems has created unique opportunities for providers, provider support teams, healthcare professionals and organizations etc. to access and use the patient data that is already collected during clinical workflows. While the Health IT systems provide many access paths through their pre-defined interactions between a user and the system, they are limited in their support for data queries, APIs, or services to access data sets as needed. Where Health IT systems provide data access, they likely do not use industry standard access methods. Increasing support for this class of data access, using industry standards, would enable other applications to expand the ability of users to create value out of their data without having to rely on the predefined access paths. Allowing access to this data by researchers, can enable a provider to further analyzeanalysis of the collected data by providers to understand a patient’s overall health, interrogation of the data for population health trends and safety signal detectionthe health of a provider’s collective patient population, and use the data to power innovative new applications and tools to take more efficiently translate research and provide better improved care of patients and populations.

The Data Access Framework (DAF) is standardizing how data can be accessed within an organization from disparate systems (called as Local DAF) and how data can be accessed from external organizations (called as Targeted DAF) and from multiple external organizations (called as Distributed DAF). The data will be accessed by providers and researchers for care delivery and research purposes.

DAF Data Elements, Resources, Profiles and IG:

DAF has developed a list of data elements starting from ONC 2014 S&CC and ONC 2015 S&CC which are expected to be retrieved using APIs and queries. These data elements include problems, medications, allergies, patient demographics among others. DAF will be specifying the Query parameters that must be supported for each FHIR resource representing the data elements. In addition DAF may constrain cardinality and vocabularies on FHIR resources being returned as part of the Query Result.

Over 80% of the DAF data element needs are covered in the existing FHIR DSTU and the existing DAF FHIR profiles. However a small number of resources and profiles would be required to enable diverse researcher workflows for Patient Centered Outcome Research (PCOR) activities. Work will begin shortly to harmonize BRIDG, OMOP, PCORNet, i2b2 and Sentinel models; BRIDG and OMOP have been mapped previously. BRIDG and PCORNet The work that has been completed in mapping existing PCOR data models have also been mapped to FHIR. As identifies these new resources are identified from these mappings, and they would be proposed to HL7 FHIR Infrastructure WG.

Further there has been feedback from the industry vendors working on Argonaut project on the FHIR profiles and concepts that DAF has used in the previous IG, so the IG would be updated to reflect this feedback.

3.c.[2.f.] Security RisksWill this project produce executable(s), for example, schemas, transforms, style sheets, executable program, etc. If so the project must review and document security risks.

YesX No

Unknown

document.docx 2016 Release Page 3 of 6© 2023 Health Level Seven® International.  All rights reserved

3.d.[2.g.] External DriversInternational common standard models and resources are needed by the research community. Pilot implementations (e.g., from PCORNet’s REACHnet & pSCANNER projects) are underway providing feedback on the IG and resource profiles which will be used to inform the IG creation.

3.e.[2.h.] Project Objectives / Deliverables / Target DatesTarget Date

Submit for Ballot 2016 SeptemberComplete Ballot Reconciliation 2016 NovemberSubmit Publication Request 2016 December

3.f.[2.i.] Common Names / Keywords / AliasesBRIDG, CDISC, DAF, DAF FHIR IG, DAF FHIR profiles, DAF Data Element Access, FDA, HL7, ISO, NCI, OMOP, PCORNet, Sentinel and i2b2.

3.g.[2.j.] LineageN/A

3.h.[2.k.] Project DependenciesN/A

3.i.[2.l.] Project Document Repository LocationURL where requirements will be documented: http://wiki.siframework.org/Data+Access+Framework+Homepage FHIR's SVN repositoryFHIR gForge or Replacement Tracking Tools

3.j.[2.m.] Backwards CompatibilityAre the items being produced by this project backward compatible?

Yes No X Unknown N/A

For V3, are you using the current data types? (Refer to TSC position statement on new projects using R2B for more information on the current V3 data types)

Yes No Unknown X N/A

If you check 'No' please explain the reason:

If desired, enter additional information regarding Backwards Compatibility.

3.k.[2.n.] External VocabulariesWill this project include/reference external vocabularies?

X Yes No Unknown N/A

If yes, please list the vocabularies: (CDISC, NCI-EVS Metathesaurus, SNOMED-CT, LOINC, CPT-4, ICD-10, LOINC, Misc. Biomedical Vocabularies, RxNorm, SNOMED-CT, UCUM etc.)

4.[3.] Products (check all that apply)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 - KnowledgeElectronic Health Record (EHR) Functional Profile V3 Foundation – RIMLogical Model V3 Foundation – Vocab Domains & Value SetsV2 Messages – Administrative V3 Messages - AdministrativeV2 Messages - Clinical V3 Messages - ClinicalV2 Messages - Departmental V3 Messages - DepartmentalV2 Messages – Infrastructure V3 Messages - Infrastructure

X FHIR Implementation Guide V3 Rules - GELLOX FHIR Profiles V3 Services – Java Services (ITS Work Group)X FHIR Resources V3 Services – Web Services (SOA)

document.docx 2016 Release Page 4 of 6© 2023 Health Level Seven® International.  All rights reserved

New/Modified/HL7 Policy/Procedure/Process White PaperNew Product DefinitionNew Product Family

If you checked New Product Definition or New Product Family, please define below:

5.[4.] Project Intent (check all that apply)Create new standard Supplement to a current standard

X Revise current standard (see text box below) X Implementation Guide (IG) will be created/modifiedReaffirmation of a standard Project is adopting/endorsing an externally developed IG:New/Modified HL7 Policy/Procedure/Process Specify external organization in Sec. 6 below;Withdraw an Informative Document Externally developed IG is to be (select one):White Paper (select one): Adopted - OR - Endorsed

Balloted Informative OR

Non-balloted WG White Paper

N/A (Project not directly related to an HL7 Standard)

If revising a current standard, indicate the following:- Name of the standard being revised : FHIR- Date it was published : N/A- Rationale for revision : Allow Researcher access to data

5.a.[4.a.] Ballot Type (check all that apply)Comment (aka Comment-Only) Joint Ballot (with other SDOs)Informative N/A (project won’t go through ballot)

X STU to Normative - OR - Normative (no STU)If necessary, add any additional ballot information here. If artifacts will be jointly balloted with other SDOs, list the other groups.

5.b.[4.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? Yes X No

6.[5.] Project Logistics6.a.[5.a.] External Project Collaboration

CDISC, FDA, HL7, ISO, NCI, ONC, PCORnet grantees for piloting the standards.For projects that have some of their content already developed:How much content for this project is already developed? 30 %Was the content externally developed (Y/N)? Y PCORnet CDRNs (REACHnet,

pSCANNER), PopMedNetIs this a hosted (externally funded) project? (not asking for amount just if funded) X Yes No

6.b.[5.b.] RealmUniversal - OR - X Realm Specific

X Check here if this standard balloted or was previously approved as realm specific standard

U.S Realm IG

6.c.[5.c.] Project Approval DatesAffiliate Approval Date (for Affiliate Specific Projects): Affiliate Approval Date CCYY-MM-DD or

indicate “N/A”US Realm Steering Committee Approval Date (for US Realm Specific Projects):

USRSC Approval Date CCYY-MM-DD or indicate “N/A”

Sponsoring Work Group Approval Date: WG Approval Date CCYY-MM-DDCo-Sponsor Group Approval Date(Copy this entire row for each co-sponsor; indicate the specific cosponsor that issued approval)

Co-Sponsor Approval Date CCYY-MM-DD

FHIR Project: FHIR Management Group Approval Date: FMG Approval Date CCYY-MM-DD or “N/A”document.docx 2016 Release Page 5 of 6

© 2023 Health Level Seven® International.  All rights reserved

Architectural Review Board Approval Date: ARB Approval Date CCYY-MM-DD or “N/A”Steering Division Approval Date : SD Approval Date CCYY-MM-DD

Last Work Group Health: Green Yellow RedPBS Metrics and Work Group Health Reviewed? (required for SD Approval if not green) Yes No

Technical Steering Committee Approval Date: TSC Approval Date CCYY-MM-DDTSC has received a Copyright/Distribution Agreement (containing the verbiage outlined within the SOU), signed by both parties. Yes No N/A

6.d.[5.d.]

document.docx 2016 Release Page 6 of 6© 2023 Health Level Seven® International.  All rights reserved