There's a ton of small issues with spelling and grammar. It's what happens when all I have is 30 minutes to summarize everything I've just spent this 4-day weekend working on when I wasn't BBQ-ing or playing video games or reading cheap Sci-fi novels or something else.
For what it's worth, I've put over 80 hours of thought into reading, commenting on, and getting feedback from others on this particular rule (at least 10 of that this weekend).
------------
Stop producing such large rules every two to three years. Instead, consider adding smaller chunks of optional certification criteria more frequently (e.g., annually) to address specific topics (e.g., Public Health reporting, Scheduling, Subscriptions, et cetera) and give adequate time for implementation. Make a schedule for updating the rule (every three years), and stick to it, and leave out the kitchen sink. I love and hate the RFI questions. It's a good way to get out the vote, as it were, each big rule essentially being a presidential election. At the same time, it's extra work in an already huge endeavor that could be better served by an annual strategic RFI inquiry.
Please do discontinue year themed editions. The years were always wrongly applied in any case.
Yes, please do use the definition of "Revised Certification criteria" as defined in the proposed rule.
Please do adopt the most current published versions of USCDI, FHIR US Core and C-CDA Companion Guide, but provide a reasonable time period for implementation, no less than two years after publication of a final rule, and preferably 3.
Please use current guidance on Sex Parameters for Clinical Use (rather than the badly named Sex for Clinical Use) and do not treat this a patient observation. You could literally kill somebody if you mess this up and get it confused with Sex/Gender. Pay more attention to the parts of this that are truly important, which are those parts that are outside of Male - Typical and Female Typical, where these observations need MORE work.
Where the dictionary will do, please stop defining terms to mean something in conflict.
Provide already has an adequate dictionary definition, what more do you need? If there is something extra, please say it.
Demographics is already observations about a person useful for classification, why do you need to add observations to the name?
A singular fairness measure doesn't exist. Corbett-Savises and Goel describe 3 mechanisms to ensure fairness, and in one of these, 8 different measures; Berk et al give 7, and Corbett-Savises and Goel already describe area under the ROC Curve.
Others have shown that if effects differ between groups, fairness is not possible to establish. Read page 69 in the chapter on Fairness in "The Alignment Problem" by Brian Christian. Instead, report on how fairness was approached, and leave it as text.
There simply isn't a single number here yet, and there likely won't be for some time.
The new DSI criteria raises an issue of anti-competiviness that ONC should consider carefully. Certified algorithms have a higher regulatory bar. Uncertified algorithms can be used and built on APIs. Providers will use both. Consider carefully how the impact of requiring certified clinical decision support capabilities in a Base EHR (for which providers are incented by CMS) interacts with the need to promote competition. Ensure that this regulation and further like it don't create a requirement to generate a one-off feature to meet the criteria, but can instead promote and advance clinical decision support use in EHR systems in a fair and competetive way. In other words, ensure that certified clinical decision support has a percieved benefit other than just checking a box on a feature list for Base EHR system.
The Predictive decision support definition should include the word clinical:
Predictive decision support intervention means technology intended to support **clinical** decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.
Yeah, NTP is good enough as it is.
Start using industry standard ways of defining SLAs if you are going to start including SLAs such as performance times in a rule.
e.g., 95% of requests are completed in 15 minutes.
Please stop referencing draft content in section 299. Yes, I understand ONC is coordinating 10 or more different moving parts but if I can get it done in time as an unpaid volunteer, then people who are being paid by an ONC contract should be able to get it done in time as well. Otherwise, find other contractors who can. It feels sloppy.
Patient demographics and observations. Leave the title "Patient Demographics" They are all demographics. All demographics can be classified as observations about the patient. The name change does little to add clarity and instead promotes a distinction between classically concieved demographics and novel demographics that really makes that latter second class citizens in data collection.
DS4P sucks. It's not a good implementation guide, for CDA or for FHIR. It does little to explain how to use existing FHIR features to meet an existing need, it's been primarily driven by VA and one ambulatory vendor with an add-on product, with little adoption anywhere else. This work needs a do-over. The CDA work requires hundreds of lines of XML to do what the V3 RIM indended in one line. The FHIR work provides NO conformance criteria (profiles on uses of defined terminology on FHIR resources). There's nothing at all that addresses how to express break glass (essential when security tags are introduced with an exception for emergency care).
You really should look into what is going on with the IHE Patient Consent on FHIR (PCF) profile for future rulemaking.
Josh Mandel is awesome. I love some of what Argonaut has done. But honestly, Scheduling misses the boat for patient needs in a broad sense, and as currently specified only serves providers or payers with an existing relationship to a consumer needing an appointment. This needs more patient/consumer focused attention.
On RFI inquiries: ONC clearly needs someone to help them develop a plan for strategic adoption of standards. This is part marketing, part industry leadership, part alliance development, and then several parts execution in standards development. ONC focuses well on the latter part of this, but fails to accomplish it elsewhere. Argonaut and Da Vinci initiatives seem to have improved on the former parts, but there are still missing constituencies, especially those focused on patient empowerment. Some of those missing constituencies lack the marketing, industry leadership and standards awareness skills necessary to pull it off. ONC could help here, but the model used by Helios for Public Health is not one that seems to be developing the necessary industry leadership or momentum to drive itself forward without continued ONC and CDC support, and there's no such group as yet for patient empowering initiatives.
I like the focus that the TECFA manner allows QHIN and QHIN participants to focus on interoperability using nationally recognized standards. I think it could be more clearly written.
With regard to data segmentation, I've previously developed FHIR APIS for Certified EHR systems that allow data to be restricted at the patient, visit or observation level, limiting access for different users and purposes of use. The first step is to ensure that systems are able to tag the data in certain ways for a limited set of use cases, the second is to ensure that sensitive data assocaited with a "restricted" visit can be tied back to that visit so that the restricted associated with that visit (e.g., a self-pay visit) can be identified, and then lastly to ensure that only users with specific access (e.g. emergency care, or with access to restricted visits) can access such data, and only when those accesses are requested. There is no rocket science in this effort, but a lot of due dilligence. The key challenges are:
1. Ensuring that data access layer understand the
a. The associated user access priviledges and
b. Requested purpose of use
2. Only retrieve and return data that is allowed by 1a and 1b.
Most EHRs do NOT have or drive this capability into product. It's expensive to rework systems that weren't designed with this kind of security at the outset.
I would focus first on the "restricted" visit use case (e.g., self-pay visit).
1. Define the security flag associated with this visit.
2. Define the access roles and priviledges associated with the use of this information.
3. Define the application functions associated with the display of this information to a user in
a. The EHR
b. The PHR
c. treatment, payment and operations use cases.
d. Other disclosers.
4. Define the mechanism by which purpose of use is communicated via APIs (e.g., Scope, HTTP Category Header)
5. Define the application functions to support "break the glass functionality"
6. Define what happens when restricted data is requested but not authorized (e.g., via search).
a. Can a user know that restricted data exists?
b. Is this a feature available only to some users but not to others? (e.g., provider can know that restricted data exists that will be shown if they have break the glass privileges, but others will NOT be shown any indication).
0 comments:
Post a Comment