Stream: smart/health-cards
Topic: Bundle Format
Grahame Grieve (Apr 20 2021 at 22:14):
From http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/conformance.html#data-minimization
Implementers SHALL use resource:0 syntax for IDs and references
Where is the URI scheme resource: defined?
Abbie Watson (Apr 20 2021 at 22:23):
Great question. +1 for this. I just rolled with it, but first I'd ever seen or heard of it.
Josh Mandel (Apr 20 2021 at 23:50):
There's an old provisional scheme (prov/resource) sitting in the IANA registry next to (prov/oid, which incidentally appears to be the OID scheme FHIR uses). It was used by firefox back in the day, but I don't think this usage is meaningfully related.
Josh Mandel (Apr 20 2021 at 23:51):
We could register a new scheme for this purpose; the functional requirements are basically: short, and works for bundle-relative links, e.g., with single-character suffixes
Max Masnick (Apr 20 2021 at 23:51):
And if there's some documentation around this that would be helpful to include in the IG, please let us know what you'd like to see.
Josh Mandel (Apr 20 2021 at 23:54):
I'd like us to be practical about the benefits of changing this, though -- like, if we register a new fhir-bundled: scheme with IANA and switch to that... would this be an improvement?
Grahame Grieve (Apr 21 2021 at 01:36):
I'm not sure. I don't mind resource:. but the IG should be explicit about the provenance of the URL scheme
Grahame Grieve (Apr 21 2021 at 01:37):
but the usage is not consistent with https://www.iana.org/assignments/uri-schemes/prov/resource. So that suggests making up our own
Josh Mandel (Apr 21 2021 at 01:37):
That's why I say I don't think our usage is meaningfully related.
Grahame Grieve (Apr 21 2021 at 01:37):
or use cid: from https://tools.ietf.org/html/rfc2392, which would be consistent with how it was used in SOAP from my pov
Josh Mandel (Apr 21 2021 at 01:38):
I looked at this a while back when I was casting around for existing schemes... They seem longer and email like (e.g., cid:foo4%25foo1@bar.net).
Grahame Grieve (Apr 21 2021 at 01:40):
well, they don't have to be email like, so far as I can see. but you may be right about being longer
Josh Mandel (Apr 21 2021 at 01:41):
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
cid-url = "cid" ":" content-id
... it refers to RFC822 for add-rspec, so I don't see how to avoid this.
Grahame Grieve (Apr 21 2021 at 01:41):
hmm ok.
Josh Mandel (Apr 21 2021 at 01:42):
If we wanted to change from resource:0 I guess we'd just use r:0 as the MITRE team suggested in a previous round of edits. I don't see value in breaking our "v1" implementers for this (given there's no practical implementation issue) but if folks feel strongly that it'd be a benefit, we could look at this as part of a v2 (I expect we'll have... a lot of proposed changes as we enter the HL7 consensus process).
Grahame Grieve (Apr 21 2021 at 01:42):
back to resource:0, it supposed to be resource:{n} where n is a serially incrementing number? That's what I guess but it's not clear
Josh Mandel (Apr 21 2021 at 01:42):
Grahame Grieve: back to resource:0, it supposed to be resource:{n} where n is a serially incrementing number? That's what I guess but it's not clear
Yes that's the expectation, but any "short" suffix after : is OK currently. I'd like to be prescriptive as you suggest here.
Grahame Grieve (Apr 21 2021 at 01:44):
well, being prescriptive would be good, but being clear would be better :-)
Grahame Grieve (Apr 21 2021 at 01:44):
I'm looking at this:
Grahame Grieve (Apr 21 2021 at 01:44):
Warning: FHIR validation currently does not work
The FHIR Validator currently generates a number of spurious errors when validating resources that are in fact valid. This is due to the following issues:
- For data minimization reasons, we use absolute URIs in resource:# format within our Bundles. We recently received clarification that this is supported in FHIR R4, but the FHIR Validator does not fully support this yet.
- We do not include id elements in our resources for data minimization reasons. This element is not required as the cardinality is 0..1 (though this is only strictly allowed for sending resources to a server for create operations). The FHIR Validator requires id to be populated for all resources.
- The terminology server used by the FHIR Validator (tx.fhir.org) does not support a number of value sets that we use, and some of the value sets that are supported our out of date (like CVX). This causes errors both in validating codes and Bundles that slice based on profiles with required value set bindings.
- You will see warnings related to meta.security when validating that say A code with no system has no defined meaning. A system should be provided. This cannot be suppressed, but can be safely ignored.
Grahame Grieve (Apr 21 2021 at 01:49):
#1 I'm looking at this. I have a PR to support resource:, and that's why I'm checking the authority for that
#2: I'll investigate.
#3: I'll have to work on the phinvads code systems. CVX is fixed up now
#4: I don't understand this at all. Why?
Josh Mandel (Apr 21 2021 at 01:50):
I have a PR to support resource:, and that's why I'm checking the authority for that
(1) Might aim to support FHIR-31422 with support for any URI scheme when resolving from Reference.value in a bundle to Entry.fullUrl -- irrespective of scheme.
Josh Mandel (Apr 21 2021 at 01:51):
(4) the IG says to populate a value like:
"meta": {
"security": [{"code": "IAL1"}]
}
... which is valid FHIR but generates a warning for lack of Coding.system.
Grahame Grieve (Apr 21 2021 at 02:11):
an d so it should.FMG won't approve an IG that says that
Grahame Grieve (Apr 21 2021 at 02:11):
why not provide a system? ("system" : "http://terminology.hl7.org/CodeSystem/loa")
Josh Mandel (Apr 21 2021 at 02:12):
The rationale was just not to burn bytes on something that can't vary. But we could populate a system here.
Josh Mandel (Apr 21 2021 at 02:13):
(It's really unclear how often issuers will be able to populate this with a meaningful value anyway. Our IG should probably recommend omitting LOA 1 markers anyway, because they don't really you anything useful.)
Grahame Grieve (Apr 21 2021 at 02:13):
that's the same as a default value, which can't be asserted in an IG. It's worth the bytes on that one.
Grahame Grieve (Apr 21 2021 at 02:15):
and yes, I did wonder about that LOA as a security tag. It's more a tag at the most; Or actually, it's a statement about the provenance. I can't say whether it's useful or not in US context, but the usefulness of it is in the media here in Australia (by implication).
Josh Mandel (Apr 21 2021 at 02:15):
I think that's fair, especially with the advice to omit LOA1
Josh Mandel (Apr 21 2021 at 02:16):
Yeah, I mean it's an important "capability to have" because in real life nobody is checking anything, and issuers that actually have id verification policies need a way to say it. But I don't think it'll make any practical difference, and mostly it'll be missing so the byte count is theoretical ;-)
Josh Mandel (Apr 21 2021 at 02:17):
As to where it belongs or how to convey it better... we had an extensive discussion that didn't reveal much, but led to some pragmatic suggestions
- https://github.com/dvci/vaccine-credential-ig/issues/1
- https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Representing.20IAL.20in.20FHIR
Grahame Grieve (Apr 21 2021 at 02:22):
well, the definition of security label is broader than I'd like, but I still think level of assurance of identity is a not a security property of the resource
Grahame Grieve (Apr 21 2021 at 02:24):
I thought it would be a property of the id, not the resource, but I see patient ids are profiled out. So I don't really follow the value of LOA anyway
Josh Mandel (Apr 21 2021 at 02:31):
The use case is: explain whether/how you validated the patient's identity in the context of this immunization record.
Josh Mandel (Apr 21 2021 at 02:31):
It an differ from one immunization to the next (e.g., across vaccine doses)
Grahame Grieve (Apr 21 2021 at 02:32):
so you claim that you did, but don't detail with id you used... how is that useful?
Josh Mandel (Apr 21 2021 at 02:33):
?? You document the policy you applied, which could be "we checked against some kind of gov't id" vs "we didn't do anything".
Josh Mandel (Apr 21 2021 at 02:34):
It's useful because some verifiers may not want to trust records of immunizations where no identiy validation was performed. (In practice, I think I agree with you that much of the time it won't matter, but we need at least an official answer to this question.)
Josh Mandel (Apr 21 2021 at 02:35):
(When I received my first dose on Sunday, nobody asked for any kind of ID at all. This is pretty consistent with all the experience of friends and family I've talked to here. So any vaccination credential I ultimately receive will be based on the name I used to register with Walgreens.)
Grahame Grieve (Apr 21 2021 at 04:50):
my point is, what does it mean 'we checked against some id' when the id you checked with isn't specified?
Josh Mandel (Apr 21 2021 at 04:58):
The demographics that you verified are specified, and the kind of source you verified against is specified.
Josh Mandel (Apr 21 2021 at 04:59):
I think you're just pointing out that we don't include specific document identifiers as part of this metadata, which is true because (for instance) your driver's license number is not critical to interpreting the fact that I verified your name and birthdate from your driver's license.
Josh Mandel (Apr 21 2021 at 05:01):
It's helpful to document the fact that I verified your name and birth date from a valid government ID, even without documenting more information about that id.
Grahame Grieve (Apr 21 2021 at 07:44):
if the id was provided, the details would be in the use code for the id. But ok, I can understand that a statement that some government id was seen is useful. I do think it's an extension
John Moehrke (Apr 21 2021 at 12:07):
define what level of assurance is most likely to have been used, and say that is the meaning of none being indicated. Then you just have the edge cases of higher and lower that need to use up the bits to carry a value.
John Moehrke (Apr 21 2021 at 12:09):
we clearly are not using exactly the concept of any level of assurance, we are representing the kind of assurance commonly used in vaccine processing. Thus we should just define our own range of values, and not imply they are anything like NIST or other identity assurance standards.
John Moehrke (Apr 21 2021 at 12:12):
the assurance level that the vaccine-credential relying-parties "want" is very unlikely to be the one under which the patient was given the vaccine. Especially for covid, as the scale is well beyond typical scale. My family experience in Wisconsin is that they are requiring a government picture ID, but they have procedures for accepting a friendly face. I am sure the scale and urgency of covid vaccine, they are never sending someone away. That someone may not realize they would not qualify for a high assurance vaccine-credential.
Michael Turman (Apr 21 2021 at 13:51):
Adding to the 'assurance level' discussion, as a vendor, we do not have visibility to an Issuer's SOPs related to identity verification, so we will not be populating that field. To do so would be a 'guess' on our part (and likely a default across all Issuers we support), which seems to defeat the purpose.
Josh Mandel (Apr 21 2021 at 16:04):
Fortunately, the cases where issuers don't populate this field are very easy to model ;-)
Josh Mandel (Apr 21 2021 at 16:05):
For cases where we do populate this field, we've have prolonged discussion about extension vs Meta.security vs. Meta.tag. Any of these will work equivalently; we settled on Meta.security in the current spec based on feedback from discussion. I'd rather not thrash without a clear rationale.
Max Masnick (Apr 21 2021 at 17:31):
@Josh Mandel @Grahame Grieve @Michael Turman -- what's the consensus here regarding Meta.security? It sounds to me like:
- We are going to continue using
Meta.securityunless there's a rational for a different approach - We need to provide
Meta.security.system. @Grahame Grieve Ishttp://terminology.hl7.org/CodeSystem/loathe correct system? This URI doesn't resolve, and I don't see anything related to this on https://terminology.hl7.org/codesystems.html (but maybe I'm just missing it)
Is that right? If so I'll add an issue on GitHub for this.
Josh Mandel (Apr 21 2021 at 17:34):
(3) Captured in https://github.com/dvci/vaccine-credential-ig/issues/115 already ("Recommend against including LOA1")
Josh Mandel (Apr 21 2021 at 17:35):
I think for (2) Grahame was saying... we'd need to define a new valueset and get HL7 to agree to publishing it, which creates a bit of a dependency for us. I guess the best we could do would be to assume we can get this through, but the name or the contents could change in ways we don't anticipate.
Grahame Grieve (Apr 21 2021 at 20:26):
you have a value set. you just need to specify to fill out Meta.security.system with the value http://terminology.hl7.org/CodeSystem/loa. I don't see why there would be anything else required
Josh Mandel (Apr 21 2021 at 20:30):
Just that http://terminology.hl7.org/CodeSystem/loa needs to exist (or have a path to existing -- e.g. if we hit a snag and HL7 doesn't approve this name, that'd require a bit of rework)
Grahame Grieve (Apr 21 2021 at 20:33):
ah you are defining that yourself. Well, you can define it yourself, but then you need to give it the URL http://hl7.org/fhir/uv/smarthealthcards-vaccination/CodeSystem/loa. Or else you need to propose it through UTG. I think you're supposed to do UTG for stuff like this, but I'm not sure what the policy is right now
btw I am surprised at the length of the canonical here. Is this sometihng FMG approved? shc-vci would be shorter...
Josh Mandel (Apr 21 2021 at 20:40):
http://hl7.org/fhir/uv/smarthealthcards-vaccination/CodeSystem/loa is definitely too long ;-)
Josh Mandel (Apr 21 2021 at 20:40):
And for sure not having vaccination in the url would be good, given the scope is broader.
Max Masnick (Apr 21 2021 at 21:42):
I think we are supposed to request this through UTG. I'm becoming good friends with Vocab so I'll ask them for help with this :)
Josh Mandel (Apr 21 2021 at 21:50):
(Re: canonical URL for the IG though, it'd be good to update that even if we use a UTG-based LOA vocab.)
Grahame Grieve (Apr 22 2021 at 03:39):
The FHIR Validator requires id to be populated for all resources.
not any more as of next release. Now it depends on the bundle type
Paul Denning (Apr 22 2021 at 14:47):
will type="collection" require .id?
Grahame Grieve (Apr 22 2021 at 18:49):
no
John Moehrke (Apr 28 2021 at 11:25):
The LOA codes already exist in HL7 in this valueset https://terminology.hl7.org/ValueSet-v3-SecurityTrustObservationValue.html
Thus your codesystem would be http://terminology.hl7.org/CodeSystem/v3-ObservationValue
Josh Mandel (Apr 28 2021 at 12:27):
Based on our discussion in #Security and Privacy we needed to craft specific new "intermediate" LOA codes to capture the fact that most real-world id verifications don't reach IAL2.
John Moehrke (Apr 29 2021 at 11:14):
I agree adding a code to the HL7 managed codesystem is appropriate. (Adding a code to a codesystem managed by NIST would not be appropriate for us to do). But this is clearly a need driven code, and the current LOA codes are in an HL7 managed codesystem.
John Moehrke (Apr 29 2021 at 11:18):
if you think the URL is too long, then how about using the OID?
urn:oid:2.16.840.1.113883.5.1063
Alan Viars (Apr 29 2021 at 13:01):
Here is my take on this: IAL 1.5. https://github.com/TransparentHealth/healthcare-trustmark Feel free to use/adapt this if you want. I think some refinement/maturity is needed around 1.5 criteria, but you get the general idea. I don't think 1.2, 1.4, 1.8, etc is needed or desirable. Just a single level between IAL 1 and 2 is enough IMHO. I would really like to discuss this notion with NIST, ONC, CMS, etc.
Grahame Grieve (May 05 2021 at 03:03):
getting back to this resource issue... I think that resource: is superceded allowed by J#31422, but I also think that something more specific should be used. I see some resistance about to just fixing it, but I think it should be done at some stage. Anyway, next release of the validator will OK any absolute URL that is an internal reference in a bundle
Peter Bachman (May 05 2021 at 16:09):
John Moehrke said:
define what level of assurance is most likely to have been used, and say that is the meaning of none being indicated. Then you just have the edge cases of higher and lower that need to use up the bits to carry a value.
I’m wondering if the IAL level etc is really relevant if one can use something like a ICAO passport key to be embedded in a verifiable credential that’s included the smart on fhir card and it’s presentation?
Josh Mandel (May 05 2021 at 17:09):
We don't have a "passport key" embedded in Health Cards, though. We're trying to graft the Health Cards ecocystem onto existing patient identity practices.
Neelima Karipineni (May 12 2021 at 14:55):
Any chance updated validator will be released before the Connectathon?
Josh Mandel (May 12 2021 at 16:17):
I think this is a question for @Grahame Grieve or @Mark Iantorno
Mark Iantorno (May 12 2021 at 16:21):
If the changes are in the codebase I can release at any time
Mark Iantorno (May 12 2021 at 16:22):
are the changes you want currently committed? I can release now if you _need_ it
Mark Iantorno (May 12 2021 at 16:22):
@Neelima Karipineni
Neelima Karipineni (May 12 2021 at 17:25):
Thanks @Mark Iantorno . I was referring to @Grahame Grieve 's earlier comment about upcoming fix for allowing reference URLs that are internal references in a bundle. I just checked the org.hl7.fhir.validation repo and I couldn't identify a commit in BundleValidator for this. Unless I'm missing something, I think not ready for release.
Mark Iantorno (May 12 2021 at 18:50):
Once the fix is in, shoot me a message and I'll do a release for you
Grahame Grieve (May 13 2021 at 00:46):
@Mark Iantorno I had intended to get a release out a few days ago, but that went to hell. I'm on the road today, so I'll commit some stuff tonight, and you can push a new version out
Mark Iantorno (May 13 2021 at 00:46):
kk just let me know and I'll run it
Peter Bachman (May 13 2021 at 16:30):
Michael Turman said:
Adding to the 'assurance level' discussion, as a vendor, we do not have visibility to an Issuer's SOPs related to identity verification, so we will not be populating that field. To do so would be a 'guess' on our part (and likely a default across all Issuers we support), which seems to defeat the purpose.
As a practical matter the type of identification provided to get immunized at the point of service varies. For my use case involving tourism in Europe, I know the traveller will have a passport so I got a development license for a passport reader sdk which processes the data from the e-passport using a passport reader and will combine that with the data minimized Immunization resource to sign it.
Max Masnick (May 14 2021 at 15:36):
Looks like yesterdays' release of the validator resolves the warnings we were seeing related to new CVX codes and the resource:0 syntax for URIs. Thank you!
Julie Maas (Jul 21 2021 at 06:17):
If you require a level of assurance, it's helpful to include 1 in order to describe the level of verification as "self asserted".
Josh Mandel (Jul 21 2021 at 12:36):
@Julie Maas are you suggesting we should revise our current recommendation to omit LOA when it's "just" 1? (That's what we currently say, to avoid spending bytes communicating information that won't help "convince" a verifying party of anything.)
Josh Mandel (Jul 21 2021 at 12:39):
From what I've seen, most real world Health Cards implementations today have no reliable way to reach levels higher than 1 (the issuer often just doesn't have this kind of information; it's not reliably tracked/knowable in individual cases).
Julie Maas (Jul 21 2021 at 13:55):
I thought that might still be up for discussion; until we are more formally capturing something like a declaration of identity (subject claims the indicated demographics belong to them), it's certainly less meaningful to indicate "self asserted" (IAL1). My thoughts are that taking 1 away leaves its absence more ambiguous, though (NULL could mean either self asserted OR unknown); I also thought that some level of assurance was always required in the SHC spec. (What does that mean for an entity that cannot assert 1.2, 1.4, or 2?) If the community feedback is that "1" is not meaningful and won't be used, that does say something & I can understand the decision in that case. I suppose IAL1 is still in the new ValueSet so other workflows can opt to use it if it makes sense in their use cases.
Last updated: Apr 12 2022 at 19:14 UTC
