Stream: implementers
Topic: Vital signs and LOINC
Brian Reinhold (May 26 2017 at 13:38):
It is not clear to me if I HAVE to use LOINC codes for reporting a vital signs measurement in an Observation resource. This sentence
"The following core profiles for the Observation resource have been defined as well. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the following profiles:"
The Vital-Signs profile is the required profile.
If I am making my own profile and using the Observation to report a vital signs measurement, do I have to (also) use a LOINC code to beFHIR compliant?
Lloyd McKenzie (May 26 2017 at 15:08):
Yes. The LOINC codes are intended to establish a minimal level of international interoperability around vital signs. However, you're free to send additional codings for whatever other code systems are useful to you and those you exchange with.
Brian Reinhold (May 26 2017 at 16:03):
Lloyd,
When I brought this up at a European PCHA meeting last week there was opposition to this requirement. They have their own realm coding requirements.
Lloyd McKenzie (May 26 2017 at 16:52):
They're not prohibited from meeting those requirements. However, given that LOINC is free to everyone worldwide, that the number of codes to be mapped is small and that vital signs data is important to so many uses, it seems a reasonable imposition to ask implementations to include the indicated LOINC codes along with whatever other codes are required in a given jurisdiction/implementation environment. While there's been some resistance, thus far there's been no indication from anyone that they can't meet the requirement for technical, legal or cost reasons.
Richard Kavanagh (May 26 2017 at 22:07):
Nothing to be said that has not already been said before. HL7 do not know or pay the cost of conformance in jurisdictions yet have the view that that cost is reasonable. The rationale for using LOINC on vital signs is weak and could easily be extended to anywhere else in the FHIR specifications.
Grahame Grieve (May 26 2017 at 23:13):
perhaps you could explain more about the cost of conformance? As for the rationale... I don't think extending it would be easy
Grahame Grieve (May 26 2017 at 23:14):
though a lot of users would really really like us to do that
Grahame Grieve (May 26 2017 at 23:15):
The principle cost you have explained before is that systems don't know whether observations are actually vital signs or not. And this forces the source of the data to define whether they are.
Richard Kavanagh (May 26 2017 at 23:43):
So for us when using in national scale systems, off the top of my head...
- we would first have to define and maintain a cross mapping between SNOMED & LOINC
- distribute and maintain the mapping, additional work for both ourselves and our suppliers
- suppliers would then need to either extend their data model for this new code system or manage a mapping at the interface level
- as we would be forcing suppliers to do this we would need to assure that they are doing it correctly. We would need more tests, the supplier would need more testing and we would have more overhead
- suppliers would need to cater that for a set of arbitrary observations, we would call them "vital signs" and they would need to map them to LOINC. Not all the vital signs just the ones that another jurisdiction decided were vital signs.
- we ourselves would need to create our own vital sign category which would overlap with the one imposed so we would need to have a "vital signs" category called something else.
- we would need to explain this across our broad FHIR estate of RESTful, messaging and document solutions as we enter STU3.
- we would need to explain why when we already have challenging volumetrics discussions we are proposing to add more payload that has no local value
- we would have to explain to many different stakeholders that although as a jurisdiction where we are strongly pushing SNOMED we are confusing the task by at the same time asking for LOINC
- extrapolate this across many different programmes of work national, regional & local
- and all of this so as to support LOINC which not a requirement of any of our programmes
- and finally having to explain to our implementation community that we need to do this even though it adds no local value
The biggest issue though is having to explain why we are using a standard that used to be terminology agnostic, that may at any time mandate LOINC in other areas and as such impose further local challenges.
Lloyd McKenzie (May 27 2017 at 00:58):
That's one option Richard, but another possibility is that implementers can just map each of their local codes for vital signs to LOINC at the same time they're mapping to SNOMED
Grahame Grieve (May 27 2017 at 03:02):
"we ourselves would need to create our own vital sign category which would overlap with the one imposed so we would need to have a "vital signs" category called something else." - why?
Grahame Grieve (May 27 2017 at 03:03):
I think you're wrong about not adding local value, but I understand that it doesn't do that now
Grahame Grieve (May 27 2017 at 03:05):
I still think you're look at this the wrong way - as if LOINC is a thing. We just said, there's a value in having a magic value that identifies the key vital sign observations. And so we chose some magic codes. The fact that they're from LOINC is not significant.
Grahame Grieve (May 27 2017 at 03:05):
and I think that your comments support the notion that having a magic value is really useful once you start working with the data
Richard Kavanagh (May 29 2017 at 14:26):
"we ourselves would need to create our own vital sign category which would overlap with the one imposed so we would need to have a "vital signs" category called something else." - why?
OK say in our locality we deem that head circumference is not a vital sign, yet the mandatory profile says we must categorise it as one. So when we retrieve observations using the "vital-signs" category we will get "head circumference" even though we do not necessarily want it. The only thing we can do is to add a new category for "our" vital signs and add it as a second category. So now we have two categories on all of the "HL7" categorised observations the one we actually want and the one the profile mandates we must put on it. This is caused by the arbitrary definition of which observations are deemed to be vital signs. Where did that list come from...?
Lloyd McKenzie (May 29 2017 at 14:40):
It came from a consensus voting process of the international community (and before it can be locked down as normative, it will also have had to have at least 3 years of implementer experience and feedback)
Grahame Grieve (May 29 2017 at 17:57):
ok, I undestand the scenario - but is that realistic? would you deem that it's not a vital sign, and why?
Rob Hausam (May 29 2017 at 18:10):
I think it's certainly debatable whether head circumference is a vital sign - at least it wouldn't be in regard to the original meaning of the term (i.e. "signs that you are alive"). A point in time measurement of head circumference (or body weight or height) doesn't say anything about that. But those are all useful measurements that are frequently (but not universally) grouped together and tracked with other measurements that certainly are vital signs like blood pressure, heart rate and respiratory rate. Different institutions and groups do have differences in their lists and will want and need to customize the complete list according to their own view.
Grahame Grieve (May 29 2017 at 18:12):
we said that the list was open - we didn't want to say what was and wasn't a vital sign... but the specific issue Richard has identified is a sense in which we do that
Rob Hausam (May 29 2017 at 20:54):
maybe if we modified the profile to have a "core" set of VS observations that everyone really does agree on (e.g. BP [diastolic/systolic], HR, RR, body temp, and likely also body weight and height/length) and allow the others to be optional, that might help Richard's (and other's) issue at least a little bit?
I don't think you would lose much, if anything, of significance by doing that
Eric Haas (May 30 2017 at 17:08):
"and allow the others to be optional" does not fix the issue. They are still categorized as a VS if they are opted in. another approach is to have mutliple categories for head circumference in Observation: one "vital signs", an one "our vitals slgns"
Rob Hausam (May 30 2017 at 18:18):
I'm not quite sure I'm following you on that, Eric - either on not fixing the issue or about how multiple categories will help - maybe you can explain further
Rob Hausam (May 30 2017 at 18:33):
I agree that having a "core set" of vital signs doesn't mean that Richard won't have to have an additional category for "UK vital signs" (if the UK set includes something that isn't in the core set), but at least the UK wouldn't be forced to send a LOINC code for something like head circumference that they don't even consider to be a vital sign
maybe that would help just a little?
Lloyd McKenzie (May 30 2017 at 19:17):
So our objective is to ensure that a key subset of observations that HL7 considers to be vital signs are universally recognizable. The "vital signs" category that HL7 defines applies to whatever HL7 decides to put in it. It's perfectly reasonable to challenge whether head circumfrance should be considered a vital sign (though if not, what is it?) and whether it should be in the subset that's important enough to require universal interoperability. Everyone else is free to define their own categorizations. The benefit of doing so is they get tight control. The drawback is they will have less interoperability with those categories. Defining your own category won't remove the obligation to specify the HL7-defined category for those items HL7 Int'l has said fall into the vital signs profile.
Eric Haas (May 30 2017 at 19:28):
I think I said the same thing as Lloyd. @Rob we can't create a profile that has optional elements and have some opt-in and other opt out and still have universal interop.
Rob Hausam (May 30 2017 at 21:09):
I agree with what Lloyd said, too. We should just try not to include items in the subset that's important enough to require universal interoperability unless they are universally agreed on (or at least nearly so) - and maybe we're already there.
Thomas Lukasik (May 30 2017 at 21:39):
@Lloyd McKenzie RE "It's perfectly reasonable to challenge whether head circumference should be considered a vital sign (though if not, what is it?)" <= If we assume what @Rob Hausam offered as the original definition of 'Vital Signs' (i.e. "signs that you are alive"), then head circumference falls into the same set of "non-vital" extended vital signs as height and weight, since a corpse may not have a pulse or a blood pressure, but they still have a height , a weight and (except for a few exceptional causes of death) a head circumference as well. So the question is, are we lacking a working definition of "Vital Signs" within the scope of the FHIR standard? Did the "international committee" just review and approve an arbitrary set of measurements that "sounded like" 'Vital Signs' based on each voting member's individual definition of 'Vital Sign' without questioning what is or should/shouldn't be considered a Vital Sign in the scope of the standard?
Eric Haas (May 30 2017 at 21:54):
We used the vital signs CCDS from MU2015. And each 'voting member' = anybody on the HL7 OO call.
Thomas Lukasik (May 30 2017 at 22:07):
OK.. thanks @Eric Haas .. that wasn't clear from @Lloyd McKenzie's comment -- but that still leaves us with a couple of (minor?) issues in that we're lacking a working definition of "Vital Sign", and that (RE @Rob Hausam's definition of Vital Sign) some of the candidate Vital Signs that we've adopted don't actually provide any indication of "vitality" (whether the subject is alive or not), so it's hard to consider booting 'head circumference' while looking the other way when it comes to 'height' and 'weight'.
Grahame Grieve (May 30 2017 at 22:37):
I think you're taking a very narrow view of 'vital' - it's more than just whether a patient is alive.
Eric Haas (May 30 2017 at 22:49):
In fact, it is stated in the intro that is "the primary vital signs plus additional measurements such as height...".
Eric Haas (May 30 2017 at 22:50):
Because strictly speaking vitals is temp, rr, hr.
Eric Haas (May 30 2017 at 22:50):
and bp
Rob Hausam (May 30 2017 at 23:06):
Yes, we're obviously working off of the "expanded" definition of vital signs, not the "strict” (or maybe better “traditional") one, and I'm not objecting to that, since it's useful to do so - it's just that when you do there are no absolutely objective criteria to use to say what is and is not a vital sign, and different people and instutions have variations in their ideas and applications around that
Thomas Lukasik (May 30 2017 at 23:46):
Exactly, @Rob Hausam .. the only thing that seems clear is the need for either a FHIR specific working definition of "Vital Signs", or treating any of the "non vital" (extended) vital signs as just that.. extensions.
Thomas Lukasik (May 31 2017 at 00:12):
@Grahame Grieve It's not me that's imposing "a very narrow view" of vital.
And I don't think that we should use the loose interpretation of "Vital Signs" in MU 2015 as an excuse to perpetuate the problem by making it a part of the FHIR specification, and also that we can separate the core set of true vital signs from the extensions with a high degree of confidence based on the pretty much unanimous agreement (examples follow) that they are pulse rate, temperature, respiration rate, and blood pressure.
Wikipedia
Vital signs (often shortened to just vitals) are a group of the 4 to 6 most important signs that indicate the status of the body’s vital (life-sustaining) functions.
There are four primary vital signs: body temperature, blood pressure, pulse (heart rate), and breathing rate (respiratory rate), often notated as BT, BP, HR, and RR. However, depending on the clinical setting, the vital signs may include other measurements called the "fifth vital sign" or "sixth vital sign".
Vital signs are recorded using the LOINC internationally accepted standard coding system.
Note that Wikipedia also thinks that LOINC is the right choice for representing Vital Signs.
Merriam-Webster Dictionary
vital signs: Signs of life, specifically: pulse rate, respiratory rate, body temperature, and often blood pressure of a person
Cleveland Clinic Website
Vital signs are used to measure the body's basic functions. There are four main vital signs: body temperature, blood pressure, pulse (heart rate), and breathing rate.
Vital Signs (Body Temperature, Pulse Rate, Respiration Rate, Blood Pressure)
Vital signs are measurements of the body's most basic functions.
The four main vital signs routinely monitored by medical professionals and health care providers include the following:
- Body temperature
- Pulse rate
- Respiration rate (rate of breathing)
- Blood pressure (Blood pressure is not considered a vital sign, but is often measured along with the vital signs.)
Vital Signs: Indications that a person is still alive.
Vital signs include breathing, sounds of the heart beat, a pulse that can be felt, a reduction in the size of the pupils in response to bright light, movement in response to a painful stimulus and signs of electrical activity in the brain on the electroencephalogram.
~ Collins Dictionary of Medicine
Vital Signs: Any objective parameter used to assess basic life functions–eg, bp, pulse, respiratory rate, and temperature.
~ McGraw-Hill Concise Dictionary of Modern Medicine
Vital Signs: the signs of life, namely pulse, respiration and temperature.
~ Saunders Comprehensive Veterinary Dictionary, 3rd Ed
Lloyd McKenzie (May 31 2017 at 15:10):
The vote I was referring to was actually the STU ballots where the profiles were approved. Those are the votes that "count". The purpose of Observation.category is to let clients filter results to types of observations they would typically expect to see together. And in most systems that I'm aware of, height & weight are typically captured alongside blood pressure and pulse rate. (As opposed to labs or images or psychological assessments which typically each have their own separate storage locations and user interfaces.) It may be that "vital signs" is an overly narrow lable for this category, but I'm not sure what the label should be instead.
Thomas Lukasik (Jun 01 2017 at 03:58):
I think that you've defined the real problem, @Lloyd McKenzie: the term "Vital Signs" is too narrow a label for an extended set of values that includes both Vitals Signs and other related (but non-Vital) observations. So the question is, do we simply acknowledge the naming issue with a sentence or two in the documentation and live with it, or fix it?
Lloyd McKenzie (Jun 01 2017 at 04:00):
Fixing it requires someone coming up with an intuitive name for the broader grouping. If we can agree on a better name, that'd be the preferred option. If not, acknowledging the issue in the spec seems like a reasonable fallback.
Lloyd McKenzie (Jun 01 2017 at 04:00):
Do you want to raise a change request? And anyone with candidate alternative names are welcome to propose them :)
Thomas Lukasik (Jun 01 2017 at 04:07):
@Lloyd McKenzie So renaming would not be a "high impact" change? And as far as raising a change request, although I don't have as much "skin in the game" as others do when it comes to dealing with "non-vital vital signs", I could certainly do that if no one else wants to, and you think it would be beneficial to resolve the issue rather than bake it in.
Grahame Grieve (Jun 01 2017 at 04:08):
I'm not sure that coming up with a better label solves the problem, actually. I think it moves some confusion around. But going back to the earlier point... what I think I'd like is for the category tag to be recommended but not mandatory for the things that clearly aren't core vital signs, while keeping the other requirements that we have
Eric Haas (Jun 01 2017 at 04:17):
High impact depends on who you are talking about . It is for me certainly and as GG points out it doesn't solve the categorization issue that was originally brought up. But am not in favor of moving the categories around either.
Thomas Lukasik (Jun 01 2017 at 04:18):
@Grahame Grieve RE "I think it moves some confusion around".. I had a similar thought when I was trying to come up with "a better label".. it felt like I was just exchanging one problem ("Why is Head Circumference labeled as a Vital Sign?") for another ("Why are BT, BP, HR, and RR labeled as <new label here>?").
Harri Honko (Jun 02 2017 at 10:48):
Hello all, first-time participant here. I'm preparing a new vital sign panel observation to contain patient's daily activities commonly measured by the wearables (context is the Finnish PHR Project work). This panel will grab on a set of VS measurements, but will also include some other categories of observations. How would you as experts categorise e.g. 'steps taken' (has several LOINC codes with different context) or 'distance measured'? Or 'moderate-to-vigorous PA measured over 24h'? The local review team opinion in Finland is they wouldn't outright categorise those as vital signs, so we need alternative categories - or rather an opinionated answer via you experts here.
Lloyd McKenzie (Jun 02 2017 at 14:55):
You know us so well :) My guess is we need a specific category for such measurements. Feel free to submit a change proposal.
Harri Honko (Jun 02 2017 at 16:01):
Finding a good category name is going to be a challenge. Needs to be short and same time not too narrow in scope. 'tracking' - anyone, or it's too Orwellian?
Pascal Pfiffner (Jun 02 2017 at 16:18):
Would it contain mostly "fitness" parameters?
Dave Carlson (Jun 02 2017 at 16:22):
I like "fitness" better than "tracking", although there is a fuzzy boundary. Heat Rate measurement would be part of the "fitness" data set for an application collecting and evaluating fitness, but would be a "vital sign" when collected for the purpose of health evaluation.
Lloyd McKenzie (Jun 02 2017 at 16:49):
"patient-reported"?
Harri Honko (Jun 02 2017 at 17:15):
there's also notation of "health and wellness", and some parameters one can anticipate with wearables are also on behaviour - such as one's sedentariness (researchers call this "sedentary behaviour"), not just PA or "fitness"
Harri Honko (Jun 02 2017 at 17:17):
If an activity tracker measures one's average HR over a day, or RHR from the sleep time data, it's not directly "fitness" either.
Pascal Pfiffner (Jun 02 2017 at 17:55):
One could argue that HR measured during the day is reflective of the wearer's overall fitness.
Grahame Grieve (Jun 02 2017 at 21:16):
@Susan Matney - drawing your attention to this thread prior to CIMI discussion. FYI, readers, CIMI will discuss vital signs next week.
Eric Haas (Jun 03 2017 at 00:44):
The category element is 0..* because there many axis on which to categorize stuff. HR, RR, BP are vital signs but the could also and importantly be patient-reported. Before making a tracker consider which axis you are talking about. We only have published a high level general categorization after much back and forth.
Another alternative is to create a hierarchy with each category having a 'patient-reported' sub-category
Harri Honko (Jun 05 2017 at 16:59):
The idea with the Finnish PHR team is to derive all observations (so far all were purely vital-signs) from a common base observation. This discussion seems to drive towards defining another, differently named and categorised base observation for the kind of measurements I'm trying to 'observise'? That might be good also if the current strict list of UCUM units defined mandatory for vital signs in FHIR don't quite flex to - as such - fairly basic unit requirements the fitness/patient-reported category would need. I mean values like 'meters' (don't want to use centimetres for distance walked/exercised) or 'seconds' or 'minutes' for durations of different activity categories). Then on the other hand, some observations I plan to collect under a 'vital-sign panel' observation would probably be ok in either base observation track - could I 'mix and match' observations with nonsimilar categories to a single panel?
François von Kaenel (Jun 07 2017 at 05:46):
@Grahame Grieve, under the link http://www.healthintersections.com.au/?p=2487, you mention the observation category "fitness". Does it mean, that it will be added to the standard?
Eric Haas (Jun 07 2017 at 15:10):
since category is 0..* we can add as many valuesets as we want (although I don't think the specification tooling supports multiple bindings...yet) but the bindings can be no stronger than referred so not sure is that useful to provide more than a single binding. May be more appropriate to use profiles to define them.
Harri Honko (Jun 12 2017 at 10:51):
@Grahame Grieve did the CIMI discussion on vitals reach anything that could help us further here? As as status update, I've derived a Finnish PHR fitness observation base profile v0.1, visible in Simplifier here: https://simplifier.net/DailyActivityObx/fiphr-fitness-stu3. It has multiple base references to 'global' HL7 fitness observation profile or valueSets that don't exist :) until such get worked on the global level. If getting the 'fitness profile' work done on this level is too time consuming, should the PHR project define its own independent category and values?
Grahame Grieve (Jun 13 2017 at 03:34):
yes you should for now. Note that there's talk of a connectathon stream in San Diego around this subject - will anyone from Finalnd/your project be attending the San Diego meeting?
Eric Haas (Jun 13 2017 at 16:48):
@Grahame Grieve are you referring to the patient reported data tract? This would be great topic but my interest in this chat stream is the question on how to have >1 value set in the spec for Observation.category and are we able to do that?
Grahame Grieve (Jun 13 2017 at 22:39):
at the moment you can do that by slicing
Eric Haas (Jun 13 2017 at 23:32):
but not in the base standard right?
Grahame Grieve (Jun 13 2017 at 23:36):
no
Harri Honko (Jun 14 2017 at 13:45):
@Grahame Grieve we need to discuss attendance to San Diego connectathon here with the project funders. I _might_ actually not be far away from SD in September (in Arizona if all plans hold), so it would be a low extra cost to arrange. For sake of notice, there's already also a 'Daily Activity fitness panel' profile on the same project. The HL7 STU3 validator tool nor Simplifier had no complaints to set observations of both 'vital-signs' and 'fitness' categories under the observation.related.target.
Harri Honko (Jun 14 2017 at 13:46):
Doesn't of course relate directly to Eric's question.
Eric Haas (Jun 14 2017 at 16:23):
My questions are actually from a FHIR Core editor perspective. .category has a Max of * so it should support multiple axis. In the core spec we only get one bite at the apple when publishing a valueset. So proposing a second set of values is tricky although we could add something in the text somewhere. A concept like fitness could capture more that just vitals so not appropriate to stick in the vitals profile in the FHIR spec.
Brian Reinhold (Jun 20 2017 at 11:37):
Well this discussion has gone a lot further than I expected at the start. My original concern was the requirement to follow the vital signs profile when my Observation reported a measurement that was considered a vital sign. That includes the requirement of using LOINC in the code, UCUM in the code for the units of the valueQuantity, and specifying a category.
In the PCHA profile for reporting measurements from PHD devices (used primarily for remote patient monitoring) there is no category, and the MDC coding system is used. In the valueQuantity, we use MDC codes for the unit code and system, but we do optionally use UCUM in the unit string value to get the best of both worlds (if the UCUM transaltion is known). Since vital signs are fairly common, we are concerned about message bloat when we need to upload data from streaming pulse oximeters or heart rate monitors. Given that the MDC code specifies not only what the measurement is but also frequently the measurement technique (there are several codes that specify heart rate but they are different when the come from a pulse ox, ecg, bp cuff, or activity monitor) thus we want to keep the MDC code. But that means doubling up on the code.coding and adding a category element.
In addition, LOINC codes are not provided by the devices, MDC codes are. If there is a future device that measures a heart rate in a different manner (say a continuous bp meter) today's gateway will not be able to map that device to the specified set of LOINC codes because it wont know that it is a vital sign and it will not know the mapping. It will, however, be able to create the MDC code for the Observation.code.coding.code element since it is provided by the device. It does not have to know what the code means.
As I look at the problem of requiring the vital signs profile its more a matter of message bloat and future interoperability. One thing the 11073 specifications have going for it is that it is extensible. Granted the end reader will have to be up to date with the latest codes, but the gateways in the field won't.
Grahame Grieve (Jun 20 2017 at 11:41):
is that better? that all the applications reading vital signs will have to know all the possible source codings?
Brian Reinhold (Jun 20 2017 at 11:50):
Those following the PCHA profile will as all the measurements are reported using the MDC nomenclature codes There are many more measurement types than just vital signs). At least these codes follow a standard that is used in V2 messaging as well. We would rather put the burden on the reader than on the set of potentially thousands of remotely located gateways. As it is, the gateway has the challenge of handling the medical devices. It is PCHA's hope that more devices will eventually follow the standards. Today many do not and spit out their data in a proprietary manner. To work with these the gateways are already stuck with mapping to the MDC standard. Obviously there is no way an existing gateway can work with a new proprietary device.
Grahame Grieve (Jun 20 2017 at 11:51):
I'm sure you'd rather not solve the problem at all; just leave the consumers of the data to figure it out. All EHR clients will naturally know about and keep up with the MDC standard
Jayashree Surnar (Jul 25 2017 at 10:39):
hi,
how to specify bodyposition as partof bp measurement? whether it is Observation.bodySite or something else?
Lloyd McKenzie (Jul 25 2017 at 13:44):
It would be a component observation
Richard Townley-O'Neill (Jul 26 2017 at 00:56):
Wouldn't the extension (observation-bodyPosition) be on Observation rather than Observation.component?
Eric Haas (Jul 27 2017 at 01:23):
@Richard Townley-O'Neill You are correct. There are other codes as described in the Comments here that can be used to describe the cuff position.
Eric Haas (Jul 27 2017 at 01:23):
Just add more observations
Jayashree Surnar (Jul 27 2017 at 04:47):
thank you all, yah i found the bodyPosition extension in simplifier.net but that extension doesn't contains the valueset like sitting,standing etc. so i want to create our own extension bodySite which has the codes like sitting,standing etc. for that i need to create valueset also but here my doubt is if i create valueset wich has the above values then what code and codesystem i need to choose?
Eric Haas (Jul 27 2017 at 16:52):
that is up to your use case and copyright requirements. Here in the US, I prefer SNOMED since we are licensed to use it.
Jayashree Surnar (Jul 28 2017 at 04:30):
@Eric Haas thank you.
Last updated: Apr 12 2022 at 19:14 UTC
