Versions Compared

Old Version 276

changes.mady.by.user Brian S. Alper

Saved on

compared with

New Version 277

changes.mady.by.user Brian S. Alper

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

On March 20, the Project Management Group revised the handling of Classification Profile ArtifactAssessment Resources for Citations to FHIR Resources on the FEvIR Platform to support display under Third-Party Classifiers in the Citation Viewer.

On March 23., the 27, the Project Management Group prepared the manuscript "Study Design Terminology in the Scientific Evidence Code System (SEVCO)" for submission to the Clinical Trials journal and continued development of creating a master index of ArtifactAssessment Resource content and Citation.citedArtifact.classification content on the FEvIR Platform. 

On March 30., the Project Management Group compiled the suggested agenda for the next 8 days:

Friday, March 2431:

  • 8 am Eastern: GRADE Vocabulary Working Group – draft GRADE concept paper
  • 9 am Eastern: Risk of Bias Terminology and Tooling Working Group – continue review and addition of terms and definitions to the Scientific Evidence Code System; attention to Reporting Bias terms
  • 10 am Eastern: Communications Working Group – review progress on publications (Study Design Terminologyarticle accepted for LHS), presentations (GIN), and website
  • 12 pm Eastern: Eligibility Criteria Working Group – Characteristic Resource modeling (valueExpression example); Cohort Definition Track for May Connectathon

Monday, March 27April 3:

  • 8 am Eastern: Project Management – review IG preparations and FHIR Trackers and IG preparations
  • 9 am Eastern: Setting the SRDR Platform on FHIR Working Group – review FEvIR™: SRDR+ Project Importer and SRDR+ progress
  • 10 am Eastern: ResearchOnFHIR Working Group – continue learning about CQL
  • 2 pm Eastern: Statistic Standard and Terminology – define draft SEVCO terms to match StatisticalModel Profile and sample size calculation example; Standard Deviation terms for SEVCO

Tuesday, March 28April 4:

  • 9 am Eastern: Scientific Knowledge Accelerator Foundation Board of Directors Measuring the Rate of Scientific Knowledge Transfer Working Group – test our method with a third RCT
  • 12 pm Eastern: FEvIR Metadata Framework Working Group – review Indexes derived from ArtifactAssessment Profiles
  • 2 pm Eastern: Research Design Working Group – prepare ‘Study Design Terminology from SEVCO’ presentation for SCT 2023 May meeting; discuss next steps for Study Design Terminology 

Wednesday, March 29April 5:

  • 8 am Eastern: Knowledge Ecosystem Liaison Working Group – determined by participants

Thursday, March 30April 6:

Friday, March 31April 7:

  • 8 am Eastern: GRADE Vocabulary Working Group – Continue GRADE Vocabulary Development Methods Protocol
  • 9 am Eastern: Risk of Bias Terminology and Tooling Working Group – continue review and addition of terms and definitions to the Scientific Evidence Code System; attention to Reporting Bias terms
  • 10 am Eastern: Communications Working Group – review progress on publications, presentations, and website
  • 12 pm Eastern: Eligibility Criteria Working Group – review of Characteristic Resource and Cohort Definition Track for May Connectathon

On March 27, the Project Management Group prepared the manuscript "Study Design Terminology in the Scientific Evidence Code System (SEVCO)" for submission to the Clinical Trials journal and continued development of creating a master index of ArtifactAssessment Resource content and Citation.citedArtifact.classification content on the FEvIR Platform. 

Knowledge Ecosystem Liaison Working Group Updates:

...

Knowledge Ecosystem Liaison Working Group Updates:

We have collaborated with several other organizations. Active and pending coordination efforts include:

...

On March 21, the Research Design Working Group prepared the final changes to the manuscript "Study Design Terminology in the Scientific Evidence Code System (SEVCO)" to prepare for submission to the Clinical Trials journal. 

On March 28, the Research Design Working Group SUBMITTED the manuscript "Study Design Terminology in the Scientific Evidence Code System (SEVCO)" to the Clinical Trials journal, and started drafting the outline for a presentation on “Reporting Study Design with the Scientific Evidence Code System (SEVCO): A novel community-reviewed standard vocabulary” to be presented May 23 in the Society for Clinical Trials (SCT) annual conference. 

Statistic Standard and Terminology Working Group Updates:

...

On March 29, the HL7 Clinical Decision Support Work Group discussed coordination between the Canonical Resource Management Infrastructure Implementation Guide and the Evidence Based Medicine Implementation Guide. Our current thinking is the CRMI IG will cover things like CanonicalComposition and CanonicalArtifactAssessment Profiles for the ‘computable’ and ‘publishable’ versions of ‘shareable’ knowledge artifacts while the EBM IG will develop numerous Profiles for different ‘scientific domain’ aspects of the ‘scientific’ knowledge artifacts.  

EBM Implementation Guide Working Group Updates:

The EBMonFHIR project is an HL7 project sponsored by the HL7 Clinical Decision Support (CDS) Work Group and co-sponsored by the HL7 Biomedical Research and Regulation (BRR) and Clinical Quality Improvement (CQI) Work Groups. The EBMonFHIR Implementation Guide Working Group is an HL7 CDS WG EBMonFHIR project sub-WG meeting to facilitate HL7 processes for standard development and further develop the EBM Implementation Guide.

The EBMonFHIR project (HL7 PSS-2124) is formally named FHIR Resources for Evidence-Based Medicine Knowledge Assets (EBM-on-FHIR) and the FHIR Management Group has approved the development of an Evidence Based Medicine Implementation Guide (EBM IG). The EBM IG repository will be maintained at https://github.com/HL7/ebm.

...

On March 30, the HL7® Biomedical Research and Regulation (BRR) Work Group reviewed the Acute Coronary Syndrome treated with oral antiplatelets example of ‘Characteristic Resource’ (for the Vulcan RWD IG Cohort Definition example) and created the Initial diagnosis of Acute Coronary Syndrome (terminology-related expression variant 2) example to demonstrate how to use an expression to define a generated value set as an alternative to creating a ValueSet Resource. In developing this model, we added Expression as a datatype to Characteristic.definitionByTypeAndValue.value[x] in the proposed Characteristic Resource StructureDefinition.

On March 30, theHL7® Clinical Decision Support (CDS) Sub-Work Groupfor LHS Connectathon Coordination set April 27 as the Track Kickoff time for the Cohort Definition Track of May 2023 FHIR Connectathon and discussed coordination of the cross-group projects with potential developments of creating a virtual space in the HL7 LHS WG Confluence page and/or re-organizing the HEvKA Summary Update to consolidate Cohort Development efforts distinct from other Standards Development efforts.

EBM Implementation Guide Working Group Updates:

The EBMonFHIR project is an HL7 project sponsored by the HL7 Clinical Decision Support (CDS) Work Group and co-sponsored by the HL7 Biomedical Research and Regulation (BRR) and Clinical Quality Improvement (CQI) Work Groups. The EBMonFHIR Implementation Guide Working Group is an HL7 CDS WG EBMonFHIR project sub-WG meeting to facilitate HL7 processes for standard development and further develop the EBM Implementation Guide.

The EBMonFHIR project (HL7 PSS-2124) is formally named FHIR Resources for Evidence-Based Medicine Knowledge Assets (EBM-on-FHIR) and the FHIR Management Group has approved the development of an Evidence Based Medicine Implementation Guide (EBM IG). The EBM IG repository will be maintained at https://github.com/HL7/ebm.

The specific Profiles will change as we learn the best modeling, but we are currently anticipating 38 Profiles of 9 Resources (see https://fevir.net/resources/Project/29736) including:

...

On March 23, the EBM Implementation Guide Working Group revised the CertaintyOfEvidence Profile of ArtifactAssessment to add back (remove the deletion of) workflowStatus and disposition elements. We then created a RiskOfBias Profile of ArtifactAssessment and, for binding to RiskOfBias.content.type, a Risk of Bias Type Value Set which is defined by ‘Include codes from https://fevir.net/sevco where concept is-a SEVCO:00001’. We limited the artifactReference element of the RiskOfBias Profile to reference Evidence, Composition, ResearchStudy, or Citation Resources. This completes the first pass of all 8 Profiles of ArtifactAssessment Resource. Next week we will start on Profiles of Evidence Resource.

Eligibility Criteria Working Group Updates:

Developments to support expression of structured eligibility criteria with FHIR include:

...

On March 30, the 

EBM Implementation Guide Working Group created and revised multiple Profiles of Evidence including:

  • ComparativeEvidence Profile
    • Description: Profile of Evidence for Evidence Based Medicine IG. The ComparativeEvidence Profile is used for evidence with a measured variable that is considered the outcome of an exposure or intervention, and an exposure and reference exposure that is being compared.
    • variableDefinition 3..* comment = "To report comparative evidence for a research question defined by Population, Intervention, Comparator, and Outcome (PICO), one would use four variableDefinition instances. In the 4-variable approach, the Population has variableRole of population, the Intervention has variableRole of exposure, the Comparator has variableRole of referenceExposure, and the Outcome has variableRole of measuredVariable. In some types of Comparative Evidence, where the groups being compared are not from the same Population (and thus not a PICO-style research question), the combination of Population and Intervention is expressed with the variableRole of exposure, the combination of Population and Comparator is expressed with the variableRole of referenceExposure, and the Outcome is expressed with the variableRole of measuredVariable. The 3-variable approach may be used for example to compare cats and dogs."
  • NonComparativeEvidence Profile
    • Description: Profile of Evidence for Evidence Based Medicine IG. The NonComparativeEvidence Profile is used for evidence about a single group with no comparisons between groups.
    • variableDefinition 2..*
  • InterventionOnlyEvidence Profile
    • Description: Profile of Evidence for Evidence Based Medicine IG. The InterventionOnlyEvidence Profile is used for evidence with a measured variable that is considered the outcome of an exposure or intervention, and an exposure that is the intervention of interest in a comparative evidence. The InterventionOnlyEvidence descirbes the evidence for the intervention group.
    • variableDefinition 2..* comment = "To report intervention-only evidence for a research question defined by Population, Intervention, Comparator, and Outcome (PICO), one would use three variableDefinition instances. In the 3-variable approach, the Population has variableRole of population, the Intervention  has variableRole of exposure, the Comparator is not included in the ComparatorOnlyEvidence, and the Outcome has variableRole of measuredVariable. In some types of InterventionOnlyEvidence, where the groups being compared are not from the same Population (and thus not a PICO-style research question), the combination of Population and Intervention is expressed with the variableRole of exposure, and the Outcome is expressed with the variableRole of measuredVariable. The 2-variable approach may be used for example to compare cats and dogs."
    • useContext 1..* with an attempt to required a useContext.code = {Coding for Program} and useContext.valueCodeableConcept.text = “intervention-only-evidence” BUT WE DID NOT GET THE IG BUILD TO WORK (NEED TO LEARN HOW TO EXPRESS THIS IN FSH)
  • ComparatorOnlyEvidence Profile
    • Description: Profile of Evidence for Evidence Based Medicine IG. The ComparatorOnlyEvidence Profile is used for evidence with a measured variable that is considered the outcome of an exposure or intervention, and an exposure that is the reference expsoure in a comparative evidence. The ComparatorOnlyEvidence descirbes the evidence for the comparator group.
    • variableDefinition 2..* comment = "To report comparator-only evidence for a research question defined by Population, Intervention, Comparator, and Outcome (PICO), one would use three variableDefinition instances. In the 3-variable approach, the Population has variableRole of population, the Intervention is not included in the ComparatorOnlyEvidence, the Comparator has variableRole of exposure, and the Outcome has variableRole of measuredVariable. In some types of ComparatorOnlyEvidence, where the groups being compared are not from the same Population (and thus not a PICO-style research question), the combination of Population and Comparator is expressed with the variableRole of exposure, and the Outcome is expressed with the variableRole of measuredVariable. The 2-variable approach may be used for example to compare cats and dogs."
    • useContext 1..* with an attempt to required a useContext.code = {Coding for Program} and useContext.valueCodeableConcept.text = “comparator-only-evidence” BUT WE DID NOT GET THE IG BUILD TO WORK (NEED TO LEARN HOW TO EXPRESS THIS IN FSH)
  • StatisticalCalculator Profile
    • Description: Profile of Evidence for Evidence Based Medicine IG. The StatisticalCalculator Profile is used for specification of the executable formula corresponding to a statistical model (for a statistical analysis plan or applied analysis)

Eligibility Criteria Working Group Updates:

Developments to support expression of structured eligibility criteria with FHIR include:

...

  • Specifying Metadata to MCBK spreadsheet defining 138 data elements for the specification of 13 metadata categories to communicate the Findability, Accessibility, Interoperability, Reusability, and Trustability (FAIR+T) of knowledge artifacts
  • Mapping the “COKA MCBK Common Metadata Framework” to multiple crosswalks of metadata schemas created by various Research Data Alliance (RDA) working groups
  • Creation of a ‘SchemaElement Resource’ structure to describe an element in any schema and map it to elements in other schema, and then
    • Creation of about 10,000 SchemaElement Resources to document portions of FHIR, ClinicalTrials.gov, and Research Information Systems (RIS) schemas and > 1,000 map elements within some of these SchemaElement Resources to document conversions between these schemas
    • Creation of 146 SchemaElement Resource instances to fully specify all the Common Metadata Framework elements, and mapping to and from 55 RIS SchemaElement Resource instances
  • Creation of a ‘Common Data Structure’ for more efficient specification of 40 datatypes for the Common Metadata Framework (most are linked from https://fevir.net/FLI/CommonDataStructureArtifact), and mappings to and from the Common Data Structure with RIS and FHIR Citation structures

We refocused this Working Group on the metadata structures used and shared on the FEvIR Platform as a real-world implementation and practical application.  An initial step was the creation of a Classification Profile of ArtifactAssessment Resource.

...

    • .gov, and Research Information Systems (RIS) schemas and > 1,000 map elements within some of these SchemaElement Resources to document conversions between these schemas
    • Creation of 146 SchemaElement Resource instances to fully specify all the Common Metadata Framework elements, and mapping to and from 55 RIS SchemaElement Resource instances
  • Creation of a ‘Common Data Structure’ for more efficient specification of 40 datatypes for the Common Metadata Framework (most are linked from https://fevir.net/FLI/CommonDataStructureArtifact), and mappings to and from the Common Data Structure with RIS and FHIR Citation structures

We refocused this Working Group on the metadata structures used and shared on the FEvIR Platform as a real-world implementation and practical application.  An initial step was the creation of a Classification Profile of ArtifactAssessment Resource.

On January 10, 2023, the Common Metadata Framework Working Group added Profiles to the developing Evidence Based Medicine Implementation Guide, including:


Classification

Profile of ArtifactAssessment for Evidence Based Medicine IG. The Classification Profile is used for classifier tags that may be created independently from Resource creators and may be used for search indexes.

ParticipantFlow

Profile of Evidence for Evidence Based Medicine IG. The ParticipantFlow Profile is used for counts of completion and reasons for non-completion of participation in a research study.

Participant Flow Measure

Profile of EvidenceVariable for Evidence Based Medicine IG. The ParticipantFlowMeasure Profile is used to describe outcome measures for completion and reasons for non-completion of participation in a research study.

The Research Design Working Group reviewed the ParticipantFlow Profile Demonstration to view examples of the ParticipantFlow and ParticipantFlowMeasure Profiles.

On January 17, 2023, the Common Metadata Framework Working Group developed proof-of-concept code in preparation for using Classification Profiles of ArtifactAssessment Resource as a search index on the FEvIR Platform.

On January 24, 2023, the Common Metadata Framework Working Group added Profiles to the developing Evidence Based Medicine Implementation Guide, including:

...

Profile of ArtifactAssessment for Evidence Based Medicine IG. The Classification Profile is used for classifier tags that may be created independently from Resource creators and may be used for search indexes.

...

ParticipantFlow

...

Profile of Evidence for Evidence Based Medicine IG. The ParticipantFlow Profile is used for counts of completion and reasons for non-completion of participation in a research study.

...

Participant Flow Measure

...

Profile of EvidenceVariable for Evidence Based Medicine IG. The ParticipantFlowMeasure Profile is used to describe outcome measures for completion and reasons for non-completion of participation in a research study.

The Research Design Working Group reviewed the ParticipantFlow Profile Demonstration to view examples of the ParticipantFlow and ParticipantFlowMeasure Profiles.

On January 17, 2023, the Common Metadata Framework Working Group developed proof-of-concept code in preparation for using Classification Profiles of ArtifactAssessment Resource as a search index on the FEvIR Platform.

On January 24, 2023, the Common Metadata Framework Working Group became the FEvIR Metadata Framework Working Group to reflect the change in focus from a generalized framework for metadata across platforms to focus on the specific metadata framework applied to the FEvIR Platform. Today we applied changes to the FEvIR Platform related to complex data operations in which data is managed as both a string and a number in inter-related contexts. In one instance, in responding to community feedback to sort Summary of Net Effect Contributions to list the benefits then the harms, we used the value of the net effect contribution (positive if benefit, negative if harm) for the sorting. We learned the data value needed to be a number for net effect calculations but needed to be a string for proper FHIR compliance when reported in a Narrative datatype for the Composition Resource. In another instance, we discovered that our data entry fields for number-type data worked fine on Google Chrome but users on Firefox were able to enter non-numeric data and have their data erased. We learned that the data input uses a string datatype (TextField data entry) even if the output is set to type='number' so we applied RegEx-based checks of the data input for use in browsers that do not handle it automatically. 

On January 31, the FEvIR Metadata Framework Working Group identified a bug in the FEvIR Platform code that was producing and interpreting profiles as a string datatype instead of an array of string datatype (in Resource.meta.profile) and applied bug fixes necessary for proper functioning of the Classification Builder/Viewer, Comment Builder/Viewer, Adaptation Builder/Viewer, and FEvIR Search tools.

On February became the FEvIR Metadata Framework Working Group to reflect the change in focus from a generalized framework for metadata across platforms to focus on the specific metadata framework applied to the FEvIR Platform. Today we applied changes to the FEvIR Platform related to complex data operations in which data is managed as both a string and a number in inter-related contexts. In one instance, in responding to community feedback to sort Summary of Net Effect Contributions to list the benefits then the harms, we used the value of the net effect contribution (positive if benefit, negative if harm) for the sorting. We learned the data value needed to be a number for net effect calculations but needed to be a string for proper FHIR compliance when reported in a Narrative datatype for the Composition Resource. In another instance, we discovered that our data entry fields for number-type data worked fine on Google Chrome but users on Firefox were able to enter non-numeric data and have their data erased. We learned that the data input uses a string datatype (TextField data entry) even if the output is set to type='number' so we applied RegEx-based checks of the data input for use in browsers that do not handle it automatically. 

On January 31, the FEvIR Metadata Framework Working Group identified a bug in the FEvIR Platform code that was producing and interpreting profiles as a string datatype instead of an array of string datatype (in Resource.meta.profile) and applied bug fixes necessary for proper functioning of the Classification Builder/Viewer, Comment Builder/Viewer, Adaptation Builder/Viewer, and FEvIR Search tools.

On February 7, the FEvIR Metadata Framework Working Group reviewed developments for the FEvIR™: Adaptation Builder/Viewer.

On February 14, the FEvIR Metadata Framework Working Group reviewed developments for the FEvIR™: Adaptation Builder/Viewer, tackling challenges in recursive processing.

On February 21, the FEvIR Metadata Framework Working Group identified the proper canonical URLs for Profiles defined by the Evidence Based Medicine Implementation Guide (http://build.fhir.org/ig/HL7/ebm/artifacts.html), added a Comment Profile to the EBM IG, and modified the FEvIR Platform (Adaptation, Classification, Comment, and Recommendation Justification Builder/Viewer tools) to use the canonical URLs in meta.profile values for corresponding Resources.

On February 28, the FEvIR Metadata Framework Working Group facilitated last-minute changes to the FHIR Build before code freeze for the R5 version, and adjusted FEvIR Platform handling of metadata pattern elements with expectations for array form in the FHIR specification. We also developed a major function gain in FEvIR™: Characteristic Viewer which now shows the details of Inclusion Criteria and Exclusion Criteria for a Characteristic Resource defined by a combination of characteristics – see https://fevir.net/resources/Characteristic/111977 for an example.

On March 7, the FEvIR Metadata Framework Working Group reviewed developments for the FEvIR™: Adaptation Builder/Viewerand refined multiple changes to the FEvIR Platform to support more efficient data entry for metadata elements (MetadataResource interface elements).

On February March 14, the FEvIR Metadata Framework Working Group reviewed developments for the FEvIR™: Adaptation Builder/Viewer, tackling challenges in recursive processing.On February 21improved the data entry for Reference datatype and applied editing and viewing of multiple MetadataResource interface elements to the Citation Builder/Viewer.  The Citation Builder/Viewer has a specialized Citation Metadata section to distinguish the metadata for the Citation Resource from the metadata for the cited artifact (which may also be a FHIR Resource).

On March 21, the FEvIR Metadata Framework Working Group thanks Bryn Rhodes for a ‘guest visit’ to help orient us to the Canonical Resource Management Infrastructure Implementation Guide and we discussed various strategies for coordinating these concepts with the Evidence Based Medicine Implementation Guide (in development) and with the FEvIR Platform.

On March 28, the FEvIR Metadata Framework Working  Group identified the proper canonical URLs for Profiles defined by the Evidence Based Medicine Implementation Guide (http://build.fhir.org/ig/HL7/ebm/artifacts.html), added a Comment Profile to the EBM IG, and modified the FEvIR Platform (Adaptation, Classification, Comment, and Recommendation Justification Builder/Viewer tools) to use the canonical URLs in meta.profile values for corresponding Resources.

On February 28, the FEvIR Metadata Framework Working Group facilitated last-minute changes to the FHIR Build before code freeze for the R5 version, and adjusted FEvIR Platform handling of metadata pattern elements with expectations for array form in the FHIR specification. We also developed a major function gain in FEvIR™: Characteristic Viewer which now shows the details of Inclusion Criteria and Exclusion Criteria for a Characteristic Resource defined by a combination of characteristics – see https://fevir.net/resources/Characteristic/111977 for an example.

On March 7, the FEvIR Metadata Framework Working Group reviewed and refined multiple changes to the FEvIR Platform to support more efficient data entry for metadata elements (MetadataResource interface elements).

On March 14, the FEvIR Metadata Framework Working Group improved the data entry for Reference datatype and applied editing and viewing of multiple MetadataResource interface elements to the Citation Builder/Viewer.  The Citation Builder/Viewer has a specialized Citation Metadata section to distinguish the metadata for the Citation Resource from the metadata for the cited artifact (which may also be a FHIR Resource).

On March 21, the FEvIR Metadata Framework Working Group thanks Bryn Rhodes for a ‘guest visit’ to help orient us to the Canonical Resource Management Infrastructure Implementation Guide and we discussed various strategies for coordinating these concepts with the Evidence Based Medicine Implementation Guide (in development) and with the FEvIR Platform.

Setting the SRDR Platform on FHIR Working Group Updates:

The Agency for Healthcare Research and Quality (AHRQ) maintains a Systematic Review Data Repository (SRDR), and efforts are underway to convert the data in this SRDR to FHIR format. The Setting the SRDR Platform on FHIR Working Group facilitates the data conversion to FHIR and collaborative developments between the SRDR-Plus Platform, the FEvIR Platform, and potentially the AHRQ Evidence-based Practice Centers (EPCs) and the CEPI Evidence Discovery and Retrieval (CEDAR) Project.

On January 9, 2023, Group continued development of a Classification Index for the FEvIR Platform, pulling Classification data from each of ArtifactAssessment Resources with Classification Profile and Citation.citedArtifact.classification element instances.

Setting the SRDR Platform on FHIR Working Group Updates:

The Agency for Healthcare Research and Quality (AHRQ) maintains a Systematic Review Data Repository (SRDR), and efforts are underway to convert the data in this SRDR to FHIR format. The Setting the SRDR Platform on FHIR Working Group facilitates the data conversion to FHIR and collaborative developments between the SRDR-Plus Platform, the FEvIR Platform, and potentially the AHRQ Evidence-based Practice Centers (EPCs) and the CEPI Evidence Discovery and Retrieval (CEDAR) Project.

On January 9, 2023, the Setting the SRDR Platform on FHIR Working Group reviewed concepts in the application of FHIR Questionnaire and QuestionnaireResponse Resources, including Questionnaire.useContext to relate the Questionnaire to a specific Project, and skip logic and nested items within the Questionnaire. We also reviewed the FEvIR™ API and Computable Publishing®: ClinicalTrials.gov-to-FEvIR Converter and discussed strategies to facilitate SRDR users to add a Project ID on the FEvIR Platform and retrieve all the project data in FHIR Resources.

On January 23, the Setting the SRDR Platform on FHIR Working Group reviewed the initial pre-release view of FEvIR™: SRDR+ Project Importer and were pleased to demonstrate retrieval of FHIR JSON content from SRDR+ in response to sending a Project ID and a SRDR+ API token.

On January 30, the Setting the SRDR Platform on FHIR Working Group confirmed the initial FEvIR™: SRDR+ Project Importer is correctly returning the SRDR project FHIR Resources as a Bundle and is limited to projects for which the user is the project owner. We discussed changes to the API response to include project id, project title, and selected project attributes. Next steps will be to convert each Resource in the Bundle to an entry on the FEvIR Platform and associated the Resources with a Project entry on the FEvIR Platform.

On February 6, the Setting the SRDR Platform on FHIR Working Group p reviewed concepts in the application of FHIR Questionnaire and QuestionnaireResponse Resources, including Questionnaire.useContext to relate the Questionnaire to a specific Project, and skip logic and nested items within the Questionnaire. We also reviewed the FEvIR™ API and Computable Publishing®: ClinicalTrials.gov-to-FEvIR Converter and discussed strategies to facilitate SRDR users to add a Project ID on the FEvIR Platform and retrieve all the project data in FHIR Resources.On January 23the Classification Profile http://build.fhir.org/ig/HL7/ebm/StructureDefinition-classification.html of ArtifactAssessment Resource and discussed how it is the optimal model for data exchange where the classification data is generated by persons other than the data being classified.  This is a common use case for SRDR+ including the project-specific screening classifications of Citations which are not project-specific. There is also a desire to share such classifications between SRDR+ and PICO Portal, so we may use this Working Group time to further develop the Classification Profile.

On February 13, the Setting the SRDR Platform on FHIR Working Group p reviewed the initial pre-release view of FEvIR™: SRDR+ Project Importer and were pleased to demonstrate retrieval of FHIR JSON content from SRDR+ in response to sending a Project ID and a SRDR+ API token.On January 30format of responses from the SRDR+ API with project data, created an example FEvIR Project Page for SRDR+ projects to define the desired output (https://fevir.net/resources/Project/112344), and wrote the specifications for a function to convert the SRDR+ API response to an individualized FEvIR Project Page linking to all the project FHIR Resources on the FEvIR Platform.

On February 20, the Setting the SRDR Platform on FHIR Working Group confirmed reviewed the initial FEvIR™: SRDR+ Project Importer is correctly returning the SRDR project FHIR Resources as a Bundle and is limited to projects for which the user is the project owner. We discussed changes to the API response to include project id, project title, and selected project attributes. Next steps will be to convert each Resource in the Bundle to an entry on the FEvIR Platform and associated the Resources with a Project entry on the FEvIR Platform.On February 6 which is still in development and with the initial release accepts an SRDR+ Project ID and API token, then creates a Project page on the FEvIR Platform with links to all the associated project data in FHIR Resources on the FEvIR Platform.  We looked at an initial project and identified improvements to apply to FHIR Questionnaire Resources for the project.

On February 27, the Setting the SRDR Platform on FHIR Working Group reviewed the Classification Profile http://build.fhir.org/ig/HL7/ebm/StructureDefinition-classification.html of ArtifactAssessment Resource and discussed how it is the optimal model for data exchange where the classification data is generated by persons other than the data being classified.  This is a common use case for SRDR+ including the project-specific screening classifications of Citations which are not project-specific. There is also a desire to share such classifications between SRDR+ and PICO Portal, so we may use this Working Group time to further develop the Classification Profile.On February 13applied changes to the FEvIR™: SRDR+ Project Importer including the addition of 'All project information loaded as FHIR Resources will be publicly available.' on the first page, and displaying the Project Title with the initial display of the resulting Project page.

On March 6, the Setting the SRDR Platform on FHIR Working Group reviewed discussed models for the format of responses from the SRDR+ API with project data, created an example FEvIR Project Page for SRDR+ projects to define the desired output (https://fevir.net/resources/Project/112344), and wrote the specifications for a function to convert the SRDR+ API response to an individualized FEvIR Project Page linking to all the project FHIR Resources on the FEvIR Platform.On February 20use of Questionnaire Resource to represent data collection forms for systematic reviews in which questionnaire items are specific to study arms. One idea suggested is to create an EvidenceVariable Resource for each study arm, then create a separate QuestionnaireResponse for each study arm set of responses with a Questionnaire item to identify the study arm with valueReference. The group also reviewed the FEvIR™: SRDR+ Project Importer to identify some bug fixes.

On March 13, the Setting the SRDR Platform on FHIR Working Group reviewed established the functionality of the FEvIR™: SRDR+ Project Importer which is still in development and with the initial release accepts an SRDR+ Project ID and API token, then creates a Project page on the FEvIR Platform with links to all the associated project data in FHIR Resources on the FEvIR Platform.  We looked at an initial project and identified improvements to apply to FHIR Questionnaire Resources for the project.On February 27 by a participant importing their own test project. We also explored the "How to Cite" feature on the FEvIR Platform which autogenerates citations for Resources on the FEvIR Platform and includes these citations as relatedArtifact entries in the resource JSON, and the "How to Cite" feature in edit mode in selected resource types that provides the JSON for a full Citation Resource.

On March 20, the Setting the SRDR Platform on FHIR Working Group applied changes to the FEvIR™: SRDR+ Project Importer including the addition of 'All project information loaded as FHIR Resources will be publicly available.' on the first page, and displaying the Project Title with the initial display of the resulting Project page.On March 6, the Group discussed the use of ArtifactAssessment Resource for the “labels” of abstract evaluation processing during systematic review screening, and we showed how the Classification Profile could use content.type, content.classifier, and content.author elements to manage the full set of “labels” across multiple raters. We demonstrated how these “labels” could then be viewed with the Citation Viewer. We also discussed how to use additional elements within ArtifactAssessment Resources to support AI/ML applications.

On March 27, the Setting the SRDR Platform on FHIR Working Group discussed models for the use of Questionnaire Resource to represent data collection forms for systematic reviews in which questionnaire items are specific to study arms. One idea suggested is to create an EvidenceVariable Resource for each study arm, then create a separate QuestionnaireResponse for each study arm set of responses with a Questionnaire item to identify the study arm with valueReference. The group also reviewed the FEvIR™: SRDR+ Project Importer to identify some bug fixes.

On March 13, the Setting the SRDR Platform on FHIR Working Group established the functionality of the FEvIR™: SRDR+ Project Importer by a participant importing their own test project. We also explored the "How to Cite" feature on the FEvIR Platform which autogenerates citations for Resources on the FEvIR Platform and includes these citations as relatedArtifact entries in the resource JSON, and the "How to Cite" feature in edit mode in selected resource types that provides the JSON for a full Citation Resource.

On March 20, the Setting the SRDR Platform on FHIR Working Group discussed the use of ArtifactAssessment Resource for the “labels” of abstract evaluation processing during systematic review screening, and we showed how the Classification Profile could use content.type, content.classifier, and content.author elements to manage the full set of “labels” across multiple raters. We demonstrated how these “labels” could then be viewed with the Citation Viewer. We also discussed how to use additional elements within ArtifactAssessment Resources to support AI/ML applications.

On March 27, the Setting the SRDR Platform on FHIR Working Group identified and discussed multiple issues to improve the FHIR output from the SRDR+ API, including:

  • Avoiding an API crash when missing certain types of data
  • Specifying the expected datatype for answers to questionnaire items in Questionnaire.item.type
  • Use of QuestoinnaireResponse Resource for the data representing completed questionnaires
  • Use of ArtifactAssessment Resource (and Classificaiton Profile) for the “labels” of abstract evaluation processing during systematic review screening
  • Use of RelatedArtifact Datatype to share PDF attachments for full-text

Research Development Updates

Scientific Knowledge Accelerator Foundation Updates:

On January 31, the Scientific Knowledge Accelerator Foundation Board of Directors discussed the development of metrics to measure the pace of scientific knowledge transfer. We decided to target two concepts for initial metric development:

  1. For systematic reviews, time from publication (date) to citation in 2 or more independently published guidelines, clinical reference, clinical education, or clinical decision support artifacts
  2. For clinical trials, time from publication (date) to citation in 2 or more independently published systematic reviews, guidelines, clinical reference, clinical education, or clinical decision support artifacts

We decided to start the Measuring Rate of Scientific Knowledge Transfer Working Group as a weekly HEvKA meeting on Tuesdays at 9 am Eastern. The last Tuesday of each month will be used for the Board of Directors meeting.

On February 28, the Scientific Knowledge Accelerator Foundation Board of Directors reviewed the progress of the Measuring Rate of Scientific Knowledge Transfer Working Group and discussed three upcoming collaborative grant opportunities (let us know if you would like to participate in any of them):

...

Group identified and discussed multiple issues to improve the FHIR output from the SRDR+ API, including:

  • Avoiding an API crash when missing certain types of data
  • Specifying the expected datatype for answers to questionnaire items in Questionnaire.item.type
  • Use of QuestoinnaireResponse Resource for the data representing completed questionnaires
  • Use of ArtifactAssessment Resource (and Classificaiton Profile) for the “labels” of abstract evaluation processing during systematic review screening
  • Use of RelatedArtifact Datatype to share PDF attachments for full-text

Research Development Updates

Scientific Knowledge Accelerator Foundation Updates:

On January 31, the Scientific Knowledge Accelerator Foundation Board of Directors discussed the development of metrics to measure the pace of scientific knowledge transfer. We decided to target two concepts for initial metric development:

  1. For systematic reviews, time from publication (date) to citation in 2 or more independently published guidelines, clinical reference, clinical education, or clinical decision support artifacts
  2. For clinical trials, time from publication (date) to citation in 2 or more independently published systematic reviews, guidelines, clinical reference, clinical education, or clinical decision support artifacts

We decided to start the Measuring Rate of Scientific Knowledge Transfer Working Group as a weekly HEvKA meeting on Tuesdays at 9 am Eastern. The last Tuesday of each month will be used for the Board of Directors meeting.

On February 28, the Scientific Knowledge Accelerator Foundation Board of Directors reviewed the progress of the Measuring Rate of Scientific Knowledge Transfer Working Group and discussed three upcoming collaborative grant opportunities (let us know if you would like to participate in any of them):

  1. National Science Foundation (NSF) Pathways to Enable Open-Source Ecosystems (POSE)
  2. NIH Accelerating Data and Metadata Standards in the Environmental Health Sciences (R24 Clinical Trial Not Allowed)
  3. NIH Notice of Intent to Publish a Funding Opportunity Announcement for Accelerating Behavioral and Social Science through Ontology Development and Use (U01) – for this, we considered, once the Study Design Terminology in SEVCO paper is submitted for publication, to focus development of additional Study Design terms for behavioral and social science needs.

On March 28, the Scientific Knowledge Accelerator Foundation Board of Directors reviewed grant opportunities (NIH U01 Accelerating Behavioral and Social Science through Ontology Development and Use, NIEHS Accelerating Data and Metadata Standards, NSF Pathways to Enable Open-Source Ecosystems (POSE), NLM Research Grants in Biomedical Informatics and Data Science). For the NLM opportunity, we drafted first-draft Specific Aims for a 4-year project:

  • Year 1) Translate original research results (effect estimates/statistical findings and variable definitions), from studies used in pre-existing meta-analyses (at snapshot time 1), into FHIR. Validate reliable translation/transformation of original research results into computable evidence.
  • Year 2) Translate search strategies, from pre-existing meta-analyses, into FHIR. Validate precision and recall of computable searches.
  • Year 3) Translate statistical analysis plans for pre-existing meta-analyses into FHIR. Validate that automated processing of computable evidence in FHIR reliably reproduces the meta-analysis results.
  • Year 4) Update the meta-analyses with automated support using data available at snapshot time 2. Validate reliable reproduction of the updated (cumulative) meta-analyses.


Measuring the Rate of Scientific Knowledge Transfer Working Group Updates:

...

  • "Success is peace of mind, which is a direct result of self-satisfaction in knowing you made the effort to become the best of which you are capable." --John Wooden

  • "The reward for work well done is the opportunity to do more" --Jonas Salk
  • "Look in your disappointments for the resolve to transform your experiences into solutions." --Bryant H. McGill
  • "The thing that is really hard, and really amazing, is giving up on being perfect and beginning the work of becoming yourself." --Anna Quindlen

Monthly Participation:

  • For January 2023 – 37 people (AI, AS, AYL, BA, BK, BM, CE, ES, GL, GV, HL, IK, IR, JD, JJ, JL, JM, JO, JT, JV, KOB, KP, KR, KS, KW, MA, MD, MH, MT, NA, NO, PW, RC, RL, SS, YG, YW) from 8 countries (Canada, Costa Rica, Finland, Germany, India, Taiwan, UK, USA) participated in up to 56 active working group meetings.

  • For February 2023 – 31 people (AI, BA, BM, CE, CS, GHM, GL, GV, HL, IK, IR, JD, JJ, JO, JR, JT, KOB, KP, KR, KS, KW, MA, MH, MT, NO, PR-S, PW, RC, RL, SS, YW) from 8 countries (Canada, Costa Rica, Finland, Germany, Norway, Taiwan, UK, USA) participated this month in up to 60 active working group meetings.

...