In hl7 messages the HD DataType consists of NameSpaceID, UniversalID and UniversalID Type. What do these different entities specify and how are they used? I mainly want to know what is NamespaceID in scope of an organization and when is it used?
HD is most commonly used as part of other data types like CX(Patient IDs, for example) or XCN(Provider name + ID). Usually it gets labeled as "Assigning Authority" or "Assigning Facility".
The best example I can think of is a Provider's NPI number. NPI is issued by CMS/NPPES, so that is what the HD data type is trying to encode. The Namespace ID, might just be NPI, or whatever two parties agree upon to use to identify that the number is an NPI number. NPI has an OID as well. So any of the following would be valid HD uses:
Just namespace ID:
NPI
All three:
NPI&2.16.840.1.113883.4.6&ISO
Just the Universal parts:
&2.16.840.1.113883.4.6&ISO
Or some other local code instead of the ISO code:
&NPI&HEALTHSYSTEM123
Part of the reason that there is a Namespace ID at all is for backwards compatibility reasons. It's probably best to send all three if you can, but expect most systems to only look at and process the namespace ID.
From Chapter 2.A.33 of the HL7v2.7 spec:
The HD is designed to be a more powerful and more general replacement for the application identifier of HL7 versions 2.1 and 2.2. It adds two additional components, the and the to the former application ID (which is renamed more generically to be the namespace ID).
Related
During development, an internal name is given to a particular feature. That name is then used in function and variable names. Later, when the UI and Documentation are finalized, a different public-facing name is assigned to that feature. Should variable names be renamed too to correspond to the new public name?
On one side, the public-facing name may change frequently and so it is unpractical to rename internal references all the time. On the other hand, it can create confusion in meetings and among new team members if a single feature has different names (should there be a spreadsheet that maps the public and private names?).
Is there an industry standard for this?
The concept of an "ubiquitous language" discusses how external and internal names should be consistent.
To quote this great article:
Ubiquitous Language is the term that Eric Evans uses in “Domain-Driven
Design – Tackling Complexity in the Heart of Software” in order to
build a language shared by the team, developers, domain experts, and
other participants.
Using consistent names makes it easier for all parties to understand concepts in the product and code.
I've created a domain name such as: même.vip
I can see in the database, that the domain name has been registered with IDN table: "fr".
However, 'ê' can be Portuguese, Norwegian, etc...
I am trying to understand who is assuming the IDN table here...
I can see the EPP transaction - it is not using the IDN extension and therefore cannot supply an IDN table to the server, even if it wanted to
I cannot access the code that populated that DB record
Therefore, my best chance is to know if the Punycode domain name contains information on which table was used. If not: then I know it's the DB or some service at the registry, after the EPP command.
(Of course, if the punycode DOES contain the IDN table, then I have more digging to do!)
Does a Punycode domain name (UName) store the IDN table used?
TL;DR: No.
You are mixing multiple things, but it is difficult to summarize everything (I did a very detailed answer at https://webmasters.stackexchange.com/a/122160/75842 which should help you).
For the computers, ê being either Portuguese or Norwegian does not make a difference at the DNS level. In the same way that at the Unicode level, ê is
"U+00EA LATIN SMALL LETTER E WITH CIRCUMFLEX" that is just defined as a "Latin" character, irrespective to which language might use it.
In short:
the IETF invented the Punycode algorithm, and more precisely the IDNA standard just to make sure that people could use (almost) any character in their domain name. As such the algorithm is just a translation from "any Unicode string" to "an ASCII string starting with xn--"
The domain name industry, with ICANN and all registries, then decide on rules on top of that. For example there is a major rule "you can not mix characters from multiple scripts in the same string", to avoid IDN homograph attacks mostly (so not really a technical constraint); my answer above gets in full details on this.
At the EPP level, various actors created various extensions, there is no real standardized "IDN" specification here. Which is also why you will find people speaking about "scripts", other about "languages", other about "repertoire", etc. It is a mess (Unicode only speaks about scripts, not languages). Some registries do not use any extension, while others do. Some want you to always pass an IDN "table" (aka script/language/whatever) reference, some will require it only in some cases. For example look at Verisign IDN practices at https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml; It boils down to "all IDN registrations need a language tag; some of them are attached to specific list of possible characters"
You can find in theory all but in practice only most of IDN tables existing at https://www.iana.org/domains/idn-tables and you can see they are per registry, showing that this extra information is really not encoded in the ASCII form of the domain name, after conversion by Punycode algorithm.
I am trying to understand who is assuming the IDN table here...
There should be no assumption (either it is given by registrar or not given) or there is no IDN table needed (the registry will just do the Punycode conversion in reverse and decide, based on characters found, which table it should be in).
I can see the EPP transaction - it is not using the IDN extension and therefore cannot supply an IDN table to the server, even if it wanted to
Which registry? If you are a registrar, in practice the registry should be able to help you and answer this kind of questions. Note that most of the time (I could write "all the time", but I am not sure no counter example exists or at least I have none in mind right now), during EPP domain:check you just pass the name (in ASCII form) without any IDN extension, while you pass the IDN extension, if any, during the domain:create. Which also means that the domain:check might not get you the proper full reply, just because at that point not everything is known.
See these EPP documents on IDN extensions:
https://datatracker.ietf.org/doc/html/draft-ietf-eppext-idnmap-02
https://datatracker.ietf.org/doc/html/draft-wilcox-cira-idn-eppext
https://tools.ietf.org/id/draft-gould-idn-table-07.html
https://datatracker.ietf.org/doc/html/draft-sienkiewicz-epp-idn-00
I'm trying to create a database for my project to lookup mac vendors. I added a UNIQUE key on the prefix column. When inserting rows from an officially published MA-L csv file, I got the duplicate entry error from DB. Then I looked it up in the csv file and found 3 entries for prefix '080030'.
Is the file wrong or I'm misunderstanding how to use the OUI list? If I want to look up the vendor of a mac with prefix '08:00:30', which one of the three is correct?
There are currently two duplicate assignments in the MA data files.
Registry,Assignment,Organization Name,Organization Address
MA-L,080030,NETWORK RESEARCH CORPORATION,2380 N. ROSE AVENUE OXNARD CA US 93010
MA-L,080030,ROYAL MELBOURNE INST OF TECH,GPO BOX 2476V MELBOURNE VIC AU 3001
MA-L,080030,CERN,CH-1211 GENEVE SUISSE/SWITZ CH 023
Registry,Assignment,Organization Name,Organization Address
MA-L,0001C8,THOMAS CONRAD CORP.,1908-R KRAMER LANE AUSTIN TX US 78758
MA-L,0001C8,CONRAD CORP.,
The IEEE provides the following footnote on page 7 of the linked document.
The IEEE Registration Authority makes a concerted effort to avoid
duplicate assignments but does not guarantee that duplicate assignments
have not occurred. Global uniqueness also depends on proper use of
assignments and absence of faults that might result in duplication.
https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf
The Wireshark OUI lookup tool, based on their own compiled list, gives one answer for which of these organizations is currently assigned.
Network Research Corporation
https://www.wireshark.org/tools/oui-lookup
And the maclookup website, which seems reasonable, gives a different answer.
CERN
https://maclookup.app/macaddress/080030
There are no timestamps in the data file. There is no explicit row sorting and ordering (and it doesn't look sorted or ordered). Bottom line, there seems to be no way to use the data file and supporting documents alone to determine which assignment is correct.
This is strange, never seen such a thing, are you sure you are pulling the correct file from IEEE.
I've reviewed the 3 companies you mentioned in the file, it has different Prefixes.
CERN Mac prefix is 80D336
Network Research Corporation has two prefixes, one of which the one mentioned in the question.
Couldn't find this company in any DB.
I think your parser is somehow corrupted especially if you are parsing the text file.
I am trying to map an existing domain into HL7 FHIR.
So far it was pretty easy to find FHIR resources that more or less represent the same data and can be used for that purpose. But now I am running into a problem of which I am not sure how to solve it.
The existing domain allows that data can be anonymized depending on the users access level. e.g. a patient's name or address might be removed and marked as anonymized. Other data will be pseudonymised, for example a the birthdate in 1980 will be replaced with 01.01.1980. An Age of 37 will be replaced with a category of 30-40.
So I am unsure how to integrate that into the FHIR domain. I was thinking I could create an extension holding a boolean, indicating if a value was anonymized or not and always replace or remove the original value. This might work, but I will run into big problems when the anonymized value is of a different type than the original value (e.g. Age is replaced by a range of values)
Is that even a valid approach? I thought this might be common problem, but I could not find any examples where people described methods of how to mark data as altered. Unfortunately the documentation at http://build.fhir.org/extensibility-registry.html does not contain anything that would help my case.
You can use security labels for this purpose (Resource.meta.security). Take a look at REDACTED and SUBSETTED in the security label value set: https://www.hl7.org/fhir/valueset-security-labels.html
If you need to convey a data type other than the one allowed by the resource (e.g. wanting to convey a range rather than a birthdate), you'd need to use an extension. (Note that dates are valid even if you only include the year.)
In the protobuf documentation (https://developers.google.com/protocol-buffers/docs/proto#customoptions) it says this about custom options:
One last thing: Since custom options are extensions, they must be
assigned field numbers like any other field or extension. In the
examples above, we have used field numbers in the range 50000-99999.
This range is reserved for internal use within individual
organizations, so you can use numbers in this range freely for
in-house applications. If you intend to use custom options in public
applications, however, then it is important that you make sure that
your field numbers are globally unique. To obtain globally unique
field numbers, please send a request to
protobuf-global-extension-registry#google.com. Simply provide your
project name (e.g. Object-C plugin) and your project website (if
available). Usually you only need one extension number.
Why do the options field numbers have to be globally unique for public applications? In what way can collisions be a problem?
Basically, because you wouldn't know whether the data you get is correct.
The protobuf binary wire format only stores the field numbers and the payload (which is itself, for complex types, just field numbers and sub-payloads). There is no name data. So: when you store and retrieve an extension field, all you're saying is "fetch field {field number}, interpret it as {type}". If two different systems have extended the same data using the same field number, then you don't have any way of knowing whether the data you're fetching was actually in that format.
Normally this isn't a problem - as it is rare to conflict like this on the same data; but custom options are different! I'm a library author; I might want to add a custom option that my schema parsing tools recognize, by extending (say) MessageOptions. MessageOptions is the extension point for DescriptorProto, which is to say: that's what option (foo) = "bar"; goes to inside a message.
To do that, I need to assign a number for foo. I choose 5000 arbitrarily (MessageOptions defines extensions 1000 to max;, so that's fine). All is good. My tooling works.
Unknown to me, another library author has chosen to do something similar and has also used 5000. Once the schema is compiled (by protoc or similar), all I have is numbers. If I ask for the data from field 5000, I don't know whether I'm getting my extension, or the other one. The meaning is lost. OK, at a push I could also check the dependency list on the FileDescriptorProto, but ... that's hit and miss.
I don't know whether the presense of value 1 in field 5000 is:
option (.mystuff.someext) = 1;
vs
option (.anotherlib.whatever) = -1; // stored as sint32
vs
option (.yetanother.library.option) = true;
If those extensions all have number 5000, they appear identically on the wire.