Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 84 Next »

Introduction

The purpose of this page is to capture the goals and requirements to enhance ELR reporting in the context of the COVID pandemic, in light of HHS guidance, and in that context provide clear guidance to all parties in the communication flow to enhance their contributions to enhance the ELR transaction to a Public Health Authority. 

This is meant to be a working document that we rapidly evolve based on latest understanding. Once it is believed to be sufficiently complete and accurate it will be published elsewhere as a guidance document.

Contributors


NameOrganization
NameOrganization
Rita AltamoreDepartment of Health Washington State
Janet HamiltonCSTE
Ketty AndreasenEpic
Christi HildebrandtGDIT
Nancy BarrettCT DPH
Riki MerrickAPHL, HL7 Orders & Observations Co-Chair, IHE Pathology and Laboratory Medicine Co-Chair
Brooke BeaulieuCSTE
Craig NewmanAltarum, HL7 Public Health Co-Chair
Amy BittrichDHS Wisconsin
Andrea Pitkus, PhD, MLS(ASCP)CMLaboratory LOINC Committee Member, previously of Laboratory Interoperability Cooperative (LIC) focused on ELR
Laura BleielEpic
Dan RutzEpic
Hans BuitendijkCerner, HL7 Orders & Observations Co-Chair, EHRA Standards & Interoperability Chair
Kathy WalshLabCorp
David BurgessLabCorp, HL7 Orders & Observations Co-Chair
Michael WatersFDA
Freida HallQuest Diagnostics
Mary WedigSLH Wisconsin
Jason HallCDC
Jennifer JohnsonGDIT


















 Definitions

  • AOE - Ask at Order Entry
  • eCR - Electronic Case Report (can be reported using CDA or FHIR) - is complimentary dataflow
  • eDOS - Electronic Directory of Services implementation guide or transaction according to that guide
  • CLIA- Clinical Laboratory Improvement Amendments
  • ELR - Electronic Lab Reporting implementation guide or transaction according to that guide - in this context the referened guide is R1 (2010 with clarification and errata)
  • EUA - Emergency Use Authorization
  • IICC - IVD Industry Connectivity Consortium
  • LDT - Laboratory Developed Test 
  • LIS/LIMS - Laboratory Information System (Clinical Labs) or Laboratory Information Management System (Public Health Labs)
  • LOI - Laboratory Order Interface implementation guide or transaction according to that guide
  • LRI - Laboratory Results Interface implementation guide or transaction according to that guide
  • O - Optional
  • PD1 - Patient Demographics 
  • PHA - Public Health Authority
  • PID - Patient Identification Segment
  • PV1 - Patient Visit Segment
  • RE - Required but may be Empty (Must support)
  • R - Required
  • UDI - Unique Device Identifier

Current Challenges

When ELRs are sent to PHA at times, they may not contain sufficient demographic, and other data as required by public health by law.  This guidance aims to facilitate collection and transmission of these vital data at order entry, for transmission to the performing laboratory and on to the respective PHA.  While some of the data may be part of a provider eCR report to public health, eCR is out of scope for this discussion, but ELR data would need to be aligned with eCR reporting.  These data often available at order entry, and their transmission to the performing laboratory and in that lab's ELR report, may be the first notice to PHA and accelerate PHA processes.

Currently, the following are the data flows that would be impacted:  

  • Device manufacturer(s) provide(s) label information with UDI(s) and insert information to the laboratory to enable them to validate their test system (EUA, LDT) in accord with regulations like CLIA (i.e. §493.1253).  (Same information is provided to test performers using waived testing device(s).)  
  • Performing laboratory/test performer builds test orders, results, result values, reference ranges, AOEs, and associated test information in their LIS/LIMS; configures interfaces from their instruments to their LIS/LIMS and/or sets up capabilities for manual results entry in LIS/LIMS; and configures interfaces from performing laboratory LIS/LIMS to/from ordering provider EHRs, other laboratory LIS/LIMS, and PHAs to support transmission and receipt of data for LOI, LRI, ELR, etc.  (HJB: These are not widely deployed according to those standards and we should not set the expectation that they are.)
    • Format (in lab interfaces):  IHE-LAW, ASTM
    • Format (external interfaces):  LOI, LRI, ELR (HJB: These are not widely deployed according to those standards and we should not set the expectation that they are.)
  • Performing laboratory maps national code systems (i.e. LOINC, SNOMED CT) for test(s) performed with their device(s) into their LIS/LIMS for use in messages LRI, LRI, etc.  AOEs, test orders, and results are mapped to LOINC, while SNOMED CT is used for qualitative test result values, specimen types (i.e. swab), specimen source (i.e. left nares).  (HJB: These are not widely deployed according to those standards and we should not set the expectation that they are.)
    • Format: paper, LIVD (IICC spreadsheet format), LIVD FHIR IG (future)
  • Performing laboratory builds information required for test ordering (in accord with §493.1241 Standard: Test request) into their paper or electronic CLIA Specimen Collection Manual.  AOEs for orderable tests should include their code system mappings.  The performing laboratory informs the ordering provider (EHR) or referral laboratory (LIS) (who informs their ordering providers) of required data elements for test requests (orders) including relevant AOEs.  For consumer/home testing, home specimen collection, or where Direct to Consumer (DTC) Testing is allowed, a system shall be in place to collect the required data elements from the consumer and/or ordering provider about the patient being tested.
    • Format: Paper, eDOS IG, FHIR order catalog (future)
  • The ordering provider (via their EHR or order entry system) must include all required data available at the time of order entry on the test request (order message) directly to the performing laboratory or indirectly via a referral laboratory that forwards the required information to the performing laboratory.  Both laboratories may be responsible for ELR submission depending on jurisdictional requirements and at a minimum, the performing laboratory.  
    • Format: Paper, web portal (pdf or structured data), HL7 v2.3 and higher using ORM, HL7 v2.5 and higher OML, HL7 LOI IG (future)
  • The performing lab using their LIS/LIMS reports results back to the ordering provide directly (to their EHR or portal system) or to the referral laboratory (to their LIS/LIMS or portal)  which sends the results to the ordering provider (to their EHR or portal system).  The patient may receive their results via phone, their EHR, or other online portal or application, from the performing laboratory directly, especially in jurisdictions where Direct to Consumer testing (DTC) is allowed;  from the ordering provider, or PHA.
    • Format: Paper, fax, telephone, webportal (pdf or structured data), HL7 interfaces in any version using ORU, HL7 LRI IG (future)
  • The performing laboratory with their LIS/LIMS has capabilities to receive and store all test request information from senders including AOEs and code mappings so they can be associated with patient results, device(s) utilized in performing testing, and any other required data elements to be leveraged in reporting to the provider, referral laboratory if applicable, and PHA.  The performing laboratory communicates all required information for reportable conditions in accord with all pertinent regulations/laws (i.e. CLIA, HHS, PH jurisdictions) and their timelines for reporting.
    • Format: Paper, telephone, flatfile, various HL7 v2.x formats, ELR IG,
  • The Public Health Agency forwards the information as appropriate (e.g., de-identified) to HHS for sharing with and use by federal agencies (i.e. CDC, FEMA, White House, FDA)
    • Format: flatfile, HL7 v2.3.1, ELR R1, NMI formats (for cases), various other file formats

[If time permits include a diagram]

As certification to HL7 ELR R1 IG is not required for EHRs, nor LISs, and adoption of certified ELR capabilities is voluntary under CMS' Meaningful Use/Promoting Interoperability program for providers, while not addressed in other programs for Laboratory (e.g., CLIA), while states introduce further variations, and lab order transaction formats are not addressed anywhere, implementations across all data flows vary widely and production use of HL7 EHR R1 IG is limited.  Additionally, the ELR reporting enhancements could almost all be addressed with the latest HL7 LRI R1 STU R3 IG, but that has not been adopted by anybody, since it was not included in MU regulation. 

Additionally, as the PHA onboards the lab, they may accept a variety of fields, formats as long as they are receiving key information.  Also it's unclear if point of care testing locations like pharmacies, drive up/drive through testing sites or state national guard collection sites for COVID-19 are 1) reporting ELR at all, 2) providing all required information and 3) those reporting on paper requisitions will not be providing LOINC or SNOMED CT codes and are often lacking demographics, specimen source and other required PHA elements. 

Throughout the data collections and flows there are numerous challenges  in terms of data not being able to be collected (even if it could be available), not being documented, not using standard vocabulary, not including it in the order, not forwarding certain data, dropping standard vocabulary, not retaining data, not communicating data available to the PHA. 

Currently the specific challenges in that area are:

  • Device identification data is not included in device/test documentation
    • The latest LIVD guidance (IICC spreadsheet) nor the balloted but not yet published LIVD FHIR based IG does not include an ability for the relevant identifier for each test kit.  (AP:  LIVD does include capability for vendor instrument device information in the Equipment UID field and Equipment UID Type field.  LIVD provides a Vendor Analyte Code and Vendor Reference ID for the test kit/reagent, but it's not specified if one or either of these could/should be used for test kit UDI or if new field is desired.  Topic for future LIVD call? HJB: Agreed we need to clarify between current LIVD guidance in IICC spreadsheet vs. non-published LIVD FHIR IG vs. upcoming LIVD FHIR IG.)
  • Deployed lab order implementation guides do not include the guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently.
    • The latest eDOS guide has the commonly used set of AOEs with standard LOINC codes and where applicable answer sets, but is not complete to cover the latest updates at this time.
    • The latest LOI guide addresses the ability to communicate all relevant data, including any AOEs, but is not deployed in active use.
    • Upgrading to the latest LOI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation.
  • Deployed lab reporting implementation guides do not include the guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently, nor the relevant device information, nor sufficient clarity on minimum desired demographic data (some fields may need to be marked RE rather than O, or X).
    • The latest LRI guide (that now includes ELR in form of the PH_component) accommodates the ability to send any relevant AOEs, but may need more specificity on other patient demographic data already available in PID, PV1 or PD1, and will need added guidance on how to convey the relevant device/test kit(s) used to perform the test.
    • Upgrading to the latest LRI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation.

As indicated before, there are many other challenges to ensure that data is fully, accurately, and consistently documented and communicated, including use of encoded standard vocabulary (at least along with any local coding that remains relevant), but that is not addressed here.  Our goal is to provide guidance on how to address the above challenges in the necessary implementation guides that can be deployed as quickly as possible and as consistent as possible across ALL jurisdictions.

In short, the challenges this guidance is looking at is ensuring that the relevant data can be communicated from ordering provider through a potential intermediary lab to the performing lab and on to PHA as an ELR in a complete, standard, consistent format and with vocabulary, with the least amount of effort to meet the deadlines.

Requirements

The following data set is desired to be made available as part of an ELR transaction, whatever version of the HL7 ORU message is used, as much as available upon placing the order and to the extent that the laboratory has access to any additions before the ELR is sent.

Optionality Legend: O-Optional, R-Required (cannot be blank), RE-Required but can be empty if not available, ND-Not Desired by HHS, NF-Not Forwarded to HHS, C-Conditional

Demographic Data

SeqNameOptionalityDefinitionHL7 MappingImplementation guidanceComments / Open questions
1Patient date of birthRE-PHA, O-HHSThis is the preferred field to populate.PID-7

2

Patient age Hans Buitendijk since this is really handled as AOE should it be moved there, or keep here, because it does NOT flow across orders?

C-PHA, RE-HHS

Condition for PHA: If Patient Date of Birth is not available, then include the age at time of specimen collection using the methodless LOINC (30525-0^Age^LN) in case it is not in a dedicated field or cannot be calculated correctly at the time the order is placed.

For reporting from PHA to HHS (CDC), when DOB may not be included or in ELR, when DOB is not available.

OBX-5

Send as AOE OBX:

OBX-2 = NM (can be SN)
OBX-3 = 30525-0^Age^LN
OBX-5 = numeric value
OBX-6 = age units in UCUM as applicable - expected as years => a^year^UCUM
other options:
months => mo^month^UCUM
days => d^day^UCUM
hours => h^hour^UCUM
OBX-29 = QST

Question: Can HHS accept DoB and figure out the age so we don't need to calculate? 

3Patient raceRE-PHA, RE-HHSUsed for socio-demographic analytics, and as permitted by jurisdiction.  This may be different than the race used for clinical interpretation (e.g., reference range).  If a race is needed for clinical interpretation as well, that must be communicated with an AOE in addition to this field.PID-10

Code as follows:
1002-5^American Indian or Alaska Native^HL70005
2028-9^Asian^HL70005
2054-5^Black or African American^HL70005
2076-8^Native Hawaiian or Other Pacific Islander^HL70005
2106-3^White^HL70005
PHC1175^Refused to answer^CDCPHINVS or use ?

When the value is unkown, leave blank.

  • FH: Race and Ethnicity have an extra value not in the 2018 Lab Value spreadsheets:  "PHC1175^Refused to answer^CDCPHINVS", do we need an action item to update the Value Set spreadsheets?  (I was not successful updating the spreadsheet so added question here)  HJB: Agreed. RM: Unknown is also NOT in the value set - should we provide guidance to leave empty if unknown or add UNK from V3 Nullflavor?
4Patient ethnicityRE-PHA, RE-HHSUsed for socio-demographic analytics, and as permitted by jurisdiction.  PID-22

Need to create a new value set

Code as follows:
H^Hispanic or Latino^HL70189
N^Not-Hispanic or latino^HL70189
U^Unkown^HL70189
PHC1175^Refused to answer^CDCPHINVS 

Race and Ethnicity have an extra value not in the 2018 Lab Value spreadsheets:  "PHC1175^Refused to answer^CDCPHINVS", do we need an action item to update the Value Set spreadsheets? 

5Patient sexRE-PHA, RE-HHSUsed for socio-demographic analytics, and as permitted by jurisdiction.  This may be different than the sex used for clinical interpretation (e.g., reference range).  If a sex is needed for clinical interpretation as well, that must be communicated with an AOE in addition to this field.PID-8

Send only the codes from HL70001 table

(PHVS_AdministrativeSex_HL7_2x)


6Patient residence zip codeRE-PHA, RE-HHS
PID-11.5

Some jurisdictions consider a combination of age, sex and zipcode PII, because of the population densitiy - need to accommodate that by allowing creation of regions (and that may be better done in the county field)

7Patient residence countyRE-PHA, RE-HHS
PID-11.9ELR R1 requires use of numeric FIPS 6-4 codes (PHVS_County_FIPS_6-4)

Some jurisdictions consider a combination of age, sex and county PII, because of the population density - need to accommodate that by allowing creation of regions


8Patient name (Last name, First name, Middle Initial)R-PHA, NF-HHS
PID-5

9Patient street addressRE-PHA, NF-HHS
PID-11.1

10Patient phone number with area codeRE PHA, NF HHS
PID-13This assumes it is the patient's home phone

Order Data

SeqNameOptionalityDefinitionHL7 MappingImplementation guidanceComments
1Ordering provider addressRE-PHA, NF-HHS
ORC-24.1

2Ordering provider phone numberRE-PHA, NF-HHS
ORC-14/OBR-17

3Ordering provider name and NPI (as applicable)RE-PHA, RE-HHSIf the ordering provider is not known, then the ordering facility should be included.OBR-16Ordering Provider Name is in OBR-16.2 and OBR-16.3; NPI would be OBR-16.1; when populating OBR-16.1 also populate ORC-12.9/OBR-16.9 as: "NPI&2.16.840.1.113883.4.6&ISO"
and ORC-12.13/OBR-12.13 as "NPI"

For some testing there may not be a specific ordering provider (e.g. employment related testing, mass screening) - it is a CLIA requirement so need to ensure that this is provided. 

What about ordering provider for home test (is covered through doctor office or on-line doctor who ordered).

For drive-thru it is possibly the Surgeon General or appropriate Medical officer

4Ordering provider zipRE-PHA, C-HHS

The zip code of the location where the ordering provider is located at the time of ordering.  

Condition: If patient is in a low density area this should not be forwarded to HHS.

ORC-24.5


5Date test ordered (date format)RE-PHA, RE-HHS
ORC-15
For the PH_HHS_ELR_Guidance_component this element will be RE
6Test ordered – use harmonized LOINC codes provided by CDCR-PHA, R-HHSThe test currently being reported to PHA as the test orderedOBR-4LOINC is strongly recommended in ELR R1

The LIVD document in the link currently does not cover order LOINCs - that needs to be clarified by HHS

Ask at Order Entry

Valueset for Y/N/U - Use PHINVADS valueset (Y/N from HL70136 and UNK from V3 Nullflavor) that is used for Case notifications: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.888.  U is replaced with UNK below.

Suggest to HHS to include Asked but Unknown (UASK) and/or refused to answer?

SeqNameOptionalityDefinitionAllowable AnswersImplementation GuidanceComments
1

First test

Suggest to HHS to change to: Whether this is the patient's first test for the condition of interest


RE-HHSPatient's first test for the condition of interest that is being ordered.Y/N/UNKOBX-2 = CWE
OBX-3 = 95417-2^First test for condition of interest^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 95417-2^Whether this is the patient's first test for the condition of interest^LN

Questions:

  • What is the intent of its use and does the patient have to answer it?
  • Is this for the exact test code ordered, or the type of order?  If the latter, what types do we need to consider like or different?  E.g. if a provider is ordering a COVID-19 serology test, but the patient has had a PCR test done in the past, would we say Y or N?  
  • Is this only for tests ordered within that organization, or ordered anywhere anytime?  E.g., since it’s possible that the patient has had other tests through other means (e.g. walk-up clinics, or at a separate ED, etc.)?
  • Is it relevant for previous test for diagnostic, screening, or research.
  • Is there clarification between first diagnostic test and first screening test?
  • Hans to check with HHS CIO office.
2

Employed in healthcare?

Suggest to HHS to change to: Whether patient is employed in a healthcare setting


The main focus is on patients who work in a high-risk setting with patients who could be a super spreader. (first responders, front line clinicians, environmental staff, therapists, in direct contact with patients or in their location).

Y/N/UNK


OBX-2 = CWE
OBX-3 =  95418-0^Employed in a healthcare setting^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 95418-0^Whether patient is employed in a healthcare setting^LN


3

Symptomatic as defined by CDC?

Suggest to HHS to change to: Whether patient has symptoms related to condition of interest

RE-PHA, RE-HHSSymptomatic per current CDC guidance at time of order for the reportable condition/illnessY/N/UNKOBX-2 = CWE
OBX-3 = 95419-8^Has symptoms related to condition of interest^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 95419-8^Whether patient has symptoms related to condition of interest^LN


4

Date of Symptom Onset

Suggest to HHS to change to: Illness or injury onset date and time 

C-PHA, C-HHS

Condition: If Symptomatic is Y.mm/dd/yyOBX-2 = DT
OBX-3 = 11368-8^Illness or injury onset date and time^LN
OBX-5 = formatted as YYYYMMDD
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 11368-8^llness or injury onset date and time^LN

5

Hospitalized?

Suggest to HHS to change to: Whether patient was hospitalized because of this condition


RE-PHA, RE-HHS

Patient has been hospitalized for the reportable illness/condition that this order has been placed for (suspected or diagnosed)

When ordered during ER duration, the answer would be N.


OBX-2 = CWE
OBX-3 =  77974-4^Patient was hospitalized because of this condition^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 77974-4^Whether patient was hospitalized because of this condition^LN


When interested in whether hospitalized at time of order, use PV1-2 (Patient Class).

6

ICU?

Suggest to HHS to change to: Whether patient was admitted to intensive care unit for condition of interest

RE-PHA, RE-HHS

Patient has been admitted/transferred to the ICU at any time during the encounter for the reportable illness/condition that the order has been placed for (suspected or diagnosed).

Y/N/UNKOBX-2 = CWE
OBX-3 =  95420-6^Admitted to intensive care unit for condition of interest^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 95420-6^Whether patient was admitted to intensive care unit for condition of interest^LN

When interested in whether in ICU at time of order, use PV1 location/organization providing care.

7

Resident in a congregate care setting (including nursing homes, residential care 
for people with intellectual and developmental disabilities, psychiatric treatment 
facilities, group homes, board and care homes, homeless shelter, foster care or other setting)

Suggest ot HHS:  Whether patient resides in a congregate care setting

RE-PHA, RE-HHS

This is at time of exposure where they normally live.Y/N/UNKOBX-2 = CWE
OBX-3 =  95421-4^Resides in a congregate care setting^LN
OBX-5 OBX-5 can be one of:
Y^Yes^HL70136
N^No^HL70136
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 95421-4^Whether patient resides in a congregate care setting^LN

8Pregnant?C-PHA, C-HHS

Condition: If patient is female

Current pregancy status of the patient

Pregnant, Not pregnant, UnknownOBX-2 = CWE
OBX-3 =   82810-3^Pregnancy status^LN
OBX-5 = can be one of:
77386006^Patient currently pregnant^SCT
102874004^Possible pregnancy^SCT
60001007^Not pregnant^SCT
UNK^Unknown^NULLFL
OBX-11 = F
OBX-14 = Date question was answered
OBX-29 = QST

LOINC: 82810-3 Pregnancy status

LOINC from https://loinc.org/sars-cov-2-and-covid-19/

Specimen Collection

SeqNameOptionalityDefinitionHL7 MappingImplementation guidanceComments
1Date specimen collected (date format)R-PHA, R-HHS

OBR-7

also in SPM-17 (2.5 and up)

OBR-7 is required;ELR allows use of 0000, when date is unknown
2Specimen Source - use appropriate LOINC, SNOMED-CT, or SPM4 codes, or equivalently detailed alternative codesR-PHA, R-HHS

SPM-4 (after 2.5)

OBR-15.1



SPM-8 (after 2.5)

OBR-15.1

Code to SNOMED CT codes for SPM-4 as provided in the vendor specimen description column of the LOINC mapping tab in the LIVD document; ELR also allows use of both SNOMED CT codes from the speicmen hierarchy (PHVS_Specimen_CDC) and  HL70487 codes (PHVS_SpecimenType_HL7_2x)

Some labs may support the sending of source site information; ELR R1 uses SNOMED CT codes compiled in the HITSP body site value set (PHVS_BodySite_HITSP)


3Accession #/Specimen IDR-PHA, R-HHS

ORC-3/OBR-3

SPM-2 (V2.5 and up)

This is the testing lab's specimen ID or accession number - may also send the submitters specimen ID / accession number
In older versions of HL7 only ORC-3/OBR-3 can be used; for the submitter's accession number use ORC-2/OBR-2.


Test Result

SeqNameOptionalityDefinitionHL7 MappingImplementation guidanceComments
1Performing facility name and/or CLIA number, if knownR-PHA, R-HHS

OBX-23 (V2.5.1 and up)

ORC-15

In older versions of HL7 OBX-15 (Producer's ID can be used for the Performing Lab ID) or it can be conveyed in the NTE following the result OBX, ensuring it is included on the report.


2Performing facility zip codeR-PHA, R-HHS
OBX-24 (V2.5.1 and up)In older versions of HL7 this information can be conveyed in the NTE following the result OBX, ensuring it is included on the report.


3Device IdentifierRE-PHA, RE-HHS

The test kit/reagent(s) used to perform the test, and as necessary the instrument platform(s) when used off-label.  The EUA may be used when used as authorized.


OBX-17




OBX-18 (v2.4 and up)

Use OBX-17 when describing the manufacturer and model of either test kit (reagent) or instrument used; or when referencing the EUA (see more detailed guidance below).
Use OBX-18 when passing the serial number or UDI of the test kit (reagent) or instrument

The model is acceptable.  It is allowed to use the Device Identifier (as defined per FDA's UDI definition) or the UDI Carrier (the full human readable form of the barcode) instead or as well if that can be obtained.

For the PH_HHS_ELR_Guidance_component OBX-18 will be RE

4Test result R-PHA, R-HHSThis is the code of the test being resulted.OBX-3LOINC Is required in LRI and ELR R1, when an appropriate LOINC exists - since this points to LIVD, as long as LOINC is listed there for the manufactueer test kit, MUST use.Include the fully structured test code, name, and code system of the applicable LOINC code in accordance with the CDC guidance for the reportable illness/condition
5Test result valueR-PHA, R-HHSThe result value.OBX-5

For coded results use the appropriate SNOMED CT code for qualitative result values in accordance with the CDC guidance for the reportable illness/condition.

For numeric results include units in OBX-6 when appropriate (code units in UCUM)

Suggest to HHS to clarify, that not all results are coded.

6Test Result dateRE-PHA, R-HHSThe date the test result was obtained and approved for release

OBX-19 (V2.4 and later)

OBR-22 (as proxy in V2.3.1 and earlier)? HANS??

Must be sent for each result - may not be populated for AOE OBX segments


Updates to Implementation Guides

The following updates need to be made in the base implementation guides for a next version to include the short-term Implementation Guidance provided in the next section.

  • LIVD
    • Add the device identifier for the test kit in the correct resource (DeviceDefinition or ObservationDefinition?)
      •  Need a product reference uid to identify the ObservationDefinition OR is it really on the DeviceDefinition?
        • If on the ObservationDefintion, need to re-include ObservationDefinition.identifier 0..*
          • identifier.type = "product-reference-identifier"
          • identifier.system = TBD (for uid)
        • If on the DeviceDefinition .....
    • Add the assigning authority as well.  This is particularly important for OBX-18.3 if the identifier is not an official device identifier.
  •  eDOS
    • Add new AOEs to master list, but nothing needed for the rest 
  •  LOI
    • CLIA test request requirements listed under Resources below.
    • Update the value sets for race and ethnicity
    • ??
  • LRI
    • Add PH_HHS_ELR_Guidance_Component that provides:
      • Guidance on how to convey device identification information
        • Report information about the manufacturer and model in OBX-17 (can repeat to accommodate the test kit and the instrument)
        • Report instance information (i.e. the serial number / UDI) in OBX-18 (can repeat), changing usage of OBX-18 to RE
        • Can also be sent in PRT
      • Support for Test order date by shcnging usage of ORC-15 to RE
      • Create the MSH-21 component ID
      • Update the value sets for race and ethnicity
      • Update conformance statement around OBX-14 timing
      • Identify use of OBX-29 as part of this profile (not sure how to best do that, since that is already part of the base) Hans Buitendijk??

Implementation Guidance

General

  • Data Elements
    • Use proper segments per Mapping in the table above for PID, ORC, OBR, and if applicable to your version of HL7 SPM fields.
      • If the guide indicates they are optional or not supported, apply the usage as listed in the Optionality column above.
      • If not possible, then use OBX segments using LOINC codes Hans Buitendijk  - now that we took the mapping spreadsheet out, should we just point to eDOS Appendix?
    • For socio-demographic relevant data for population level analytics, use the fields in PID and consider them RE.  These include:
      • race
      • sex
      • ethnicity
    • Although not a specific requirement for HHS, if you need to convey the clinical relevant values for for interpretation of lab result for the following data, use AOE OBX as provided by the lab:
      • race
      • ethnicity
      • sex
  • Orders - Any HL7 v2 ORM or OML message in place between Ordering Provider and Laboratory as well as Laboratory and Reference Laboratory where the tests are outsourced.
      • Use LOI R1 STU 3 Section 1.4.10 and 6.15 for specification on how to add AOEs using pre-adopted OBX capabilities. (RM: I guess we want folks to go looking at the sections rather than copying it here, right? Hans Buitendijk?)
      • Include Profile PH_HHS_ELR_Guidance_Component in MSH-21 so receiving system recognizes it may contain OBX segments that are based on HL7 v2.8.2.
      • Use eDOS R2 STU 3 Appendix A for an initial list of AOEs in addition to any listed above
      • AOEs are sent as OBX segments after the OBR it applies to, but before the SPM.
      • AOE OBX segments include OBX-29 as pre-adopted element (from v2.8.2) that is valued "QST" (from HL70936_USL in the Lab Value Set Companion_Guide)
      • It is expected that the AOE description in the message is drawn from LOINC.
  • Results - Any ELR to PHA
    • Use LRI R1 STU 3 Section 8.11 and 13.3.3 for specification on how to add/forward AOEs with the result using OBX segments that are based on HL7 v2.8.2  (AP note:  AOEs become/are results and their values in OBX 3/5 messages sent to providers and PHA via ELR.  HJB: clarified in both Orders and Results.  Thank you!)
    • WE ALREADY HAVE THAT UNDER DATA ELEMENTS - rmeove here? Hans Buitendijk Use Mapping for PID, ORC, OBR, OBX, and SPM fields for the data elements listed in the tables above and according to the optionality listed in those tables.
    • Use Device Identifier guidance below
    • AOEs are sent as OBX segments after the OBR it applies to, but before the SPM.
  • Strongly Recommended
    • Adopt LIVD as quickly as possible to stay informed on latest LOINC mappings and device identification information
    • Adopt eDOS Attachment A as quickly as possible to stay informed on latest AOEs per test. 
    • Adopt LOI Rn as quickly as possible to enable most consistent and complete communication of Lab orders.
    • Adopt LRI Rn, including specifically the LRI_PH_component, as quickly as possible to enable most consistent and complete communication of ELR.

Mapping Spreadsheet - remove this section?

Use this spreadsheet to map the HHS elements to various places in order and result/ELR messages.

We strongly recommend to pre-adopt where more currrent versions (up to v2.8.2) have been used in the latest LOI/LRI(ELR) guides.  When you pre-adopt any elements beyond the version you currently support, include the following in MSH-21: [get a profile from Ted - Hans]

You should encode fields according to the respective guides referenced above as indicated.


Device Identification

There are four components that are potentially of interest for which to include an "identifier":

  • Testkit/reagent - This is the most important one to communicate.  If multiple test kits/reagents are used, all need to be included.
  • Instrument Platform - This is needed if the test kit/reagent is used off-label with a different instrument OR multiple instrument platforms were used as well.
  • Manual kit - This is needed if the test was performed manually.
  • Emergency Use Authorization -  This can be used when a particular combination of testkit/reagent(s) and instrument platform(s) is used that is authorized by an EUA.  In this case the individual test kit/reagent(s) and instrument platform(s) do not need to be communicated as well.

There is no need to include identification information for calibrators, controls, or collection devices.

These devices can be identified as a kind of using two different approaches:

  • Model Name
    • The most likely information available for a testkit/reagent or instrument platform is a model name (unofficial or official); usually when combined with the name of the manufacturer it is unique.
  • Emergency Use Authorization Identifier
    • Defines the particular combination of testkit/reagent(s) and instrument platform(s) is used that is authorized by an EUA as listed on the FDA websitehttps://www.fda.gov/medical-devices/coronavirus-disease-2019-covid-19-emergency-use-authorizations-medical-devices/vitro-diagnostics-euas#individual-molecular
    • The combination of the value listed in the "Manufacturer" column and the value listed in the "Diagnostic (Letter of Authorization)" - including all spaces and special characters (except (TM) or (R)) creates the official name for this EUA
      • a "+" at the end of the Diagnostic might indicate a significant update and consitutes a new entry in the table
      • The goal is to provide that string in the CDC LIVD mapping file in the "Equipment UID" column, identifying the "Equipment UID Type" as EUA. e.g for the following EUA:
        • COVID-19 Coronavirus Real Time PCR Kit Jiangsu Bioperfectus Technologies Co., Ltd.
    • A smiliar identifier can be created for Lab Developed Tests (LDT) based on Appendix A table by combining "Laboratory" and "Letter Granting Inclusion under EUA", e.g. for the following
      • Cormeum SARS-CoV-2 Assay_Cormeum Laboratory Services
  • Device Identifier
    • This must then be the device identifier according to the UDI definition by the FDA
    • The manufacturer would have made this available, e.g. through their LIVD spreadsheet or otherwise and this likely would have been configured into the LIS so it need not be entered by a user at time of testing.


The device identification information will be captured in either OBX-17 when describing the kind and OBX-18 when describing an instance.


In order to differentiate which of the devices is being described we propose a list of abbreviations to represent each kind (for use in OBX-17)

ElementType of identifierAbbreviation for the type
Emergency Use AuthorizationEUAEUA
Testkit/reagentModelMNT
Testkit/reagentDevice IDDIT
Instrument PlatformModelMNI
Instrument PlatformDevice IDDII
Manual kitModelMNM
Manual kitDevice IDDIM

In OBX-17 (specifications using the CWE datatype like ELR R1V2.5.1 will populate the original text component (OBX-17.9) / specifications using CE will populate the text component (OBX-17.2) based on the following formula to construct the string based identifier: <Model name or Device ID>_<Manufacturer name>_<Abbreviation for the type>

Alternatively these devices can be identified as the specific instance used in testing by their UDI as defined by FDA (for use in OBX-18).

  • UDI Carrier
    • The full representation of the barcode in human readable form.
    • Likely only obtained through scanning.

Since the OBX-17 and OBX-18 fields can repeat, multiple values can be communicated.  However, given the structure of OBX-17 and OBX-18 we cannot maintain proper relationships between test kits/reagents and instrument platform if more than one instrument platform needs to be declared AND there is no EUA identifier available (Hans Buitendijk I thought Mike said this will not happen, so can we remove this sentence?).  While the newer PRT segment can improve on this somewhat, it still would require a new field to maintain these relationships.  Shifting to FHIR where this already can be addressed is not realistic in the timelines needed and given most LIS/LIMS currently lack FHIR functionality.  However, given the likely configurations being used, we do not believe we need to address that yet while data curation in the analtyics phase can address this challenge. 

ScenarioLocation in messageFormat to be usedInstructionsWhere to find the information
Cepheid Xpert Xpress SARS-CoV-2 test used as described in EUAOBX-17Xpert Xpress SARS-CoV-2 test_Cepheid _EUA<Diagnostic (Letter of Authorization)>_<Manufacturer name>_EUA

CDC LIVD mapping file in the "Equipment UID" column

Abbott ID now as described in EUAOBX-17ID NOW COVID-19_Abbott Diagnostics Scarborough, Inc. _EUA<Diagnostic (Letter of Authorization)>_<Manufacturer name>_EUACDC LIVD mapping file in the "Equipment UID"  column
LDT listed in Appendix A OBX-17

Cormeum SARS-CoV-2 Assay_Cormeum Laboratory Services_EUA

<Letter Granting Inclusion under EUA>_<Laboratory>_EUACDC LIVD mapping file in the "Equipment UID"  column





CDC test run on Abbott m2000 using model namesOBX-17 for test kitCDC 2019-nCoV Real-Time RT-PCR Diagnostic Panel_CDC_MNT<Test kit name>_<Manufacturer name>_MNTName used in package insert?
CDC test run on Abbott m2000 using model namesOBX-17 for instrumentm2000 RealTime System_Abbott_MNI<Instrument name>_<Manufacturer name>_MNILIVD file from Abbott in the "Model" column





bioMérieux ARGENE SARS-COV-2 R-GENE test run on ABI 7500 Fast Dx Real-Time PCR Instrument using device IDOBX-17 for test kit423735_bioMérieux_DIT<Device ID>_<Manufacturer name>_DITLIVD file Vendor reference number ?? (that's what I used for this example - maybe we can get real device ID?)
bioMérieux ARGENE SARS-COV-2 R-GENE test run on ABI 7500 Fast Dx Real-Time PCR Instrument using device IDOBX-17 for instrument4351106_Applied Biosystems_DII<Device ID>_<Manufacturer name>_DIICatalog# - maybe be can check and replace with an instrument we can get a device ID for?





Manual test kit for AB testing using model nameOBX-17 for manual test kitSARS-CoV-2 IgM/IgG Antibody Test Kit_Biohit Healthcare_MNM<Manual kit name>_<Manufacturer name>_MNMCDC LIVD mapping file in the "Model"  column or would that make this EUA? else Name used in package insert?





PH Lab developed test kit on Roche Cobas 6800 using model name for bothOBX-17 for test kitSARS-COV-2 rt-PCR_SLOPHL_MNT<modelname = whatever the lab calls it>_<Labname = manufacturer name>_MNTPH lab documentation
PH Lab developed test kit on Roche Cobas 6800 using model name for bothOBX-17 for instrumentcobas® 6800/8800 Systems_Roche_MNI<IVD platform model name>_<Manufacturer name>_MNILIVD file from Roche in the "Model" column
PH Lab developed test kit on Roche Cobas 6800 using model name for kitOBX-17 for test kitSARS-COV-2 rt-PCR_SLOPHL_MNT<modelname = whatever the lab calls it>_<Labname = manufacturer name>_MNTPH lab documentation
PH Lab developed test kit on Roche Cobas 6800 usingUDI for instrumentOBX-18 for instrument

[udi carrier]^2.16.840.1.113883.3.3719^ISO

OBX-18.1 = [udi carrier]

OBX-18.3 = "2.16.840.1.113883.3.3719"

OBX-18.4 = "ISO"

GUUID??





Using Roche COBAS INTEGRA 400 plus using UDIOBX-18 4015630924592 GTIN

not sure here - this does not seem to be an instance ID, but rather the device ID of the UDI, correct? Would this be in OBX-17 as: 4015630924592_GTIN_DII Hans Buitendijk

LIVD file from Roche "Product Reference UID" provides the identifier; "Product Reference UID Type" provides the assigning authority for the UDI
UDI carrier scanned on  barcode using OIDOBX-18

OBX-18.1 = [udi carrier]

OBX-18.3 = "2.16.840.1.113883.3.3719"

OBX-18.4 = "ISO"

???
UDI carrier scanned on barcode using URIOBX-18

OBX-18.1 = [udi carrier]

OBX-18.3 = "http://hl7.org/fhir/NamingSystem/fda-udi"

OBX-18.4 = "URI"

???

Need to get additional guidance on where to go to get the values for the fields above] (AP:  Expect many to be on package labels per the GUDID website, and perhaps a Package Insert, if Mike can confirm?  Laboratory professionals will need to find them from their vendor shipments. Can we also confirm that they are on the actual reagent packs and not only the external boxes?  Some labs may take reagent packs out of boxes and through away the external boxes and thus not retain the UDI.  Also these currently aren't stored in the LIS.  Do we wish to point folks to a "blank" LIVD sheet so they can collect the UDIs for instruments and reagents or if they have LDTs?  Given a small number of IVD vendors currently provide LIVD content.  They may download 2 LIVD maps from vendors for their commercial assays and if they have created a LDT, need to enter their own info.  BTW, the examples above are fantastic!)

  • Is there expectation that LDTs would have a UDI and how would that be acquired? If not, what is entered when there is no UDI? N/A? Is field blank? see scenarios below.
    • May wish to distinguish LDTs using IVD reagents for a different non 510 k /EUA approved specimen type versus a LDT with totally different reagents, such as own reagents created from scratch.  RM: I DID NOT use this as the speciment type is in SPM - but assume this should be like CDC test run on Abbott m2000 - choice of either the model name or the device ID
    • If LDT uses commercial test kit reagents with UDI on IVD platform with UDI, but with modification (i.e. specimen, reporting) that makes it LDT, expect reagent UDI and instrument UDI can be sent as specified, but should confirm with FDA whether an issue as would appear same as non LDT. RM - did not add to table
    • If LDT uses non commercial test kit reagents without UDI (i.e. home made reagents) on IVD platform with UDI, expect no UDI for reagents, but one for instrument.
    • If LDT uses non commercial test kit reagents without UDI (i.e. home made reagents) on IVD platform without UDI, expect no UDI for reagents or instrument. - would use <modelname = whatever the lab calls it>_<Labname = manufacturer name>_MNT and <IVD platform model name>_<Manufacturer name>_MNI - see example for PHL
  • UDI for manual test kits and LDTs (non analyzer performed tests)? Done - see example for AB rapid test

Flat File

ONLY if no HL7 v2.x support then use flat file (link: Ulrike Merrick to add ONCE AVAILABLE).  But if you have a HL7 v2 feed continue to use and upgrade as quickly as possible.

If you do not have an HL7 v2 feed, work with your PHA to determine when you can put that in place.

Open questions on spreadsheet

  • Copy final tables into tabs of a spreadsheet to enable download.

Open Issues

  • If the ELR R1 is in use and supports PI attestation, will inclusion/adoption of this guidance invalidate that attestion.

Closed Issues

  • Replaced by the table above:

    • The following provides specific guidance what to put where depending on the kind of identification information available for the component being documented. 

      • Model Name
        • The most likely information available for a testkit/reagent or instrument platform is a model name.
        • Testkit/reagent:
          • In 2.3.1 or later later: OBX-17.9 = "MNT" + [some agreed to character that is not widely used] + [model name] + [some agreed to character that is not widely used] + [manufacturer name if available]  (example: CDC 2019-nCoV Real-Time RT-PCR Diagnostic Panel_CDC  OR  CDC 2019-nCoV Real-Time RT-PCR Diagnostic Panel_CDC _ MNT)
          • In v2.3 or earlier: OBX-17.2 = [model name] + [some agreed to character that is not widely used] + [manufacturer name if available] + "MNT"
        • Instrument Platform:
          • In ELR OBX-17.9, in older versions OBX-17.2 = "MNI"+ "[some agreed to character that is not widely used] +[model name] + "[some agreed to character that is not widely used] + [manufacturer name if available] (example: ABI 7500 Fast Dx Real-Time PCR Instrument Applied Biosystems  OR  ABI 7500 Fast Dx Real-Time PCR Instrument Applied Biosystems _ MNI)
        • Manual Kit:
          • In ELR OBX-17.9, in older versions OBX-17.2 = "MNM"+ "[some agreed to character that is not widely used] +[model name] + "[some agreed to character that is not widely used] + [manufacturer name if available] (example: 
      • Emergency Use Authorization Identifier (include hyperlink - Riki)
        • In HL7 2.3.1 and later: OBX-17.9
        • In HL7 v2.3 and earlier: OBX-17.2 = "EUA" + "[some agreed to character that is not widely used] + [device identifier] + "[some agreed to character that is not widely used] + [manufacturer name if available]  (example: ID NOW COVID-19_Abbott Diagnostics Scarborough, Inc. _EUA)
      • Device Identifier
        • This must then be the device identifier according to the UDI definition by the FDA
        • The manufacturer would have made this available through their LIVD spreadsheet and likely would have been configured into the LIS so it need not be entered by a user at time of testing.
        • provided by the manufacturer in some way.
        • Testkit/reagent:
          • In ELR OBX-17.9, in older versions OBX-17.2 = "DII" + "[some agreed to character that is not widely used] + [device identifier] + "[some agreed to character that is not widely used] + [manufacturer name if available] (Example: 4015630924592 _ Roche _ DII)
        • Instrument Platform:
          • In ELR OBX-17.9, in older versions OBX-17.2 = "DII" + "[some agreed to character that is not widely used] + [device identifier] + "[some agreed to character that is not widely used] + [manufacturer name if available]
        • Manual Kit: OBX-17.2 = "DIM" + "[some agreed to character that is not widely used] + [device identifier] + "[some agreed to character that is not widely used] + [manufacturer name if available]
      • UDI Carrier
        • The full representation of the barcode in human readable form.
        • Likely only obtained through scanning.
        • Option 1)
          • OBX-18.1 = [udi carrier]
          • OBX-18.3 = "2.16.840.1.113883.3.3719"
          • OBX-18.4 = "ISO"
        • Option 2)


  • Some of the AOEs may be able to be answered based on knowledge in the system (e.g. is patient hospitalized = Patient class is inpatient in encounter)
    • We should do an analysis of which of these HHS questions are available in the EHR-s (and in what format) and then decide on the best way to share that data, e.g., use PID/PD1/PV1/PV2/NK1 (occupation) - I got some feedback, that UNLESS the element is already in ELR R1 (like PV1-2), OBX segments will be easiest in the short term to add to the surveillance system.
    • Understanding is some drive up/drive through COVID testing sites are using paper requisitions for ordering, so data elements would be required on paper req to performing lab, who would enter them into their results reporting to PHA ELR message (if provided!).
    • ADDRESSED
  • Options for differentiating OBX for AOE vs OBX for results:  (Hans Buitendijk  can we delete this note since we talked about this?AP Note:  The AOE question and response, would be represented as a result and result value.  The LOINC is likely the same for the AOE question and result in most cases.  However, they may have an order ID/identifier for the AOE, and a result ID for the result field to distinguish the two uses of the same data item.  Also is this question on the ELR/LRI?)
    • NOTE: I used the OBX-29 in all of these example messages; we will need to update the OBX-14 conformance statement ELR-051 that compares OBX-14 to OBR-7 and SPM-17: based on OBX-29 is valued 'RSLT' or is not valued 'QST"?
    • LOINC code  
    • OBX-29 as in LOI/LRI 
    • In eDOS, AOE is represented in OMC-4, while OMC-11 defines the allowed answers and OMC-9 defines the expected datatype of the answers and OMC-6 describes the location where it can be found in the message instances.
    • In LOI, AOE is represented in OBX after the OBR it belongs to.
    • ADDRESSED
  • While communication of a .csv or flat file from performing lab to PHA, if the above guidance cannot be implemented in time, is out of scope of HL7 to define format, we could make some suggestions on what to include to match with the ELR transaction that it needs to match up with.  
    • APHL is creating a flatfile format for this purpose (not csv, but rather tab delimited) - the elments in this flatfile are all mapped to the respective ELR R1 location, so that transformation could occur at the sender or receiver side (conversion tooling for the PHAs is being discussed) Current version of the file (still submject to change: 
    • Suggest to allow for Direct Messaing to convey the file. Riki: need to check with the PHA, what transport mechanism they allow, but I don't see why it shouldn't be an option
    • Why not just use ELR in xml format via Direct? Riki: Because this is for manual data entry
    • ADDRESSED
  • What shall we point to for LIVD latest guide? If this is for the link to the LIVD specification, I think we need to use the IICC site (since IVD on FHIR is not yet published) - if to the COVID specific LOINC listing on the CDC site - that is embedded in the HHS guidance etter and also already in Resources for Background
    • ADDRESSED

Resources for Background

  • Link to current guidance: https://www.hhs.gov/sites/default/files/covid-19-laboratory-data-reporting-guidance.pdf
  • Link to FAQ document: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4996955/
  • Information Blocking Actors:  https://www.healthit.gov/cures/sites/default/files/cures/2020-03/InformationBlockingActors.pdf  (Includes labs)
  • Information Blocking Definition:  https://www.healthit.gov/topic/information-blocking
  • USCDI Data Classes, Elements and Standards:  https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf
  • CLIA regulations:  https://www.ecfr.gov/cgi-bin/text-idx?SID=1248e3189da5e5f936e55315402bc38b&node=pt42.5.493&rgn=div5
    • CLIA Order/test request/requisition info as aligned to HHS requirements is below.  Items I bolded apply to most of the AOEs, such as 8).
    • §493.1241   Standard: Test request.

      (a) The laboratory must have a written or electronic request for patient testing from an authorized person.

      (b) The laboratory may accept oral requests for laboratory tests if it solicits a written or electronic authorization within 30 days of the oral request and maintains the authorization or documentation of its efforts to obtain the authorization.

      (c) The laboratory must ensure the test requisition solicits the following information:

      (1) The name and address or other suitable identifiers of the authorized person requesting the test and, if appropriate, the individual responsible for using the test results, or the name and address of the laboratory submitting the specimen, including, as applicable, a contact person to enable the reporting of imminently life threatening laboratory results or panic or alert values.

      (2) The patient's name or unique patient identifier.

      (3) The sex and age or date of birth of the patient.

      (4) The test(s) to be performed.

      (5) The source of the specimen, when appropriate.

      (6) The date and, if appropriate, time of specimen collection.

      (7) For Pap smears, the patient's last menstrual period, and indication of whether the patient had a previous abnormal report, treatment, or biopsy.

      (8) Any additional information relevant and necessary for a specific test to ensure accurate and timely testing and reporting of results, including interpretation, if applicable.

      (d) The patient's chart or medical record may be used as the test requisition or authorization but must be available to the laboratory at the time of testing and available to CMS or a CMS agent upon request.

      (e) If the laboratory transcribes or enters test requisition or authorization information into a record system or a laboratory information system, the laboratory must ensure the information is transcribed or entered accurately.




  • No labels