Stream: united states
Topic: NPRM
Grahame Grieve (Feb 19 2019 at 06:12):
I'm hoping that a number of the responses to the NPRM will be driven from the excellent spreadsheet at https://docs.google.com/spreadsheets/d/1C9faN7Ne0DIgrmXbMVBcff9KTotuejIEbpr4ZPE3tUE/edit#gid=0 maintained by @Michele Mottini
Grahame Grieve (Feb 19 2019 at 06:13):
- must support FHIR
- must support Smart on FHIR
- must have doco
- must have sandbox
- must allow app registration automatically
- must list provider end-points somewhere
Michele Mottini (Feb 19 2019 at 14:20):
I better update it then... I did not check for new certified system in a while, I'll do that next week
Michele Mottini (Feb 25 2019 at 17:22):
Updating the document - there are a bunch of new certified systems so it will take some days
Yunwei Wang (Feb 25 2019 at 19:12):
@Michele Mottini Thank you for the list. When you say "certified systems", which organization issue those certification?
Michele Mottini (Feb 25 2019 at 19:22):
The ONC issues and maintain the certification criteria, the certification itself is done by accredited private testing organization - paid by the vendor seeking the certification. The full list of certified systems is at https://chpl.healthit.gov/#/collections/apiDocumentation
Grahame Grieve (Feb 25 2019 at 23:09):
this list is awesome... thanks
Michele Mottini (Feb 26 2019 at 00:19):
Finished updating it, and added columns for Centralized app registration / Publish list of end points / App enabled by default - filling them with what I know (only for those system that support SMART)
SueAnn Svaby (Apr 11 2020 at 15:01):
According to the 21st Century Cures Act, we should be compliant with C-CDA R2.1 and FHIR R4. I found a big discrepancy in the value sets for Immunization status:
FHIR (Immunization.status)= completed | entered-in-error | not-done
CDA (Immunization Activity) = normal | aborted | active | cancelled | completed | held | new | suspended | nullified | obsolete
Both specs require the status and the binding to the value sets is required. If we combine the two lists, our FHIR Resources and our C-CDA could end up with validity errors. Any suggestions on how we should deal with this?
Lloyd McKenzie (Apr 11 2020 at 16:57):
You'll have to map. The set of codes supported by C-CDA include codes that don't make a whole lot of sense and are generally not used. You might also ask on #CCDA / FHIR mapping stream
SueAnn Svaby (Apr 11 2020 at 19:15):
Lloyd McKenzie said:
You'll have to map. The set of codes supported by C-CDA include codes that don't make a whole lot of sense and are generally not used. You might also ask on #CCDA / FHIR mapping stream
@Lloyd McKenzie Thank you so much for your response. We are under the impression that a value set binding of SHALL indicates we have to support (as in give the user the ability to select) all of the values in the value set. Is that your understanding as well? Thank you!!
Lloyd McKenzie (Apr 12 2020 at 02:50):
No. In FHIR, there's an extension that can be used if there's a minimum subset of the codes that must be supported. In the absence of that, the only requirement is that whatever concepts you choose to expose are drawn from that value set. It's completely legitimate if, as a sender, you don't support creating instances with all of the codes. It's also possible (though less desirable) to refuse to consume instances if they make use of codes that violate your business rules. For example, a registry service might refuse to accept patients with a gender of "unknown"..
Robert McClure (Apr 12 2020 at 15:11):
@Brett Marquard Any chance we can harmonize these two value sets?
Lloyd McKenzie (Apr 12 2020 at 18:36):
In theory a future version of CDA could tighten down on the allowed statuses, but it'll never be possible to use the same code system for both. v3 and FHIR both mandate the use of specific code systems for statuses.
Vassil Peytchev (Apr 12 2020 at 23:31):
Is this a case where adding a Task resource to the FHIR structure in order to account for some of the available uses of the C-CDA immunization activity something to consider? Some of the C-CDA statuses have matching values in Task.status...
Brett Marquard (Apr 13 2020 at 10:48):
Robert McClure said:
Brett Marquard Any chance we can harmonize these two value sets?
In a future update of C-CDA we could definitely cut down the values, but full alignment is difficult. (CDA doesn't have a not-done concept on status, there is a fun negation that is used)
Eric Haas (Apr 13 2020 at 16:26):
here is a quick back of the envelope draft mapping I just did. but like Lloyd said check with #CCDA / FHIR mapping stream or with @Craig Newman and the PHER WorkGroup to see if they have done this in their modeling of the resource. Also @Vassil Peytchev is correct that some of these ccda statuses would fall into Task for some workflows.
Craig Newman (Apr 13 2020 at 17:17):
I would agree that most of the values in the CDA value set don't necessarily work with the FHIR definition of the Immunization resource (either an administration event that has happened or the opportunity for an event which wasn't taken (because the patient refused or something)).I think Eric's draft maps seem reasonable although I might argue that held, new and suspended might be "no map" for the same reason that "active" is a "no map". The Public Health WG hasn't formally done any mapping between FHIR and CDA (or v2 for that matter), at least not recently. Prior to the administration event (or refusal), we would expect a MedicationRequest or some such resource to potentially exist to indicate the intention to vaccinate.
Last updated: Apr 12 2022 at 19:14 UTC
