g(9) Rebecca - Vitals Provenance

[Matt Szczepankiewicz]

Hey all--we're running into the following error for the g(9) Rebecca patient:

The scenario requires Provenance data of Time : 20150622 and an Organization Name of : at the Vital Signs Section/VitalSignsOrganizer/VitalSignsObservation, which was not found in the submitted data.

This is strange for two reasons:

1) Specifying a time along with that date (eg 201506221100-0500) causes the validator to reject it. If only the date is required, shouldn't the validator accept a provenance timestamp containing just the date or a timestamp containing the date + any time on that dat?

2) The required Organization Name is blank. It seems like the validator doesn't mind if you do specify an org name here instead of forcing it to be blank, but it's still kind of odd when you read the error message.

Any thoughts on these issues?

- Matt 

[Nagesh Bashyam - Drajer]

Matt

Can you send us the XML, we will run it and examine it.

--
You received this message because you are subscribed to the Google Groups "Edge Test Tool (ETT)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to edge-test-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/edge-test-tool/374be8a3-83e6-4d7c-bf5a-fd61f4a69b88n%40googlegroups.com.

[Matt Szczepankiewicz]

Sure, here you go.

[Dan Brown SITE]

Thanks for the file, Matt.

Since this is similar to the thread here, https://groups.google.com/u/1/g/edge-test-tool/c/o9vDNZq4da8/m/ivsgBRTsAgAJ " Document-Level Provenance Timestamp ", I will post part of the same response for the resolution plan.

For the issue regarding the blank organization. The error output will now be dependent on the knowledge of the organization being null in the data. What this means from a user perspective is that a check at the document level will likely only mention the date in the error message, if it is an issue. At the section level though, the organization could still be relevant.

For the issue regarding the time value, we will update the validator to be a bit more lenient. The enforcement will work as follows:

-If the scenario includes a date, then the submitted file must match that date exactly

-If the scenario also includes a time, then the submitted file must match the precision and format of that time, but not the exact values

-If the scenario does not include a date, then the submitted file would not need to include a date. Of course, we won't likely have a scenario without a date.

-If the scenario includes a date only (no time), then the submitted file must match the exact date, but is allowed to have time as well, which matches any point in time, but also matches the required C-CDA format. This is because a submitted file can always have more data than the scenario file, but must meet its standards at a minimum.

Hopefully this helps. If there are any concerns please let me know.

Thanks,

Dan

[Matt Szczepankiewicz]

Thanks! That should address this issue!

[Matt Szczepankiewicz]

Has this issue been fixed yet? In the attached document for the b(1) sample3_v4.pdf scenario, we're seeing a similar (though not 100% identical) bug--the scenario expects a provenance timestamp of 202006221100-0500 for the vitals observations, but in the attached doc it's precise to the second (20200622110000-0500), causing the validator to throw an error on each of the vitals observations. (Some of the other data in that document genuinely doesn't match up with the expected data for the scenario and throws legitimate errors, but the 12 errors it's throwing specifically for the vitals provenance all seem like a validator bug.)

- Matt

[Dan Brown SITE]

Hi Matt,

This issue should be resolved as per the 3.1.45 April 5 2021 SITE release. Please let us know if you have any concerns.

Thanks,

Dan

[Matt Szczepankiewicz]

Hey Dan, we're still seeing odd behavior here. For instance, the scorecard seems to be throwing the error below against every VitalSignsObservation in the attached doc for the 170.315_b1_toc_amb_sample3_v5.pdf scenario  (every VitalSignsObservation in the doc has "20200622110000-0500" as its provenance timestamp). Mind taking another look?

- Matt

Error - 

The scenario requires Vital Signs Section/VitalSignsOrganizer/VitalSignsObservation (Time: Value) Provenance data which was not found in the submitted data. The scenario value is 202006221100-0500 and a submitted value must at a minimum match the 8-digit date portion of the data.

Line number: 0

[Dan Brown SITE]

Thanks, Matt. We will analyze this soon and get back to you.

[Dan Brown SITE]

Hi Matt,

The issue is two-fold.

1: There is an issue with mismatched Provenance data within your submitted document.

2: The message returned is confusing/failing to mention representedOrganization/name.

1:

A mismatch within the representedOrganization name is causing/triggering the fail.

The Ref (scenario) is expecting:

           <name>Neighborhood Physicians Practice</name>

But the Sub is providing a different name, of:

         <name>Epic FACILITY</name>

2:

The error does not properly explain this. It overly specific about the time Provenance data not found and fails to mention the representedOrganization/name data not found. There are complexities that have grouped this logic together and thus have lead to this output. By the release on 2021 04 26 it will instead read something like this when testing against the document provided, as is, with the criteria provided:

The scenario requires Vital Signs Section/VitalSignsOrganizer/VitalSignsObservation Provenance data of time and/or representedOrganization/name which was not found in the submitted data. The scenario time value is 202006221100-0500 and a submitted time value should at a minimum match the 8-digit date portion of the data. The scenario representedOrganization/name value is Neighborhood Physicians Practice and a submitted name should match. One or all of the prior issues must be resolved.

Please let me know if that makes sense and if you have any other issues or suggestions.

Thanks,

Dan

[Patrick Peyton]

Follow-up question regarding the Provenance data for Vitals.  Is the ETT always expecting the <author> for the Provenance to be in the <observation> and not the <organizer>?

We group the vitals together based on the single collection of the data, within the <organizer>  For example, user collects 5 pieces of vitals data, we have a single <organizer> with the 1 Provenance <author> but have five (5) individual <observations> without the <author> becuase it's reported in the <organizer>.

I noticed the error calls out each <observation> -  Error - The scenario requires Vital Signs Section/VitalSignsOrganizer/VitalSignsObservation Provenance.

Here's a small snip of code - 

<organizer classCode="CLUSTER" moodCode="EVN">

                            <!-- ** Vital signs organizer (V3) ** -->

                            <templateId root="2.16.840.1.113883.10.20.22.4.26" extension="2015-08-01" />

                            <templateId root="2.16.840.1.113883.10.20.22.4.26" />

                            <id root="638dc54e-1f29-474a-8a60-e3307dd96130" />

                            <code code="46680005" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Vital signs">

                                <translation code="74728-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Vital signs" />

                            </code>

                            <statusCode code="completed" />

                            <effectiveTime value="20150622101500-0600" />

                            <!-- The author represents the person who provides the content in the document -->

                            <author>

                                <templateId root="2.16.840.1.113883.10.20.22.5.6" extension="2019-10-01" />

                                <!-- datetime of when the information was recorded -->

                                <time value="20210429124300-0600" />

                                <assignedAuthor>

                                    <!-- The physician's NPI number where root identifies National Provider Identifier -->

                                    <id root="2.16.840.1.113883.4.6" nullFlavor="UNK" />

                                    <assignedPerson>

                                        <name>

                                            <given>User1</given>

                                            <family>Healthland</family>

                                            <suffix>IV</suffix>

                                        </name>

                                    </assignedPerson>

                                    <representedOrganization>

                                        <!-- Tax Identifier of Company Record -->

                                        <id root="2.16.840.1.113883.4.2" extension="12-1222222" />

                                        <name>Centriq Hospitals</name>

                                        <telecom use="WP" value="tel:+18008883254" />

                                    </representedOrganization>

                                </assignedAuthor>

                            </author>

                            <component>

                                <observation classCode="OBS" moodCode="EVN">

                                    <!-- ** Vital sign observation (V2) ** -->

                                    <templateId root="2.16.840.1.113883.10.20.22.4.27" extension="2014-06-09" />

                                    <templateId root="2.16.840.1.113883.10.20.22.4.27" />

                                    <id root="f5d59ded-8b52-44c5-9f1a-569d701c7daf" />

                                    <code code="8302-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Height" />

                                    <statusCode code="completed" />

                                    <effectiveTime value="20150622100500-0600" />

                                    <value xsi:type="PQ" value="69.69" unit="[in_i]" />

                                </observation>

                            </component>

                            <component>

                                <observation classCode="OBS" moodCode="EVN">

                                    <!-- ** Vital sign observation (V2) ** -->

                                    <templateId root="2.16.840.1.113883.10.20.22.4.27" extension="2014-06-09" />

                                    <templateId root="2.16.840.1.113883.10.20.22.4.27" />

                                    <id root="35ef9b8b-96d7-4364-a6ed-058477597bb9" />

                                    <code code="29463-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Weight measured" />

                                    <statusCode code="completed" />

                                    <effectiveTime value="20150622100500-0600" />

                                    <value xsi:type="PQ" value="194" unit="[lb_av]" />

                                </observation>

                            </component>

[Nagesh Bashyam - Drajer]

Yes

We are looking for provenance information at the observation entry level similar to what is done in FHIR at the resource level.

Thanks
Dragon

> On Apr 29, 2021, at 3:24 PM, Patrick Peyton <dp8...@gmail.com> wrote:
>
>

[Vijai Kumar RK]

Can we have 170.315_b1_toc_amb_sample3_v5 CCDA sample file

[Nagesh Bashyam - Drajer]

You can download from the tool…

--
You received this message because you are subscribed to the Google Groups "Edge Test Tool (ETT)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to edge-test-too...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/edge-test-tool/fb3b539b-a062-46a2-b01a-da025c13b8e6n%40googlegroups.com.