Stream: smart/health-cards
Topic: credentialSubject
Richard Braman (FLY.HEALTH) (May 04 2021 at 11:51):
Does this always have to be fhir? what if the data was in HL7 2.x? Would it need to be converted to to fhir?
Richard Braman (FLY.HEALTH) (May 04 2021 at 12:18):
Is there a possibility for duplicate credentials? Because the NBF value is changing, each generation is unique at the credential level. But what about at the credential subject level? Is it bad for two credentials to exist from the same issuer with the same credential Subject?
Michael Turman (May 04 2021 at 14:39):
What is the harm in 'duplicate' credentials? Both can be independently verified.
A consumer may request their SHC from one device, and then use a different device and request the SHC again - I don't see any problems in supporting that workflow from an Issuer or Verifier perspective.
Josh Mandel (May 04 2021 at 14:43):
We don't try to express any constraints about the universe of credentials; we're focused on helping issuers create a narrowly defined set of Health Cards for purposes of broad interoperability. Issuers are free and welcome to generate other credentials (and of course to share data in other formats that might not be verifiable), but that is beyond the scope of this project.
Richard Braman (FLY.HEALTH) (May 04 2021 at 16:38):
Josh, I get that. But isn't the most broadly implemented interop standard for immunizations and lab results hl7 2.x ?
Richard Braman (FLY.HEALTH) (May 04 2021 at 16:41):
are we just saying fhir only in the credential subject?
Josh Mandel (May 04 2021 at 17:07):
We're saying a lot more than just "FHIR"; we are providing specific profile guidance for these use cases, all in the context of FHIR.
Josh Mandel (May 04 2021 at 17:09):
While it is true that many connections between EHR and public health use HL7v2, it does not follow that this format is suitable for consumer access and sharing (where it's important to align with other investments in consumer access; these are FHIR based).
Alan Viars (May 04 2021 at 21:26):
I think @Richard Braman (FLY.HEALTH) has a pretty valid point here. An HL7 v2 representation would be much smaller and more easily ingestible by existing EHRs. While I'm no fan of Hl7 v2, this is a more compact way to represent the same data. I made an ADT to Identity structure converter last spring which is somewhat relevant. https://github.com/TransparentHealth/oauth2org/blob/adt/apps/adt/parse_adt.py It accepts an HL7v2 ADT stream and outputs id_token like JSON objects.
Josh Mandel (May 04 2021 at 21:38):
A custom JSON schema would be compact and contemporary :-)
Neelima Karipineni (May 04 2021 at 22:11):
Even if we used v2 instead of FHIR, new profiles would have to be developed. Existing standard messages like VXU and the RSP_K11 z32 profile don't comply with the health card requirement for data minimization/privacy. A lot of data elements that are currently allowed (encounter details, insurance info) would have to be disallowed. So any currently implemented standard for interop in IIS or LIS systems would still have to be modified/enhanced.
Nathan Bunker (May 12 2021 at 22:54):
I would add that while state systems don't widely support FHIR. They do support HL7 v2 quite extensively, but these were designed for a different workflow (IIS to EHR or IIS to IIS). They are not prepared to support a "consumer access" interface. The biggest problem facing state systems is not the message format, it is the interaction with consumers. Converting the data from an HL7 v2 RSP format into FHIR and then into VCI is a pretty straightforward technical exercise. We did this in an internal project and it was completed in a few hours, message format is one of our easier problems to solve. We are expecting to continue using HL7 v2 for our legacy interfaces and are looking to FHIR to support new cases.
Last updated: Apr 12 2022 at 19:14 UTC
