The skinny on the NoBlocking provisions of the CuresNPRM

In my own contribution to two reams, I put together a tweet stream of of over 150 tweets yesterday covering the information blocking related provisions of the Cures NPRM released by ONC during HIMSS week.  It's finally available from the Federal Register (but not yet "published"), and you can find the copy I used to summarize it from ONC here.  Next Monday you should be able to get to the web-based Federal Register content, and I've heard also that ONC will publish the Word version (which is going to be my source for comments given that I can modify electronic commenting tools I've developed for my HL7 work to gather feedback).

I'm NOT going to give the long details of that stream in this skinny post, but you can find the full set at tweet 18 in this 14-page unroll.

The information blocking provisions are the biggest addition to ONC oversight in terms of new regulation since inception of the CEHRT program, and also have potentially the biggest raw impact since then.  The provisions impact:

• Patients
• Data Providers
• Healthcare Providers
• Health Information Networks
• Health Information Exchanges
• Health IT Vendors
• Certified EHR Technology vendors

The most challenging aspects of this rule related to the fact that data blocking is essentially defined as a behavior that would restrict, restrain, discourage or otherwise prevent access to electronic health information UNLESS ... and then details 7 exceptions.  The exceptions together take about 17 pages of REGULATION, and somewhere around 180 pages of explanatory text in the preface.  That works out to about 2.5 pages per exception for the regulation alone, and around 25 pages of explanatory text per exception.

45 CFR 171 is all new content, and touches deeply on the rights and responsibilities of stakeholders with regard to exchange of electronic health information (EHI is the new acronym you need to learn), in ways that to my knowledge, are unprecedented in digital commerce.

In the main, past regulatory efforts regarding digital data tied to an individual have been related to what CANNOT flow, or in the cases of an individual, what data MUST flow to that individual.  In the case of the Information Blocking rule, the regulatory effort is about what must flow, and what legitimate reasons must exist that might inhibit that flow.  This is a very new approach.

The current challenge has to do with the fact that while the regulation touches on rights and responsibilities of stakeholders, it isn't written in a form that corresponds to any new or existing rights.  Instead, the form it is written in closely corresponds to the ruling law found in the 21st Century Cures Act.  This meets the test that all regulation must meet in being able to establish its ties back to the supporting legislation, but unfortunately doesn't make it very easy to understand.

I think my comments on this regulation are going to be an attempt to reinterpret it based on rights and responsibilities that appear based on the intent of the legislation.  But this is an area where I think I'm going to need to get some expert assistance.  Because while I can probably figure out the right model, I'm not entirely clear on the constraints that current law might impose in interpretation.

    Keith

A Brief summary of my IHE ACDC Profile and A4R Whitepaper Proposals

This week I'm at IHE meetings, and am submitting one of the first (and second) out-of-cycle proposals to IHE workgroups following the continuous development process adopted by IHE PCC and IT Infrastructure (and under consideration in QRPH).

The first of these is the ACDC (Assessment Curation and Data Collection Profile), which advances assessments in a new way that hopefully addresses the challenge that there are literally tens of thousands of assessment instruments that we'd like to be able to exchange in an interoperable manner.  The goal is here is to disconnect the encoding of assessment question and answer concepts from standardized vocabularies such as LOINC and SNOMED CT (which can take some time), yet still enable the capture of assessment data, and handle the encoding task in volume at scale using a mechanism that still needs some R&D.

The profile addresses two connected use cases: the process of assessment instrument acquisition (e.g., by a provider or vendor from an assessment instrument provider or curator), and the process of data collection through a singluar common resource, identified by it's Questionnaire canonical url (basically, a web accessible URL that also acts as a unique identifier).

The first use case allows the assessment instrument curator to make it possible for an assessment instrument acquirer to search for, and explore available instruments and metadata, and eventually get back enough information to make an acquisition decision, and after taking the necessary steps to obtain access (e.g., licensing, click-through, or whatever), to then acquire the executable content (the full Questionnaire resource).

The next use case allows a system that has access to use an executable assessment instrument to ask an assessor application to gather the essential data to make the assessment (it could be through a user interface that simply asked the provider or patient to answer some questions, or it could be more complex, involving answering questions based on available EHR data, or provide some adaptive responses based on other data).  The response to this inquiry would be something like a Bundle containing a) the QuestionnaireResponse, new resources that may have been created as a result of processing the Questionnaire, and perhaps some ClinicalImpression resources that provide the assessment evaluation.

For example, a questionnaire implementing APGAR Score might result in one QuestionnaireResponse resource, and six ClinicalImpression resources, one each for the scores associated with the 5 components of the APGAR score (respiration, heart rate, muscle tone, reflex response and color) and the overall APGAR score result (the sum of all the component scores).

Assessment instruments are commonly used to collect data essential in clinical research regarding a patient's current cognitive or functional status, data related to social determinants of health at the start of a research program, or during the course of research (to determine patient progress).  They are also used to collect data about patient reported outcomes, most often at the end of the research intervention, but perhaps also periodically (also to assess progress).

As we look at the R&D effort that is undertaken to address the scaling problem, we'll be keeping track of our findings regarding what efforts we attempt, and our success in addressing the scaling problem, and will report this in the Assessments for Research (A4R) white paper.  The purpose of doing the white paper gives us the opportunity to explore different approaches and publicize our findings in a way that helps us drive forward progress on the scaling problem associated with encoding assessment instruments in an interoperable manner.

Some thoughts as we've discussed this profile thus far:

1. It's important to classify assessment data elements by a set of categories that might be important for research.  The hierarchical structure of the Questionnaire allows for groups which enable us to introduce groups that can be used to record classification codes.  For example, if one is performing research on alcohol use, one might be interested in seeking a wide variety of data from multiple assessment instruments.  Enabling use of classification codes in the Questionnaire will enable groups of related questions from multiple instruments to be identified.
2. How should automated pre-population of responses be addressed.  For example, in cases where there is sufficient data in an EHR system to answer common questions re: Age, gender, et cetera, how might this be enabled in the encoding of the questionnaire resource.

A lot of what goes into these proposals is based on work on assessments and automated data capture for research that started in IHE in 2006 on the RFD profile, in 2007 in the Assessments work done by Patient Care Coordination, and continued through ONC efforts on Structured Data Capture in 2012 (which greatly influenced the work of the FHIR Questionnaire and QuestionnaireResponse resources), and current work being done on Patient Reported Outcomes in FHIR by HL7.

As John Moehrke said, this work won't be "Done Dirt Cheap", which also means it likely also won't be a dirty deed that doesn't get the job done either.  I think we're about to rock on assessments.

---

Update: Both proposals were accepted today. More later as the work progresses.

The short and long of the PatientAccess rule

I never did finish up my regulatory summary post on the patient access rule last week, even though I finished reading the regulation text on Monday of last week. So I'm going to combine that with the detail review.  While the rule still hasn't been published in the Federal Register, you can find the preprint from CMS here.

The Short of It

This is what the reg says, and my responses to it. I start there because I don't want to anchor myself in the regulator's thinking just yet. It's also a LOT less text to read.  

Patient Access

Think of "mom" below as Medicare enrollee, and Kingle as Medicaid enrollee. These are real people for me, which helps me to think about the impacts of the rule.  

Patient Access for Mom

Mom's MA organization has to provide APIs that allow her to use an app after mom approves it to access standardized claim data, adjudications, appeals, provider payments (remittances) and co-payments (cost-sharing) within one business day of claim processing. This is an API form of an EOB essentially, but CMS doesn't use that phrase anywhere in the rule, however see how they describe things here.

Mom can also get standardized encounter data within 1 day, provider directory data, including names, addresses, and phone numbers within 30 days of update, and clinical data and lab results within one day.

And because Mom is also covered by a Part D plan, she'll be able to get information about medications covered too and pharmacy directory data, and formularies,

All using the standards that are adopted by the Secretary at 45 CFR 170.215, which includes FHIR DSTU2, ARCH, Argonaut Data Query, SMART, OIDC and FHIR STU3 ... or some more advanced version of the standards unless specifically prohibited; what @HealthIT_Policy (Steve Posnack) calls raising the upper bar.

Mom can tell her Medicare advantage organization to go get data from her previous plan up to five years after changing the plan.

MA providers have to participate in a trusted exchange where they can exchange this data.

Patient Access for Kingle

Now, Kingle, a Medicaid beneficiary I know basically gets the same rights as Mom, because the States have to do this for them too. And just like Mom, Kingle gets access to the same data. With all the same aforementions and aforesaids thereunto pertaining.

And MA and States must provide web sites in which mom and Kingle can get all the information they need about this stuff, including their rights, and how to bitch to the OCR and the FTC if need be.

And 438.242 of the rule says that Health Information Systems must "Participate in a trusted exchange network" which exchanges health information, supports secure messaging or query between payers, providers and PATIENTS.

Patient Access for Any Life CMS Touches

All of the aforemented, aforesaids and thereuntos apply to CHIP beneficiaries as well, and qualified health plan members in federally facilitated exchanges (27 states), and some other stuff. So, basically, if the Feds give money to states or MA organizations to provide healthcare, they have to give mom, Kingle or any other beneficiary access to their data.=

Conditions of Participation

Conditions of Participation translated means if you get paid by CMS funding, you have to do this. If you happen to be a hospital participating in Medicare or Medicaid and you have an EHR (just about all of them), implementing HL7 V2.5.1 ADT messages (all of them), then the system must send notifications with patient name, doctor, hospital and diagnosis.

Critical Access Hospitals and Psychiatric hospitals have the same responsibilities as other hospitals. The reason for separating these out is so that CMS can change there mind about them individually in the final rule, because some of them might complain very loudly, and this gives CMS a way to codify their requirements differently.

Qualified Health Plans in Federally funded (facilitated) Exchanges have to do the same thing as MA, States, CHIP plans, et cetera, or get a special exception and have a good reason for non-compliance and a timeline for correction. And even then, there special exception becomes public.

Thus ends my analysis of the rule itself, and you know just about everything I do about what the proposed regulation says.

The Long of It

This is where I analyze the front matter, which contains the regulator's justifications for the regulation content. In here, you also find the alternatives which they consider (and which are still fair game in the final text), and the other questions they are specifically asking you to respond to, and what they say that aren't going to do, or may do later. This is good reading, but I don't want to read it first, because I want to have my own thoughts in front of me before I read theirs.

For whom the bell tolls

The Patient Access rule applies to Medicare/Medicaid Fee for Service, CHIP and CHIP entities, Medicare Advantage, Managed Care, prepaid inpatient & ambulatory health plans, and qualified health plans in federally facilitated exchanges. Nearly anywhere CMS writes a check, as best I can figure.

All patients can have their clinical and administrative data travel with them, with complete records available to their providers, and Payers should be able to exchange with other payers. Of course, APIs play a significant role "without special effort". Everyone in government’s definition of  interoperability references the now famous “without special effort” IEEE text which I was writing about here in 2013.

APIs will use FHIR as the Standard

The most important part of the history in this section for me is the call out of the Da Vinci Project Coverage Requirements Discovery (CRD) profile with CMS, and work on prior auth for CPAP.  Between that and the recent letter of thanks that CMS sent to HL7, we can get a very strong idea of some of the directions of CMS thinking around APIs for Medicare/Medicaid in the future.  There's also some potential here for FHIR to supplant X12N EDI transactions for HIPAA in the future, and some appetite in the industry for the same ... just as a related trend to think about.

HIPAA allows for APIs

In a somewhat long winded response, @CMSGov reminds covered entities that patients are not covered entities and that they can direct covered entities to third parties (and Apps by association) by right under HIPAA (as revised by the OmniBus regs). You might recall my own observations on the impacts of the HIPAA Bus and e-mail, well, they apply equally to APIs according to this text (and my own analysis).

Everyone to Use FHIR

The rule would require “MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs (excluding issuers of SADPs)” use HL7 FHIR for APIs. CMS intends “to prohibit use of alternative technical standards that could potentially be used for these same data classes and elements, as well as earlier versions of the adopted standards named in 42 CFR 423.160 [the HIPAA ePrescribing standards], 45 CFR 162 [the HIPAA transaction standards] & proposed at 45 CFR 170.213” 

CMS also reports a “wish to assure stakeholders that the API standards required of ...[that list of payees]... under this proposal would be consistent with the API standards proposed by ONC [in the Cures rule]."  Where no standards are elsewhere mandated and HIPAA transaction standards are the only ones available, the rule would “require entities subject to these proposals to use these HIPAA standards when making data available through the API.”  In payer to payer information exchanges, they could still use HIPAA trasaction standards they already have or could use FHIR et. al. for exchange required by the rule, not throwing the baby out with the bathwater.

Pages 32-57 is mostly about use of FHIR and APIs and some not quite so new stuff already in regs from CMS.  If you read the cures rule, you'll see a lot of similar discussion here.  It's mostly background though.  The key point is that the APIs are going to be FHIR, same set as selected by ONC (though I imagine some thought will be needed around claims, and EOB statements as that work progresses in HL7).

Page 57 starts the discussion from CMS’s view on standards update process, and is following ONC's lead in the Cures rule.

The open API in the rule “would include: adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where available).” Simplifying that for the non-EDI crowd: Claims data is what docs send to payers, cost/remittance/cost-sharing is what patients get from insurers on an EOB statement, and clinical data what providers put in their EHR (using USCDI).  Also available via APIs would be provider directories and medication formulary data. 

CMS has to say much of the same things over and over because different regulations apply to different entities they pay under programs legislated at different times, and some require slightly different variations because of those variations.

Miscellaneous but Important Short Topics

Timelines

Much of the rule is to be applicable by January 1, 2020, but for some (CHIP), by July 1, 2020. That’s not a typo. Shot and a beer that the industry response is going to push for a later date is a bet I think nobody will take, maybe we should bet on the actual date appearing in the final rule.  Given rule deadlines, Jan 1, 2020 is very short notice.  The rule still hasn't been published, let's say it is on March 1, then the comment period goes through March and April, and then CMS can start putting together it's responses afterwards.  I'd allow for another 60 days or so for that to get done, and it still has to go through another week or more at OMB before publication as an FR.  So, call it about 90 days total.  That means an FR could show up in the late July early August time frame, with an implementation date 6 months away?  That seems VERY tight, especially for the payer space.  I'm guessing those dates will move in response to industry push back.

Color Commentary

CMS claims patient access is “designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it.”

It sure as hell will as I read it!

This kind of data will make unprecedented price transparency available to patients through APIs, and the third parties they wish to share it with under the rule. Imagine if you will what one could do with EOB and price data from millions of patients, think of intervention studies where the intervention is a change in health plan for example.  Think about what patients who pool their data with others might learn:  Under plan 1, doctor D charges X$ for procedure P, what does doctor D charge under plan 2?  What does doctor E charge under plan 1?  How many procedures P do doctors D and E do?  What's the cost of procedure Q? As I think these parts through, this could be earth-shattering to enable patient cost controls, almost makes me sorry to not be on Medicare just yet.

The scary part is who else will try to take advantage of it... and I see many opportunities for abuse here... especially in terms of resale of patient data gathered by apps, even anonymized or aggregated.  I think much thought is needed on the unforeseen consequences, and a risk analysis on these components is something I think the industry should certainly do in response, with feedback to CMS on the results.

Trusted Exchange Network

As I read through the section on Trusted Exchange Networks in in the rule, I don't see enough words for me to equivilate [yes, that’s a word] it to the same as trusted exchange framework, though I see parallels. A Framework is not a network (just ask someone from Carequality/Sequoia if they are a network).  I think there will certainly be tie-ins between the two, but I don't think they are the same thing.

Complexity in the Rule

CMS comments on the need to align Medicare and Medicaid to support care, but the rule also makes it clear that CMS needs to align many programs (MA, part D, CHIP, FFE and others) on standards. A better rule structure with common content might improve compliance.  This, as I said earlier has in part to do with the legislative background associated with CMS responsibilities under so many programs.  I think a "Chinese Menu" approach might be applicable here though, where, like ONC, CMS creates a list of requirements that other sections reference as appropriate.

(Some) States need to Up there Game on Dual Eligible Patients

Under Increasing the frequency of federal-state data exchanges for dually eligible individuals CMS is telling states that do this monthly is that daily exchange is necessary, and will help them cut costs and improve patient outcomes for both CMS AND the states that are behind.

The new "Wall of Shame"

CMS runs through background on Information Blocking from page 126 through 135, and the fact that CMS will publish attestations regarding information exchange publicly on the three questions in section I here.

NPPES to support Electronic Contact Information

Under the rule, CMS would use its NPI provider directory to publish digital contact information for both individuals and facilities eliminating the problem I described here.  This was a thought that I've dropped in various suggestion boxes of many years, and was discussed very early on in the Direct project.

ADT Notifications

Under conditions of participation for hospitals, the rule would require some form of notification (i.e. a functional capability) to be give to other providers upon patient admit, transfer or discharge, but not requiring a specific standard for it, for those providers with 2015 CERHT having HL7 V2.5.1 ADT messages (see 170.299(f)(2)).  Special call-outs for psychiatric hospitals and critical access hospitals allow CMS to use same or different requirements for these kinds facilities in the final rule.  This is a smart move by CMS to alleviate the challenges that might be raised by those institutions with special requirements.

Requests for Information

The last part of the Patient Access NPRM isn't about rules, but rather questions that CMS wants to get feedback on before it makes more policy in this space.  There are three key topics, and I'd suggest you read and respond to these:

1. Supports for Long-term and Post-Acute Care
2. Patient Matching
3. Innovation Center Models for Advancement

The End (for Now)

And that takes us to the end of the interesting stuff in the front matter.  The rest (from page 172 to the start of the regulation) cover regulatory disclosures that talk about costs of the rule, data collection, and other stuff that is required of the regulatory, but generally very difficult to analyze without deep economic expertise.  However, if you have that ability, and provide feedback in this space (not many do), it would probably wake someone up.

Functional and Structural in the context of FHIR Resources

I often get into discussions of Functional and Structural roles in terms of security, because that is where roles most often get discussed.  In this space,

1. Structural role depends on is who you are, or what specific skills or licensing you have attained
2. Functional role depends on how you behave, what you are doing.

In the case of a taxi driver delivering a baby, their structural role is taxi driver, that is how they are licensed. But their functional role might be "attending OB", in terms of what role they are taking on.  In the context of

Structural roles describe static capabilities, functional roles dynamic behaviors.

I came upon the realization today that these concepts can also be applied to "Resources" in FHIR.  Here's the context: How should one represent a transcription on a diagnostic test or procedure reported as a text report via an HL7 ORU message?

Is this DocumentReference, because basically the content is a document?  Or should it be represented as a DiagnosticReport because the content is a report on a diagnostic test?

The DocumentReference resource has to do with what it is, it's physical structure and components.  The DiagnosticReport focuses more on the functionality it provides, and the purposes and ways it would be expected to behave (e.g., the state diagram that might be associated with it).  See 4+1 Architectural View Model for yet another way to look at these distinctions.

My answer in this case, to this either/or question, is essential my father's default answer to any either/or question. Yes.

The report COULD be accessed via DocumentReference, and in this case, the API capabilities would be focused on the "document-ness" of the content.  It COULD also be accessed via DiagnosticReport, and the API capabilities would be focused on the "diagnostic-ness" of the content.

In the Venn diagram describing these thing, some documents are diagnostic reports (and others are different kinds of things, e.g., scans of identity cards), and some diagnostic reports are documents (and others are simply combinations of structured data that eventually can be rendered in document form, but don't exist natively in that form).

And FHIR is simply the interface that is provided to access all these things, and when a thing has dual nature, well, why not make it accessible either way.

The ONC Information Blocking Rule

 

The Cures NPRM added a new section to regulations that covers not just certified EHR technology, but the behaviors of organizations in possession of patient data with regard to information exchange, which I covered earlier this week in my #NoBlocking tweet stream.

The rule itself is a difficult read, the preface, I hope is a lot easier to comprehend. Remember, I read the regulation text first, I haven't gotten to the preface yet.  It gives me an opportunity to get my own impression of the regulations without achoring myself on ONC's justifications for why they did what they did.  I'll be coming back to these again after going through the front matter.

Generally, as I understand this section, ONC is seeking to ensure that all parties who want to use APIs to enable access to patient data (with the patient's authorization) are treated fairly and equally, and that bars to competition are not raised on the basis of access to patient data.

By all parties, ONC applies this section (45 CFR 171) to health care providers, health IT developers of certified products (including API developers and technology suppliers), health information exchanges and networks.  So, if you are a user, developer, reseller, or other third party that essentially deals with deploying, maintaining, using, updating, or otherwise providing access to software certified to use APIs to facilitate the exchange of patient data, this applies to you.

The whole point of this rule authorized under the Cures Act is to prevent ANYONE from interfering with, preventing or discouraging exchange of health data.  ONC makes it clear, ignorance of the requirements aren't an excuse (knows or SHOULD KNOW is the specific wording).  Now, it's pretty clear that ONC understands that there are reasons to prevent access to data, either permanently or temporarily, and that some essential industry behaviors will be seen by some as "information blocking".  The very fact that organizations are making money from healthcare is anathema to some, and so ONC is working hard to try to figure out how to explain the behaviors that aren't considered to be information blocking by listing out the various practices that are allowed.  This is a difficult task for an organization that doesn't engage in business, and I suspect that this part of the Cures NPRM will be the most commented on.

There are a list of things that organizations are permitted, anything not explicitly permitted is at the very least behavior that could be questioned with regard to "information blocking", and this is a case where ONC is the referee who gets to make the decision.

1. Preventing harm
2. Promoting privacy and security
3. Recovering reasonable costs incurred,
4. Avoiding infeasibility,
5. Allowing for reasonable and non-discriminatory licensing fees
6. Maintenance and updates.

Arian Malec presents an excellent sound track and interesting commentary on items 3 and 5 above and a great follow up on contractual requirements that highlight some of the most difficult parts of 45 CFR 171.

Many of exceptions are pretty straightforward to understand.  The first of these falls clearly within the pervue of providers under "do no harm", and is also aligned with HIPAA.  HIPAA and the no blocking rule rule are also aligned on promoting privacy and security (my #2 above).  And lastly, allowing information providers to take information offline temporarily for maintenance and updates is something we all expect and should allow.

Sections 3-5 have to address API providers, but also those who might need to respond to a request for health information.  I think this section is having a little bit of an identity crisis simply because it has to cover so much territory.  I think ONC needs to divest some parts of this section which are already covered under HIPAA (perhaps even by referencing that regulation).  This could help greatly, and in fact make it easier to maintain this section of the regulation.

Avoiding infeasibility addresses a host of issues and concerns.  Many API providers today for example, place limits on the amount of information that can be accessed in a single request, which could be viewed as "information blocking".  These are essential constraints in order to enable responsiveness in technology (returning all of the lab results for the past ten years for a single patient who has been very ill could take a VERY long time, and prevent others from accessing data depending on implementation).  But this section also has to address other sorts of requests for information, which is part of  it's identity crisis.  In this section, ONC makes it very clear, using your access to electronic health information as a means to prevent competition or to force others into paying a fee to access it doesn't make a request for access infeasible.

So, health data is still a commodity under #NoBlocking, but no longer a strategic commodity that the "haves" can hold over the "have nots", and further more, treating it as such could be cause for a claim of "information blocking".  I'm pretty sure I'm in agreement with that general principle, but I'm also sure that this portion of the rule is going to be gone over (by me and others) with an extremely fine-toothed comb.

   Keith

My Comments on the HIPAA RFI

I thought I had missed my opportunity to comment on the HIPAA RFI, but saw a tweet about someone posting comments today, so I break from comments on other stuff to put together my thoughts in HIPAA.

0. HIPAA is seen as a barrier rather than promoting sharing of information to support care.  It needs revamping and probably renaming to change the perception.

1. Most covered entities with a certified EHR can provide data immediately and certainly within 24 hours through a portal or other means of access based on my own personal experience across more than a dozen institutions.  Payers also provide for online access with nearly immediate results.  Paper records, or full records that are part of the entire designated record set that are needed for more detailed review (usually to address issues in adjudication or eligibility of benefits) take for **** ever.  Payers are worse on requests that providers in my own experience.  Plans that are causing challenges (from the patient perspective) are more difficult to get data from than those that aren't.   There are variances across providers that is generally based on technical and infrastructure capacity.

2. In general, it is quite feasible to get the most important data within 24 hours.  The entire designated records set is harder to acquire, because that can include diagnostic reports in paper form, xrays and other imaging requiring storage of external media instead of download. 

3. Digital media and electronically available data should be available within 2 business days, paper or film original formats perhaps a bit longer but no more than a week, and any data in the Common clinical data set by a provider with a certified EHR should generally be available within 24 hours.

4. Ask instead what burdens would a shortened time frame relieve for patients, and the associated costs, and you will get a much more enlightened an appropriate answer.

5. I cannot speak to clearinghouses.

6. Yes, providers have challenges getting data for treatment, generally from other providers, often with the excuse "because HIPAA", although some also claim 42 CFR 2 preventes exchange due to over cautious risk tagging of data that MAY be covered by that regulation.

7. Yes, generally covered entities should be required to disclose PHI for verifiable treatment (without making "verifiable" hard, perhaps slightly more challenging than simple attestation, but not so challenging as to make this too difficult).  Verifiable proofs might be as simple as proofs based on existing treatment relationship (e.g. claims) or attempts to establish one (e.g., via prior auth tx) or facsimile copy of patient signature authorizing treatment, or established provider relationships.   I won't address P and O.

7a, this would improve  care coordination and case management, it would create some burdens to implement new requirements, but not insurmountable ones.  New administrative costs would eventually reduce burdens after implementation.

8. not addressed.

9. Doctors should be required to disclose information to other doctors in a treatment relationship for the purposes of treatment, regardless of electronic billing status.  This would challenge some implementations in that they would have to have a process to identify providers not using electronic billing (e.g., due to lack of NPI).  That could readily be addressed by requiring NPI be obtained by all providers regardless of whether or not they engage in electronic billing.

10. A verbal request would be acceptable from a known entity, but an unknown entity should be verified in some way, along with the existence of a treatment relationship.  Signed patient authorization of treatment (or facsimile copy) would be sufficient evidence, but other documentation or proofs of a treatment relationship might also be accepted.  Appropriate policies would be needed.

11-13. Not addressed.

14. Interaction with other laws such as 42 CFR part 2 should be addressed.  It will be a problem.

15. Appropriate policies should be created, with known entities possible getting easier treatment than unknown entities.  The providers should have a policy, and a means to document and enforce it.

18. Yes, this should be made more feasible and easier, and required.  I've seen requests sit for 30 days for these kinds of services.

19- end: Ran out of time.

The Cures NRPM

You will be getting a lot from me this week.  I'm going to start with the first part of the Cures Rule, prereleased by ONC and I'm just going through the regulatory text, rather than all the prefatory material.  That's next on my late night reading list (1000 pages is a lot to read, this cuts it down by at least 80%).

To start off with, some 2014 related materials were removed from the rule.  Thus stuff no longer applies now, so it's not material to any discussion.

Content Standards added include:

• C-CDA Templates for Clinical Notes R1 Companion Guide
• NCPDP Script Standard Implementation Guide, Version 2017071
• 2019 QRDA Category I Hospital Quality Reporting Implementation Guide
• 2019 QRDA Category III Eligible Clinicians & Professionals Quality Reporting Implementation Guide

API Standards (what we've all been waiting for include):

1. FHIR DSTU 2
2. API Resource Collection in Health (ARCH) (more on this in a bit)
3. Argonaut Data Query 1.0
4. SMART on FHIR
5. Open Id Connect
6. FHIR STU3
7. Consent2Share profiles (I'm guessing you are wondering what this is to).

Of these, 2 and 7 had me scratching my head.  #2 is pretty straightforward, just click the link.  It's a list of FHIR profiles that need to be supported according to the NPRM.  #7 was a downright bitch to locate, though I finally did.  I suspect that if John Moehrke had been awake, he could have found it a lot faster.  This is basically an STU3 profile of the FHIR Consent resource.  #6 and 7 basically mean that ONC is allowing STU3, but ONLY for the exchange of consent information, not allowing STU3 for anything not already covered by 1-3 above.

So, how did I do in my bet? If the proposed rule becomes the final rule, I lose it, but I picked the options correctly.  I still think my bet is sound, but I'll give it a 60% chance of being the final result, with the alternative being what we saw proposed this morning.  If I'd thought about it harder, I would have known that ONC couldn't have submitted a proposal with R4 because IT HADN'T been published at the time it was submitted to OMB, which still doesn't leave it out of the running.  The proposed rule text published by ONC does contain a reference to R4 in section 170.299.  My bet (and I'll know more tomorrow) is that the industry will push for R4 and the US Core specifications.

Even if they don't, ONC's changed the rules so that they (and you) can upgrade to newer standards, so that the rule can set both a lower and upper bar.

USCDI is something we are all going to have to become more familiar with.  I took my first look at it a year ago.  It's still not much more than the CCDS and a collection of C-CDA templates.  For the most part, there's nothing challenging here, it's just work for your engineers and validation staff.

There's additional guidance in the rule on how to use CCDA (see the companion guide link in the previous section), and on how to handle Assessment and Plan, Goals, Health Concerns, and UDI (device identifiers) data in the rule.  Expect test procedures to change (I imaging those folks are starting to think about what to change, but won't really get to work until the rule is final).  However, I don't expect a big lift here.

Section D; Conditions and Maintenance of Certification for Health IT Developers is brand new content for certification.  It applies to the organizations who certify product, and how they must behave, rather than what the product must do.  To summarize:

400: This is authorized by the Cures act.

401: As a developer you will attest to ONC that you won't block.  This is a regulatory form that basically makes it possible for you to be fined under the false claims acf if you say you won't and then you are found to do so (c.f. recent news), if I'm reading this correctly.  This is powerful stuff which makes enforcement possible by more than just ONC revoking a certification, the DOJ can get involved.

402: Prove it, and furthermore, don't do what other guys did (see the last link), and make getting that single patient data export document out easy peasy, and keep your records for 10 years, and you have 2 years to handle that patient data export change.

403: What I call the "No Gag Rule" clause says that a health IT developer cannot restrict communication regarding:

1. usability,
2. interoperability,
3. security,
4. user experience,
5. business practices,
6. ways in which the product has been used.

Anything is fair game to be communicated, including proprietary, confidential or IP content when the communication is about one or more of the above for communications:

1. required by law
2. regarding patient safety, to government agencies, accreditors or patient safety organizations,
3. about privacy and security to government agencies,
4. about information blocking to government agencies,
5. about certification non-compliances to ONC, an ONC-ACB 

Restrictions are permitted to or about:

1. contractors and employees,
2. non-user facing aspects,
3. IP except that screenshots ARE permitted with certain reasonable provisions, EXCEPT for cases of premarket testing and development until the product ships, after which they are subject to prior rules

And must notify (within 6 months) and make effective (within a year) that any existing contract provisions that contravene the above are basically null and void hereafter.

404: This section requires a close read by your staff involved in revenue generation from APIs.  Basically it says you have to disclose everything needed to use them, make clear how you are charging, be fair in the way you charge, not specifically designed to be anti-competitive, not require non-compete clauses, not require exclusivity or transfer of IP rights, or require reciprocation.

There are some other clauses in here as well, regarding "allowing production use" quickly, and publishing endpoint addresses for systems "in a computable format". 

405: Just as FDA requires post-market surveillance and corrective action, ONC is now requiring ongoing testing and maintenance for certified product, requiring the developer to make a plan, share it with ONC, execute it, and report on the results.  

And you've got 2 years to upgrade your products to the new standards.

406: The developer must attest to all of the aforemented, aforesaid, thereunto appertaining stuff at the time of certification and every six months thereafter, therefore becoming subject to additional enforcement opportunities by ONC and DOJ.

I'm not going to spend much time on section 500, as it mostly pertains to the operations of ACBs, but there's some impact on Health IT Vendors here to look at in this section, mostly in that adopting section D above ONC now has a responsibility to verify that section D is being complied with.  This means that they may perform surveillance about developer behavior in addition to product behavior.

And, as a result of that surveillance, ONC may also BAN a developer from the certification program based on their behavior, giving them yet more enforcement capabilities.

Section D is going to be the hardest discussed section in the industry, but I think in generally it is fairly written (if complex).  There's definitely some work that could be done to make the language simpler and easier to read.  A lot of that may already be written in the preface (which I have yet to read, I like to get my first opinions by reading the regulations, rather than the regulatory body's justifications for them).

I'll be covering what I call the "No Blocking" part of this rule later this week, as well as the Patient Access rule released by CMS.  NOTE: I'm reading the prerelease versions that were available from ONC (and CMS) prior to publication in the Federal Register.  I'll read those versions in my second full read through, just to see if there are any significant differences.

As always, I'm not a lawyer, and this is NOT legal advice, and you get what you paid for.  This also is my own opinion (as are all posts written here), and not the opinion of my employer nor any other organization I might have some affiliation with.  

Keith

My read through tweet streams can be found by searching my stream for #CuresNPRM, #PatientAccess and #NoBlocking.

Getting to Outcomes for PrecisionMedicine

I've been thinking about precision medicine and standards a lot lately for my day job.  One of the things I have to work out is how to prioritize what to work on, and how to develop a framework for that prioritization.

I like to work by evidence (objective criteria) rather than eminence (subjective criteria), and so I need some numbers.  Which means that I need measures.  In any process improvement effort, there are three fundamental kinds of measures that you can apply.

Structure

Measures that demonstrate appropriate systems, structures and processes are in place to support the outcome.

Process

Measures that demonstrated that processes to support the outcome are being executed.

Outcome

Measures of the outcome.

If I were to rank these measurements in terms of value and ability to move the needle on the scale, you've got bronze, silver and gold (a scoring system that works both by weight and by monetary value).

But, in my world, they also rank by time over which they are implemented.  You have to first have the infrastructure deployed (which means it must be available with support for the needed technology), and then the workflow designed, and the processes implemented and executed before you will see changes in outcomes.

Let me give you an example.  If you want to measure the impacts of Sexual Orientation and Gender Identity on health outcomes, you first need the standards to record that information readily available (structure), then you need to have processes designed to support the capture of that information (also a structure measure), then those processes need to be implemented and executed (process measures), and then you need standards designed to exchange that data (structure measures), the software available (structure) and configured to perform that exchange (process), and then data exchanged that includes SOGI to occur (process).  And then you can get to outcomes.

This is a pipeline that has 7 segments that need to be completed before we can use SOGI data in research (the desired outcome).  Working on any of these segments can proceed in parallel BUT that's challenging to coordinate.  Some of the work has already been done at the federal level to promote utilization of the standards for federal reporting for HRSA Health Center grantees (a.k.a. Federally Qualified Health Centers), but hasn't been included in requirements for other healthcare providers.  For example, birth sex (a signal that SOGI data is surely relevant) is part of the Common Clinical Data Set (CCDS, now know as USCDI) that MUST be able to be exchanged by EHR systems, but the SOGI data itself is NOT part of this definition, and so while it may be available in an EHR, neither the processes to capture, nor the C-CDA documents being exchanged may actually do anything with SOGI data.

There's two missing segments in this seven segment pipeline.  The necessary standards are there, the mechanism of exchange is there, the process for exchange exists, but implementing the workflow to capture the data isn't incented in any way by current regulations (which focus on USCDI exchange), nor is exchange of that data mandated.

So, I can identify where the work needs to be done, and I can assess (measure) even, how much work that is.

Now, compare this work to the effort associated with capturing data from wearables (e.g., blood pressure, heart rate, physical activity, blood glucose, sleep cycles, et cetera).  There's a lot more missing segments.  I know what that work is, and I can also estimate how much work there is here.

Now, suppose for the sake of argument that I needed to choose just one of these to work on.  How would I justify one over the other?  NOTE: This is completely for the sake of argument, and I've set up an arbitrary a/b scenario.  There's a reason for this.  If I can build a framework for making that decision, I can extend that framework in ways that allow me to make decisions about how to SPLIT the work and how much to invest in each.  That's just how math works.

So, how to get to prioritization. I need a different sort of evaluation and to measure in a different way.  What can I measure?  I can measure the quantity of research that might be enabled.  I could take a crack at, but it would at best be a guess on the impacts of that research to patient care, or cost.  I could look at the impacts of the diseases that research affects.

And then there's the missing link problem.  If there are 2 of 7 links missing before I can get to outcomes, what's the value of working on broken link 1 or broken link 2?

This is risk assessment turned on its head, as my friend Gila once put it, it's opportunity assessment.  But using the framework for risk assessment is still valid in this case, it's just that what you measure is different.

And now, I think I have the start of a sketch for the framework for my answer.

Time to do some more reading.

   Keith

HealthIT Interoperability isn't Simple

Let's start (as I'm often want to do), with a definition:

Ability of a system or a product to work with other systems or products without special effort on the part of the customer. Interoperability is made possible by the implementation of standards. -- IEEE Standards Glossary

Now, let's think about what the phrase "special effort" means.  Thesaurus.com suggests "fall over backwards", "go out of the way", or "take special pains."  I might also suggest "do extra work", or "more than ordinary effort."  It goes back to the definition of what is normal or expected of a system.

In 2006, when my work in interoperability really started to take off, the ability to import data between competing EHR systems wasn't considered to be a normal function of the EHR system.  The ability for patients to access data via an application of their choosing also wasn't considered to be a normal function.  Over time, these capabilities became the norm as a result of two things:

1. Changes in Health IT Policy over the course of ten years which incentivized the development of of these capabilities in systems.
2. Changes in Payment Policy made use of these capabilities the norm for providers who wanted to get as much money as they could from CMS.
3. The development of standards (the second part of the definition) which enabled these capabilities.

Making a policy change isn't simple.  It's a process that takes years to complete, and a ton of people and effort.  CMS doesn't just get to decide to make a change, tell everyone, and then everyone complies.  There's a multi-year long process to making a rule, and that operates under the presumption that there's already legislation in place to make the rule.  If not, there's another several month long (at least) cycle just to get the legislation in place.  And rules have to leave time for people to implement them.  So, from legislation to implementation is at least a 3 year long process, and that's when the pressure is on (i.e., the early years of the HITECH Act).

Once implemented, we now begin a new stage of learning ... what works, what doesn't work, and what needs to change.  And then the process starts over again (and if well designed, it already had moved into the next stage).

Developing standards is equally complex.  The best work takes decades.  But e-mail ... took 60 years to get where it is today.  But the internet (HTTP, HTML and the web) ... took 20 years to get where it is today.  But XML ... took 3 years from inception of the project to become a standard, and it started from a standard (SGML) that had been in existence for 20+ years before it, and is still being advanced today some 20 years later.  But JSON ... is based on work started in 2006 and took another 7 years to be defined as a standard ... and is still being refined today.  CDA is almost old enough to drink as a standard, and was in the womb for three years before it's first publication.  The inception of FHIR can be dated back almost a decade, the first published proposal (and there was a lot of work before that was published) goes back eight years.

Whether it's technology or policy, by the time you get there, the goal posts will have changed.  That's called progress.

   Keith

History of the Concern Act in CCDA

This particular post results from questions on the HL7 Structured Documents workgroup's e-mail list.  It basically boils down to a question of why the Condition and Allergy observations have an Act structure wrapping the Observation related to the Condition or Allergy that is described within.

The answers are below:

1. What were the intended semantics associated with the effectiveTime on the concern act?
   This is the time that the reported problem became the concern of the provider.
2. What were the semantics of the author on the concern act as opposed to the semantics of the author on the Problem Observation?
   One provider can be concerned about an observation made by another provider.  The author of the concern is basically the person saying, this is an issue I need to track.
3. What were the semantics of the Priority Preference on the concern act as opposed to the semantics of the Priority Preference on the Problem Observation?
   Again, this is related to the distinction between the "concern" and the "condition".  A low priority problem for the patient (e.g., a minor twinge in their tooth), might be a high priority concern for the patient's dentist.
4. How was the design of the Problem Concern intend to be used relative to representing “the patient’s problem list”? 
   The provider's problem list for the patient can be viewed as the provider's record of the concerns they have regarding the health of the patient.

General Background

In 2005, shortly after CDA was introduced, HL7 and IHE collaborated on a joint project to develop templates to exchange a care record summary.  HL7 was to to work on level 1 and 2 templates (documents and sections), and IHE was to work on Level 3 templates (entries) to enable the exchange of of this data (you might recall that ASTM was building the CCR around this time as well).  I was the editor for both the HL7 and IHE documents (and later the editor for the HITSP C32, and one of many editors for CCD and later C-CDA).

Involved in this project also from the HL7 and IHE sides was Dan Russler, cochair of the Patient Care workgroup at the time in HL7, and alongside me, of the IHE Patient Care Coordination Workgroup.  Dan brought extensive knowledge of V3 structures and vocabulary that HL7 had been developing in Patient Care to the project, and I was the go to person for mapping this to CDA.  The project had been cooked up by leadership of HL7 and IHE to basically try to get something done on care record exchange, because some of the IHE sponsors who had also been engaged with the CCR project were getting tired of it getting bogged down in ASTM.  Also involved from the HL7 and IHE sides was Larry McKnight, a physician from Siemens.

In HL7, we based a lot of our work on the Vancouver Island Health Authority's e-Medical Summary, developed for CDA Release 2.0 in 2004 (before CDA Release 2.0 had even finished publication).  That organization was the first organization to use Schematron for validation in CDA documents, something that continues to this day, 15 years later.  But the eMS didn't really get into details for level 3 templates for problems, meds and allergies (our key areas of concern in this project).  Fortunately, the HL7 Patient Care group had been working on vocabulary and modeling to describe Concerns about a patient.

If you look at the changes to CCD over time, you will see in C-CDA 1.1 that the Problem Concern Act uses CONCERN from ActClass in Act.code.  This is because it couldn't be used in Act.class because CONCERN hadn't been an accepted V3 vocabulary term at the time CDA R2 was completed.  This resulted in part from long running debates over the semantics of the CONCERN Act, which didn't finally get resolved until 2014 and later after the third and final push to complete this work.

The Problem Concern Act in C-CDA is the representation in CDA of the semantics of a Health Concern, which is distinct from the underlying problem that causes the concern.  Concern is about provider awareness of a problem, while the problem observation is directly related to the problem itself.  Consider this: I have Cervicular Radiculopathy again, but this time in my left arm.  I told my physician about it on January 19th, but had symptoms going back to a week before, and I was examined on the 22nd.  So, the concern about my nerve pain should be dated 1/19, or perhaps 1/22 after he evaluated me, but the problem itself should have a start date somewhere around 1/11.  When this problem is resolved (say in a few more weeks), it can be marked in the problem observation with regard to the date is was resolved, and in the concern act when that resolution is reported to my provider (which will likely be after that).

The health concern itself can change over time, and acts as a wrapper around the relevant data: When I originally had the problem, we could have included not just the physician observation, but also subsequent diagnostic test data, the treatment plan and evaluation.  All of this development of the Health Concern act evolves from the Problem Oriented Medical Record pioneered by Dr. Larry Weed.

   Keith