I am new to the Health Level 7 standards and messaging paradigm and was reading up on OIDS/URIs. While I know OID are unique Identifiers assigned under an Assigning Authority, I would like to know the following:
If there any difference in their usage for V2 and V3 messages.
Whatis actually sent over the wire in terms of an OID?
Why is there a
switch from OIDs to URIs in the context of the new HL7 FHIR standard?
Any help is appreciated.
Thanks
FHIR tries to move away from OIDs because of human readability:
Implementers strongly prefer a human readable URI. http://acme.com/patients/mrn is a great deal easier to work with than urn:oid:1.2.3.4.5.6.7
This text from the specification also answers your second question about the representation. You use the construct urn:oid: in those places, so the OID is represented as a URI.
Please take a look at https://www.hl7.org/fhir/terminologies.html for more information, and https://www.hl7.org/fhir/terminologies-systems.html and https://www.hl7.org/fhir/identifier-registry.html for a list of systems and their representation.
Related
TL;DR: I need a source for as many different output formats from a whois query as possible.
Background:
I am looking for a single reference that can provide as many (if not all) unique whois query output formats as possible.
I don't believe this exists but hope to be proven wrong.
This appears to be an age old problem
This stackoverflow post from 2015 references the challenge of handling the "~40 formats" that the author was aware of.
The author never detailed any of these formats.
The RFC for whois is... depressing
The IETF ran an analysis in 2015 that examined the components of whois per each RIR at the time
In my own research I see that registrars like JPNIC do not appear to comply with the APNIC standards
I am aware of existing tools that do a bang-up job parsing whois (python-whois for example) however I'd like to hedge my bets against outliers with odd formats. I'm also open to possible approaches to gather this information, however that would likely be too broad to fit this question.
Hoping there is a simple "go here and download this" answer. Hoping...
"TL;DR: I need a source for as many different output formats from a whois query as possible."
There isn't, except if you use any kind of provider that does this for you, with whatever caveats.
Or more precisely there isn't something public, maintained and exhaustive. You can find various libraries that try to do this, in various languages, but none is complete, as this is basically an impossible task, especially if you want to include any TLDs, like ccTLDs (you are not framing your constraints space in a very detailed way, nor in fact really saying you are asking about domain name data in whois or IP addresses/ASN data?).
Some providers of course try to do that and offering you an abstract uniform API. But why would anyone share their internal secret sauce, that is list of parsers and so on? It makes no business incentive to do that.
As for opensource library authors (I was one at some point), it is just tedious and absolutely not rewarding at all to just update it forever with all new formats and tweaks per registry (battle scar example: one registrar in the past changed its output format at each query! one query gave you somefield: somevalue while next time it was somefield:somevalue or somefield somevalue, etc. of course that is only a simple example).
RFC 3912 specified just the transport part, not the content, hence a lot of cases appeared. Specifically in the ccTLD world, each registry is king in its kingdom and it is free to implement whatever it wants the way it wants. Also the protocol had some serious limitations (ex: internationalization, what is the "charset" used for the underlying data) that were circumvented in different ways (like passing "options" in your query... of course none of them are standardized in any way)
At the very least, gTLDs whois format is specified there:
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois
Note however that due to GDPR there were changes (see https://www.icann.org/resources/pages/gtld-registration-data-specs-en/#temp-spec) and will be other changes in the future.
However, you should be highly pressed to look at RDAP instead of whois.
RDAP is now a requirement in all gTLDs registries and registries. As it is JSON, it solves immediately the problem of format.
Its core specifications are:
RFC 7480 HTTP Usage in the Registration Data Access Protocol (RDAP)
RFC 7481 Security Services for the Registration Data Access Protocol (RDAP)
RFC 7482 Registration Data Access Protocol (RDAP) Query Format
RFC 7483 JSON Responses for the Registration Data Access Protocol (RDAP)
RFC 7484 Finding the Authoritative Registration Data (RDAP) Service
You can find various libraries doing RDAP for you (see below for links), but at its core it is JSON over HTTPS so you can emulate simple cases with any kind of HTTP client library.
Work is underway to fix some missing/not precise enough details on RFC 7482 and 7483.
You need also to take into account ICANN specifications (again, only for gTLDs of course):
https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf
Note that, right now, even if it is an ICANN requirement, you will find a lot of missing or broken gTLD registries or registrar RDAP server. You will also find a lot of "deviations" in replies from what would be expected per the specification.
I gave full details in various other questions here, so maybe have a look:
https://stackoverflow.com/a/61877920/6368697
https://stackoverflow.com/a/48066735/6368697
https://webmasters.stackexchange.com/a/115605/75842
https://security.stackexchange.com/a/213854/137710
https://serverfault.com/a/999095/396475
PS: philosophical question on "Hoping there is a simple "go here and download this" answer. Hoping..." because a lot of people hoped for that in the past, and see initial remark at beginning. Let us imagine you go forward and build this magnificent resource with all exhaustive details. Would you be inclined to just share it with anyone, for free? The answer is probably no, for obvious reasons, so the same happened in the past for others that went on the same path as you, and hence the results of now various providers offering you more or less this service (you would need to find details on which formats are parsed, the rate limites, the prices, etc.), but nothing freely available to share.
Now you can just dream/hope that every registries and registrars switch to RDAP AND implement it properly. Then the problem of format is solved once for all. However, the above requirements ("every" + "properly") are not small, and may not happen "soon". Specifically in ccTLDs, where registries are in no way mandated by any external force (except market pressure?) to implement RDAP at all.
I am trying to add support for sidecar applications in EHR platforms. I am taking a pure implementer's approach to build an intermediate representation (such as an XML) for mapping CDA<--->FHIR. I am using the smart-on-fhir as the reference implementation for this. The CDA I am trying to use is the Australian extension - ereferral (www.digitalhealth.gov.au/implementation-resources/clinical-documents/EP-0936-2012/NEHTA-0967-2012).
Is it possible to create such an intermediate representation using the smart-on-fhir (or any other FHIR) reference implementation? Has anyone else tried this?
While searching for actual implementations I came across these repos:
github.com/jmandel/sample_ccdas
github.com/amida-tech/fhir2ccda
github.com/amida-tech/cda-fhir
The FHIR group has some hand crafted examples. Are there any equivalent CDA examples for these FHIR resources?
I have read couple of web articles and white paper documents regarding the challenges between the transforms, such as:
David Hay's blog says "FHIR document is that it is like an object graph, rooted in the composition resource", so is their an equivalent representation for CDA?
Rene Spronk's article about whether HL7 v3 is a message or a document. What are the implications for an implementer who has to handle and validate representations across both CDA and FHIR
Lantana Group position paper - "If or when FHIR can accommodate the full CDA use case, the future holds the promise of seamless integration and information sharing between clinical documents and APIs". Does this mean that CDA<--->FHIR transform is not possible at this stage of the FHIR standard?
Apologies for cross posting it in both SO and FHIR community forums: http://community.fhir.org/t/cda-fhir-mapping-implementations/211/1
CDA to FHIR is fairly straightforward and it looks like you've already found some repositories that do that.
FHIR to CDA is also fairly straightforward - assuming all you care about is something that is valid. You may need to adjust those libraries for use in the AU/NZ locales.
That said - Keith Boone has some blog posts about some of the challenges in mapping between the two, as there will always be quirks.
The biggest hurdle you will have is loss of fidelity. A CDA (at least a C-CDA here in the states) comes with so much HL7v3 cruft that by turning it into FHIR, you're instantly not going to be able to re-create the original C-CDA from FHIR. The CCD template has evolved so much that you find documents that contain C32 elements, C-CDA 1.1 templateIds, and maybe someday C-CDA 2.1 templateIds. So while you can reasonably make a valid C-CDA out a FHIR bundle, you will have to pick a specific implementation and version to target.
My startup https://www.redoxengine.com has a JSON version of CDA that yo can see on the docs page. It's designed for simplicity, but can be mapped back and forth to FHIR resources.
Are the HL7-FHIR, HL7 CDA, CIMI, openEHR and ISO13606 approaches aiming to solve the same health data exchange problems?
FHIR, CDA, 13606, CIMI, and openEHR all offer partial and overlapping approaches to 'solving health data exchange problems'. They each have strengths and weaknesses, and can work together as well as overlapping each other.
FHIR is an API exchange spec that's easy to adopt
CDA is a document format that's widely supported
CIMI is a community defining formal semantic models for content
openEHR does agreed semantic models and an application infrastructure
13606 is for EHR extract exchange
CIMI is clearly an initiative to think about the content of archetypes and recurring patterns
FHIR is a specification for API's including a limited set of content models
openEHR is a community and an open-source specification with standardised Reference Model, and Archetype Object Model, Data types and Termlist
CEN/ISO 13606 is a community using its formal, public(?), and CEN and ISO standardised Reference Model, and Archetype Object Model, Data types and Termlist
Scopes of all overlap. The most overlap is between openEHR and 13606. And to a lesser extend with CIMI.
Two level Modeling Paradigm. CIMI, openEHR and 13606 have a lot of interactions and adhere to the Two level Modeling Paradigm.
Archetypes can be used by FHIR. CIMI is creating archetypes as are the openEHR and 13606 communities.
I see a future for 13606 in context of cloud EHR, were the exact location of data is not always known, but what matters is how to get access to them.
13606 can provide a standard for interfacing to the cloud, and provide features as queries and requests for detailed information, instead of precooked general purpose message-formats, like patient summaries, etc.
Erik, you write: "I do not understand why you call the openEHR specification proprietary (it is CC-BY-ND licenced and freely available online) and you call the ISO 13606 more open (it is copyrighted and behind a paywall)"
The point is is that in case of an ISO standard third parties should not claim IP. You must pay for the information, and you may not distribute the copyrighted text, but you may use the information without risk of being confronted with excessive claims afterwards.
There is a policy on ISO deliverables regarding to patents, which gives insurance for not having to deal with excessive patent-claims afterwards. See for more information:
http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
Resume: There can be IP claims on ISO deliverables, except from the copyrighted text, but those claims must be handled in a non-discriminatory and reasonable way. So, no excessive claims are possible.
In a patent-related legal case, the judge will find it important that the deliverable was published at ISO.
Two equitable defenses to patent infringement that may arise from a patent owner's delay in taking action are laches and equitable estoppel. Delays give rise to a presumption that a delay is unreasonable, inexcusable, and prejudicial. This is certainly true when it concerns an ISO deliverable.
This policy does not exist in the case CC-BY-ND licenced work. This work gives no guarantee at all. The user of CC-BY-ND licenced work is not safe for claims.
Therefore it is important that AOM2.0 will be submitted to ISO. It can only be submitted to ISO in context of the 13606 Renewal. That is why the OpenEHR community, for its own sake, must work on a Reference Model agnostic standard in all parts, to help and convince the ISO13606 renewal committee to implement it.
AOM1.4 has been an ISO standard for years, so we can be pretty sure that there is no hidden IP on that.
I would say the only standard which aim is NOT to solve data exchange problems is openEHR.
openEHR defines a complete EHR platform architecture to manage clinical data structure definitions (archetypes, templates), including constraints and terminology/translations, manage clinical information (canonical information model), access clinical information (standard query language AQL), define rules for clinical decision support (standard rule language GDL), and defines a service model (REST API is close to be approved).
So looking at openEHR, it tries to solve the all the interoperability problems that come before any data exchange but are needed to make data exchanged interpreted and used correctly, in short openEHR allows interoperability but doesn't define how data is technically exchanged.
Not sure whether it is here to ask these basic questions about REST...
The more I try to understand REST and want to implement it, the more I get confused. I think probably because of those abstract words I see when people come to teach you what a REST is. For instance,
REST from wikipedia,
Representational state transfer (REST) is an abstraction of the
architecture of the World Wide Web; more precisely, REST is an
architectural style consisting of a coordinated set of architectural
constraints applied to components, connectors, and data elements,
within a distributed hypermedia system.
And from this link
Representations of resources should be uniform
Use hypermedia—not URL schemes or resource name mapping—to represent
relationships
Use a single entry to an API, hyperlink from there (hyperlink? why not hypermedia??)
Include a “self” link in your representations
REST doesn’t just mean spitting out ActiveRecord models as JSON (so what should you spit out??)
So, what does it mean by these abstract jargons below?
Representations,
resources,
URL schemes,
hypermedia (what the difference of it from hypertext or hyperlink???),
resource name mapping—to,
ActiveRecord models
Can you explain them in a concrete examples?
Representation is the name given for the complete set of bytes that are sent over the wire when you make a request to a resource using a link.
Resource is a any concept that is important to your application and you wish to expose it to a client application. A resource is identified by a URL.
Technically an URL Scheme is the first few bytes of a URL that appear before the colon. e.g. http, urn, ftp, file, etc.
However, I suspect in the context you are seeing it, it means a convention for organizing the paths segments and query string parameters of and URL and assigning a significance to those pieces of the URL.
From the perspective of REST, a server can create URL conventions, but clients should know nothing about those conventions.
Hypermedia is a classification of media types that support hyperlinks. Hypertext is an older term that is almost synonymous with hypermedia. In theory hypermedia does not need to be a text based format. So far I'm not aware of any hypermedia formats that are not hypertext.
Hyperlink, link and web link are synonymous.
Unfortunately these terms are abstract by definition. There are many different ways to implement these concepts.
ActiveRecord is an implementation concept that is often used to contain the data that will be used to build a representation of a resource. However, if you limit yourself to only being able to create resources from ActiveRecord instances, you will likely struggle to implement an effective REST API.
Representations of resources should be uniform - This makes no sense to me. There is a REST constraint called "Uniform Interface". However, this constraint refers to using a consistent interface to enable building layered applications. i.e. When a client wants to talk to server, you can slip a proxy, load balancer, cache in between and the client and server don't know the difference because the interface is consistent.
Use hypermedia - Hypermedia helps you to decouple your client and server to allow either to evolve independently. If this is not important to you (i.e. you can always deploy your client javascript at the same time as the website) then you are not going to get a whole lot of value out of it.
Use a single entry to an API - See previous point. If you need independent evolvability then explore some more.
Include a “self link in your representations And again...
REST doesn’t just mean spitting out ActiveRecord models as JSON REST is an architectural style of the boundary of your application. Exposing ActiveRecords as Resources ties your client to implementation details of your server. Also, HTTP is limited to just a few methods (GET, PUT, POST, DELETE, OPTIONS, HEAD). In order to compensate for this limited vocabulary you will need to create Resources that are nothing to do with records in a database.
Many are quick to point out that "REST," as typically used, isn't really REST, as originally defined.
There's endless (and pointless) discussion and debate around this topic, but from a practical standpoint I prefer to think about "resources," and how best to expose them.
The concept of REST may be instructional in this regard, even if common implementations diverge from the source.
In the end, we're programmers and have to build things that meet today's objectives, knowing they won't be tomorrow's.
I have had a request by a client to pull in the Lab Name and CLIA information from several different vendors HL7 feeds. Problem is I am unsure what node I should really pull this information from.
I notice one vendor is using ZPS and it appears they have Lab Name and CLIA there. Although I see that others do not use the ZPS. Just curious what would be the appropriate node to pull these from?
I see the headers nodes look really abbreviated with some of my vendors. I need a perfectly readable name like, 'Johnson Hospital'. Any suggestions on the field you all would use to pull the CLIA and Lab Name?
Welcome to the wild world of HL7. This exact scenario is why interface engines are so prevalent and useful for message exchange in the healthcare industry.
Up until, I believe HL7 v2.5.1, there was no standardization around CLIA identifiers. Assuming you are receiving ORU^R01 message, you may want to look at the segment OBX and field 15, which may have producer or lab identifier. The only thing is that there is a very slim chance that they are using HL7 2.5.1 or are implementing the guidelines as intended. There are a lot of reasons for all of this, but the concept here is that you should be prepared to have to do some work here for each and every integration.
For the data, be prepared to exchange or ask for a technical specification from your trading partner. If that is not a possibility or if they do not have one, you should either ask for a sample export of representative messages from their system or if they maybe have a vendor reference. Since the data that you are looking for is not quite as established as something like an address there is a high likelihood that you will have to get this data from different segments and fields from each trading partner. The ZPS segment that you have in your example, is a good reference. Any segment that starts with Z is a custom segment and was created because the vendor or trading partner could not find a good, existing place to store that data, so they made a new segment to store that data themselves.
For the identifiers, what I would recommend is to create a translation or a mapping table for identifiers. So, if you receive JHOSP or JH123 you can translate/map that to 'Johnson Hospital'. Each EMR or hospital system will have their own way to represent different values and there is no guarantee that they will be consistent, so you must be prepared to handle that scenario.