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 57 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, 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 ??
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 PitkusUniversity of Wisconsin-Madison
Laura BleielEpic
Dan RutzEpic, IHE ???
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 WeditSLH Wisconsin
Jason HallCDC





















 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
  • 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
  • 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
  • RE - Required but may be Empty (Must support)
  • R - Required

Current Challenges

When ELRs are sent to PHA at times, they may not contain sufficient demographic, and other data as is necessary required by public health by law.  While some of that data could be part of a subsequent eCR, if the data is already available at time of order and ELR transmission before an eCR is available (or the next eCR is available) helps accelerate the process.  eCR is out of scope for this discussion., although important too, and so data would need to be aligned with it.

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

  • The device manufacturer provides label/insert information to the Laboratory to enable them to configure connections with their instruments
    • Format: paper, IICC spreadsheet, LIVD IG (future)
  • The performing laboratory (LIS) needs to inform the ordering provider (EHR) directly or through intermediary Lab on the AOEs relevant for the orderable tests in accordance with the CLIA Specimen Collection Manual
    • Format: Paper, eDOS IG
  • The ordering provider (EHR) needs to include with the order all available data at time of ordering on the request (order message) to the Lab, which may in turn forward to the actual performing laboratory that is responsible for the ELR submission
    • Format: Paper, HL7 v2.3 and higher using ORM, HL7 v2.5 and higher OML, HL7 LOI IG (future)
  • The performing Lab (LIS of public health lab or hospital or referral lab) back to ordering provider (EHR) or lab LIS (for referral specimens).  (HJB: Andrea, can you clarify which data flow this is?)
    • ??
  • The performing Lab (LIS) holds on to all information received and includes that plus the results and further information, e.g., identification of the device(s) used to perform the test, to Public Health Agency. 
    • Format: Various HL7 v2.x formats, ELR IG
  • The Public Health Agency forwards the information as appropriate (e.g., de-identified) to HHS (CSELS - HJB: is that accurate?)
    • Format: ??

[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. 

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. 
  • 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. 
    • 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 or PD1, while it does need 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

SeqNameOptionalityDefinitionComments
1Patient date of birthRE-PHA, N?-HHSThis is the preferred field to populate.
2Patient ageC-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 in case it is not in a dedicated field.

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

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.



4Patient ethnicityRE-PHA, RE-HHSUsed for socio-demographic analytics, and as permitted by jurisdiction.  PLEASE CONFIRM THIS APPLIES: his may be different than the ethnicity used for clinical interpretation.  If ethnicity is needed for clinical interpretation as well, that must be communicated with an AOE in addition to this field.


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.


6Patient residence zip codeRE-PHA, RE-HHS

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

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

ELR requires use of numeric FIPS 5-2 codes

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

9Patient street addressRE-PHA, NF-HHS

10Patient phone number with area codeRE PHA, NF HHS






Order Data

SeqNameOptionalityDefinitionComments
1Ordering provider addressRE-PHA, NF-HHS

2Ordering provider phone numberRE-PHA, NF-HHS

3Ordering provider name and NPI (as applicable)RE-PHA, RE-HHSIf the ordering provider is not known, then the then ordering facility should be included.

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 (if through doctor office or on-line doctor who ordered).

For drive-thru it is possibly the Surgeon General

4Ordering provider zipRE-PHA, C-HHSCondition: If patient is in a low density area this should not be forwarded to HHS.

Question: Which zip code should be used for a provider who has multiple locations?

5Date test ordered (date format)RE-PHA, RE-HHS

6Test ordered – use harmonized LOINC codes provided by CDCR-PHA, R-HHSThe test currently being reported to PHA as the test ordered

Question: Should this really be what the provider really ordered, vs. what OBR-4 actually contains going to ELR?  We interpret this as OBR-4 as valued at time of ELR?  Hans: Check with HHS CIO who wants this and why.

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.

SeqNameOptionalityDefinitionAllowable AnswersComments
1First testRE-HHS
Y/N/UNK

LOINC: ?

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: Patient works in 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


LOINC: ?

3

Symptomatic as defined by CDC?

Suggest: Patient currently has symptoms consistent with suspected reportable condition/illness

RE-PHA, RE-HHSSymptomatic per current CDC guidance at time of order for the reportable condition/illnessY/N/UNK

LOINC: ?

Question: Currently symptomatic or ever symptomatic (within the past x # of days/weeks)?

4

Date of Symptom Onset

Suggest: Illness or injury onset date and time 

C-PHA, C-HHS

Condition: If Symptomatic is Y.mm/dd/yy

LOINC: 11368-8 Illness or injury onset date and time

5

Hospitalized?

Suggest: 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.


LOINC: 77974-4 Patient was hospitalized because of this condition
6

ICU?

Patient has been admitted/transferred to the ICU for this condition?

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/UNK

LOINC: ?

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: Patient normally resides in a congregate care setting

RE-PHA, RE-HHS

This is at time of exposure where they normally live.Y/N/UNK

LOINC: ?

8Pregnant?C-PHA, C-HHS

Condition: If patient is female

Current pregancy status of the patient

Pregnant, Not pregnant, Unknown

LOINC: 82810-3 Pregnancy status

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

Specimen Collection

SeqNameOptionalityDefinitionComments
1Date specimen collected (date format)R-HHS
ELR allows use of 0000, when date is unknown
2Specimen Source - use appropriate LOINC, SNOMED-CT, or SPM4 codes, or equivalently detailed alternative codesR-HHS

OBR-15.1 and OBR-15.4 in V2.3 

SPM-4 - SPM-8 in V2.5.1

3Accession #/Specimen IDR-HHS

Accession# = OBR-3 in V2.3 and V2.5.1

Specimen ID = N/A in V2.3, SPM-2 in V2.5.1

Test Result

SeqNameOptionalityDefinitionComments
1Performing facility name and/or CLIA number, if knownR-HHS


2Performing facility zip codeR-HHS


3Device IdentifierR-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.


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.

4Test result R-HHSThis is the code of the test being resulted.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-HHSThe result value.

Use the appropriate SNOMED CT code for qualitative result values in accordance with the CDC guidance for the reportable illness/condition

6Test Result dateR-HHS


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 (AP:  Is the expectation that the performing lab update their descriptions to those in a master list?  (i.e. they say Pregnancy Status and AOE master is Pregnant?) 
  •  LOI
    • None?  CLIA test request requirements listed under Resources below.
  • LRI
    • Add guidance on how to convey device identification information
      • Can be sent in OBX 3 as a result for "reagent identifier" build as a test result in the panel reporting COVID results.
      • Can also be sent in PRT-15 (I think)
      • Can be sent in OBX-18

Implementation Guidance

General

  • Data Elements
    • Use proper segments per Mapping Spreadsheet below for PID and OBR fields.
      • If the guide indicates they are optional or not supported, consider them according to the Optionality column above.
      • If not possible, then use OBX segments using LOINC codes per Mapping Spreadsheet.
    • 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 the following data, use OBX for interpretation of lab result:
      • 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.
      • Include Profile TBD, but a new profile 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 PLUS [whatever list Riki is adding if maintained separately for now]
  • Results - Any ELR to PHA
    • Use LRI R1 STU 3 Section 8.11, 13.3.3, Z 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!)
    • Use Mapping Spreadsheet below for PID, OBR, and OBX fields that are RE if not R.
    • Use Device Identifier guidance below
  • 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 as quickly as possible to enable most consistent and complete communication of ELR.  (AP Note:  LRI is separate form ELR and ELR is required by law, while LRI is not technically required anymore, but was for stage 2 MU of hospital labs only)

Mapping Spreadsheet 

Use this spreadsheet to collect options and comments around the proposed mapping of the HHS elements to various places in Order and result messages.

Strongly recommend to pre-adopt where more currrent versions (up to v2.8.2) have been used in the latest LOI/LRI(ELR) guides.

As structured and encoded as the LRI R... indicates for that field.

When using HL7 v2, the date format is according to the specification.


Device Identification

The device identification information will be captured in either OBX-17 and OBX-19 as is indicated in the spreadsheet above.  (NOTE: This ends up a bit goofy and off-the-wall for using OBX-17.  So question is whether this is worth it, or go with OBX+LOINC codes for each of these, which is a lot more verbose, tough to link to the right OBX if multiple OBX-s under the same OBR, lest we get a dot notation in OBX-4 to make this work without interferring within any other dot notation.  I.e., OBX-17 may be ugly, but best of all evils).

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.
  • 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.
  • Manual kit

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

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.  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.  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. 

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: OBX-17.2 = "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]
    • Instrument Platform: 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]
    • Manual Kit: 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]
  • 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: 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]
    • Instrument Platform: 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]
  • Emergency Use Authorization Identifier
    • 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]
  • 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)

Open questions on spreadsheet

  • Suggest to organize by data types.  IF there is a need to link back to a sequence on an HHS spreadsheet, let's use HHS ID and I'll fix the in-line tables above accordingly to have the link.
  • Suggest to replace Must Support with RE for consistency with guides.
  • Suggest to remove the LOI,LRI, ELR columns as it really does not matter what is in the guides as we are effectively indicating do what we are indicating here.
  • Unclear whether the optionalities by guide are current or recommended - these were the current usages I found, so some will need to be adjusted
  • 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.

  • 2020-06-16 FH: SPM-4 in ELR R1, Section 6 Vocabulary Constraints  references Specimen Type Value Set, description is "Specimen Type - Union of HL70487 and SNOMED CT Specimen sub-tree (12303009)." The Mapping Spreadsheet references LIVD with comment: "LIVD provides SCT codes for SPM-4."  For ELR can we use the value set defined in ELR?

  • 2020-06-17 FH: typo in Patient Ethnicity coding system reference,  "U^Unkown^HL70005" should be U^Unkown^HL70189"
  • 2020-06-17 FH: Patient Race includes "U^Unkown^HL70005" but HL70005 User Defined table does not include Unknown (even in V2.8.2)
  • For specimen source/type, should we also reference OBR-15 for really old systems that don't support SPM?

Open Issues

  • 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?
    • 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 reaggents created from scratch.
  • UDI for manual test kits and LDTs (non analyzer performed tests)?
  • Do we need multiple test kits? Ed will check if 1 or 2 UDIs

  • Since ELR is subject to certification and the provider is supposed to use the certified version, there must be clarity that pre-adoption of the AOEs according to the latest LRI IG sections is permissible.  (AP:  What is meant by certification?  ELR for non hospital labs has not required use of 2015 vendor certification products.  In fact it can still be sent on paper, flat file or via portals.  Also ELR and LRI guides/messages are separate and go to different places.  Some LISs have fields in their database and send ELR messages with fields they don't send back to ordering provider via LRI.)
  • 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!).
  • Options for differentiating OBX for AOE vs OBX for results:  (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?)
    • LOINC code  
    • ELR R1 expects OBX after SPM for patient age - could put others there
    • Use a separate OBR for EPI important information
    • OBX-29 in LOI/LRI
    • In eDOS, AOE is represented in  XXX  field
    • In LOI, AOE is represented in 
  • 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: Becasue this is for manual data entry
  • What shall we point to for LIVD latest guide? Riki: Unfortunately the IICC link is the only one official, right?

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