Stream: implementers
Topic: ONC Certification Final Rule
Shubham Sharma (Apr 16 2020 at 05:09):
Hi All,
While we are going through rule and USCDI support using US Core FHIR Profiles. Just needed quick help if some one has already analyzed this.
Does it means we need to implement individual resources for Allergy, Medication , Diagnoses etc..
Or Server can have Patient resource and Document Resource and exposes C-CDA as Document.
Or Server can have Patient resource and provide include/_revinclude faclity to pull all other information.
Michele Mottini (Apr 16 2020 at 12:50):
You have to implement all individual resources as specified by the US Core implementation guide - http://hl7.org/fhir/us/core/STU3.1/
Robert Scanlon (Apr 16 2020 at 18:04):
And you can't just support returning them in something like a $everything or _revinclude on /Patient, you need to implement all of the RESTful calls with SHALL requirements in the US Core v3.1 server capability statement (http://hl7.org/fhir/us/core/STU3.1/CapabilityStatement-us-core-server.html). There are quite a few.
Robert Scanlon (Apr 16 2020 at 18:10):
Clarification: all non-write interactions for resources are required. The ONC final rule only requires read-only for USCDI classes/elements.
Shubham Sharma (Apr 21 2020 at 12:48):
Thank You All for clarification.
We also reach to same conclusion while further readings of Rule.
SueAnn Svaby (Apr 27 2020 at 20:27):
Shubham Sharma said:
Thank You All for clarification.
We also reach to same conclusion while further readings of Rule.
I'm looking to clarify something. The 21st Century Cures Act states:
"Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR resource level, from one specific FHIR resource (e.g., “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). This capability will give patients increased control over how much EHI they authorize applications of their choice to receive. For example, if a patient downloaded a medication management application, they would be able to use these authorization scopes to limit the EHI accessible by the application to only information contained in FHIR “MedicationRequest” and “Medication” profile."
Does this literally mean that we need to give patients the ability to select which resources they will share with each application that might request access to their data? In other words, if, as a patient, I want to use 3 different applications, do I have to indicate that I will share Meds, Allergies and Problems with Application A; I will share Meds, Allergies, Problems, and Immunizations with Application B; I will share everything with Application C? Any guidance would be greatly appreciated. Thanks in advance.
Michele Mottini (Apr 27 2020 at 22:37):
Yes, that's what it means. Applications typically register with the scopes they need, so only those will be shown to the user. Do you have a link for that text?
Robert Scanlon (Apr 28 2020 at 01:04):
pg 352-353 on https://s3.amazonaws.com/public-inspection.federalregister.gov/2020-07419.pdf#page=352
Cooper Thompson (Apr 28 2020 at 21:32):
Note that there is an Argonaut project to improve the scopes to be more "real-world" than FHIR Resource-based scopes are. Authorizing "Observation" is pretty meaningless. If we do come up with better scopes, I believe we'd need the ONC to use their version advancement process to allow that though.
Meghan Holloway (Apr 29 2020 at 16:34):
I am looking to clarify how Provenance should be captured. According to US Core FHIR Basic Provenance IG https://www.hl7.org/fhir/us/core/basic-provenance.html specification with reference to provenance authorship, it is our understanding that for a document that is manually scanned in to a certified electronic health record, the author would be the user scanning to the chart and not the creator of the original content. While we do not believe this to be philosophically correct, it is our understanding of the specification. An example would be a referral letter for a patient from a specialist sent to the primary care provider, that is manually scanned into the CEHRT. According to the specification the author would be the individual performing the scan and not the originator of the content, the specialist. Please confirm that our understanding is correct.
SHALL support searching for all resources of a particular type for a patient and all the Provenance records for those resources using a combination of the patient parameter for that resource and the us-core-includeprovenance search parameter: GET [base]/[DocumentReference]?patient=[id]&us-core-includeprovenance
Example:
GET [base]/DocumentReference?patient=1233541&us-core-includeprovenance
.
Robert Scanlon (Apr 29 2020 at 16:46):
I'm not sure if this substantively changes the question @Meghan Holloway (probably not), but be sure to always look at the v3.1.0 version of the guide for ONC Certification. The link you provided is an older version. See https://www.hl7.org/fhir/us/core/basic-provenance.html
Last updated: Apr 12 2022 at 19:14 UTC
