HTI1, the raw tweet stream on the next round of @ONC_HealthIT's CEHRT requirements

 My long overdue tweet-through of @ONC_HealthIT's #HTI1 rule begins. 

The stream is over 100 tweets long.  I'm making the raw data available first, I'll summarize it later.

Highlights: Certification has new requirements for decision support, patient demographics, and observation and electronic case reporting (eCR), + updates to USCDI. #HTI1 

The TOC provides more highlights:

ONC learned from experts on commenting on long documents. They make the text available in Word, and provide a comment template. @IHEIntl and @HL7 have benefited from comment templates for decades. #HTI1 

#HTI1 is a long rule, 62967 pages in length. I may have to take a break or two going through it. I'll likely segment the Decision Support Interventions (#DSI) as a separate topic for later. 

Thematically, @ONC_HealthIT references encouragement of economic growth through advancement of Health IT, health equity, and transparency in #HTI1 

In the theme of "there can be only one", yearly themed certification criteria are going away. There will only be ONE certification criteria as of #HTI1. This will avoid confusion, and prior rules already made the need for upgrading mandatory under conditions of certification. 

The first change of #HTI1 is the switch from USCDI v1 to USCDI v3. The jump of two versions may surprise some, but I honestly don't see it as being that big of a deal. The advancement of USCDI is done quite well and is very transparent. See

United States Core Data for Interoperability (USCDI)Please checkout the landing page of United States Core Data Interoperability (USCDI)https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi

Another possible double promotion in #HTI1 is from the C-CDA Companion Guide Release 2.0 to Release 4.0 if HL7 finishes it in time, or Release 3.0 if not. Again, I'm all for this.

Although seeing 2 in a row makes me wonder about the rest... like promotions in brain candy SciFi 

Another slew of #HTI1 updates to terminology standards in §170.207
(a) Problems
(c) Laboratory tests
(d) Medications
(e) Immunizations
(f) Race & ethnicity
(m) Numerical references
(n) Sex
(o) SOGI data
(p) Social, psych & behavioral data
(r) Provider type
(s) Patient insurance 

These #HTI terminology changes will impact §170.315 (a,b,c and f).

There's also a name change from in §170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” 

So far, I'm likely to be largely supportive of these changes in #HTI1. Like many, I've long been an advocate of keeping the terminology used in #HealthIT systems up to date on a regular basis. If this is a challenge for your Health IT vendor, you need a new one. 

Electronic case reporting will get a deeper dive later in my review of #HTI1. @ONC_HealthIT chose NOT to make a choice between #FHIR and @HL7 CDA for eCase reporting, in fact, it appears to NOT even choose a standard, saying "consistent with" where both CDA & FHIR options exist 

If you saw the HIMSS interop showcase demonstration of eCase Reporting with FHIR, what you mostly saw was slideware. That's because many are still working towards it, but have presently deployed CDA versions. Thus, the #HTI1 choice seems appropriate as it ... 

... allows the industry to move towards FHIR for eCase reporting, yet leaves them with a CDA standards based solution for now so that those certifying under #HTI1 can proceed forward with both. In a few years, I suspect only FHIR will be supported. 

Someone needs to understand that #HTI1 sets a #FHIR under eCR, and that folks implementing eCR solutions need to move faster in getting FHIR deployed. 

I'll talk more about #HTI1 #eCR in more detail later, just like I will with Decision Support Interventions #DSI. These are both topics requiring focus and detail. 

In #HTI1: **predictive decision support intervention** #DSI "means technology intended to support decision-making based on algorithms or models that derive relationships from ... data ... used to produce ..., prediction, classification, recommendation, evaluation, or analysis.

"intervention risk management" is a key phrase in the #DSI discussions in #HTI1.
"We propose three intervention risk management practices: (1) risk analysis, (2) risk mitigation, and (3) governance." 

#IRM ~= "... practices to promote transparency regarding how ... certified health IT analyzes and mitigates risks, at the organization level, ... developers establish policies & implement controls for governance, including ... data ... acquired, managed, and used ..."#HIT1

I had to jump ahead just to understand the implications of what appears in the introduction. I'm really only at page 22 of the intro in #HTI1 but had to move ahead 100+ pages just to understand what "intervention risk management" (#IRM) was in @ONC_HealthIT's collective minds. 

Back to simple stuff in #HTI1:
Network Time Protocol (NTP), yes, version? Pick one. Any currently implemented version is likely good enough. I agree. 

Next up: FHIR US Core v6.0 if ready in time, otherwise v5.0.1. If you were counting, that's three double promotions in #HTI1. I think this shows some of the challenges @ONC_HealthIT has in keeping the standards and related guides updated. Still not opposed though. 

Note, that's FHIR US Core, not Core FHIR that's being updated to version 6.0 in #HTI1. So far, I've found no mention of FHIR R4B either via search, so I'm assuming it's NOT to be (or 4B). 

SMART on FHIR only gets a single promotion in #HTI1, from v1 to v2. And tokens get to last only an hour. And endpoint URLs must be published.

Sounds good so far. 

So, in #HTI1 Patient Demographics changes to "Patient Demographics and Observations" in apparent deference to people who think some of the SOGI or other observations aren't demographic data. 

My dictionary says demographics are: "statistical data relating to the population and particular groups within it." It's also correct that some of these are "observations". It's not a hill I will die on, but it feels stupid. The former is correct and need not change in #HTI1 

On the other hand, I'm very concerned about "Sex for Clinical Use", because right now this seems to be a reversion to "birth sex" or something, and it's VERY ill-defined.

There are numerous sexual characteristics that are relevant for clinical use & these vary based on context. 

Are we talking about genes? Endocrinology? Organs?
In the days of ANSI/HITSP, somewhere we enumerated a dozen clinically significant gender/sex related aspects which might have clinical relevance based on context. #HTI1 takes too simple an approach for an important topic. 

If you want to get clinical, then damn it all, get clinical in #HTI1. This is NOWHERE close to clinical:

* Female
* Male
* Unknown
* Something else, please specify

The side effect of this data element in #HTI1, given lack of specificity addressing real concerns of Lab, Imaging, Procedures and Clinical Testing is to enable providers to assign gender as they see it. It's NOT clinical & likely to be abused in parental (I know better) form. 

The other danger is that this uses the same terminology with contextually sensitive definitions. This is completely inappropriate for how to use terminology. The definition of the term DOES NOT change with context. #HTI1 should NOT go down this path. 

On a positive note, two additional demographics (NOTE, I don't call them observations, though some might argue with me) including pronouns and name to use for the patient are included under this same section. So, this part of #HTI1 is not all bad. 

Transitions of care is being updated in #HTI1 to align with USCDI v3. This is pretty much a no-brainer that I fully support (except for Sex for Clinical Use #SFCU). 

#HTI1 proposes to add the ability to tag data as being restricted:
(14) Patient requested restrictions.
i) .. enable a user to flag whether such data needs to be restricted ... used or disclosed as set forth in 45 CFR § 164.522;
ii) Prevent any data flagged ... from ... use ... 

#HTI1 presents a reasonable first approach at enabling fine-grained sensitive data tagging. The key challenge for many #HealthIT providers is figuring out how to implement it. ... 

One approach to implementing #HTI1 fine-grained sensitive data tagging is to have a way to communicate authorizations and purpose of use to the data access tier, and let it provide only what is authorized. 

... been there ... released it even. It's perfectly reasonable, if a little invasive.

The restricted access of #HTI1 is very much aligned to support 45 CFR 164.522 (see law.cornell.edu/cfr/text/45/16…), and that gives you hints about tagging.

So does #FHIR:

https://hl7.org/fhir/R4/security-labels.html

Finally in this first section, #HIT1 proposes "to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers ... 

OK, Section 1 of the executive summary done, only 4 more sections to go until we get to the real meat. So far I'm on page 27 of 629 in #HTI1. This isn't so bad is it?

;-) 

The next four sections of #HTI1 actually go quickly:

2. Basically proposes that once a component certified, developers have to keep up with @ONC_HealthIT rules for certification, and must provide it in a timely manner.

Section 3 of the summary addresses how @ONC_HealthIT corrects an oversight on how continuous real-world testing is tracked.

"by requiring health IT developers to include in their real world testing results report the newer version of those certified Health IT Module(s) ..." 

#HTI1 adds 9 CEHRT measures
1. C-CDAs obtained by Mechanism
2. C-CDA reconcilliation
3. Apps Supported
4. Use of FHIR in Apps &
5. " in Bulk Data Access
6. Electronic Health Information Export
7. Immunization Submitted to IIS &
8. " History/Forecasts
9. Individuals’ Access 

The devil will be in the details of those measures. Is what they are asking for reasonable? Perhaps even knowable? The system best able to count C-CDAs may not have a clue about mechanism of exchange. This will be an area for deeper scrutiny of #HTI1 for EHR vendors. 

Table 2 on Page 365 of the word document provides a table of measures:

Section 5 is a continuation of @ONC_HealthIT's efforts to differentiate provider organizations and the like (e.g., supporting consultant organizations) who develop certified apps from commercial entities who develop them commercially in its defining a #HealthIT developer in #HTI1 

And finally under #HTI1, QHINs and their participants get to focus on being networks using QTF and don't have to offer alternatives... or worry about a couple of other details.

In other words, QTF / QHIN / TECFA is the way of the future, and we aren't going back ...

#HTI1 

OK, we've finished the #HTI1 executive summary at page 32 of this monstor rule, and are about to get to my favorite part:

.
.
. skipping
.
.

I've just skipped a dozen pages of background and are now reading about the CEHRT program updates.  

That starts around page 44, but with more electronic magic I'm moving ahead to page 599: The rule itself

The executive summary gives me a briefing of what I'm about to review next. From page 44 to 599 is a bunch of explanation of what the regulators writing #HTI1 were thinking. 

By skipping that (but going back to it as necessary), I can avoid their influence for another 30 pages, and "The #HTI1 Rule" is what my folks have to abide by, the preface is explanation and justification for it. 

In the #HTI1 rule, @ONC_HealthIT updates its definitions first (always good practice). 2015 goes away, Base EHR and Certification criteria stay with the year modifer.

Revised certification criteria is defined as one might expect, but with the formality of regulation. 

For some reason, #HTI1 defined "Provide":

"Provide means the action or actions taken by a health IT developer of certified Health IT Modules to make the certified health IT available to its customers."

I'm unsure why "make available for use, supply" was insufficient (Oxford) 

Predictive decision support intervention = tech intended to support decision-making based on algorithms ... that derive relationships from training ... data ... used to produce an output ... related to ... prediction, classification, recommendation, evaluation, or analysis. #HTI1 

This definition is broken. I've written and worked on ML-based systems using training data. I've also read the Alignment Problem by Brian Christian (see amzn.to/3owgBkj), and the thematic overiew in #HTI1 (including Health Equity), and so understand where this is going. 

https://amzn.to/3owgBkj

#HTI1 says "on algorithms or models that derive relationships from training or example data"

Examples:
1. Aggregate data about cause of death & demographics e.g., actuarial tables
2. 10 years of telemetry from speech recognition
3. a high frequency words list from clinical notes 

4. An X-ray image database
5. An EHR database with 10 years of history
6. an extraction of articles from the national library of medicine or other clinical sources
7. The ICD-10-CM index and text.
8-14. All of the aforementioned, annotated by experts.

#HTI1 

All of this is material I've personally worked with to develop algorithms and models. All of it is used to support decision making. All of it in #HealthIT 

My point being, most of what we do that adds values is based on "example data", and precious little of that is related to unexplained behavior in ML systems based on training.

Risk stratification
Natural Language Processing and tagging

Yet, it is also subject to bias... 

The key challenge in this definition for me right now is that it isn't restricting itself to clinical decision making, instead, any decision making. And that's where I think #HTI1 is headed a bit off the rails.

That may change in a few pages. 

But my gut tells me that ANY decision support aide could be considered by a lawyer to be subject to any #HTI1 rule using that definition. That may NOT promote better IT, it could suppress it, because folks scared about regs may avoid innovation after talking their lawyers. 

I'll see how it's used later, but my quick fix for #HTI1 would be to add clinical between "support" and "decision-making", restricting the use of it. It's very much aligned with the original intent, as the #DSI requirements are an alternative CDS approach for the first few years. 

Now we get to some simple stuff, and then raise my blood pressure again, and then go back to simple stuff in the second on standards at 45 CFR 170.20X in #HTI1. 

#HTI1 moves to C-CDA STU Companion Guide Release 3.
It also adopts FHIR and CDA standards for Electronic Case Reporting. These are solidly grounded, compatible with each other (developed by the same people even)

So far, so good. This is all solid advancement work. 

As much as I hate it that #ECR is way behind on the FHIR implementation side, I think @ONC_HealthIT made a good choice to allow both FHIR and C-CDA here in #HTI1, providing a path forward. 

For 45 CFR 170.207 Vocabulary standards for representing electronic health information,
almost all the advancement is good with ONE solid exception #HTI1. 

If you guessed that I'm going to start bitching about the stupidity of Sex for Clinical Use #SFCU, you aren't quite right. It's NOT the concept. It's the implementation.

The concept of needing to know about sex-linked traits for clinical care is totally appropriate. 

To tie it all back to two grossly overused terms "Male" and "Female" with meanings differing based on context (Clinical Use, Administrative Use, Lab Use, Imaging Use) operates on the context switching strength of human minds, rather than the clarity found in good terminology. 

A good terminology has a principal that you have a preferred term, it has a definition, possibly some alternative names (possibly in multiple languages), and a code. The DEFINITION does not change based on context. It always means what it means.

#HTI1 

In the proposed use, and selection of the standard for labeling "Sex for Clinical Use" in #HTI1 suggests LOINC codes, but no value set. Fine, I'll use 46909-0 Sex. loinc.org/46098-0/

Is that NOT what you meant? Get specific.

Oh, you mean these? healthit.gov/isa/sites/isa/…

LOINC 46098-0 SexIn LOINC, sex refers to the biological sex of an organism, which is most commonly determined based on anatomy and physiology or genetic (chr... See page for copyright and more information.https://loinc.org/46098-0/

Show me the codes, because using search.loinc.org, I cannot find them.

And the proposed answer sets in that list are a serious crock of **** because they overload the meaning of the terms male and female giving them different meanings in different contexts.

#HTI1 

http://search.loinc.org

Am I hot under the collar about how badly #SFCU is currently proposed #HTI1? You bet I am. It's because of how easily as proposed it could have the unintentional effects on LGBTQ+ care seekers who find themselves reading their labs & feeling misgendered on the basis of #SFCU 

That kind of psychological damage is triggering enough to cause death.

Use different, contextually relevant terms to deliver information about sex-linked patient traits relevant for laboratory, imaging, clinical testing or procedure information.

You will save lives. #HTI1 

OK, I'm going to take a short break from that rant on #SFCU in #HTI1. I'm sure you will hear more about it. 

One more note, I said unintended consequences. Because the basis of work of #SFCU is NOT a bad idea. It's a good one. But it needs a real effort, not slipshod use what we already think we know terms.

The reality is, if that's what you came up with, you didn't ask the experts. 

There was a whole meeting in ANSI/HITSP where this topic was discussed in detail more than a decade ago. I've had similar conversations with folks on the lab side, worked for a key company in imaging for a nearly a decade and a half. It's important in ways that M/F don't cover. 

Convene a group of stakeholders (different from the one that came up with the original inadequate proposal) to do better.

I said I was going to take a break from #SFCU. My brain can't. This is too important to family members and friends who could be negatively impacted. 

In #HTI1 this is a better definition than that for #SFCU and shows more of what is necessary:

Financial resource strain must be coded in accordance with, at a minimum, the version of LOINC ® codes ... attributed with the LOINC ® code 76513-1 and LOINC ® answer list ID LL3266-5. 

And now we move on to section 45 CFR 170.299.

Here, in #HTI1 I'm looking for ONE thing really. Is the referenced standard really an official standard. 

An THIS lone item in #HTI1 is not:
(41) HL7 FHIR® Data Segmentation for Privacy Implementation Guide: Version 1.0.0 – current – ci-build, December 1, 2022, IBR approved for § 170.205(o).

ci-builds are NOT approved HL7 standards. 

I SUSPECT, what happened here, is that a publishing deadline was missed on DS4P. The official publication is at hl7.org/fhir/uv/securi…, and is the one that SHOULD be referenced by #HTI1. 

http://hl7.org/fhir/uv/security-label-ds4p/

In a standards advancement program that is updating more than a dozen documents (if memory serves), missing one for #HTI1 is not a big deal. Note though, @ONC_HealthIT called out 2 others not quite ready with latest but should be out by final rule: C-CDA Companion Guide & US Core 

OK, onto the big section, the certification criteria.

#HCI1 clarifies that if you certify in year 1, and the standards advance, you must advance with them, and deliver the updated software to your customers. I suppose you have the option to stop certifying for that criteria... 

... but that is not clear, and the impacts on your customers is also unclear (wrt to CMS and other regulations), nor are the penalties for failure to follow this section. I'm hoping that's covered elsewhere in #HTI1 

I reject this implementation of #SFCU
(F) Sex for Clinical Use. Enable a patient’s sex for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026. 

Reserved section 45 CFR 170.315(a)(11) is replaced in #HTI with the #DSI efforts.

These words frighten me:

Module enables ... one or more predictive decision support interventions as defined in § 170.102 based on any of the data expressed in the standards in § 170.213 

It's clear from context that this is clinical decision support, but never stated in that fashion. And that's worrisome, because that lack of clarity opens up this section to whole new ways of interpreting the meaning of decision support. 

Arguably, all decision support systems used in #HealthIT impact care. However, until this rule, they weren't considered to be such in the rule, because they weren't Clinical Decision Support.

I'll go with my original recommendation for #HTI1: Insert clinical in the definition 

How does #DSI compare to prior CDS related content in CERHT in #HTI1?
New:
1. There's an attestation, is it predictive decision support?
2. Documented use of demographics (and obs), or SDOH, or Health Status data
3. 8 items reported about development
4. 5 performance measures 

#DSI #HTI1
1. The attestation makes failures MORE actionable by the regulation.
2. Documented use of data impacting health equity makes sense.

So far, so good. Now for the ugly (but not necessarily bad). 

Here is where some of the complaints begin on #DSI in #HTI1
(2) You must report on development:
(i) features of the intervention and test data.
(ii) process to ensure fairness
(iii) External validation

... 

And (3) update all of the aformentioned via maintenance.

#HTI1

(D) Futhermore, if
(1) it isn't available (for external validity, fairness) must show it is not available.
(2) developed by non-developers of certified Health IT, it could also be shown unavailable in that case 

One concern raised: There's lots of CDS in use that isn't certified that can plug into an EHR system. How is the certified developer responsible for the customer's use of uncertified CDS?

This should NOT be a concern of the CEHRT provider, but nowhere is that made clear.

#HTI1 

And the maintenance aspect includes:
validity and fairness in local data (rather than test data). I'm assuming what this means is an evaluation of ongoing validity and fairness in light of current use with local data, but how can this aspect of #DSI in #HTI1 be assessed? 

#DSI cannot be assessed w/o outcomes. In such testing, the outcomes need to be captured in controlled ways to ensure accuracy in the measures. What if the provider using the #DSI does not follow the same standards for assessing outcomes as used in development.

#HTI1 

This next aspect of #DSI development comes naturally to one that has worked for a vendor of Class 3 medical devices, and that applies to many EHR developers as well, but not all.

Intervention Risk Management #IRM is what you do already if you have a clue. 

Before developing an intervention, and throughout, you do risk analysis (I should do one for #SFCU because it is high risk).

#HTI1 makes that official policy for #HealthIT developers of CEHRT. 

You also do risk mitigation. I've never seen risk analysis without risk mitigation, but then perhaps I've been well trained.

Mitigation may involve cross-checks, fail-safes, et cetera.
#HTI1 #DSI 

Sometimes risk mitigation involves redesign for a less risky solution.

It also involves ongoing monitoring, and examining any anomalies or reported adverse events to see if they are caused by flaws, and then addressing them.

#HTI1 #DSI 

Finally, #HTI1 requires governance of #DSI: DOCUMENTED internal policies for how such systems are built, data is acquired and managed, and the system is designed to be safe, secure, fair, and valid. 

This is very similar to what some organizations already do for their quality management system and to some degree also safety enhanced design processes in 45 CFR 170.315(b)(3 and 4). #HTI1 #DSI 

If you are building a #DSI, and already have a QMS, then the documentation and process around that QMS likely includes some, if not all of what you need for reporting about #DSI.

#HTI1 

Missing in this though, are some essentials on testing for fairness in #DSI, for which no standards are referenced in #HTI1. I'm not sure that the standards have caught up to the science here. 

There's nuance and variance here, and I'm NOT a CDS developer. Yes, the requirements feel like a PIA for developers, and not all providers will see value in them either. I DO think they are important to get people thinking about health equity. #DSI #HTI1 

And the documentation requirements, when you get down to it from an implementation perspective are NOT arduous. I expect competent #HealthIT developers will have this available quickly for new #DSI interventions. It's the existing stuff that's worrisome. #HTI1 

My internet is internot right now, so #HTI1 tweets are being posted under one bar conditions 

And now internet is spelled with two e's, so I'm back with my read through of #HTI1.

We left off at #DSI, and are starting up again now, next up it patient requested restrictions. 

Patient Requested restrictions is rather straightforward in #HTI1.

For any data expressed in USCDI enable a user to flag restrictions for subsequent use or disclosure as set forth in 45 CFR § 164.522; and

Prevent flagged data from being included in a use or disclosure. 

As previously mentioned, FHIR has vocabulary to support such flags in Resource•meta•security. See hl7.org/fhir/R4/resour… and hl7.org/fhir/R4/securi…

For authentication purposes, purpose of use is likely a scoped context, but there are cases where break glass may be needed. 

https://hl7.org/fhir/R4/security-labels.html

https://hl7.org/fhir/R4/resource.html#Meta

I'm thinking @johnmoehrke probably has something about how to include a break-glass assertion in a FHIR query. It can work as a scope via SMART/OAuth, but perhaps there should be an alternative in the query to say "this is for emergency use".

#HTI1 

For ECR, honestly, I think that @ONC_HealthIT should change the wording from "consistent with" to "conforming to":
---
B) Create a case report consistent with at least one of the following standards:

(1) The eICR profile of HL7 FHIR eCR IG ...
or
(2) ... of the HL7 CDA eICR IG 

As expected, #HTI1 applies safety enhanced design requirements on #DSI. I will note that your Quality Management System **already** applies to certified components 

There's minor updates to (g)(10) related to linking that rule to the new standards selected in 215(a) (b)(1) and (d). This used to be just 215(a).

(b)(1) is FHIR US Core
(d) is Bulk Data Access (a.k.a. Flat FHIR).

#HTI1 

Under 170.402 Assurances, there's new language about having to upgrade components to match the current rule.
What's missing from #HTI1 is what should happen if a developer decides with withdraw a component rather than upgrade it because for some reason they are unable to update.

Under 170.404 APIs in #HTI1 "Certified API Developer must publish, at no charge, the service base URLs and related organizational details" using the FHIR Endpoint resource.

https://hl7.org/fhir/R4/Endpoint.html

Now we get to Insights in 170.407 of #HTI, this is going to be a bit longer, as the details are important.

As previously mentioned, there are 9 measures:
See the table at

Unroll available on Thread Reader

If you have more that 50 hospital users or 500 clinician users you must report on each of the 9 measures according to #HTI1 if you have a module certified to the specified criteria in the previous table. 

For #HTI1 Patient Acceess Insight 1 you must report:
Numerator 1: Number of patients w/ an encounter who accessed PHI through 3rd-parties using (g)(10), a patient portal via e(2), or vendor supplied app using (g)(10)
Numerator 2: Number accessed PHI regardless of encounter status 

#HTI Patient Access
Denominator 1: Number of patients who had an encounter in the reporting period.
Denominator 2: Number of patients who had an encounter and accessed via one of 3 methods.
Denominator 3: Number of patients who access PHI regardless of encounter status. 

NOTE: These measures are defined in the preamble of #HTI1 and DO NOT show up in regulatory text. Thus they are sub-regulatory. @ONC_HealthIT says you must report according to their specifications in the rule, but the specifications are not part of the regulation. 

But as I read the measure definitions in #HTI1 for Patient Access, they don't actually make sense because the numerators and denominators seem to be defined identically, and they don't specifically call out any stratifications, but it's clear that they want strata by access type. 

Here's the @ONC_HealthIT intent in #HTI1:
1. % of individuals with an encounter who access EHI by the type of method
2. % of individuals with an encounter who access EHI by at least one type of method
3. % of all individuals who access EHI by at least one type of method 

I'd want in #HTI1 insight 1:
1. # individuals w/ encounter during the reporting period.
2. # individuals w/ encounter & accessed PHI, stratified by method: Portal, 3rd party API, vendor app
3. # w/encounter accessing by any method.
4. 1-3 above, regardless of encounter status. 

Note in that stratified by method of access for #HTI1 Insight 1 is OVERLAPPING strata. An individual can appear in multiple strata. This is legit, just not often used feature of measures.
My #2 could be combined with #3 by addition of 4th stratum to say "any method". 

And I missed above that you also need to count # of individuals who COULD have access to EHI by any method type to compute the necessary percentages.

That COULD needs defining. Is is % of patient population? If so, how does one attribute an individual to a provider. #HTI1 

I see my GI specialist once every 3 years. I'm still his patient. I should be part of his denominator.

There needs to be a way to clearly define this, as it may also vary by specialty. I think CMS has some rules regarding attribution of patients to providers for VBC. #HTI1 

Going through the #HTI1 insights measures is tedious, because I have to math every one of them and then put on my measure developer hat and reword them.

I'm putting that on the back burner for now.

The rule is, you have to report. ONC will tell you how later. 

And #HTI1 need good advice about how to report on these 9 measure and how to make it clear. They've done an OK job, but lacking the actual measures makes it difficult. Be sure to comment on the preamble section III.F. Insights Condition and Maintenance of Certification p312-379 

Essentially, the 312-379 pages is all requests for comment about how to build good measures in #HTI, and it appears to need some work.

It also looks as if different people wrote sections for different measures, some consistency is needed across this material. 

Finally, I'd want to understand how and where these Insight measures for #HTI1 will be published. 

So, after jumping back into the #HTI1 preamble to skim 67 pages of text, I'm back to page 657.

Woo-hoo! More skipping but only two pages as not much has changed for § 170.523 Principles of proper conduct for ONC-ACBs. I just need to make sure it makes sense as a customer ... 

More skimming and skipping, but basically what I've already said about changes to information blocking covers what's in the actual rule.

#HTI1 

Things to come back for in new threads on #HTI1:
#DSI Decision Support Interventions
#HTInsights HTI1 Insight Measures
#SFCU Sex for Clinical Use follow-ups 

Hey @threadreaderapp please rollup my #HIT1 thread for myself and others.