Hello fellow HL7 developers,
a question regarding the XML representation of person/patient names came up while I browsed the most recent normative release of the HL7 standard (release 2014). This version of the standard uses ITS R2 (new schemas, changed datatypes).
According to the standard (CD1/Edition2014/infrastructure/itsxml/datatypes_its_xml.html, section 2.20.2), a person name should be represented by XML elements "<given>", "<family>" etc. However, no such elements are defined anywhere in the XSD files that accompany the standard. How is a person name correctly rendered in XML in this version of the standard?
Regards,
Michael
datatypes_its_xml.html is the filename of the R1 version of the specification. Although you are looking at an R2 based version, R1 is included for information sake, and you've found it. Use ISO data types 21090 which is the correct version for the schema.
As for names, in this version if my memory is correct.
Related
I am using Lua 5.2. I am receiving large tables (1-dimensional array) of size 800,000. I want to dump these tables quickly. I found an article on wiki titled Save Table To File and used it but found not up to the mark. A sample table saved using this method, i.e., table.save(table, filename) is shared in my DropBox here. (File is too large to put here. 8MB approx)
Since my primary concern is speed, I am ready to adopt binary serialization if such exists.
Are you bound to Lua 5.2? 5.3 introduced bitwise operators and built-in binary pack/unpack operations (see chapter 13, “Bits and Bytes”, of Programming in Lua, 4th edition). There are also specific algorithms and recommendations for serializing tables in chapter 15, “Data Files and Serialization”. These chapters will be your best source of information for a proper implementation.
I have some misunderstanding issues with HL7 specially in PID segment.
if we have a patient has two different names, how can we build the PID-5 using the two names?
Example
the previous name
Han John Burke
the current name
Han Robert Mat
Any idea guys
PID-5 is a repeating field:
|name-1^components~name-2^components|
if a system doesn't support repeating components, it doesn't support multiple names
You may use the repeating character to separate the two names within PID.5, but ultimately it depends on what the system you're integrating with accepts. I found a standard HL7 spec from one EMR vendor that states if the HL7 version is greater than 2.2, PID.5.7 will populate with L, and if there are multiple other names PID.5.7 will populate with an M. The M may be a required flag to show that there is an additional name. For HL7 versions less than 2.2 PID.5.7 may not be used. You may need to have additional carats put in place until the 7th sub-component for it to work as well.
I tested this in our test system and the result is below. You can see the M was used multiple times because there were multiple other versions of this person's name. Hope this helps! Thanks!
|TEST^FAITH^^^^^M~test^hello^^^^^M~maiden^faith^^^^^M|
Background:
I was given a pile of yokagawa "mxd" files without documentation or
description, and told "convert it".
I have looked for documentation and found none. The OEM doesn't seem to "do" reproducibility in the sense of a "code book". (link)
I have looked for online code for converters and found none.
National Instruments has a connector, but only if I use latest/greatest
LabVIEW (link). I don't have that version.
The only compatible suffix is from ArcGIS, but why would DAQ use a format like that.
Questions:
Is there a straightforward way to convert "mxd" to "csv"?
How do I find the relationship using the binary data? Eyeballing HEX seems slow/inefficient.
Is there any relationship between DAQ mxd and ArcGIS mxd?
Yokogawa supplies a progam called MX100 Standard Software: https://y-link.yokogawa.com/YL008/?Download_id=DL00002238&Language_id=EN, this program can read the *.mxd files and also export them to ascii or excel. See the well hidden manual: http://web-material3.yokogawa.com/IMMX180-01E_040.pdf, page 105 has chapter 3.7: converting data formats.
I have been working with EDI documents for the past few months and dealt with different EDI formats like 810 (Invoice), 850 (PO), 855 (PO Ack) etc.
I just wonder where does this Segment names comes from? What is the exact definition for each segment? Like ISA, GS, GE, IEA etc.
Also beginning of a segment possess different values for each document formats. Like BIG for 810, BEG for 850 etc. Where does these abbreviations comes from?
They come from the implementation guides. This is an example of one of them: http://www.att.com/Common/docs/EDI_820_Guide.pdf
Traditional EDI (segments/elements) documents are defined by a governing standards body, usually ANSI (X12) or EDIFACT (U.N. standard). (TRADACOMS and HL7 are also standards bodies) These entities created and published the document types, enveloping, segment names and definitions, element data types and size, component elements, etc. http://www.x12.org/ is the main site for the X12 standard (predominantly found in the US). EDIFACT can be found here: http://www.unece.org/cefact/edifact/welcome.html. These groups are repsonsible for pushing the standard further as business requirements evolve and new data attributes are created. Version 4010 in the ANSI X12 was the first Y2K compliant X12 standard released. There have been many versions released since then, but many still use version 4010 as their standard.
The decision makers made some segments somewhat "mnemonic", so that you can easily determine what kind of information is in the segment. BEG is a good example of this, as common sense would dictate it is "Beginning" of the transaction. Of course, this doesn't apply consistently in the standard. N1 for Names and Addresses, TD3 and TD5 for routing and lading qty.
The end users would then devise their own guideline as to how they implemented the standard. In some cases you'll find some bastardization of the standard to fit special case needs.
Most translators come with some kind of built-in Dictionary Viewer where you can browse. X12 is mostly closed-source and the commercial translator makers pay X12 to include the library. EDIFACT (which is not your example above) is published free of charge. There is a free tool from Liaison called EDI Notepad that you can download and get a sense of the syntax and validation. That can be found here: https://www.liaison.com/products/integrate/edi-notepad/edi-dictionary-viewer/
What products support 3-digit region subtags, e.g., es-419 for Latin-American Spanish?
Are web browsers, translation tools and translators familiar with these numeric codes in addition to the more common "es" or "es-ES"?
I've already visited the following pages:
W3C Choosing a Language Tag
W3C Language tags in HTML and XML
RFC 5646 Tags for Identifying Languages
Microsoft National Language Support (NLS) API Reference
I doubt that many products like that exist. It seems that some main stream programming languages (I have tested C# and Java) does not support these tags, therefore it would be quite hard to develop programs that does so.
BTW. NLS API Reference that you have provided, does not contain region tag for any of the LCID definition. And if you think of it for the moment, knowing how Locale Identifier is built, there is no way to support it now, actually. Implementation change would be required (they should use some reserved bits, I suppose).
I don't think we will see support for region tags in foreseeable future.
Edit
I saw that Microsoft assigned LCID of value -1 and -2 to "European Union 1" and "European Union 2" respectively. However I don't think it is related.