1c. Is Your Project an Investigative Project (aka PSS-Lite)?
No
1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?
No
1e. Today's Date
1f. Name of standard being reaffirmed
1g. Project Artifact Information
1h. ISO/IEC Standard to Adopt
1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?
1j. Unit of Measure
2a. Primary/Sponsor WG
Cross-Group Projects
2b. Co-Sponsor WG
Clinical Decision Support
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)Other Involvement. Specify details in text box below
2c. Co-Sponsor Involvement
Wants active involvement, at least for aspects relevant to CDS concerns.
2b. Co-Sponsor WG 2
Clinical Quality Information
2c. Co-Sponsor Level of Involvement
Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)
2b. Co-Sponsor WG 3
Service Oriented Architecture
2d. Project Facilitator
Preston Lee
2e. Other Interested Parties (and roles)
2f. Modeling Facilitator
2g. Publishing Facilitator
Preston Lee
2h. Vocabulary Facilitator
2i. Domain Expert Representative
Preston Lee, Bryn Rhodes
2j. Business Requirements Analyst
2k. Conformance Facilitator
Bryn Rhodes
2l. Other Facilitators
2m. Implementers
Logica Health, AHRQ
3a. Project Scope
The project goal is to develop a metadata standard that can address how to exchange any standards-based app or clinical content package by any organization (e.g., IHE, HL7, Logica, etc.). Standard metadata modeling is significant to clinical decision support, clinical quality measures, clinical smart apps to manage information for orders, laboratory studies, imaging studies, social determinants of health, patient empowerment calculations, clinical observations, military history, clinical exposures to determine patient risk for disease or injury, insurance benefits, clinical trial candidates, etc. Possible metadata concepts include items such as author / steward of the content, date(s) applicable, inclusion criteria, exclusion criteria, references, supporting evidence, strength of evidence and recommendation, expected users, etc, with actual concepts to be developed as part of the project.
As metadata elements need to address and accommodate resources owned and managed across HL7's product families, i.e. FHIR, CDA, V2, as well as resources that are found outside of the HL7 (i.e. BPM+), the project should be managed in Cross-Group Projects rather than a single area/domain. There is some existing work in CDS and CQI that will represent a good start and therefore, those WGs have signed on as co-sponsors, but to scope is to generalize those metadata for all concerns.
The Logica/HL7 Health Services Marketplace Release 2 (the "Specification" under SOA) provides a vendor-agnostic API for publication, curation, discovery, and distribution of interoperable service implementations. It is design to be agnostic to programming language, development framework, database, and I/O technologies, as well as account for client-side applications that require on-site deployment, such as SMART-on-FHIR.
This implementation guide defines the product metadata for products implementing several prominent or emerging HIT standards. That is, marketplace implementors intending to support curation and exchange of standardized product types should follow the guidance provided here to optimally support exchange of of product listings across implementations. Once implemented, marketplace operators should be able to:
* Accept manual and automated product build submissions from developers compliant with the standards supported under this IG.
* Post-product submission, provide:
** Automated "smoke test"-level regression testing against standard-specific compliance validations.
** Manual review by non-technical SMEs.
* Allow users to search for relevant products based on standard- and artifact-specific metadata, such as via free text search.
Attachments
3b. Project Need
The Marketplace API STU does not define "product metadata" structures for asset submissions, as it is assumed the implementor will select schemas specific to and specialized for each supported standard relevant to the purpose of the implementation and content types.
3c. Security Risk
No
3d. External Drivers
3e. Objectives/Deliverables and Target Dates
2021 September Initial Draft Guide
2022 January ballot cycle; will attempt to keep dates aligned with external stakeholder organizations and events such as AHRQ roadmap, HIMSS, MCBK etc.
3f. Common Names / Keywords / Aliases:
Marketplace Product Packaging and Metadata
3g. Lineage
3h. Project Dependencies
HSP Marketplace 2 STU1 (under SOA WG)
Collaboration with external communities concerns with computable HIT metadata structures.
3k. Additional Backwards Compatibility Information (if applicable)
3l. Using Current V3 Data Types?
Unknown
3l. Reason for not using current V3 data types?
Un
3m. External Vocabularies
Unknown
3n. List of Vocabularies
3o. Earliest prior release and/or version to which the compatibility applies
4a. Products
Guidance (e.g. Companion Guide, Cookbook, etc)
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
4c. FHIR Profiles Version
4d. Please define your New Product Definition
4d. Please define your New Product Family
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. White Paper Type
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Externally developed IG is to be (select one)
5a. Specify external organization
5a. Revising Current Standard Info
5b. Project Ballot Type
STU to Normative
5c. Additional Ballot Info
5d. Joint Copyright
Yes
5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.
Yes
6a. External Project Collaboration
Will be under the same Joint Project Plan and MOU with Logica Health as the Marketplace STU. Should not require changes to those agreements.
6b. Content Already Developed
No
6c. Content externally developed?
No
6d. List Developers of Externally Developed Content
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Regulatory Agency, Standards Development Organizations (SDOs), Payors, Other
6f. Other Stakeholders
6g. Vendors
EHR, PHR, Health Care IT, HIS
6g. Other Vendors
6h. Providers
Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)
6h. Other Providers
6i. Realm
Universal
7d. US Realm Approval Date
7a. Management Group(s) to Review PSS
7b. Sponsoring WG Approval Date
Feb 20, 2020
7c. Co-Sponsor Approval Date
Feb 06, 2020
7c. Co-Sponsor 2 Approval Date
Feb 06, 2020
7c. Co-Sponsor 3 Approval Date
7c. Co-Sponsor 4 Approval Date
7c. Co-Sponsor 5 Approval Date
7c. Co-Sponsor 6 Approval Date
7c. Co-Sponsor 7 Approval Date
7c. Co-Sponsor 8 Approval Date
7c. Co-Sponsor 9 Approval Date
7c. Co-Sponsor 10 Approval Date
7e. CDA MG Approval Date
7f. FMG Approval Date
7g. V2 MG Approval Date
7h. Architecture Review Board Approval Date
7i. Steering Division Approval Date
Feb 25, 2020
7j. TSC Approval Date
Mar 30, 2020
Show Changes
Version
1
Modifier
Jean Duteau
Modify Date
Feb 11, 2021 18:44
1a. Project Name
Marketplace Product Packaging and Metadata
1b. Project ID
1608
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
No
1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?
No
2a. Primary/Sponsor WG
40
2b. Co-Sponsor WG
Clinical Decision Support
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)Other Involvement. Specify details in text box below
2c. Co-Sponsor Involvement
Wants active involvement, at least for aspects relevant to CDS concerns.
2b. Co-Sponsor WG 2
Clinical Quality Information
2c. Co-Sponsor Level of Involvement
Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)
2d. Project Facilitator
Preston Lee
2g. Publishing Facilitator
Preston Lee
2i. Domain Expert Representative
Preston Lee, Bryn Rhodes
2k. Conformance Facilitator
Bryn Rhodes
2m. Implementers
Logica Health, AHRQ
3a. Project Scope
The project goal is to develop a metadata standard that can address how to exchange any standards-based app or clinical content package by any organization (e.g., IHE, HL7, Logica, etc.). Standard metadata modeling is significant to clinical decision support, clinical quality measures, clinical smart apps to manage information for orders, laboratory studies, imaging studies, social determinants of health, patient empowerment calculations, clinical observations, military history, clinical exposures to determine patient risk for disease or injury, insurance benefits, clinical trial candidates, etc. Possible metadata concepts include items such as author / steward of the content, date(s) applicable, inclusion criteria, exclusion criteria, references, supporting evidence, strength of evidence and recommendation, expected users, etc, with actual concepts to be developed as part of the project.
As metadata elements need to address and accommodate resources owned and managed across HL7's product families, i.e. FHIR, CDA, V2, as well as resources that are found outside of the HL7 (i.e. BPM+), the project should be managed in Cross-Group Projects rather than a single area/domain. There is some existing work in CDS and CQI that will represent a good start and therefore, those WGs have signed on as co-sponsors, but to scope is to generalize those metadata for all concerns.
The Logica/HL7 Health Services Marketplace Release 2 (the "Specification" under SOA) provides a vendor-agnostic API for publication, curation, discovery, and distribution of interoperable service implementations. It is design to be agnostic to programming language, development framework, database, and I/O technologies, as well as account for client-side applications that require on-site deployment, such as SMART-on-FHIR.
This implementation guide defines the product metadata for products implementing several prominent or emerging HIT standards. That is, marketplace implementors intending to support curation and exchange of standardized product types should follow the guidance provided here to optimally support exchange of of product listings across implementations. Once implemented, marketplace operators should be able to:
* Accept manual and automated product build submissions from developers compliant with the standards supported under this IG.
* Post-product submission, provide:
** Automated "smoke test"-level regression testing against standard-specific compliance validations.
** Manual review by non-technical SMEs.
* Allow users to search for relevant products based on standard- and artifact-specific metadata, such as via free text search.
3b. Project Need
The Marketplace API STU does not define "product metadata" structures for asset submissions, as it is assumed the implementor will select schemas specific to and specialized for each supported standard relevant to the purpose of the implementation and content types.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
2021 September Initial Draft Guide
2022 January ballot cycle; will attempt to keep dates aligned with external stakeholder organizations and events such as AHRQ roadmap, HIMSS, MCBK etc.
3f. Common Names / Keywords / Aliases:
Marketplace Product Packaging and Metadata
3h. Project Dependencies
HSP Marketplace 2 STU1 (under SOA WG)
Collaboration with external communities concerns with computable HIT metadata structures.
1 Comment
Anne Wizauer
Preston Lee Bryn Rhodes I am sending this to TSC e-vote today, but I believe this will need a publishing facilitator added to receive approval.