smart-on-fhir / health-cards Goto Github PK
View Code? Open in Web Editor NEWHealth Cards Framework: implementation guide and supporting material
License: Other
Health Cards Framework: implementation guide and supporting material
License: Other
e.g. to say something more specific than "share your immunization cards", might include a FHIR query string that narrows down via CVX code to just Tdap.
The goal here is to:
I think EHR-Issuers and their Patients will want to support multiple wallets per Patient, just having multiple DIDs linked to an account.
To support this, the EHR will need to know which Holder a VC is being issued for, since this will determine what DID document/JWE encryption key is used by the issuer.
This is easy enough to support for download of fhir-backed-vc
files, since the issuer portal can just ask the patient which wallet the file is destined for. The portal could also try and be smart about this, where it can sense what device the user is logged in with and only show wallets that it knows came from that device (maybe registering an IP address for the device during the SIOP flow).
For supporting this with $HealthWallet
resources, the best answer would be to include a holderDid
parameter in the POST /Patient/:id/$HealthWallet.issueVc
API call.
Here's an example payload:
{
"resourceType": "Parameters",
"parameter": [{
"name": "credentialType",
"valueUri": "https://healthwallet.cards#covid19"
},
{
"name": "holderDid",
"valueUri": "did:ion:<<identifer for holder>>"
}]
}
Note this also covers the niche scenario of a patient having the same wallet installed on multiple devices. Those wallets will have the same client_id, BUT have separate DIDs (unless they're sharing private keys, but that seems out-of-scope). Without this parameter, EHRs wouldn't be able to recognize the difference between these two wallets issuing a $HealthWallet.issueVc
call.
Originally posted by @madaster97 in #21 (comment)
A few of the members in the W3C Credentials Community Group have been working on a Vaccination Certificate Vocabulary that is compatible with the WHO SVC work. The W3C CCG has also been working on a Verifiable Credentials HTTP API.
For those that are not familiar with the W3C CCG, it is the group (consisting of 400+ members) that created and standardized the Verifiable Credentials and Decentralized Identifier global standards (among many others that are currently being developed). These standards are used by a large number of digital vaccination certificate projects around the world (EU, US, NZ, etc.).
We (Digital Bazaar) thought it might be interesting to see if we could create an interoperability test suite for the WHO Smart Vaccination Card work using the tools listed above.
The test suite covers 28 types of vaccines that are covered in the SVC work, including Measles, Smallpox, Polio, Yellow Fever, COVID-19, and others.
Please note:
With that said, we've been able to achieve the following:
You can view the latest Vaccination Certificate test suite report here:
https://w3id.org/vaccination/interop-reports
The announcement to the W3C Credentials Community Group is here:
https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0081.html
How can we best coordinate the test suite work with VCI? We have a number of concerns related to the claims made about Health Cards being conforming Verifiable Credentials (they are not)... how can we help to close this gap?
"In the response, an optional repeating resourceLink parameter can capture the link between hosted FHIR resources and their derived representations within the verifiable credential's .credentialSubject.fhirBundle, allowing the health wallet to explictily understand these correspondences between bundledResource and hostedResource, without baking details about the hosted endpoint into the signed credential"
Please clarify if the resoruceLink
parameter may (or may not) include only part of all resources in the bundle. For example, the bundle have 10 Immunization instance and the resourceLink
has only 5 of them.
I am not sure if this is in scope for this project, but the notion of "source of truth" for immunization records is an open issue. Is it the EHR? IIS? Both? Either? Note that for both the EHR and IIS that records can change and be corrected for many reasons: simple errors, discovery of a bad vaccine lot invalidating the efficacy of the dose administered. Should the patient be able to capture their immunization record and store it in their digital wallet and assume it is forever "true"? Should they be made to validate that record from its source?
A secondary issue involves IIS or other points of record consolidation (potentially an HIE). They are only as good as the systems that submit data to them (primarily EHRs) but also apply some quality assurance steps to consolidate a coherent record for a patient. Should they be a preferred, more centralized source of information over an EHR?
Does this project even care about these distinctions?
What if an issuer such as Acme hospital wants to delegate the issuance of credentials to labs or physician within the organization?
While Acme may be recognized as a trusted issuer, delegates may not. This will likely require some form of provenance chain Acme - delegates -> lab - delegates -> physician
that will need to be followed in order to verify the integrity of a given credential. Aries has some information on this, but I'm not sure the problem is actually solved yet.
There appears to be a conflict between the SIOP Response format in the reference implementation and what's in the docs. The reference implementation payload includes a did
property, whereas the payload format in the docs includes a sub_jwk
property.
EDIT: I think I overlooked some things. The docs do include a did
property, so just wondering if we should be including the sub_jwk
.
Currently the contribution guidelines are just:
Contributing¶
To propose changes, please use GitHub Issues or create a Pull Request.
Please add a project scope which explains what this exact project hopes to accomplish... written in a level of detail that will make it clear if a given contribution would be in-scope or out-of scope.
This type of project specification will help attract contributors that have the kind of experience you are seeking.
Personally I have worked on distributed identities, am lead author on the non-fungible tokens specification, have deployed enterprise solutions and worked on the team that delivered the largest blockchain Microsoft is using in production. And I don't know if this project is worth working on or if I should make a competing product.
I'm one of the global standards Editors for the W3C Verifiable Credentials specification, W3C Decentralized Identifier specification, and a variety of ecosystem-supporting specifications. These specifications allow for a variety of design choices to be made; we did this to ensure that we were building big tent where most anyone could participate in building solutions. The downside to that philosophy is that there are a varied number of technologies that are sprouting up that, while compatible with the specifications, are incompatible with each other in many practical settings. In order to ensure that decision makers have clear guidance wrt. what technologies work well together, there are government-funded programs (in the US, Canada, and EU) that are focusing on creating interoperability test suites that test the software produced for these ecosystems for interoperability.
Therefore, it is important for the health cards initiative to clearly articulate which technologies are being used for each stage of a Verifiable Credentials exchange and how many organizations have working solutions for each technology. This issue is being created to track the various options that are available and how many organizations are supporting those options today.
Apparently, Microsoft, Salesforce, and Oracle have endorsed this project as per:
https://www.theverge.com/2021/1/14/22231187/microsoft-salesforce-oracle-digital-vaccination-records
This is an important fact that should be disclosed in README.
From Issue #36.
Federal systems, and federally funded state systems, must demonstrate FISMA compliance using the NIST SP800-53 guidelines according to Federal Information Processing Standards (FIPS) 199 Moderate level of impact to comply with the Health Information Portability and Accountability Act (HIPAA).
https://www.insidegovernmentcontracts.com/2014/12/fisma-updated-and-modernized/
The process begins with a QR code or openid://
link. The only differences are:
The SIOP Request Object includes a claims
object asking for relevant Verifiable Credentials to be included in the response:
{
"iss": "did:ion:<<identifier for issuer>>", # should this be Verifier's DID instead?
"response_type": "id_token", # should the response_type still be an id_token, when what Verifier cares about is Holder's VC?
"client_id": "<<URL where response object will be posted>>",
"scope": "openid did_authn",
"response_mode" : "form_post",
"response_context": "wallet",
"nonce": "<<unique value>>",
"state": "<<client-supplied value, possibly empty>>",
"registration": {
"id_token_signed_response_alg" : "ES256",
"id_token_encrypted_response_alg": "ECDH-ES",
"id_token_encrypted_response_enc": "A256GCM",
"client_uri": "<<base URL for issuer>>"
},
"claims": {
"id_token": {
"https://smarthealth.cards#covid19": {"essential": true},
}
}
}
As far as I know, If I go tell my PCP that I got vaccinated at walgreens/cvs/etc then he or she is likely to enter it into the EHR as a vaccination record without requiring any proof from me. Once it's in the EHR I can get a signed health card where the EHR attests to the fact that I got vaccinated, even though it's only based on my claim to my doctor.
Is this correct? If so, what's the value in providing the secure framework around the attestation when the original claim can be easily faked?
Is there a requirement for the issuers to have somehow verified records they are signing, or distinguish between patient claims of vaccinations and vaccinations that were done in-house?
Aggregated feedback suggestions on the patient onboarding document:
and:
I understand the simplicity of embedding an FHIR bundle straight into a credential. This way the VC just acts as a container and you drop the bundle as-is.
However, while that works well for a proof of concept, stabilizing that construction would be at the cost of losing the VC data model semantics.
In VC, the credentialSubject
JSON object represents the subject of the credential – for a health credential, that would usually be the patient. So semantically, any attribute in credentialSubject is to be read as an attribute of the patient: name, allergies, etc. See schema.org/Person for example of such attributes. As a counter-example, fhirBundle
is not a property of a patient as it's a standalone object with resources, the patient being one of the resources.
I think it would be very good at some point to work on a subject-centered FHIR mapping. I don't have enough knowledge of the FHIR format to propose anything more concrete at this point so I'll let the specialists speak, but one step might be to split the bundle and try to represent each individual entry as a separate credential. What do you think?
Also we might need some additional claims to articulate an individual FHIR entry to a VC – maybe other health-related ontologies would be helpful there?
If you call $HealthWallet.connect a 2nd time, this replaces the originally-bound DID with a new one.
Add a verifiable credential type to the vocabulary documentation to be used for health cards to convey laboratory data (ie https://smarthealth.cards#laboratory).
There may be better Android handling available (e.g., routing Health Cards to the right wallet app) for downloads when a MIME type is available, vs just routing files based on extensions.
Questions:
Just wanted to start a discussion on the Trust over IP Stack. The stack outlines the required components for the trust ecosystem in the context of decentralized identity technologies like DID and VCs and represents a comprehensive view informed by those who have developed the underlying standards and technologies as well as companies that have been developing solutions in this space from its inception.
As you can see each layer of the stack has both technical and governance components. In my short exposure to VCI, it appears we are primarily focused on Layer 3, and reducing governance requirements is a design goal/necessity. However, you cannot wish away governance. You can encode it or externalize it, but those choices should be made and justified by the project so that implementers are aware of those choices and a coherent implementation remains possible across multiple providers.
I would propose an ecosystem subgroup to help quickly identify and document the relevant questions at each layer for both technical and governance so that we can incorporate that into the project design documents and ensure a coherent effort across all partners.
The Trust over IP Foundation is part of the Linux Foundation and was created to address the need for some sense of orthodoxy in integrating all of the disparate technologies supporting efforts like VCI. Trust over IP is tech agnostic and neither prescribes a specific solution nor seeks to compete with standards or providers, but instead informs and advises solution developers (like VCI) in wading through all the design options. MITRE is a steering committee member for Trust over IP and I am MITRE's representative to the foundation. Feel free to reach out.
Here is some additional information on the Trust over IP Foundation and its purpose:
A JAMA perspective on vaccines and variants suggests we need to get as much experiential / real world data as we can.
https://jamanetwork.com/journals/jama/fullarticle/2777785
IMHO, digital vaccination credentials are not enough and we need to rethink our priorities.
Previous review by legal compliance at Providence Health System determine public DIDs (such as ION) would not be considered compliant with HIPAA and could not be associated with elements of ePHI.
Recommend sidetree configuration support both public and private DIDs.
Note that the Framework document references a "lab" which seems to cover the COIVID testing use case but not the immunization use case. Perhaps these two user experiences should be separated as they are not exactly the same nor used necessarily in the same way at the same time. This is also not consistent with the primary use case identified in the draft FHIR IG.
I would like to recommend a table format for operation's parameters, like http://build.fhir.org/resource-operation-validate.html. Another option would be create a separate operation page and reference it from main index page.
Benefit: It is easier to quickly identify operation's parameters' name, type, and cardinality.
The longer descriptions and examples would be after the table.
We should provide more/clarified guidance on what is required when generating DIDs.
Specifically, the Sidetree DID Create Operation spec details the creation of update/recovery key pairs. In the smart health cards spec, these aren't mentioned, yet seem to be required by the core sidetree spec when generating a DID Document/Long-Form DID.
The most appropriate place to mention the generation of update/recovery key pairs is in the Install a "Health Wallet" App section. In this section we spell out that DID generation requires a generating signing/encryption key pairs, but we should consider adding guidance on the update/recovery key pairs as well.
In addition to mentioning the need for update/recovery key pairs, could we also include some example scenarios?
For instance, if a Self-Issued OP had it's private key exposed, how would they go about rotating it out of their Long-Form DID document? Is there a specific operation that can black-list a given key?
Example scenarios seem relevant not only for issuing parties that may need to rotate a key, but also for relying parties (not strictly OIDC RPs, but anyone checking a public key) that would need to respond appropriately to a key being revoked. For instance, if an Issuer had a private key exposed, how would that knowledge propagate to the Holders and Verifiers, and how would they be expected to respond?
Take the example of an Issuer of VCs whose VC-signing private key has been exposed. For issuers using the did:METHOD:<did-suffix>:<initial-did-document>
format, they may go through the following workflow:
.well-known/did-configuration
endpoint, the issuer would rotate out the old document with the new one as did:METHOD:<did-suffix>:<rotated-did-document>
.
linked_did
entry corresponding to their most up to date DID document.did-configuration
call. For instance, the verified DID document would potentially contain patches
where a specific signing key was revoked.
registration.client_uri
, and so can't be expected to ad-hoc call the did-configuration
endpoint for the issuer of a VC. I think the expectation in this relationship is that the Holder will have verified a VC before downloading it in the first place (though not necessarily verifying again when distributing to a verifier). Other than an in-spec mechanism of revoking VCs with application logic, VCs should be able to persist in spite of corresponding private keys being compromised (as long as the key was compromised after the VC itself was issued).
well-known
documentation mechanismThe issuer key set published at https://smarthealth.cards/examples/issuer/.well-known/jwks.json
contains an encryption key. I suggest removing it, since it is no longer used in the spec. The validation tool shows warning for non-signature keys in the JWKS, so that would reduce the output for the example files.
As best as I can tell (and I am no FHIR expert) the current draft IG has no provision for a bundle that includes immunization forecast as a component. For purposes of completeness this should be included. It does not mean that any particular use case needs to use it but these FHIR resources should be available. This data is contained in the ImmunizationEvaluation and ImmunizationRecommendation resources. Work on this topic is conducted within HL7's Public Health WG. Key people working on this include Nathan Bunker [email protected] who has been participating in the weekly Tech WG calls, Eric Larson [email protected], Craig Newman [email protected], and Daryl Chertcoff [email protected] who works for me.
We could say:
Alternate VCs and the resourceLink values associated with the vc
i.e.
param: VC1, (Resoure Link for VC1), VC2, (Resource Link for VC2)
downside: it's fragile to depend on order
Or we could add a VC index in the Resource Link structure (making it {vc index, bundledResource, hostedResource)
downside: this also has a dependency on order...
Update verifiableCredential to include two parts: vc and resourceLink
downside: this breaks clients that have a simple way to extract VCs today)
Is there any concept of a stable unique identifier that wallets can use to de-dupe VCs? If not, is there any guidance for wallets on how to de-dupe VCs. For example, if the contents of the credentialSubject
/vc
object are expected to be stable, wallets could canonicalize the json object, then hash and derive an identifier from that.
Should we be using AES/GCM ?
There are two places in the IG using work "MUST". Suggest change to standard conformance language "SHALL"
MUST have "kty": "EC", "use": "sig", and "alg": "ES256"
MUST have "kid" equal to the base64url-encoded SHA-256 JWK Thumbprint of the key (see RFC7638)
FHIR convention uses lower case letter for operation name, such as "$validate-code". http://build.fhir.org/operationslist.html
Suggest change operation $HealthWallet.issueVC to $healthwallet-issuevc
While I think Sidetree is valuable as a layer 2 solution, it seems like it may be unnecessarily difficult to bootstrap the effort - especially since performance is not initially a problem. For example:
Identify regulatory constraints and restraints for the project.
Members comment on this issue with the following template:
"By default, the issuer will return health cards of any age. If the Health Wallet wants to request only cards pertaining to data since a specific point in time, it can provide a _since parameter with a valueDateTime (which is an ISO8601 string at the level of a year, month, day, or specific time of day)."
The ISO8601 extended time format (eg: yyyy-MM-ddThh:mm:ss) aligns with FHIR dateTime format.
The ISO8601 basic time format (eg: yyyy-MM-ddThhmmss) does not.
Please clarify if which format does the parameter use?
Observation.code is a coarse-grained LOINC code; more details may be needed to interpret.
Reading through the docs I've run into a couple places where we could be clearer.
kid
of did:ion:<<identifer for lab>>#<<verification-key-id>>
, and the payload has an iss
claim of did:ion:<<did-value>>
. Should the iss actually be did:ion:<<identifer for lab>>
for clarity, since this JWT was issued by the lab?id_token_encrypted_response_*
parameters in the SIOP request.Currently the contribution guidelines are just:
Contributing¶
To propose changes, please use GitHub Issues or create a Pull Request.
Please add a project scope which explains what this exact project hopes to accomplish... written in a level of detail that will make it clear if a given contribution would be in-scope or out-of scope.
This type of project specification will help attract contributors that have the kind of experience you are seeking.
Personally I have worked on distributed identities, am lead author on the non-fungible tokens specification, have deployed enterprise solutions and worked on the team that delivered the largest blockchain Microsoft is using in production. And I don't know if this project is worth working on or if I should make a competing product.
https://smarthealth.cards/examples/example-02-a-fhirBundle.json
resource:0
which is DiagnosticReport in the bundle. Even the DiagnosticReport.subject reference to itself.Please add SHALL/SHOULD/MAY to these following requirements:
Signing keys should be listed/referenced under:
authentication[]
- https://w3c.github.io/did-core/#authenticationassertionMethod[]
- https://w3c.github.io/did-core/#assertionmethodEncryption keys should be listed/referenced under:
keyAgreement[]
- https://w3c.github.io/did-core/#keyAgreementA declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.