I was looking at the GS1 Tag Data Standard and noticed the EPC has a CRC-16. However, the unique tag ID (TID), specified in Section 16, does not.
Is that the case there is no checksum on the Tag ID? If so, what is the suggested method to ensure the tag ID that is read is in fact the actual value and that no bits were flipped?
Got my answer from another message board. I'll post a summary here.
I was focused on the "StoredCRC" defined in the Memory spec mentioned above. However, I was pointed to the Air Interface spec. In there, it defines both the StoredCRC as well as the PacketCRC. The latter is used for many interrogator->tag and tag->interrogator messages.
Some notable references in that spec:
Section 6.3.1.5 gave a nice overview
Section 6.3.2.1.2.1 described how StoredCRC and PacketCRC are managed/used
Table 6.17 and Table 6.28 were good examples of the structure
Related
The current implementation of a CCDA generator I'm working on, prints a message on a <name> tag (in header sections, where no <text> is available) when something's name is not found:
<name>No information</name>
I know the right way to express not found information is through the #nullFlavor attribute:
<name nullFlavor="NI" />
But right now there is a component on the application that reads the value on the tag and shows it in a human-readable view of the CCDA document. If I use #nullflavor only, the field that shows such name will be empty, instead of "No information".
In order to avoid changing such component, I was thinking on adding the #nullFlavor attribute but still letting the message there:
<name nullFlavor="NI">No information</name>
I know this is syntactically correct, because I've tested it with the reference validator and it passes. My question is: from a semantic point of view, is it valid?
Yes it's valid. The particular specification in question - the v3 abstract data types, simple says:
invariant(ST x) where x.nonNull {
x.headCharacter.notEmpty;
};
So if there's no nullFlavor, there must be some content. But the reverse rule is not applied; there can be content if there's a nullFlavor
Although it is not restricted, my point of view is that it is not a good strategy. I understand that you have a restriction regarding this component but, when you are building a CDA, it is important to keep in mind that it is something to be shared with everyone, and I would never expect to find content inside a nullFlavor attributed element.
I am currently working on building CCD for my project.
I have a problem in code. For example let me take an example of payers section.
CONF-60:A covered party in a policy activity SHOULD contain exactly one participant / participantRole / code, to represent the reason for coverage (e.g. Self, Family dependent, student).
CONF-61:The value for “participant / participantRole / code” in a policy activity’s covered party MAY be selected from ValueSet 2.16.840.1.113883.1.11.19809 PolicyOrProgramCoverageRoleType DYNAMIC.
Above is the line i have copied from hl7 official document.
<code code="SELF" codeSystem="2.16.840.1.113883.5.111" displayName="Self"/>
Its copied from sample ccd document. Going to http://wiki.hl7.de/index.php/2.16.840.1.113883.5.111 we can see there are codes. But my system has values for which i cant find the codes there.
So my question is if cant get the codes there can i just use following and still produce a valid ccd document
<code displayName="Organ Donor"/>
In other words is it necessary to set code and code system in ccd document??
No, that particular line will not be valid and yes - It is necessary. These codes and coding systems are how other systems or programs will recognize the component. They are based in standard language meant to be recognized across EHR platforms and applications - such as LOINC (2.16.840.1.113883.6.1).
The whole purpose of the C-CDA, as the name "continuity of care" would suggest, is the seamless transition of patient information in a recognizable format to other organizations who may not utilize the same EHR.
Take a look at SMART CCDA Scorecard http://ccda-scorecard.smartplatforms.org/static/ccdaScorecard/#/
Also, what system are you using? Your system, especially for those values, should have the correct coding system because the values "SELF, MTH, FTH" are very common for documenting any demographic, insurance or patient related information. Otherwise, it might not meet the requirements of a certified EHR.
When the coding system doesn't contain an appropriate value you can use a NULL value and show the text, although usage of such is disallowed for certain elements. So your example should actually look something like this.
<code nullFlavor="OTH">
<originalText>Organ Donor</originalText>
</code>
But in general you should always try to use a valid concept code where one exists. That's the only way you'll achieve meaningful interoperability with third-party systems.
I have an iOS App disassembly which has the following block:
There are 'greyed out' comments in the picture of great interest which we want to capture from IDAPython. Such as which selectors are used on imported Framework objects such as UIWindow, CLHeading etc. IDA python however only has calls to get Repeatable comments, regular comments and function comments. Any idea which idc/idapython function gets this 'greyed out' comments? I assume they are repeatable comments from somewhere. Thanks.
UPDATES
The grey out comments are repeatable comments so I tried following the labeled address (selRef_setLastHeading on the third line) to the repeatable comment and arrived at this line:
However, when I did a RptCmt(here()) at that address, I was expecting #selector(setLastHeading:) to be returned as the comment but it returned an empty string..
The grey comments are repeating comments from the referenced item, thus for the first grey comment on the third line, if you went to the selRef_setLastHeading_ it should have a repeating comment.
If this was in a structured data block, I'd say read the address and then use that for the comment request function (sorry no IDApython experience just IDC script). but as they are an operand of an instruction, for this type of thing I'd tend to write a script that had a switch based on the instruction so you knew how to decode the reference address.
I'm found a stupid way to get the grey comments,something likes below.
widget = ida_kernwin.open_xrefs_window(pk_ea)
title = ida_kernwin.get_widget_title(widget)
ida_kernwin.close_widget(widget,0)
print(title)
I am using the Twitter Search API and I can't understand the id field of a tweet.
For example here is one: <id>tag:search.twitter.com,2005:1990561514</id>. The real ID is the final number part, right? Why doesn't Twitter already provide this in a single element? And, why is there a year of 2005on the ID field? Is that the ID of that year and the following year tweets get an ID recounted to zero? Is the ID indexed to the year?
I am asking all this stuff, because I am going to use the option of since_id to retrive new tweets. If the ID isn't really unique and depends on the year, it won't work as expected.
Thanks.
The tag is unique - but parts of it are redundant.
tag:search.twitter.com,2005:1990561514
Obviously, search.twitter.com is the URL from where you requested the document.
The ,2005 is constant. As far as I can tell, it has never changed since the service was launched. While there's no official documentation, I would guess that it refers to the ATOM specification namespace - http://www.w3.org/2005/Atom"
Finally, the long number is the Tweet's status ID. It will always be unique and can be used for the since_id.
What you will need to do is split the string, and just use the number after the colon as your ID.
I believe you are doing something wrong. If you look at all of the example results from the Twitter Search API, none of the id fields are formatted like this one you are showing.
For example:
http://search.twitter.com/search.json?q=%40twitterapi%20-via
Also, if you check out the example requests page, you will see that all of the id fields have normal formats, i.e.:
"id":122032448266698752
Update:
Now that I know you are using the atom feed, I can see where the seemingly oddly formatted element comes from. See this article on avoiding duplicates in atom feeds. Another helpful article.
Basically, atom feeds REQUIRE a unique id for each element in a feed. Some feeds use the "tag" scheme to ensure uniqueness. This format is actually pretty common in atom feeds and many frameworks use it by default. For instance, the RoR AtomFeedHelper (which might even be what Twitter uses) specifies the default format to be:
"tag:#{request.host},#{options}:#{request.fullpath.split(".")}"
I've read the documentation, but what I need to know is:
I'm not using a fictitious stock quote service (with an imaginary wsdl file). I'm using a different service with a different name.
Where, among the thousands and thousands of lines of code that have been generated, will I find the Scala trait(s) that I need to put together that correspond to this line in the documentation's example:
val service = (new stockquote.StockQuoteSoap12Bindings with scalaxb.SoapClients with scalaxb.DispatchHttpClients {}).service
Now, you might be thinking "Why not just search for Soap12Bindings in the generated code"? Good idea - but that turns up 0 results.
The example in the documentation is outdated, or too specific. (The documentation is also internally inconsistent and inconsistent with the actual filenames output with scalaxb.)
First, search for SoapBindings instead of Soap12Bindings to find the service-specific trait (the first trait).
Then, instead of scalaxb.SoapClients, use scalaxb.Soap11Clients.