Inconsistancy between the write and read operations for clinical document
fieranmason@gmail.com
#1 Posted : Friday, August 23, 2013 1:46:01 PM(UTC)
Rank: Member

Groups: Registered
Joined: 7/8/2013(UTC)
Posts: 22
Points: 66
Location: University of Victoria

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
Hello Everest,

We have encountered an issue with the parsing function of Everest.

We have successfully implemented the complete generation of a CDA document using Everest and we are now moving to the import portion of our project.

When we attempt to import the document we have successfully created, we find inconsistent read and write behaviour for the code attribute of our start element

Here is some code to demonstrate this:


public static void SaveDocumentToDisk(ClinicalDocument clinicalDocument, FileInfo cdaFileInfo)
{
MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter fmtr = new MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter();
fmtr.ValidateConformance = true;
fmtr.Settings |= SettingsType.SuppressXsiNil;

fmtr.GraphAides.Add(new ClinicalDocumentDatatypeFormatter());

using (FileStream stream = File.Open(cdaFileInfo.FullName, FileMode.CreateNew))
using (XmlWriter writer = XmlWriter.Create(stream, new XmlWriterSettings() { Indent = true }))
using (XmlStateWriter xsw = new XmlStateWriter(writer))
{
xsw.WriteStartElement("ClinicalDocument", "urn:hl7-org:v3");
xsw.WriteAttributeString("xmlns", "xsi", null, XmlIts1Formatter.NS_XSI);
xsw.WriteAttributeString("schemaLocation", XmlIts1Formatter.NS_XSI, @"urn:hl7-org:v3 Schemas/CDA-PITO-E2E.xsd");
xsw.WriteAttributeString("xmlns", "hl7", null, @"urn:hl7-org:v3");
xsw.WriteAttributeString("xmlns", "e2e", null, @"http://standards.pito.bc.ca/E2E-DTC/cda");
xsw.WriteAttributeString("xmlns", "xs", null, @"http://www.w3.org/2001/XMLSchema");

IFormatterGraphResult result = fmtr.Graph(xsw, clinicalDocument);
xsw.WriteEndElement(); // clinical document
xsw.Flush();
}
}

public static void ReadInCDADocument(FileInfo cdaFileInfo)
{
FileInfo tempCDA = new FileInfo(@"C:\temp.cda");
MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter fmtr = new MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter();
fmtr.ValidateConformance = true;
fmtr.Settings |= SettingsType.SuppressXsiNil;
fmtr.GraphAides.Add(new ClinicalDocumentDatatypeFormatter());

using (FileStream stream = File.Open(tempCDA.FullName, FileMode.Open))
{
XmlIts1FormatterParseResult result = fmtr.Parse(stream) as XmlIts1FormatterParseResult;
if (result != null)
{
ClinicalDocument readInDocument = result.Structure as ClinicalDocument;
}
}
}

The clinicalDocument being written out passes Everest validation. (Verified with debugger in the Save function looking at the graph result). We then immediately call Read on the same cdaFile and it parses the CDA document in but we get the following Validation errors:
Location: "/urn:hl7-org:v3#ClinicalDocument/urn:hl7-org:v3#code/urn:hl7-org:v3#originalText"
Message: Data type 'ED' failed basic validation, the violation was : The Data and Reference properties must be used exclusive of each other

Looking at the document in Debug for the Save Operation, the ClinicalDocument.Code.OriginalText.Data is set to byte[0] and Reference is set to NULL.
In the Read Operation, the ClinicalDocument.Code.OriginalText.Data is set to NULL and Reference is set to NULL.
justin.fyfe1
#2 Posted : Sunday, August 25, 2013 1:20:11 PM(UTC)

Rank: Administration

Medals: Mobile Tech Grasshopper: Mobile Tech GrasshopperHealth Informatics MVP

Groups: Registered, Administrators
Joined: 7/22/2010(UTC)
Posts: 96
Points: 297
Man
Location: Hamilton, ON

Thanks: 2 times
Was thanked: 17 time(s) in 17 post(s)
Hello,

Can you post the generated CDA instance so I can verify?

On graph any empty arrays won't be written, so byte[0] would result in <originalText/> which when read in would not populate the Data property as there was no data. This is consistent with graphing an empty string and parsing back a null or a SET<T> with 0 items being parsed as null. The exclusive error text might be a bug in the validation routine I will check this. I will also check the SemanticEquals method to ensure that byte[0] == null as this semantically means the same thing.

Cheers
-Justin
fieranmason@gmail.com
#3 Posted : Monday, September 16, 2013 11:09:10 AM(UTC)
Rank: Member

Groups: Registered
Joined: 7/8/2013(UTC)
Posts: 22
Points: 66
Location: University of Victoria

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
Hi Justin,

Apologies for our delayed response.

The relevant part of our output is shown below

<hl7:code code="11503-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" codeSystemVersion="2.44" displayName="Medical Records">
<hl7:originalText representation="TXT" mediaType="text/plain" />
</hl7:code>

In our code we never set a value for OriginalText. We expected that this would result in a value of NULL for that attribute but instead this resulted in a byte array of zero length.

Thanks for looking into it.

Fieran
justin.fyfe1
#4 Posted : Monday, September 16, 2013 11:17:43 AM(UTC)

Rank: Administration

Medals: Mobile Tech Grasshopper: Mobile Tech GrasshopperHealth Informatics MVP

Groups: Registered, Administrators
Joined: 7/22/2010(UTC)
Posts: 96
Points: 297
Man
Location: Hamilton, ON

Thanks: 2 times
Was thanked: 17 time(s) in 17 post(s)
Hi Fieran,

Ok, I think understand the issue now. A byte array of 0 length and null value are semantically equivalent, but I understand that it might cause some issue with parsing. I will take a look at the code that behaving like this and see what I can do. I will have to check with our team to see if there isn't any systemic consequences of changing this behavior (we have several systems using Everest and I don't want to break them).

I will let you know what we come up with.

Cheers
-Justin
justin.fyfe1
#5 Posted : Monday, September 16, 2013 2:49:35 PM(UTC)

Rank: Administration

Medals: Mobile Tech Grasshopper: Mobile Tech GrasshopperHealth Informatics MVP

Groups: Registered, Administrators
Joined: 7/22/2010(UTC)
Posts: 96
Points: 297
Man
Location: Hamilton, ON

Thanks: 2 times
Was thanked: 17 time(s) in 17 post(s)
Hello,

In attempting to validate this against 1.2.7 I don't see the behavior. Here is my unit test:

Code:

/// <summary>
/// Parse empty ED
/// </summary>
[TestMethod]
public void EDParseEmptyContentTest()
{
    string testString = "<hl7:code xmlns:hl7=\"urn:hl7-org:v3\" code=\"11503-0\" codeSystem=\"2.16.840.1.113883.6.1\" codeSystemName=\"LOINC\" codeSystemVersion=\"2.44\" displayName=\"Medical Records\"><hl7:originalText representation=\"TXT\" mediaType=\"text/plain\" /></hl7:code>";
    var cd = R1SerializationHelper.ParseString<CD<String>>(testString);
    Assert.IsNull(cd.OriginalText.Value, "Value is not null");
}


Can you verify that you're using 1.2.7?

Cheers
-Justin
fieranmason@gmail.com
#6 Posted : Tuesday, September 17, 2013 11:38:25 AM(UTC)
Rank: Member

Groups: Registered
Joined: 7/8/2013(UTC)
Posts: 22
Points: 66
Location: University of Victoria

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
Hi Justin,

Thanks for taking a look into this. We have updated to 1.2.7. We are still experiencing the same issue. We have posted a screen capture of the debugger showing the expanded code field from the read in document: http://tinyurl.com/orlsxkx

In your unit test you use the R1SerializationHelper. We were reading in with the ITS1:
MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter fmtr = new MARC.Everest.Formatters.XML.ITS1.XmlIts1Formatter();
fmtr.ValidateConformance = true;
fmtr.Settings |= SettingsType.SuppressXsiNil;
fmtr.GraphAides.Add(new ClinicalDocumentDatatypeFormatter());

Could that cause a difference in behavior?

Thanks
Fieran
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

SoClean Theme By Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.180 seconds.