HTI-1 NPRM Comment Collection

Background

Link to the ONC page: https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program

• Link to the NPRM: https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and

• Link to ONC introductory webinars: https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program

• Comments are due to ONC by June 20, 2023. Please submit comments on this page by June 5, 2023 for consideration as part of SHIELD’s comments.

• Instructions: Under each RFI section or other feedback, please add your comment, followed by your name (in case there are follow up questions).\

• This is the final version approved by the Steering Committee on 20Jun23 and submitted to ONC.

Open

Several of you have asked about comments submitted by other organizations. Here’s a link to the page with those comments. The SHIELD comments are found here.

Introduction

SHIELD Draft ONC NPRM Comments below and in this document (for download)

Open

1. Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?

To facilitate interoperability, ONC should consider adopting the following HL7 Implementation Guides (IG).  Functionality for adoption is needed by both senders and receivers, whether a LIS, LIMS, EHR, or other Healthcare IT.   SHIELD recognizes development to implement these IGs will vary amongst senders and receivers and aspects such as interfaces, Health IT vendors functionality, and coding, etc.  As a result, SHIELD is requesting funding for laboratories to help incentivize adoption and provide resources to assist in these efforts.  ONC may wish to consider requirements in “phases” to give developers time to build and certify to IG functionality below, as well as laboratories time to adopt or upgrade interfaces and functionality for these IGs.  Focus should be on raising the minimal bar/floor from those who have not yet adopted electronic systems/health IT, or interfaces with a goal of full complete adoption of all in time after all phases are complete.   ONC should also consider quality and patient safety aspects in all aspects.  For example, it may not be enough to have certification for an item.  Rather is it implemented and utilized as intended/designed (whether a code system, IG, interface or related functionality).   

An initial phase may entail requirements for both sending and receiving systems to structure and map content digitally to code systems such as LOINC, SNOMED CT, and UCUM standards as indicated in the IGs and to the most recent version of each as specified in the final rule. As such, ONC may wish to name the LOINC Mapping Guides as a resource available to help those mapping laboratory orders and results to LOINC codes.  ONC may wish to consider funding the development of similar mapping guides to SNOMED CT for Specimen Type, Specimen Source Site, Organism, qualitative result values, procedures, and other areas of need especially for specimen collection, pathology, and genomics.  Work should commence on identifying gaps in codes needed for future phase adoption such as in pathology and genomics/molecular content.

 IGs should be reviewed for content not yet included in USCDI to support implementation of IGs and laboratory test information across the entire ecosystem and in accord with CLIA requirements and associated regulatory requirements.  For example, test reference ranges, and “flags” (e.g. critical, high, low) should be included in USCDI and be a requirement with exchange of laboratory results as applicable.

ONC may wish to consider focusing initially on high volume/most common clinical laboratory testing in chemistry, hematology, microbiology, and blood bank, followed by phasing in more complex, less commonly performed laboratory orders and results.  A use case-based approach may be needed such as pathology for cancer reporting followed pathology for benign conditions, or genomics/molecular testing utilized in cancer, followed by prenatal/congenital disease testing, etc. 

Another consideration is high impact uses of laboratory data by other processes/areas so data are available when and where needed the most.  For example, LOINC encoded laboratory results are trigger codes for electronic Case Reporting (eCR).  When lacking discrete encoded laboratory results utilized for public health reporting, eCR reporting may not trigger and clinicians may miss what they are required to report by law. 

ONC is strongly encouraged to continue working with SHIELD on addressing laboratory data interoperability and usability needs. 

a.     Electronic Directory of Service (eDOS) HL7 version 2.51 for laboratories to publish, update, and exchange their compendiums electronically (as sender) with any EHR, LIS, LIMS, module, or Health IT (as receiver) involved in laboratory test ordering. 

b.     Laboratory Orders Interfacing Implementation Guide (LOI), HL7 version 2.51 for any Health IT (EHR, LIS, LIMS, module, or related Health IT) used in producing individual patient orders that are electronically sent (directly or indirectly via other systems) to the performing laboratory.  Functionality for both sending, receiving and intermediary systems is needed.

c.      Laboratory Results Reporting Implementation Guide (LRI), HL7 version 2.51 for any Health IT (EHR, LIS, LIMS, module, or related Health IT reporting or transmitting laboratory results.  Functionality for sending, receiving and intermediary systems is needed.

d.     Electronic Health Record Functional Requirements for Receipt of Laboratory Data (EHR-S) HL7 version 2.51 Implementation Guide.  Functionality for sending, receiving and intermediary systems is needed.

2. The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.

HL7 version 2 is the standard used across laboratory medicine and pathology and likely will be for quite some time.  C-CDA is involved when laboratory data are exchanged outside of an EHR as part of a summary of care or transfer of care document.  C-CDA implementations may need review and updated requirements as a number report incomplete laboratory information being exchanged such as missing laboratory reference ranges needed for decision making.  However, most clinical laboratories do not exchange laboratory data using C-CDA.  Similarly, SHIELD is not aware of any LIS or LIMS that has FHIR functionality currently, much less support CLIA compliant FHIR needs.  There are some laboratories who have deployed FHIR in their information systems and workflows downstream from the LIS such as patient facing applications. ONC should consider where in the end-to-end laboratory testing and workflow processes usage of these standards occurs and does not occur.

 Concerning FHIR, there would be significant impact to move to a FHIR based laboratory data exchange across/from laboratory medicine and pathology.  There are several FHIR IGs under development, but it is unclear if any have been adopted for laboratory data exchange.  It is recommended that as part of a longer-term plan ONC work on supporting the development of FHIR IGs, specifically those similar to guides available in HL7 Version 2 (eDOS, LOI, LRI, ELR, EHR-S for receipt of lab results in the EHR).  Development is also needed for ePathology reporting for pathology reporting using FHIR, and HL7 Clinical Genomics IG.  All IGs should be reviewed to ensure they meet CLIA (including those states exempt from CLIA) and laboratory accreditation regulatory requirements with ONC support like that of the ONC S & I framework for the HL7 Version 2 IGs.

As part of the phased approach, it would be easier to provide resources to get all laboratories to the same level of exchanging data on HL7 Version 2.51 before attempting to transition to FHIR.  Until the maturity of CLIA compliant FHRI standards are ready, laboratory data natively in HL7 version 2 would need to be converted to FHIR for use downstream such as with EHR certification requirements. 

3. What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?

It is recommended that ONC look at the total testing process and each place laboratory data are utilized for patient care, research such as clinical trials, public health needs, etc.  There are several intermediaries involved in the transmission of laboratory orders, results, and related data and coding that provide the complete meaning of a laboratory test.  When said intermediaries lack capability to receive, transmit and possibly store laboratory data related to the meaning of a test, this weakest link becomes a barrier to interoperability as names, result values, reference ranges, interpretations, encoding, flags, comments, etc. may be truncated, transformed, etc. as they pass through various health IT, interfaces, hubs, etc.  Like the telephone game, what originates at the performing laboratory may be quite different from what emerges (if at all) by users further downstream.  Where ONC does not have authority over an entity in the chain, it’s recommended that they work with those that do such as HHS, CDC, Public Health Authorities, CLIA, FDA, etc. and those working on interoperability such as SHIELD so an aligned, interoperability solutions can be developed targeting gaps, intermediaries, etc. and improving laboratory data interoperability and usability.

One example is the desire to utilize Universal Device Identifiers (UDIs) for test kits and devices as noted in COVID HHS regulatory requirements.  While a short-term solution was developed for COVID, a longer-term solution needs to be developed for the nuances of other test results in laboratory medicine and pathology before they can be implemented.  Functionality is needed to electronically capture UDI information from IVD vendors (so they are not manually entered by laboratory professionals burdening them), store UDIs in any information system associated with each lab result, and transmitted with laboratory results in a way that does not create or increase burdens on laboratory professionals, and any users of the data.  This is especially the case when more than four UDIs may be needed to describe a result and its value, with complex lab results including calculated results involving multiple lab results, results from stained slides such as in hematology, pathology, cytology, microbiology, etc., many molecular and genomics tests, etc.  ONC is encouraged to work with FDA and other entities on a longer-term plan to support UDIs across the care continuum, while minimizing the burden to health professionals collecting, storing, and using them.  This may include functionality for IVD vendors as well as Health IT vendors to support. 

4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers’ products?

Laboratories may not be able to support many interoperability needs without functionality from their Health IT vendor product or home-grown systems (LIS, LIMS, EHR, custom).  Laboratories also need financial incentives to make a compelling reason to adopt said functionality and perform updates.  It is recommended that needed functionality to adopt the eDOS, LOI, LRI, ELR, EHR-S IGs, as well as support of genomics, cytology and pathology reporting be included in LIS, LIMS, EHR and other Health IT supporting laboratory ordering and results exchange (whether internal or external) be considered for certification.  For data in legacy systems, or originating in paper, fax, pdf, or text blob, there may need to be functionality to accurately transform said data into more discrete formats with encoding and capability to exchange (internally and externally) without loss of test meaning. Certification would help set a minimum of healthcare IT vendor standards to support such as LOINC, SNOMED CT, UCUM for all laboratory results, LOINC for all laboratory orders (where available).  Details should be specified on the underlying data model needed for supporting the complete meaning of laboratory data across the health IT ecosystem to help ensure relationships and context is accurately transmitted amongst systems and meaning isn’t lost. 

Although certification provides a set of available functionalities, it does not mean said functionality is adopted or implemented.  ONC should consider criteria to measure or indicate whether functionality is adopted (and perhaps a level of adoption where aspects are phased in) and utilized by clinical laboratories and all those involved in the end-to-end ecosystem where laboratory data are utilized. Clinical laboratories are often burdened with these transformation costs and need financial help to transition to a new or existing system with this functionality too.  ONC may wish to survey laboratories on functionalities needed to improve laboratory interoperability and additional ways to reduce burdens on clinical laboratories.

Some functionality may need to be more use case driven too.  Where data exists in report or document format that is exchanged, it may need to be easily transformed to discrete, encoded data for public health, population health needs, clinical decision support algorithms, or other uses of discrete data. Two high value use cases are cancer reporting and use of clinical genomics.  The College of American Pathologists (CAP) Electronic Cancer Protocols (eCP) permit structured data capture for cancer registry reporting.  However, the exchange of these reports among other institutions is not well established.  ONC should work on what is needed to support the exchange of pathology and genomics data amongst all information systems (LIS, EHR, public health, cancer registries, oncology, and clinical trials systems, etc.) to ensure the data are available in a computerized processable format with the correct context and meaning to all who need it.  Said solutions should try to leverage encoding discrete data at its point of origin and transmission of said data to downstream users and systems to minimize burden on pathologists, public health, and other users.  For example, if procedure, specimen, and other data are collected at origin by the surgeon or other provider ordering testing and integrated into pathology reporting, burden and typographical and other errors would be reduced, not only in pathology, but for cancer registry, clinical trials, and other users of these data.  Functionality for “add-on” orders in the laboratory may need to be visited.  There may be functionality for billing, but challenges exist in some areas to add on documentation needed for clinical care and reporting needs.  ONC may consider studies on how much pathologist and other user’s time is reduced by these improvements in interoperability (burden and/or cost reduction) and other measurements of improvements.

ONC should collaborate with FDA to work on getting IVD vendors to provide standardized terminologies like LOINC and SNOMED CT for the laboratory data produced by the test kits and/or devices in Laboratory In Vitro Diagnostics (LIVD) format.  LIVD maps should be readily available to all laboratories, but also other entities which may need to map laboratory data.  It’s recommended that ONC and FDA continue work with and support of SHIELD efforts on establishing an IVD hub to host LIVD maps.   

5. Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?

Additional areas ONC and HHS should focus upon to advance laboratory data interoperability include:

1. Education and training for those implementing requirements. 

2. Examples may include good and bad examples of what is and is not an interoperable laboratory report.  ONC may consider working with laboratory and pathology professional organizations to develop these examples and criteria.

3. For implementing and mapping standardized terminologies, such as LOINC and SNOMED CT, it’s recommended to point implementers to the LOINC and SNOMED CT User guides and LOINC Mapping Guides.  Additional guides may be developed that are use case or driven or for specific laboratory areas such as pathology, genomics, microbiology reports, etc.

4. Implementations that are CLIA compliant (examples of what is and is not), in collaboration with HHS, CLIA, CDC.

5. Education on terms/items needed for interoperability.  Specimen type and source are easily confused as laboratory understanding/use of these terms is different that standards development organizations.

6. Resources for clinical laboratories, especially financial resources and clear, meaningful, and compelling incentives to garner adoption and change.  This may include indicating benefits of adopting standards, IGs, health IT and changing existing processes.  Benefits may include quality, safety, financial, reduction in burden, other cost savings, etc.  Why should laboratories invest in these changes?  Also mapping guidance, education, and resources.

7. ONC may consider review of terms in other regulations pertaining to laboratory data such as CLIA, Medicare/HHS regulations, public health regulations and provide operational definitions/cross walks for them.  Terms used in laboratory and pathology community and regulations are not used the same way/have the same meaning by those external to this community, other areas of healthcare, by some standards development organizations, etc. and thus different understanding/interpretation by implementers, developers, and others using these data and terms.  Coupled with education this may go a long way to increase understanding of laboratory data interoperability needs.

Call Notes Follow Below

RFI for laboratory Interoperability (See pages 331 - 334, link)

1. Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?

Comments

1. To facilitate interoperability, ONC should consider adopting the following HL7 Implementation guides:

   1. electronic Directory of Service (eDOS) HL7 v 2.51 for laboratories to publish, update, and exchange their compendiums electronically with EHRs having the capability to receive any laboratory compendium, integrate and update the compendium content in their databases, and utilize to present providers laboratory test compendium content in their CPOE systems. This content includes Ask at Order Entry (AOE) questions (and response options if provided), LOINC encoding of orders, results, and SNOMED CT qualitative result values, etc. EHRs should support displaying each performing laboratory’s naming conventions to the ordering provider. The EHR may supplement additional functionality for providers such as allowing them to designate “favorite” orders especially for specialties, patient populations, etc.

   2. Laboratory Orders Interfacing Implementation Guide (LOI), HL7 version 2.51 for EHRs to use in producing individual patient orders to electronically send to the performing laboratory. EHRs should utilize LOINC encoded orders where LOINCs are available, include Ask at Order Entry questions which are LOINC encoded, their responses with SNOMED CT encoded qualitative result values, SNOMED CT encoded Specimen Collection Procedures, Specimen Types, Specimen Source Sites, and qualifier values such as laterality should all be included in the Order Message. The performing laboratory’s naming convention should be used in the order to standardize the ordering process across all providers submitting orders to the same laboratory for the same test.

   3. Laboratory Results Reporting Implementation Guide (LRI) (AP to finish)

   4. Electronic Health Record Functional Requirements for Receipt of Laboratory Data (EHR-S) Implementation Guide (Ap to finish)

   5. Commenter: Andrea Pitkus

2. Hung: LOI, LRI fit for purpose? full implementation would result benefits versus piecemeal functionality. Thoughts?

3. Walter Sujansky: LRI initially selected as MU2 requirements, then removed in Stage 3 MU. Why removed? Any barriers?

4. Julia Skapik: push back from industry, some in favor, others against. LIS vendors not included.

   1. Maturity level may be argument not to go forward. Now industry is further along.

   2. Dan R: MU challenges: distinction, requiring everything to be fully compliant versus 90% meeting it in spirit. SO for existing interfaces to be redone without significant added factor. EMR/LIS groups. gaps of no interfaces versus not LRI/LOI compliant. Targeting gap may be more effective effort.

   3. Julia: where is the sweet spot. Existing certification program does have gaps. Provide clarity on floor would be helpful to ONC. Certification to level of real world implementations. Why comments are important. Government can’t act without comments.

   4. Walter Sujansky: alternative HL7 implementation guides to LOI and LRI. ELINCs results reporting from 10+ years ago. More streamlined. labs and EHRs considered feasible.

   5. Julia: standards in consensus development while flying. Some are fixes from earlier versions. Speaks to variability, performance, and what learned in development. LOINC and/or another standard. Do we need specimen source, codes. What we didn’t do and what we did do examples for the comment.

   6. Steve Powell: Systems thinking and how this is viewed. How infuse into comments. CMS requirements. naming and coding. Don’t want to create unintended consequences. IVD alignment too with requirements from different agencies. Think through ONC feedback from others in ecosystem. data quality or efficacy issues. Weaken

   7. SHIELD:

2. The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.

1. Comment….. Commenter:

2. DanR: labs could handle FHIR if needed to, but not yet. Don’t have all the right pieces currently. Basic result reporting in chemistry is fine, micro is questionable, genomics is complex (accelerators working on it), pathology (text blob is not interoperable, versus discrete data). Evolution over the years from textual to discrete and having capability to represent all lab data before widespread use. Works,

3. Rob H: Capability is analogous to v2, but not compelling reason to move forward,

4. Srikar: CHL/USC Ca: Co Chair HL7 Genomics WG, champion CodeX work. Do we engagement with LIS and EHR vendors? Yes. Do we have access to try FHIR lab standards to see if they adopted? Genomics: many using pdf reports still. Labs using Epic convert to v2. transition. Some room not 100% compatible before full implementation.

5. Julia: Structured docs at last HL7 Meeting, may not be able to get rid of Pathology report free text for awhile. One vendor put all data in free text blobs. Things that can be structured should be. Where others than can’t should have capaiblities for abnormal flags and high value pieces of lab results. ONC shoudl start focusing. More volume ofnormal labs doesn’t help us much, Need to process, new findings of abnormal lab results to drive decision support. Need something for free text results for cancer diagnosis, etc. Let’s story tell with comments. Not many clinical or Lab results. Story of what we need or why.

6. Steve Power: add to comments. With large information exchanges w CCDA, rarely are lab results ranges coming across. May be part of the comment and critical to get. multiple folks support reference

3. What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?

1. Comment….. Commenter:

2. Julia: Early SHIELD call. If we leave out intermediaries out how do we expect info to flow to systems that need it. IF ONC doesn’t have authority over entity in chain, work with other federal agencies (i.e. PH, CDC, FDA). Another workflow needed.

3.  

4.  

4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers’ products?

1. During SC Call 6/6/23:

   1. AdvaMed is submitting comments on this question

2. Eric. ACLA submitting comments too. Laboratories may not be able to support interoperability needs without certified. Without certification requirement on laboratory systems and incentives to adopt certified technology. Concern is handling updates to legacy connections. What is the incentive to update? Provide the issues that would need to be addressed if certifying the other systems.

3. Andrea: Question is how do we get the structured data to the systems for later use when the data does not come in structured format from the labs due to older connectivity. There’s a variety of adoption from nothing due to reporting on paper/fax. Crawl, walk run approach so not huge burden all at once.

Hung: Labs are making great effort to support new requirements, but having to come up with workarounds to cover these until the LID are updated to support those requirements - that work is not free; comparability of results are becoming more important - need to map external results into the EHR-s, but that is hard to do, when not all the data is available, so a lot of extra work to get this accomplished - certification would move that part forward, labs already bear the burden now, but not visible to others. This should be broader and include the underlying data model and ensure that relationships and context is transmitted.

4. Burdens of mapping external data in EHR,

Data elements/standards and funcitionality to capture and transmit.

Lab

UDIs: need capability to collect, store, and transmit

LOINC

SNOMED CT

6. IVD certification::

7. LIS certification:

Raj need use case driven. Interoperability is abstract until you get to the details. AP report, needed at right time when exchanges between systems. PDF or discrete data may be transmitted. Depends on care provided to patient. PDFs do not work as well for population health. Use cases low hanging fruit. Success in reporting to cancer registries versus other data for cancer reporting with CAP, ACOS requirements and standard format for reporting. Unless you have sometingn like that, difficult to share data. Cancer Protocol shared with antoher insitution is not well established.

Mehdi: Agree on use cases especially for genomics. LOINC standards doesn’t really serve practicel purpose with high through put/ NGS. Identify a variant, then when classification changes, creates a whole new set of issues for interoperability even between vendors. Even though some standards, it’s variable with vendors.

Robin: Variant frequency in reports. Doesn’t annotate and limited, even with most successful company. It’s the variant and context in which variant occurs. doesn’t mean same in each disease state. KRAS. Needs to be understandable by those treating the patient. Needs to be interoperable. Genomics report need to be tied to clinical hx and disease entity. Don’t have specific cancer dig in genomics report. Format doesn’t follow a template like AP.

non cancer APs are still more different: Transplant Kidneys report in all different formats. Also template and vocab may exist, but not used in the right way: May be in another section. microscopic portion of APLIS but not used by pathologists. They prefere to use notes instead.

Having a standard way to add on more tests (supports only billing aspect of workflow, not documenting

Blood bank systems:

Operational uses, efficiencies of pathologist entering data vs level of data structuring, what’s the value proposition for capturing the data at that level? What use cases require this level of detail? IF capturing data in this way impacts efficiency and how addressed? Pathologists time.

What use cases require it. Not all require it.

ALL SHIELD call comments

1. Craig : review previous comments above.

2. DanR: mentioned to focus feedback on adoption versus certification. Cert is minimal bar versus functionality and no guarantee of implementation or business drivers not achieving certified level in reality. Adoption is what we really need to get. others Agree.

3. Steve Powell: Not seen here. Resources labs need. Education component is huge with all of this. Needed in all areas. Learning from stakeholders, education and training. People may not know what right thing to do.

4. DanR: would go a long way to improve what folks are willing and able to do. Understand better how to achieve good results. How would it happen? Who would do it? Is it MLS, lab Dir, informatics teams, etc? Combination. How to deliver? Does CAP or others have education/good leadership to spearhead this? Focused training on implementations. Ideas? Need it further front.

5.  

5. Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?

1. Comment….. Commenter:

2. Good and bad examples to educate all on what is and is not an interoperble lab report.

3. Dan R: Regenstrief micro guide has good and bad examples

4. Steve Powell: clear incentives for change and adoption. Incentives have to be meaningful. Stronger. give people a reason to participate.

5. Craig: Include laboratories in those incentives

6. Share will comments. Julia will comments

Other NPRM Feedback and Comments

1. ONC is encouraged to require EHR and information system certification criteria to include discrete data collection, storage, encoding with SNOMED CT, and messaging/exchange with other information systems for the following to support their use across the continuum of clinical care, research, public health, clinical decision support including algorithms and machine learning, to foster interoperable and machine usable health data. The data should be able to be integrated and utilized in clinical laboratory and pathology functions, including middleware, instruments, etc. to be integrated into each downstream systems' functionality to reduce manual data entry, reduce error and clinical burden/ For example, any specimen info collected by surgical procedures, should be used to populate Electronic Cancer Protocols, and cancer registries, as the data move from system to system :

   1. Procedure for specimen collection. Mapped to SNOMED CT procedure hierarchy term/code. Required for laboratory orders, including clinical laboratory areas of blood bank, chemistry, hematology, microbiology, genetics and molecular testing, pathology, and cytology. If the collection is due to a surgical procedure, it shall be collected discretely, encoded and exchanged either within EHR modules or interfaced to a clinical laboratory or pathology information system, public health, data warehouse, clinical trials, research, cancer registry, and other information systems.

   2. Specimen Type including qualifiers (AP to finish)

   3. Specimen Source including qualifiers (AP to finish)

   4. ONC may wish to use a stick/penalty approach to foster clinician adoption as the previous Meaningful Use Incentives have not been successful in increasing functionality and use in this area.

   5. Commenter: Andrea Pitkus

2. CAP will be submitting comments

3. Comment….. Commenter:

Other NPRM Comments That May Be of Interest to SHIELD

(Click on link, download comment, scroll/search to navigate to the laboratory RFI section to see what others commented. Feel free to add more, especially those referring to SHIELD.)

1. American Association for Clincal Chemistry (AACC)

2. American Clinical Laboratory Association (ACLA)

3. American Medical Association (AMA)

4. Association of Public Health Laboratories (APHL)

5. College of American Pathologists (CAP)

6. Epic

7. Health Information Technology Advisory Committee (HITAC)

8. HL7 lab RFI confluence page and HL7 comments

9. Meditech

10. National Association of Community Health Centers (NACH)

11. National Independent Laboratories Association (NILA)

12. Oracle Health (Cerner)

13. Regenstrief Institute