FHIR Chat · Covid-19 survelliance proposal · Covid-19 Response

Stream: Covid-19 Response

Topic: Covid-19 survelliance proposal

---

Grahame Grieve (Apr 07 2020 at 21:29):

https://healthpolicy.duke.edu/sites/default/files/atoms/files/covid-19_surveillance_roadmap_final.pdf

I think that we should come up with a list of things HL7 should do to enable this?

Grahame Grieve (Apr 08 2020 at 01:31):

My analysis of what HL7 should do to support this:

Grahame Grieve (Apr 08 2020 at 04:11):

Other innovations that will greatly expand the ease and use of testing are validated, self-administered
tests that reduce the need for infection prevention resources like personal protective equipment.
These tests may potentially be used effectively for at-home sample collection, e.g. from
symptomatic contacts identified through contact tracing. Under this approach, patients would
be able to administer a swab themselves, if linked to a reliable method for transport to a lab for
analysis

This anticipates a need for (at a minimum) messaging to support self-administered sampling. It's not clear to me what the workflow would be - who initiates the testing? But considering the wider thrust of the paper, the answer would appear to be, essential workers test themselves on schedule?

It's still not clear, though, whether HL7 (or FHIR) specifically plays a role here, or whether this is standard consumer level sales/supply chain. It appears to imply that a lab still tests....

Grahame Grieve (Apr 08 2020 at 04:11):

but:

Grahame Grieve (Apr 08 2020 at 04:12):

CMS could also provide coverage and payment guidance for laboratory test developers that offer additional payment for test platforms that demonstrate effective electronic data sharing and that report additional high quality and interoperable data (e.g., symptoms and date of onset), or that provide additional payment when new tests approved by FDA for emergency use demonstrate their ability to meet or exceed performance standards for sensitivity, specificity, and timeliness in practice. Surveillance grants could also be used to position testing tools in Federally-sponsored community health clinics and other priority community settings that states determine are critical to achieving surveillance goals.

Grahame Grieve (Apr 08 2020 at 04:13):

this absolutely anticipates standalone devices deployed out in the wild that do all testing start to finish; that a consumer would grab the device, enter some identifying information, enter their symptoms and exposure from some questionnaire, and then bingo, test is reported to consumer and CDC.

Grahame Grieve (Apr 08 2020 at 04:14):

have I understood this correctly?

if so, it would appear to imply the need for some web-ish version of LRI? Or would we say that LRI using v2 is still the thing to use in this context?

Grahame Grieve (Apr 08 2020 at 04:17):

To support effective understanding of the course of the outbreak, the data collected should include presence of symptoms, date of symptom onset, and test platform (to help assess new testing platforms that have limited evidence on test sensitivity and specificity), in addition to usual laboratory result data fields such as patient demographics, geographic location, and test result. This should be enabled through an “Ask on Order Entry” (AOE) input requirement at the time of test ordering

Grahame Grieve (Apr 08 2020 at 04:18):

so I'm not clear what % of lab tests (particularly for SARS Cov 2) are ordered electronically in USA, and there fore subject to AOE. @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM do we have numbers?

Grahame Grieve (Apr 08 2020 at 04:19):

but this suggests that HL7 should ASAP publish an addendum to LRI describing an order message that includes symptoms with date of onset

For tests not associated with an AOE context, but where patient EHR supports Argonaut (is that combination a thing?), we could provide a standalone app that looks up the relevant symptoms etc from the EHR (assuming they are made available though the Argonaut interface)

Grahame Grieve (Apr 08 2020 at 04:20):

Given that reporting is already required, it's the labs or the EHRs that report? I'm not clear on the current reporting framework? Is it anything more than by fax?

Grahame Grieve (Apr 08 2020 at 04:21):

However, progress to date in expanding this electronic case reporting through the Initial Case Report (eICR) Project has been slow and is well below the level needed for reliable and timely surveillance. Linking data sharing to provider payment will accelerate progress.

Grahame Grieve (Apr 08 2020 at 04:23):

eCR gets a rapid acceleration. Given the current situation that means the CDA format as a the backbone(?), but also working on an App that uses Smart-On-FHIR access to create the CDA format. (Work is already in progress on that).

Logical response for HL7: 1 eCR connectathon coming up pronto

Grahame Grieve (Apr 08 2020 at 04:25):

The goal of these efforts should be to automate such data sharing as tests
are ordered, reported, and billed in electronic record systems, with minimal additional effort required by providers

Can use CDS Hooks to orchestrate this for EHRs that don't implement eCR natively? Can also use v2 order feeds to orchestrate this?

Grahame Grieve (Apr 08 2020 at 04:25):

Over the past decade, a national infrastructure has been established for the real-time monitoring of a sample of emergency department visits for different syndromes of public health interest, including for influenza-like illness (ILI)

Grahame Grieve (Apr 08 2020 at 04:26):

this doesn't use HL7 IP now, right? so we don't need to look at this

Grahame Grieve (Apr 08 2020 at 04:27):

this data collection and analysis infrastructure should be enhanced to provide additional support for COVID-19 decision making

Sounds like there's plenty of space for CDS Hooks apps to action the data...

Grahame Grieve (Apr 08 2020 at 04:31):

the COVID-19 surveillance system would benefit from timely access to other sources of electronic data, including electronic feeds on admissions, discharges, and transfers (ADT)

Grahame Grieve (Apr 08 2020 at 04:32):

we (HL7) need to publish a v2 IG ASAP that describes a standard way to include covid related symptoms in the ADT feed

Grahame Grieve (Apr 08 2020 at 04:33):

or would we say that there should be an intermediary that picks up the v2 feed as is, and turns the v2 feed into a series of eCRs?

Grahame Grieve (Apr 08 2020 at 04:35):

we could initiate an open source app that receives an incoming v2 ADT feed, and uses a mix of existing v2 information, Argonaut interfaces, and an extensible set if other methods to do what ever is required to build a CDA eCR report. (@John Loonsk )

Grahame Grieve (Apr 08 2020 at 04:35):

In collaboration with the CDC, states should use these integrated capabilities for COVID-19 surveillance, incorporating testing results, to produce daily summaries by metro area or region of COVID-19 related case trends, as well as the comprehensiveness of testing and response activities based on testing results

Grahame Grieve (Apr 08 2020 at 04:35):

Could be using FHIR Measure / MeasureReport - but I think that would be a hard sell?

Grahame Grieve (Apr 08 2020 at 04:38):

To enable a return to case-based interventions as incidence declines, these capacities need to be expanded. Improved capacity will be most effective if coordinated with health care providers, health systems, and health plans and supported by timely electronic data sharing

that implies a format for sharing contact/quarantine information. I think FHIR could be pressed into duty. but should it? I'm not clear on that, but I don't think we'd put any other standards forward for that?

Grahame Grieve (Apr 08 2020 at 04:39):

interesting comments:

Cell phone-based apps recording proximity events between individuals are unlikely to
have adequate discriminating ability or adoption to achieve public health utility, while
introducing serious privacy, security, and logistical concerns

wooah - I think that's harsh. I think they'll get up elsewhere.... but I guess culturally US would rather spend more money elsewhere...

Grahame Grieve (Apr 08 2020 at 04:40):

To improve data collection and reduce burden, [we] should establish a common platform for facilitating automated queries to hospitals on behalf of Federal, state, and local public health.

I think that is logically FHIR and we already have defined all the relevant pieces, right?

Grahame Grieve (Apr 08 2020 at 04:40):

State and local health departments should, with the help of Federal funding, make available adequate local facilities for isolation and quarantine of individuals who voluntarily choose to use them

Grahame Grieve (Apr 08 2020 at 04:41):

that implies the extension of SANER to cover more residential services - where Quarantine appropriate facilities can be found.

Grahame Grieve (Apr 08 2020 at 04:41):

The CDC-led collaboration, working with CMS, private payers, and providers, should support the identification of approaches, best practices, and supporting tools to expand effective COVID-19 case management models.

Grahame Grieve (Apr 08 2020 at 04:42):

I'm not even sure where to start on that one. It's kind of everything we do...

Grahame Grieve (Apr 08 2020 at 04:43):

@Farzad Mostashari - thanks for being a contributor to this document. I'd welcome your review of my comments looking for where HL7 would/should be part of the vision you've drawn in the document, and suggestions for anything else we can do to support.

Grahame Grieve (Apr 08 2020 at 04:45):

everyone else - the degree to which we need to respond/push to support this document depends on the degree to which it influences national policy. And the degree to which we can have a good discussion here about this will influence how HL7 responds to this in the halls of power...

Grahame Grieve (Apr 08 2020 at 05:08):

that thread kind of got out of control. I've rationalised my comments into here: https://docs.google.com/document/d/18PfbedlPldYz0jV9uGbM0M-AlE1_biXsE0_j_rpy6nA/edit?usp=sharing and will try and keep the google document as a current summary of discussion

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 08 2020 at 13:44):

Great questions @Grahame Grieve Do we separate threads? Will try to address those with lab implications over next few days. The Duke document also has many points. (Ironically, did my laboratory training and worked at Duke's main clinicial laboratory.) There are some ideas that we may need to delve into form different perspectives as some aspects may be missing or from one perspective. (Which is ok, but to get the full picture)

Let's review the lab ordering to resulting process at high level. (Will be US specific per regulations, but mant countries such as Singapore and Canada also model their ministry of health lab regulations after the US. Some are more or less stringent.) Clinical Laboratory Improvement Ammendments (CLIA):
https://www.ecfr.gov/cgi-bin/text-idx?SID=1248e3189da5e5f936e55315402bc38b&node=pt42.5.493&rgn=div5

1. Laboratory professionals decide with IVD (In vitro diagnostics) tests/methods or laboratory developed tests (LDTs) they will set up and validate (per CLIA requiremetns) in their labs. Most COVID-19 testing is PCR based currently, but Serology testing and those advertised as point of care testing (POCT) are emerging into market. Also heard a patient collected specimen option (Let's call these consumer testing) is also coming to market soon.

2. For US COVID-19 testing, FDA needs to approve for use in US. As of earlier this week, ALL US testing is considered moderate to high complexity (including those listed as POCT, like Abbott ID Now.) Regulatory requires all mod-high complexity testing to be performed by a trained laboratory professional. Therefore, there is no Drive up testing, but there is Drive up specimen collection (with a valid physician order/requesition).

3. Once test is laboratory validated (by each lab offering), it is listed in the lab's CLIA Specimen Collection Manual, along with allowed specimens, Ask at Order Entry (AOE) questions (i.e. information needed by the laboratory to initiate testing which is not covered in demographics, other fields such as which specimen has been collected? ), specimen containers or swabs used for collection, transport info, etc. and other regulatory required info, including specimen rejection criteria, minimum volumes, etc. If required info not provided or improper specimen collection, the specimen may be rejected (lab must provide a reason which is in HL7 v2.51 spm 21 field) and test may not be performed (per lab discretion). CLIA Specimen Collection Manual is required to be at all places orders are placed/specimens are collected.

Think of this as the lab's menu/test catalog/lab comendium of what can be ordered. Can't order a taco from McDonald's (as they don't have supplies, not validated test, etc.). Most labs have online catalog, but there is not widespread adoption of a test menu HL7 standards, either Electronic Directory of Service (eDOS, V2.51 format), or Service Catalog (FHIR). Such electronic formats woudl ideally be served up to all CPOE locations where orders are placed (usually EHR) as orders require a physician (or advanced provider) to place in most all countries. This is known as the order requisition.

So far we have Test catalog (orders) -> EHR/CPOE systems..... from interoperability perspective.

cont...

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 08 2020 at 14:17):

cont....

4. Each laboratory builds/models the test info in their LIS for ordering and resulting as several major data items: Test Order, Test Result (i.e observation), and Test Result Value (i.e. numeric, Qualitative), which may or may not vary dependign on type of specimen analyzed. Often, the Ask at Order Entry (AOE) questions and responses are built in the LIS as Test Result items and reponses/values. All these data are the Source of Truth (SOT) for laboratory data. This is the basic lab data infrastructure/modeling used most everywhere, since the 1960's when lab data was first digitized.

Lab professionals when they set up and validate tests according to regulatory also need to follow the manufacturer's insert as to allowed units, result values, etc., which also influences test build. Each lab is to distinguish tests on their menu. Each usually comes up with it's own version of naming a test. Often these laboratory naming conventions are not seen in EHR builds as most all US EHRs come up with their own generic way of naming a test as they may be interfaced/offer 1-5 test catalogs for physician ordering (often based on patient insurance), but also which laboratories a physician practice/hospital is contracted with/interfaced to in providing lab testing.

These generic Order name builds, are usually in EHR dictionary which populates CPOE (clinical provider order entry) that a provider uses on a patient instance level when they decide to order a test. In the US, electronic ordering /CPOE has been required for Meaningful Use (MU) so most all Eligible Providers (EP) and Elgible Hospitals (EH) should be creating electronic orders. They still might print them off and include paper requisitions with the specimen in some cases as HL7 Lab Orders Interfacing (LOI) Guide wasn't required in MU 3. Interfaces are established between most EHRs and LISs, but may not exist in others.

It would greatly help with interoperability if both eDOS/Order Catalog were required and then the orders therein and AOEs were sent across interfaces to the performing laboratory. The quickest way is to utilize the HL7 2.51 interfaces as many have 2.31 or 2.51 already in use and clinically validated (interface checks between EHR and LIS and EHR for orders and results is also an accreditation requirement for some lab accrediting bodies in US). FHIR functionality isn't part of routine order and results interfacing/serving in any LISs that Hans and I are aware, even though a number of vendors that have LISs are active FHIR developers/connectathon participants (although all would be welcome to test service catalog, orders, results, etc). It will likely take 10 or more years for lab community and regulations to catch up to support FHIR. HL7 V2.51 is fairly widespread in lab community. However, there are still a number of laboratories that may still use paper, fax, flatfile and other means to transmit orders and results. That is because only hospital labs were part of MU requirements. So the largest lab segment physician office labs (POLs), goverment/DOD (have their own regs), blood banks, independent labs, etc Do NOT have to use MU standards (HL7 messaging, LOINC, SCT) as there is no requirement!! Several large reference labs like LabCorp and Quest are adopting voluntarily (which is wonderful!!) Sadly, a number of independent labs have not adopted. Need to get ALL labs on the same standards for interoperability.

So now we have Performing lab Test catalog (idealy future use of eDOS/Service Catalog)->> receipt by EHR and then used for CPOE order catalog in EHR--->> Used to generate on patient instance level a LOI message (v 2.51 format/future FHIR service request needs to be tested with all types of orders) sent from EHR to-->> receipt in performing Lab LIS.

Often EHR orders aren't same name convention but more generic to meet provider needs. Provider wants a burger, but lab A has BIg Mac #3 meal and Lab B has Whopper/#2 value meal. EHR name is mapped to #2 or 3 and sent across interface. Performing lab knows by order # which test is desired on their menu. Ideally same test naming conventions will be used and not changed. Most of end to end order and resulting is seen as point to point interfaces. Most US EHRs are unable to handle dynamic test catalog updates from performing lab when a new lab like COVID-19 is on the menu. A manual build by each hospital/provider EHR is needed. Unfortunately in the US, we don't have a single test menu of test names like in Australia and some other countries by which orders and results are named/encoded for use in information systems.

This is the order process. In the catalog and LIS builds, the order is tied to a separate result component (result #). If the same test result (with numeric units, or qual result values) is used across several prder panels (panel being anytime more than one result is reported), the result component is part of one or more panels. Take a Hemoglobin. It can be ordered soly, as hemoglobin order and hemoglobin result or it can be part of a panel order Hemoglobin and Hematocrit (H&H)), Compelete Blood Count (CBC), etc. Similar to how a hamburger patty can be part of a hamburger, cheeseburger, big mac, etc. Depends on which one ordered. These result items may be build once in the LIS. Often the same test is performed on same instrument on same specimen.

For COVID-19 testing , some PCR tests are a single item and single result on a specific specimen type. In other instances, the COVID-19 test is really a panel order with 1 or many result components reported back to the ordering provider (along with any AOE results and result values).

cont... later....

Craig Newman (Apr 08 2020 at 19:19):

I haven't read the document yet, so I'm not sure what they mean by "syndromic surveillance" but there is a v2 ADT based syndromic surveillance IG. I'm not sure if it does what they want, but it may play a role.

http://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_SYNDROM_SURV_STU_R1_2019JUL.pdf

From the IG:
Syndromic surveillance is a process that regularly and systematically monitors pre-diagnostic groups of symptoms
(syndromes) and then uses these and other health-related data in near real-time to make information available on the
health of a community. This information includes statistics on disease trends and community health-seeking behaviors
that support essential public health surveillance functions in public health authorities (PHAs).

Scott Gordon (Apr 08 2020 at 19:57):

Syndromic surveillance systems at local and state public health departments (and CDC) are systems that collect emergency department information at first admission - Chief complaints such as Influenza Like Illness, etc. CDC has leveraged that - the National Syndromic Surveillance System (formerly called BioSense). (https://www.cdc.gov/nssp/index.html) Basically you can see trends of people checking into hospitals with their main problems (GI illness, ILI, etc) in semi-real time. (I think daily reporting is common). You know like that smart thermometer thing https://healthweather.us/? Like that but reflecting lots of information per check-in.

Craig Newman (Apr 08 2020 at 20:13):

The 4/9 Public Health WG call will be hearing about eCR Now, a program to enhance ECR reporting. Anyone who is interested is welcome to listen in.

Matt Zajack (Apr 09 2020 at 00:26):

Craig Newman said:

The 4/9 Public Health WG call will be hearing about eCR Now, a program to enhance ECR reporting. Anyone who is interested is welcome to listen in.

Can I get the number, or better yet the link to the WG? Thank you fort he heads up!

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 09 2020 at 02:31):

It's not clear if "test platforms" are referring to in vitro diagnostics (IVD) test vendor platforms (i.e. test kits or analyzers) or information systems, specifically laboratory information system (LIS) as the data indicated do not exist in either as it appears different notions have been conflated. Data sharing from an IVD platform is typically done via interface between the instrument and LIS within the laboratory (see IHE Lab Automation Workflow or LAW Profile or older ASTM interface standards). The data items they list would need to be provided to the performing laboratory, for the laboratory to share them with public health. These data are not typically shared with the laboratory. They seem more suited for clinician reporting to pubic health using electronic case reporting (eCR) which likely supports transmission of these data to public health. In short, clarity is needed by the intent of this proposal.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 09 2020 at 02:40):

I'd be interested in learning where one coudl find such a super device ;)

I think you are reading the paragraph correctly, but I think the authors have conflated different information and workflows and capabilities from different areas of healthcare.

Will respond on yoru LRI question about the results reporting aspects. Electronic Lab Reporting (ELR) is the standard used to report lab results to public health, whereas LRI (which was included in MU Stage 2 and removed for Stage 3) is the standard for reporting lab results back to the ordering provider/EHR.

A word on patient demographics, geographic info and test results. If information isn't provided with the order/service requeste to teh performing laboratory, often the performing laboratory won't know/have access to the information to be able to include it with ELR to public health. This has been an ongoing problem discussed in PHER and O&O calls and now more critical with COVID-19 testing. Some major reference labs have reported receiving paper requisitions lacking patient contact information with COVID-19 orders. If pos, public health contact tracing and contacting the patient are delayed which may lead to spread of the virus or patient care/safety issues. Those ordering/collecting specimens for COVID-19 testing must provide this information as it's required to be reported to public health by the performing lab as part of ELR requirements by law.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 09 2020 at 02:52):

Sooo.... several items conflated by authors... date of symptom onset, presences of symptoms would be required of eCR case reporting required of physicians, while demographics, specimen source, and perhaps a few other items would be needed to be provided to the performing laboratory at the time of order entry/specimen collection. The need for these CPOE data would be trigger by AOE, which should be addressed by the ordering provider or specimen collector and sent in the message to the performing laboratory. Most AOE information is provided, but some of these still are not.

Standards for public health reporting woudl be ELR from LIS to public health for lab required info on reportable conditions, while eCR is used for physician reporting requirements. Both are required by law, but the data differ, and thus different implementation guides (ELR and eCR).

Current frameworks are ELR in v2.51, and eCR in CDA. Concur increased adoption of eCR across country (and world?) is needed @Riki Merrick and @Laura Conn can provide further detail on barriers. (I suspect it isn't due to lack of standard, but gaining adoption of the eCR guide.) Laura helped spearhead the eCR HL7 standard.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 09 2020 at 03:07):

I think other questions should be asked first:

1. What are the desired data elements?
2. How and where are they created? Where do they live/are stored once created?
3. Is the data part of the eCR standard?
4. If so, can the data be accessed from the store and included in eCR reporting.
5. If not, how are the data communicated to public health?

Suspect it may be a combination of factors (needs to be confirmed), which may include:

1. Providers may not be capturing the data (due to lack of time, training, place in workflow to collect).
2. Do EHRs have standardized way to collect the data? or is additional functionality needed so end users can collect?
3. Is the data discretely structured, so it can be easily found and sent? Is it encoded?
4. Can the downstream system (public health) receive or is additional functionality needed on receiving system?
   Hopefully the folks that are more familiar with eCR and where the data reside can help.

It would be premature to develop a measure without understanding the data questions above. For the items that are part of ELR, there are already standards requirements so it should be much easier for this portion of data. ELR does not include contact or quarantine info. Sounds like that would be part of the public health epidemiologcal systems which might be used for contact tracing. I'd defer to some of the PHER public health attendees to chime in. @Craig Newman might have some recommendations.

Regarding cell based apps, say an AMIA presentation yesterday with speakers from China, Vietnam and other Asian countries speakign of their responses. Several countries had apps where folks woudl answer surveillance questions, symptoms, etc. on their phones and the GPA aspects would track proximity of other cell phones for easier contact tracing. I haven't heard of anything like that in the US, but it's an interesting thought. Given different laws amongst the countrie such as privacy, may not be feasible.

Grahame Grieve (Apr 09 2020 at 03:40):

I haven't read the document yet, so I'm not sure what they mean by "syndromic surveillance" but there is a v2 ADT based syndromic surveillance IG

@Craig Newman thanks - who is presently using this IG? Are you referring to this? https://www.cdc.gov/nssp/documents/guides/syndrsurvmessagguide2_messagingguide_phn.pdf - and is that what they are referring to?

Grahame Grieve (Apr 09 2020 at 03:44):

@Scott Gordon thanks. So following the links, I see that NSSP is based on V2 for data collection - the same spec I think that Craig referred to.

So I conclude, from what you say, that the survelliance system you refer is based on v2, and we would need to extend it to not only include chief complaints but also symptoms, severity and date of onset as well? Or at least, publish an example with the relevant complains included in the instance...

Grahame Grieve (Apr 09 2020 at 04:17):

@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM thanks for the detailed responses.

• I appreciate the challenges that IVD / PoC testing has. I expect things will be unusually accelerated right now, and some corners bent. For good or ill. And so I think it's rational to prepare for pure PoC testing (not just specimen collection).

• I agree that the document doesn't differentiate between IVD+LIS vs pure PoC well, but when it talks about getting tested and cleared before your shift starts, we're not talking about a lab testing service

• I conclude from what you've said that some labs have automated testing with AoE supported, but others don't - enough to make it an important case. (What I expected). I expect that all such work will be v2 based not FHIR based, and the only place I would think about arguing for FHIR would be when the whole test is PoC

• on the subject of Covid019 testing - what specific tests are in the requests panels usually? (aside for my personal interest)

• note about ELR not LRI - yes thanks. Does ELR include AoE? (Is there a reference for the spec?)

• This document implies that policy should be used to ensure that the requisite information is passed to the labs (I know they are not getting it now much) so they can pass it in. So I expect we would need to clarify the exact format

• AoE questions are always 1 question = 1 answer in my experience (and I both worked in a lab and was product manager for a LIS). So I don't know how this scales easily to a triple of (symptom + severity + onset date), and that's why I think we need to this early to get wire format consistency

I'd be interested in learning where one coudl find such a super device ;)

They are effectively asking for it to be built, and for it to conflate the existing workflows for scalability. As a lab scientist, that smells, but if the WH decides that this is the path to get the economy going again, technical quality concerns aren't going to stand in the way

Grahame Grieve (Apr 09 2020 at 04:19):

I think other questions should be asked first:

yes agree

What are the desired data elements?

I think there's some guidance on that coming. We certainly don't want to have to define them. Hopefully I can provide some external guidance soon, but there may also be guidance from CDC soon (already?)

How and where are they created? Where do they live/are stored once created? Is the data part of the eCR standard?

yes but I think the document asks for it in ELR too

If so, can the data be accessed from the store and included in eCR reporting.

That's what eCR Now is about - finding that out ASAP

If not, how are the data communicated to public health?

indeed

And your other questions are also mine

Grahame Grieve (Apr 09 2020 at 04:20):

of course, all this is dependent on this document becoming/influencing national policy. It has good positioning with authors (go @Farzad Mostashari) but who knows? But worth doing the analysis since things are moving quickly

Grahame Grieve (Apr 09 2020 at 04:21):

so... thanks for your input

Craig Newman (Apr 09 2020 at 12:27):

@Grahame Grieve https://www.cdc.gov/nssp/documents/guides/syndrsurvmessagguide2_messagingguide_phn.pdf - is the older version of the IG I mentioned. I believe the older version was including in US Meaningful Use regulation. Not sure how widely adopted it is. Going forward, we would probably want to prioritize the updated version that was published last year.

Craig Newman (Apr 09 2020 at 12:29):

@Matt Zajack (and others) - the Public Health WG call from 4-5 Eastern (US) uses the following:

1. Dial into the conference:
   Dial-in Number (United States): (515) 604-9520
   Access Code: 132783
   International Dial-in Numbers: https://www.freeconferencecall.com/wall/pher#international

2. Join the online meeting:
   Online Meeting Link: https://join.freeconferencecall.com/pher
   Online Meeting ID: pher

Scott Gordon (Apr 09 2020 at 12:53):

Grahame Grieve said:

Scott Gordon thanks. So following the links, I see that NSSP is based on V2 for data collection - the same spec I think that Craig referred to.

So I conclude, from what you say, that the survelliance system you refer is based on v2, and we would need to extend it to not only include chief complaints but also symptoms, severity and date of onset as well? Or at least, publish an example with the relevant complains included in the instance...

On the details of that I'd recommend you contact the NSSP Program Manager at CDC, Michael Coletta. It's been a few years since I worked with them, so I can't speak to it's current design.

Eric Haas (Apr 09 2020 at 16:27):

Could be using FHIR Measure / MeasureReport - but I think that would be a hard sell?

This the current approach being banged about right now.

we (HL7) need to publish a v2 IG ASAP that describes a standard way to include covid related symptoms in the ADT feed

Using for example like Da Vinci Notifications and/or R5 ver Subscriptions in FHIR??

To improve data collection and reduce burden, [we] should establish a common platform for facilitating automated queries to hospitals on behalf of Federal, state, and local public health.

nothing new here that was problem 10 -15 years ago when I started in this business, even between state and federal public health.

Grahame Grieve (Apr 09 2020 at 20:32):

Using for example like Da Vinci Notifications and/or R5 ver Subscriptions in FHIR??

we could. But since there's already v2 flows in place, the right thing to do is a 1% addition to them

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 10 2020 at 02:52):

You're welcome! Realize it's evolving. but we have the benefit of crowd knowledge/hive mind...

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 10 2020 at 03:37):

@Grahame Grieve
-right. One thing to keep in mind (which you are probably aware), is although "faster" testing is available, say like the Abbott ID Now, which can be placed in a variety of testing areas, doesn't mean it is appropriate for all testing situations. Looks like it processes only a single patient specimen at a time and thus could have throughput of 4-6 an hour. In 4 hours, only 24 or so patients would be tested, while the pcr methods might lend themselves to several hundred results in a 4 hour period if I recall correctly. Although it takes a bit longer, more patients can be tested at time, resulting in a higher throughput/testing rate, which may be most desirable. POC Testing may be find for low volume testing.

-Not 100% convinced AOE data collection is 100% on the lab side. Suspect a number of items are supposed to be sent to the lab, but it's the specimen collection/ordering person who may not be providing, such as the drive up demographics. Also although a test is POCT, often it's performed under a laboratory's CLIA certificate and thus results are entered into the LIS as though they were performed in lab and then resulted to the EHR. Which means, data are in V2.

-regarding panels, looks like one panel LOINC is for IgG and IgM serologies, so suspect one result for each. Another is for PCR

-ELR is on the results reporting side, so eDOS has capabilities listing AOEs required for a test order, whereas LOI would be where the ordering provider provides the info in the order sent to the lab. ELR would include AOEs as result items and their respective values, as would LRI. For example for a wound culture, an AOE may be "Specimen Source", which would required the person collecting the specimen to indicate where on the body the site was swabbed (right leg, left eye, etc.) . AOE received in the lab then can populate the lab result "Specimen Source" with a response of "right leg". Given certain organisms such as MRSA aren't reportable unless they are from a sterile site, it's critical that the lab know if a specimen is from a sterile site or not. A skin (non sterile site) may only be reported back to ordering provider, but MRSA inside the body from a sterile site would be reportable using ELR, and also to provider with LRI. See the combined eDOS, LOI, LRI, ELR HL7 v2.51 guide for further details

-AOE. Yes, I'd expect most AOEs to be 1 question: 1 response. Although if a question is address, it may contain several elements (street, city, etc). Totally concur on consistent format

-Regarding symptom, severity and onset date... a few factors here. Usually it's not the lab collecting or reporting this info. I think it is best suited for the provider to note and likely to report in eCR. As there are many websites and apps that now ask patients about symptoms and onset, to determine if they should get COVID-19 testing, one way to collect the data is develop an app that coudl be used on the consumer facing side for patients to self report to their providers, such as Social Determinants of Health (SDoH) or patient reported info. This info could feed into a provider system, that could be incorporated into eCR or other reportig mechanism to get that info to public health, especially if these patients are ambulatory and aren't tested. Might provide folks a better idea of the true infection rate as I've heard it may be at least 10 xs higher than pos case rate in a region.

-agree certain things in the paper may not be achievable exactly as proposed. it's great to see all the interest and folks jumping in. Taking the high level end to end interoperability data/workflows, and dividing up and conquering may be the way to go. Then testing at connectathon or with pilots. Been on CIMI calls where they have some overlap with some of the data elements as they published with Logica model late last week.

Still need to respond on the ELR and LRI paths, data, and how it could be leveraged for the FEMA/WH reporting.

Keith Boone (Apr 10 2020 at 05:43):

CVS is using the Abbot device for drive up testing in Massachusetts https://www.cnbc.com/2020/04/09/what-to-expect-if-go-to-a-drive-thru-coronavirus-test-site.html

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 10 2020 at 12:56):

@Grahame Grieve Note yesterday's PHER call with eCR status updates: https://confluence.hl7.org/display/PHWG/2020-04-09+Public+Health+WG+Call+Minutes Anything else to add @Craig Newman ? (Sorry had a scheduling conflict)

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 10 2020 at 13:00):

Thanks for sharing Keith. One of the misnomers that media has been spreading (faster than the virus) is drive up testing, when the reality has been drive up specimen collection and the samples sent else where for testing by a trained laboratory professional. FDA has classified these as moderate to high complexity test systems, so per CLIA law only laboratory professionals can perform. However, a number of CLIA requirements have been relaxed during the public health emergency, and have seen Walgreens rolling out the Abbott ID Now devices at locations too with pharmacists performing ordering and resulting.

Gino Canessa (Apr 10 2020 at 19:29):

Came across this announcement from Apple & Google re: contact tracing. Obviously light on details.

Bret H (Apr 10 2020 at 22:21):

Iceland's got one: https://grapevine.is/news/2020/04/01/covid-19-tracking-app-launches-today/ "Data security and privacy fears have been a particular concern of the Icelandic public since the proposal for the app was announced last week. In an attempt to assuage these fears, the Icelandic Director of Health, Alma Möller highlighted the app’s dual approval mechanism designed in yesterday’s press briefing. Users have to voluntarily download the app and then give their permission for the app to use GPS to track their movements and for the infection team to access their data. The data collected will only be accessible to the infection tracking team and will not be stored in a database after the end of the outbreak. What’s more, the security of the system has been certified by an independent party."

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 13 2020 at 12:43):

Continuing the lab information flow.... We discussed lab catalog (from LIS)--> consumed by EHR. Used to populate CPOE systems to generate patient instance Lab Orders Interfacing (LOI) messages for the order sent to the performing lab. --> order and specimen are received by performing lab in the lab's LIS. The specimen is processed and sent to the lab bench or analyzer for analysis. There's a "shell" of the order and results fields (which are blank), in the LIS build, where the test result values are entered for verification and reporting.

Let's look at the AOE's with an example of a 24 hour timed urine calcium. In this case, two AOE's, one for Total Volume of the specimen and another for total hours of collection of the specimen are required data for the laboratory to perform testing. Perhaps the hours of collection were 23.5 and volume was 1000 mL. Both are entered by the person collecting the specimen. (Although some laboratories will measure the volume upon receipt in the lab.) An aliquot or portion is placed in a tube to be analyzed by the instrument that generates the calcium result which travels across the interface between the instrument and LIS to populate the test result value in the LIS. There's a field for this spot/random urine calcium, and once populated, the LIS uses the volume and hours of collection to calculate a 24 hour urine calcium rate, which is reported back to the ordering provider for clinical decision making and patient care. To recap, the AOEs are reported back as test results and test result values that are part of a panel (more than one result) reported from the LIS to EHR.

For COVID-19, there may be an AOE that is specimen source, requiring the specimen collector to enter whether a nasopharangeal swab is collected or an oral swab is collected and sent to the laboratory. Specimen source is an important field for public health reporting for a variety of tests as certain organisms/results/reportable conditions (such as MRSA) are only reported from sterile sources. That is, if a culture identifies MRSA in a skin wound specimen, it may not be reportable to public health, but if it is identified in a sterile specimen like cerebrospinal fluid (CSF), then it is. Of course, all COVID-19 results are reportable, but it's been reported that oral swabs have a 30% less positive rate for identification than nasopharangeal swabs and thus a patient result may be negative, when they have the disease, a false negative. In short, AOEs provide important data and results that are essential for lab testing, clinical decision making and patient care, and public health reporting/epidemiology.

Regarding patient demographics, they are usually entered in patient registration, and other "non lab" screens/fields of the EHR. A number of these data may be part of the Admission, Discharge, and Transfer (ADT) system and transmitted in other parts of the HL7 message like PID. Additionally, these populate the LIS to provide required CLIA information (patient name, birthdate, etc.) required by the laboratory. Birthdate and gender are also important as they may drive certain laboratory reference ranges, depending on the results.

Reportable conditions are determined by each jurisdiction, usually the state or territorial public health department. In some larger metros, there are city and county health depts. too (i.e. Houston and Harris County, Chicago and Cook County, Phiadelphia, NY City/NY State, LA / LA County, San Francisco). With ELR, all labs are required to submit to the state health department level, whereby the public health information system processed the inbound ELR messages and then notifies the county and city level health depts. of cases.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 13 2020 at 13:28):

A bit about ELR. It is required by law of any laboratory (in the US) performing testing that meets reportable condition reporting criteria. Each jurisdicition determiens criteria so reporting requirements differ by each jurisdiction (which also drives LIS and EHR vendors crazy as they have to maintain the one offs). That said, Meaningful Use Stage 1, 2, 3 included it as a requirement of hospital labs to use the HL7 v2.51 messaging IG, along with LOINC for lab orders and results, UCUM for units, and SNOMED CT for qualitative result values, specimen type, specimen source, organism, and qualifiers for specimen tye and/or source. Functional requirements for ELR have been included in vendor certification requirements.

Initially with MU, LIS vendors didn't get certified as the ONC language was geared towards EHRs. However, Farzad Mostashari and others confirmed if the functionality is performed by the LIS it is considered part of the EHR system for MU criteria. So many of the LIS vendors became certified for this functioanlity (but not other functionality such as e prescirbing sinc eit's not a funciton of their informaiton systems, but rather the EHR) (I participated on the Laboratory Interopeability Collaborative, CDC funded initiative to assist over 1000 hospital labs with ELR, including over 100 Critical Access Hospitals. We taught ELR, SNOMED CT and LOINC mapping and ELR needs to laboratory professionals and public health in about half of the public health jurisdictions/states during the funding period. )

One note about ELR functionality. For instances where there is a separate LIS and EHR, which are interfaced, the LIS would be certified if the ELR message is sent directly to public health in conjunction with the results message sent to the ordering provider's EHR (which shoudl be in an Lab Results Interface or LRI HL7 message). In theory these messages should contain the same information, but some vendors have different interfaces set up and LOINC or SCT codes may be sent to public health and not the EHR. (not sure why.) Others require to ask the performign lab to "turn on" codes in the messages they send so downstream systems can receive. Some LISs share a combined database with the EHR and ELR functionality may be in another module of the EHR whereby ELR messages are generated and sent. In other cases, the LIS doesn't have ELR functionality, but the EHR was certified and so the message is sent to the EHR, and the ELR message is sent. In another scenario, an HIE or public health entity may add SCT and LOINC codes to the message and/or convert a v2.31 message into a v.251 so it's otherwise compliant and then this intermediary sends the message on to to public healt to fulfil requirements.

It's imperative, that any AOE questions and demographics be sent by the ordering/collecting person to the performing lab with the specimen. If these critical data are not reeived by the performing lab, they are not able to be communicated to public health by law. Public health has reported these failures occurring with many drive up specimen collection locations for COVID-19. Hopefully, by getting the word out and educating those originating the orders, this can be easily rectified.

Another reason appropriate coding is essential in ELR messages is public health has limited resources and their information systems are set up to automatically process and route reportables to the appropriate area handing them. Some health depts have a separate HIV area or TB area. They have used LOINC codes to route certain lab results to these areas. IF coding is not provided, it delays processing as a person needs to manually process the message. I'll also mention with different reporting crieria by each jurisdiciton, some also want other lab results such as liver function testins or a CBC to be reported for certain reportable conditions. Others have criteria whereby suspicion of disease is reported, which includes any orders (regardless if they are pos). We are seeing this aspect with COVID-19 testing whereby the FEMA/White House/HHS summary reports required hospital labs to report both orders and results and many public health jurisdictions are showing # of pending lab results on their public health websites

It would be ideal if public health could take all the reportable ELR messages and sumamrize them for WH/FEMA reporting, but challenges still remain. The largest challenge is although ELR is required by law of all labs performign testing, some are still sending in fax or flatfile or other formats to public health and not using ELR. Why? you may ask. Keep in mind MU was only required of Hospital labs, therefore other types of labs reporting are required to submit ELR, but they can stil send in HL7 2.31 messages, fax or other means as the way of reporting may not be specified for them. There are many laboraotries who have not adopted LOINC, SNOMED CT, and updated HL7 standards. The largest segment of CLIA labs in teh US (>200,000) are Physician Office Labs (POLS), but there are also blood bank, govt/DoD (which have their own requirements), and independent labs. Many small labs are not doing COVID-19 testing, but the indepedendent labs are. The large reference labs like LabCorp and Quest are providing LOINC and SNOMED CT codes in their ELR messages to which they report to every jurisdiction (since they have a large national/global footprint). However, small reference labs are not reporting LOINC and SNOMEDCT and in some cases may be issuign paper reports still, which also drives provider nuts from an interoperability perspective. It creates a lot of work for a downstream system to enter or convert these results into a structured format/discrete data with appropriate coding in their EHRs so it's computer processible. Many times these reports may be scanned and saved as a pdf electronically as a result. (Sad, but true.)

In short, there is room for improvement in the current landscape. Mostly it's funding and resources needed to get these labs up to the same standards as required for MU/ELR so everyone can report the same way from an interopeability perspective. I offered public comments last year on many of these challenges in response to ONC's NPRM on Promoting Interoperability. Most funding was directed to hospitals and elgible providers, but snce th elaboratory provides over 70% of data utiized in clinical decision making and the EHR, it's a key need that needs similar finaincial assistance. Many labs are just trying to keep up with testing demands for providing quality patient care (before COVID-19) and have received decreased reimburesements due to the PAMA law impacts which has forced some to close. Hopefuly, their criticality amidst the COVID-19 testing is realized and additional support is provided, so patient care doesn't suffer. That said, some IT upgrades and projects may be put on hold as resources are not currently available, even though they are critically needed. (Public health has echoed similar contraints on PHER calls. They are just trying to keep ther heads above water when swamped with COVID-19 responses.)

One other HL7 implementation guide that would be very helpful is the EHR-S guide for receipt of lab results in the EHR. It along with updates to eDOS, LOI, LRI and ELR have created an interoperable ecosystem for lab results. However, eDOS, LOI, and LRI were in the MU Stage 3 proposed rule and pulled in the final rule. Thus many have not adopted and implemented these HL7 standard voluntarily (although some may have done so.). Without the regulatory carrot, there haven't been many incentives for labs to adopt said standards. Why would they perform upgrades if it takes away from providing resources for patient care or they may need to cut staff as a result? From a business perspective, the laboratory is running on a thread and unfortunately extra resources may not available for such costly upgrades. Help is needed both in terms of education and funding to implement.

A similar aspect applies to some LIS and EHR vendors. I mentioned some interfaces don't have codesystem capabilities or an interface may still be on HL7 2.31 messaging. These are expensive to upgrade. Also if a LIS doesn't have functionality around encoding and messaging the data, a laboratory can't implement without the needed functionality. MU has gone a long ways to spur adoption, but independent labs don't have to have MU certified systems. They may have older LISs which lack some of the functionality needed for adopting the standards and why they are still faxing or sending paper reports. Lack of technical functionality can be a major barrier to adopting and implementing standards.

---

Last updated: Apr 12 2022 at 19:14 UTC