FHIR Chat · MFN_10 to CatalogEntry · Orders and Observation WG

Stream: Orders and Observation WG

Topic: MFN_10 to CatalogEntry

Richard Bagley (Jan 08 2019 at 21:53):

We are looking to convert our existing MFN files to a FHIR compatible bundle. However, we are having a problem listing each of the tests for each Laboratory profile to express what will be tested. Are there any plans on how this would be approached?

Lloyd McKenzie (Jan 08 2019 at 22:01):

@Eric Haas @Jose Costa Teixeira ?

Jose Costa Teixeira (Jan 09 2019 at 11:10):

We are working on Catalog for that purpose. I admit i lost track a bit but the overall picture is to have a Composition which contains a set of definitions.
I would have to ask for that concrete case, but if you have several Laboratory profiles, my first guess would be that we will have a composition that lists the Laboratory profiles, and also lists the tests contained in each profile, represented by ObservationDefinition resources.

Jose Costa Teixeira (Jan 09 2019 at 11:12):

Note that this is not mature enough so it may change, but the idea that covers MFN is to have an "authored" list of definitions. The List would be Composition, and the definitions would be any of the definitional resources - medication, device, observation (for a lab test), planDefinitions (for a list of protocols)

Yassiel Oliva (Jan 09 2019 at 14:01):

Our approach was to have a CatalogEntry for profiles and tests. In both cases wrapping anObservationDefinition. the only difference would be that CatalogEntry that represents tests would have as relatedEntry the profiles where the tests belong and relationType = child. the problem is because we saw a mismatch between the possible values of relationType:

pasted image
pasted image

Jose Costa Teixeira (Jan 09 2019 at 15:51):

Yes, I did not mention the "CatalogEntry" for some other reason, but that is the construct we have.

Jose Costa Teixeira (Jan 09 2019 at 15:52):

@Yassiel Oliva Thanks for pointing it out, there seems to be a typo/issue with the binding. It should not be requred if it mentions "etc".

Jose Costa Teixeira (Jan 09 2019 at 15:53):

http://build.fhir.org/valueset-relation-type.html should be expanded to support things like "contains, uses, replaces, requires,..."

Jose Costa Teixeira (Jan 09 2019 at 16:01):

created a tracker item for that. #19954

François Macary (Jan 16 2019 at 15:37):

The lab catalog with FHIR aka "eDOS on FHIR" uses Composition, CatalogEntry, ActivityDefinition, ObservationDefinition, SpecimenDefinition. The latest version of CatalogEntry is not built yet. There has been a lot of cleanup on this resource in December. It should appear in the build next week. Please ton post trackers on the current state.
In addition, we expect to discuss again this resource Thursday Q2 in OO WG. Please come to the discussion if you are available.

François Macary (Jan 16 2019 at 16:04):

@Yassiel Oliva
More specifically, the representation of the individual tests of a panel or of a profile is like this:
- The profile is described as an instance of ActivityDefinition hooked to the catalog.
- Each test of the profile is carried by an instance of the element ActivityDefinition.observationResultRequirement, which references an instance of ObservationDefinition.
This is also part of the discussion tomorrow.

Here is an example of the current representation of a lab panel:
pasted image
pasted image

Hope it helps.
Regards.

Artem Pavlov (Mar 05 2019 at 09:29):

Hello, we adopt our laboratory catalog to FHIR R4 resources. We have started with ActivityDefinition, SpecimenDefinition, and ObservationDefinition.
Next step was to check it with our clients. We started with the creation of ServiceRequest based on ActivityDefinition using "$apply" operation, and it works great. It would be great to have the same operation for SpecimenDefinition. Have anyone already discussed it?

Lloyd McKenzie (Mar 05 2019 at 15:45):

@Eric Haas ?

Eric Haas (Mar 05 2019 at 17:08):

@Rob Hausam , @François Macary ( BTW this is what I want to do with ObservationDef too!)

François Macary (Mar 05 2019 at 17:30):

What do you mean by "BTW"? I don't understand.

Lloyd McKenzie (Mar 05 2019 at 17:31):

"btw" = "by the way"

Eric Haas (Mar 05 2019 at 20:01):

@Riki Merrick may be have information as well

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 03:27):

Is your catalog a laboratory order catalog with specimen requirements?
If so, are you planning on applying the Specimen Definition to reflect which specimen was actually collected?

Rob Hausam (Mar 06 2019 at 12:38):

I think if we are talking about using $apply to create a ServiceRequest from SpecimenDefinition or ObservationDefinition, I think that should work. In the case of SpecimenDefinition the ServiceRequest would then be for the specimen collection procedure. If we would do that we probably would need to add something specific about it to the ServiceRequest documentation.

Eric Haas (Mar 06 2019 at 14:22):

Soecimemdef does not define the activity but rather the thing itself so I don’t see how that translates to an activity. It answers the question what specimen. But It certainly can be the template for creating the specimen instance too.

Alexander Ivanov (Mar 06 2019 at 14:25):

Yes, we try to use ActivityDefinition, ObservationDefinition, and SpecimenDefinition for laboratory order catalog with specimen requirements. We have encoded tests with ActivityDefinition and tested the "$apply" operation to produce ServiceRequest.

Our next step is to encode the Specimen required for ActivityDefinition with SpecimenDefinition.

We have several issues with SpecimenDefinition:

1. TypeCollected field have cardinality - "0..1". So we can't link "TypeCollected", "Collection" with "TypeTested". For example, the lab can accept "Blood venous" and "Microcapillary blood" for "Alanine Aminotransferase (ALT)". Using R4 we can encode it like:

SpecimenDefinition
    TypeCollected = Blood
    Collection = [Venipuncture, Finger-prick sampling]
    TypeTested = [Serum|Evacuated blood collection tube, Serum|Microcapillary blood collection tube, Plasma|Evacuated blood collection tube, Plasma|Microcapillary blood collection tube]

With such encoding, we have no knowledge of how Collection and TypeTested are connected. We can use something like the following to solve this issue:

SpecimenDefinition
    [
        {
            TypeCollected = Blood venous,
            Collection = Venipuncture,
            TypeTested = [Serum|Evacuated blood collection tube, Plasma|Evacuated blood collection tube]
        },
        {
            TypeCollected = Microcapillary blood,
            Collection = Finger-prick sampling,
            TypeTested = [Serum|Microcapillary blood collection tube , Plasma|Microcapillary blood collection tube]
        }
    ]

2. We would like the $apply operation on ActivityDefinition could recursively apply SpecimenDefinitions as well. We would like to discuss is it a best practice? How to pass selected SpecimenDefinitions to the $apply operation?

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 14:38):

Thanks for sharing more info.

1. It is correct that for the Service Request on a patient instance, one needs to know which Specimen was collected as only one of the "allowed" specimens in the Specimen Definition will be collected per test order normally (unless there are several orders such as profiles/convenience panels for those involved in those discussions recently). If the patient is pediatric, a microcapillary container may be collected while adults typically will have a venous collection for a tube of blood for ALTs.

The linkages shown with (Specimen)Type Collected, Collection Procedure, and Type Tested look great logically organized. Will defer to @François Macary @Lloyd McKenzie or @Rob Hausam on your questions.

2. The second part that is needed is the Collection Procedure as testing cannot commence without a specimen.

3. The overall question/need is how Service Request, Specimen, Collection Procedure, Observation, and Diagnostic Report all tied together from an implementation workflow perspective for each lab test? We've been discussing aspects in different Workgroups/calls from Service Catalog (Francois, Rob), to Workflow (Lloyd) to Specimen Dam (Rob, Riki), to O&O. All are needed from an end to end (catalog, order to result perspective) and need to be aligned to handle lab ordering and resulting successfully.

@Lloyd McKenzie Can you remind us of the aspects discussed on the workflow calls to achieve? The specimens to be collected I believer were listed as tasks, but what was actually collected would be Type Collected. Once processed (either at the collection/draw station or at the laboratory dependign on scenario), the specimen would be Type Tested. In the lab, following Specimen DAM, dereived specimens may occur as discussed with @Riki Merrick commonly for pathology, microbiology, but also some clinical lab testing. (Won't get into the complex referral use cases yet..)

Do we need to follow some exampes through to make sure harmonization has occurred across WGs/Resources?

François Macary (Mar 06 2019 at 15:52):

On the example of two kinds of specimen collected depending on whether the patient is a child or nor, I would typically use two distinct instances of SpecimenDefinition, one for microcapillary collection and one for the venipuncture. Each instance having its own patient constraints (e.g. age below 12 Y). Currently SpecimenDefinition offers only a patientPreparation element. We might want to add another element for patientConstraint, for instance.
@Alexander Ivanov do you plan to come to Montreal in May, and test your developments on the catalog track? That would be great.

François Macary (Mar 06 2019 at 15:59):

@Eric Haas , SpecimenDefinition does include the collection activity: element "collection"., so it could be use to generate the ServiceRequest for specimen collection, as @Rob Hausam points out. Nevertheless, I also agree that it might be interesting to generate the Specimen instance from SpecimenDefinition.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 16:33):

Thanks @François Macary There are cases with hard to draw adults too where a fingerstick capillary collection may be needed for a patient in order to get a viable specimen, so not limited to pediatric patients, although they are the most common reasons why a capillary collection occurs. There is no way to know until the phlebotomist collects the specimen which one will be needed.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 17:03):

Ideally, I'd expect when a Service Request for a lab test is instatiated on a patient (by the physician placing the order), then a series of data elements are created automatically. It'd include the Service Request for all specimen collections. (Question, would multiple Service Requests be needed if multiple containers/tubes are collected or is it a single Service Request for 5 tubes to be drawn or however many dictated by the tests requested? In the labs in which I've worked, we've only billed for a Single Venipuncture no matter how many tubes are drawn as it's a single stick/collection procedure.)

The person collecting needs to know which containers are needed (types, additives), how many of each to produce minimum specimen requirements, and aspects such as order of draw and discard tubes (for coags) depending on tests ordered. The person collecting or physician ordering may need to know about Ask at Order Entry Questions (AOEs) where they indicate for a Wound Culture Swab where was it collected from on the body?, or for a timed urine specimen collected by the patient that it was a 2 hour or 24 hour collection. These items also need to be generated with the Service Request so they are available at the point the data are available to be entered. Some data ideally may be pulled from the EHR such as Last Menstrual Period (LMP) for Pap Smears, while others may be hand entered at various points throughout the ordering, collection, or processing, steps.

Once the Collection Procedure has taken place (as indicated by the human performing the collection), then to update the collection status as performed, and indicate however many specimens have been collected for specimen tracking, etc., the actual specimen instance needs to be created. I wouldn't do it at the time of order entry as it's impossible for a physician who is placing the medical/legal order to know what is collected (microtainer or regular tube), how it's collected (venipuncture, or fingerstick), in which containers/with which additives (EDTA, Lithium Heparin, no additive) or how many of each are collected (3-4 microtainers or single 4-5mL tube to meet the minimum volume requirements to perform the testing), unless they are performing the collection themselves. For surgical specimens/pathology/trauma, this may be the case, but for most routine testing, a nurse, phlebotomist or even the patient (for urine or stool specimens) is collecting.

Information about which containers are collected will also dictate which specimen Types will be Tested. No additive containers (red, gold, Royal Blue, will result in serum. EDTA/lavender top container results in Plasma, Lt Blue Container with Sodium Citrate, Grey container with sodium fluoride, pink container with EDTA K2, or a Light Green container with Lithium Heparin, can all result in plasma specimens.

Next, once specimens are collected, are any processed by the area collecting the specimens (i.e. clinic lab or draw center) or is transport (tube, courier) needed for the specimen(s) to get to the lab for processing there and analysis. In service catalog, this is where aspects such as transport serum frozen, protect from light, etc. would be instantiated as applicable. This is also where Type Tested may come into play or later for unprocessed specimens once they reach the performing laboratory. If the draw center/clinic lab spins down the tube/microtainer and aliquots the serum or plasma into another container for transport, the Type Tested would be indicated as Serum or Plasma accordingly depending on which container/additives have been collected (and not both).

This gets into all kinds of pre-analytical workflow complexities beyond scope of service catalog, but implementing many of the service catalog definitions and ensuring the service catalog information is available at the right time, right place and right format for the appropriate health professionals to utilize in the steps of the workflow so the laboratory gets all they need once the specimen reaches the laboratory so they can commence with the Analytical Phase of testing and produce quality, safe patient results

François Macary (Mar 06 2019 at 17:40):

Thanks @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM
In any case, no matter how the choice is made and on which criteria, in @Alexander Ivanov use case, two instances of SpecimenDefinition need to be attached to the ActivityDefinition representing the orderable test.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 17:45):

Actually, wouldn't more be needed to reflect the different combinations resulting in Specimen Type tested for Serum (capillary or venous) or Plasma (capillary or venous and different containers additives resulting in each Specimen Type tested -i.e. Specimen Definition (capillary collection red top no additive resulting in serum specimen type tested), Specimen Definition (venous collection, green top tube with lithium heparin additive, resulting in blood Type collected, plasma type tested), etc. ? (Hoping to avoid such combinatorial explosion as it can get really complex really quick!)

Artem Pavlov (Mar 06 2019 at 18:25):

We tried to encode different specimen in two different SpecimenDefinition, which attached to ActivityDefinition.
But some lab test needs both SpecimenDefinition, for example: “Test of renal function, creatinine clearance test, Rehberg test”.
In this case, we need to be collected both Specimen urine and blood.
So if ActivityDefinition will have two SpecimenDefinition, how we can decide when it is a variable SpecimenDefinition (venous or capillary) or it is both required SpecimenDefinition (urine and blood).
When we have linkage like in ALT use case we have more flexibility to define Specimen required for an orderable lab test.

Artem Pavlov (Mar 06 2019 at 18:26):

Sorry for my English

François Macary (Mar 06 2019 at 19:42):

Thank you @Artem Pavlov for the very good point. My suggestion was incorrect, then, and you're right: The instances of SpecimenDefinition referenced by ActivityDefinition are cumulative: Each specimen is expected to be collected. At this point we have alternates only under SpecimenDefinition.typeTested. This brings us back to the issue raised by @Alexander Ivanov . How would you view the best structure for SpecimenDefinition to suit the need for alternates at the level of typeCollected? One way to go might be to make typeCollected a big backbone element with cardinalities 1..*, and put all the rest (patientPreparation, typeTested) within this backbone. Would that work?
To be further discussed at our next catalog call.

Artem Pavlov (Mar 06 2019 at 20:03):

@François Macary, yes, I think this way is necessary and it can help us to resolve our issues. It may be a good first step to optimize resource SpecimenDefinition.

Alexander Ivanov (Mar 11 2019 at 08:15):

Thank you, @François Macary , @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM , you've mentioned a lot of very good problems.

This week we will try to encode several complex lab tests and panels (maybe we will try to encode genetics lab tests as well) to find some other issues with SpecimenDefinition and suggest improvements.

@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM have mentioned "Ask at Order Entry Questions (AOEs)". In our current implementation (FHIR R3) we use Questionnaire resource for this purpose. A Questionnaire has several advantages over ObservationDefinition:
1. Structured Data Capture (http://hl7.org/fhir/us/sdc/index.html) project described how EHR info can be gathered automatically.
2. Some questions may not be health related (government requirements), we don't want to encode them as patient Observations.
3. There is an extension to link Questionnaire and ActivityDefinition (https://www.hl7.org/fhir/extension-servicerequest-questionnairerequest.html). We can use it for $apply operation on ActivityDefinition.

A Questionnaire also a definitional pattern, so we can use it in ActivityDefinition.

Also, @Artem Pavlov and I are going to join Orders and Observations: Conference Call. I plan to come to Montreal in May, but I'm waiting for a visa decision.

Eric Haas (Mar 11 2019 at 14:14):

What is preventing you from using questionnaire for specimen definition too?

Alexander Ivanov (Mar 12 2019 at 11:33):

It sounds good, I believe we can use a questionnaire to ask about types to be collected and types to be tested.

Anyway, I think we should have some resource to describe the specimen prototype. It can be a specimen with draft status (doesn't exist now, and I'm not sure it is correct) or specimen definition. Also, I think SpecimenDefinition should be more aligned with Specimen. It should not try to encode several states of a specimen (like a specimen for a lab testing, a specimen to be collected) in one definition.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 18 2019 at 13:27):

Thanks for sharing more info and joining the call last week. Was only able to hear first half of call due to being called away. @Alexander Ivanov interested in learning more about the use cases where you are using Questionnaire, SDC, and AOEs. Want to make sure we have captured all the resources folks may be using to capture information at Order Entry and what does and does not need to be included in the Catalog. Also workflow in exchanging captured information. Am on the v2 to FHIR calls and will be working on mapping all the resources folks are using. Also, if items are discretely captured and encoded with standard code systems or only discretely captured and stored as text blobs or potentially discrete fields (seen a variety of implementations.)

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 18 2019 at 13:29):

@Eric Haas Why that approach? Would that appraoch allow you to capture all the CLIA required Specimen data elements/Specimen DAM info?

Eric Haas (Mar 18 2019 at 15:02):

Well a form is generic and could define anything. An observation or specimen or activity.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 19 2019 at 12:20):

From an interoperability perspective, why wouldn't one use the laboratory defined (US) CLIA Specimen Collection Manual orders, results and AOEs built in the LIS, which then could be served up to the EHR so the same items/concepts/terms/ are used for CPOE, and then sent in the order to the performing laboratory where those items are already built in the LIS and reported to downstream entities such as the ordering provider and public health. Patient instance data can be entered at each step as applicable to be exchanged accordingly.

Specifically for Specimen related information, the laboratory required specimen containers, additives, processing aspects, etc are also in the Specimen Collection Manual/Catalog. Laboratories can reject specimens not meeting their criteria for quality, min volumes, etc. Whomever is collecting the specimen needs to indicate the collection procedure, specimen collected, containers (peds/adult), specimen source (from where a swab was collected or pathology tissue specimen) as often the laboratory doesn't know that information and it is needed to be able to report to public health by law in a number of cases. It's important to know the context to know if an "ear" is a specimen type (for pathology) or specimen source for microbiology culture (with a swab specimen)

While a generic form can be used to collect the information, if the data are not discrete, and codified appropriately, such efforts may not produce much value (at least from the laboratory perspective). It may be fine for many clinical notes, or data elements that might be stored as text blobs, but when actionable data may be needed for clinical decision support, downstream entities, etc. discrete data is better, and discrete, codified data is best.

@Alexander Ivanov indicated there are government required data elements that are needed. Do you have more information as to what those data items entail and how they are required for lab orders, but separate from the test catalog? Do want to make sure the O&O models meet requirements, especially country differences. HL7 v2.51 has been implemented and used widespread and while there is also a project to ensure V2 elements are represented in FHIR, it is early in the process. Understanding more of the information needs will allow us to shape the standard to make it more usable.

From the response @Eric Haas it wasn't clear how CLIA requirements would be met. Can clarification be provided?

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 19 2019 at 12:25):

@Alexander Ivanov with your original point #2, why wouldn't patient specimen information/data be considered a patient observation since it's about a specimen coming form a patient? Laboratory testing is patient centric and specimen centric by its nature (CAP even defines data files such as genomics re-analysis as a specimen). I appear to be missing a point. Can you help me understand? Are the data not specimen related?

Eric Haas (Mar 19 2019 at 15:59):

my response has to do strictly with structuring the data and not the content. Questionnaires can contain any required information. The questiionnaire is a generic definitional resource and could be used to define anything.

Alexander Ivanov (Mar 19 2019 at 18:47):

@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM , we started to use FHIR for lab ordering before R4. ObservationDefenition was not introduced and we had to describe AoE somehow. The questionnaire is a good choice for a set of questions and SDC project introduced the way to auto-populate it (http://hl7.org/fhir/uv/sdc/2018Sep/populate.html#obs-pop) with values from EHR, so the questionnaire solved all our issues with AoE for STU3.

Also, questionnaire:
0. (see previous message above);
1. Can encode logic between questions (see "enableWhen");
2. Some companies have made universal renderer for questionnaire, so they can reuse it.

Alexander Ivanov (Mar 19 2019 at 19:25):

Most questions are related to patient observations, but for some tests, a lab is enforced to report some other information like geolocation of bite for Tick-borne borreliosis test or address/"contact info" for HIV testing.

Alexander Ivanov (Mar 21 2019 at 11:45):

We discussed $apply operation on SpecimenDefinition yesterday but we didn't have much time. So I'd like to copy some of the proposals here.

I've checked "$apply" operation for ActivityDefinition found at:
- https://www.hl7.org/fhir/activitydefinition.html#12.17.3.3
- https://www.hl7.org/fhir/activitydefinition-operation-apply.html

I think we should use the same logic for SpecimenDefinition:
- Create the Specimen resource and focused on the Patient in context
- Set the status of the Specimen to draft (no such status right now)
- Apply the structural elements of the SpecimenDefinition to the target resource such as type, collection, processing, container, and so on
- Resolve the collector element based on the collector in context
- If the transform element is specified (no such element now), apply the transform to the resource
- Apply any dynamicValue elements (no such element now) by evaluating the expression and setting the value of the appropriate element of the target resource (as specified by the dynamicValue.path element)

Can we do the following:
1. Add draft/proposal status for the Specimen?
2. Add transform field to SpecimenDefinition?
3. Add dynamicValue to SpecimenDefinition?
I'd like to remove "collected-date-time" and "collected-period" from our xml template. This fields can be filled using dynamicValue.

<dynamicValue>
<path value="collection.collectedDateTime"/>
<language value="text/fhirpath"/>
<expression value="now()"/>
</dynamicValue>

Additionally, we have similar parts of Specimen and SpecimenDefinition but under different naming or with slightly different fields. Maybe we should check it:
- Specimen.processing <=> SpecimenDefinition.handling
- Specimen.container <=> SpecimenDefinition.container (different fields)
- Specimen.collection <=> SpecimenDefinition.collection (BackboneElement vs CodeableConcept)

Yassiel Oliva (Jun 13 2019 at 15:00):

Hi, we are using ActivityDefinition to hold our profiles definition (orderable items) but now we have a problem because we want to have in the same compendium profiles that are orderable for male OR female there is any way to specify that in ActivityDefinition level?

Jose Costa Teixeira (Jun 14 2019 at 18:06):

ActivityDefinition.subjectReference points to a Group, so you can use Group to define male/female

Artem Pavlov (Aug 06 2019 at 11:07):

Hi, we are using ActivityDefinition to hold our profiles definition (orderable items) but now we have a problem because we want to have in the same compendium profiles that are orderable for male OR female there is any way to specify that in ActivityDefinition level?

May be you can use ActivityDefinition.useContext - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate activity definition instances.

Aleksandr Sorokin (Dec 03 2019 at 19:27):

Hi, we are using ActivityDefinitions to hold our laboratory tests catalog and want's to store ObservationDefinitions with description of Observations which may be produced. The problem is that for some tests there may be additional observation, the availability of which depends on the test result. By FHIR R4 standard ActivityDefinitions.observationResultRequirement described as "What observations must be produced by this action". it is very important to indicate which observations must and which may produced. So how to implement such case?

Lloyd McKenzie (Dec 03 2019 at 19:51):

@Bryn Rhodes

Bryn Rhodes (Dec 05 2019 at 04:13):

Hi @Aleksandr Sorokin , this is an interesting case. I'll start by saying that the general pattern for DataRequirements doesn't necessarily imply cardinality of the provided data, so I would expect a symmetry on the output side. The detailed description of the observationResultRequirement element actually uses the wording "expected to be produced", which implies some optionality. If you need to be able to specify that optionality as part of the use case though, I think that an extension to support that would be necessary. And since the short description (as you rightly point out) says "must be produced", I think it would need to a modifier extension, something like potentialResult.

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

Also since this is related to teh specimen. May look at Specimen DAM. Don't' think we have shipping info, but if it needs to be added, feel free to bring up on Specimen call.

Last updated: Apr 12 2022 at 19:14 UTC