The ONC Jira Core and Confluence support team will soon implement an account deactivation policy for all users who have not logged into the systems within the previous 90-days or more. To avoid the risk of having your account being deactivated, please immediately log into ONC Jira Core and Confluence as soon as possible.
Accounts that are deactivated will be retained, including historic activity. Users are able to reactivate their accounts using the correct credentials used prior to deactivation. If a user has forgotten their usernames or passwords, they can email onc-jira-questions@healthit.gov to request reactivation.
Reminder: Do not include any PHI or PII in JIRA. If you require 508 accessibility assistance, then please send an email to onc-jira-questions@healthit.gov
Login Support: If you encounter a captcha prompt, login issues, or believe your account may be deactivated and require assistance, please send an email to onc-jira-questions@healthit.gov
13 Comments
Anonymous
Remember that FHIR resources are but a new way to specify data containment (containers), not really a lot different than HL7 v2 or NCPDP messages or HL7 CDA/CCD documents. That said, it's really cool that it also behaves as an API.
Anonymous
Work flow may be enabled by an orchestration of FHIR APIs in prescribed and predictable sequences.
Anonymous
As the industry improves workflow interoperability, how do you balance just-in-time CDS with the very real alert fatigue clinicians experience?
Anonymous
The question for platform developers (e.g., EHR systems), is whether they allow read only access or full read/write capabilities (e.g., via FHIR APIs)?
Anonymous
CommonWell incorporates business & legal interoperability frameworks to govern access to patient data. How does the SMART Health IT proect support business & legal interoperability?
Anonymous
An open API will allow an app ecosystem to flourish. CARIN alliance might help here...
Anonymous
Our challenge in using a number of FHIR test servers and sandboxes is that very few actually support FHIR AuditEvent and Provenance resources, to support assurance requirements for authenticity, audit and accountability. Note that this is a requirement specified in the FHIR Implementers Safety Checklist (see #9): http://hl7.org/fhir/safety.html
Anonymous
Our EHR vendor exposes a FHIR API which our third-party integration partners are thrilled about, however, the EHR vendor offers no filtering via the API. For example a payer interface may only be allowed to access those patients attributed to the payer's population. This would seem to expose a large PHI issue if the payer is left to their own filtering. Any technical suggestions to lead our EHR to filter the API?
Anonymous
find a better vendor
Anonymous
FHIR based API specifications require the same amount of specificity and clarity as implementation guides/profiles based on other standards. Therefore, if there is need for a more filtered data set that should be consistently available across platforms, either a new or updated API specification needs to be created and agreed to by the industry so expectations on what data it will or can serve up will be clear to everybody using that vs. another API.
Anonymous
HIEs have the ability to send an aggregated clinical summary to the patient. It would help facilitate patient directed exchange if HIEs could be considered as a covered entity and/or allowed to share their information with the patient.
Anonymous
All these advances in new EHR versions are nice. But, it costs a lot for a provider to move to a newer version which has lot of functions that are listed on these slides. How can a medium or a small provider efficiently move to a newer version without causing a lot of money?
Anonymous
One of the panelists hit the nail on the head with the fact that API really only liquefies the data. In order for that data to be useful and trusted downstream we need robust data quality and feedback which are much more difficult to achieve. We should pick a few prioritized data use cases for API and concentrate on getting those right and of high quality. Trying to do too many use cases at once is much like trying to boil an ocean.