Tuesday, March 14, 2023

Intercepting Secure Socket Calls

Transport Layer Security is something I've been working with since the very first publication of Cross Enterprise Document Sharing (XDS).  For that very first Connectathon, we had to demonstrate that we could secure the XDS communications channels, and I struggled with that part.  So much so that I wrote what might be considered my first blog post, the ATNA FAQ.

Since then, I've become somewhat expert in implementing, diagnosing, and resolving issues with TLS implementations in Java.  One of my most recent challenges involved having to diagnose problems with a protocol where the usual methods in the ATNA FAQ don't work, because the underlying implementation is on Bouncy Castle FIPS, and that doesn't respond to the usual Java -Djavax.net.debug options I first wrote about 20 years ago.  There's a good reason for that, but it makes debugging protocol implementations a bit of a beast when you cannot see what is happening.  Sure, you can wireshark it, but that doesn't always work when you aren't in control (as I wasn't) the responding service.

The solution is rather ugly, and it involves interceptors.  What I wound up doing was getting a hold of the client socket factory, wrapping it with my own implementation, intercepting calls to the Socket creation code, wrapping them in interceptors which catch calls get underlying Input and Output streams, and wrapping each of those in an Interceptor which filters the input or output stream to duplicate the output onto my console.

This is brutually tedious code, because it involves overriding EVERY implemented public method of these classes, calling the original intercepted object's method and returning the result (or slightly modifying it in a very few cases).  Fortunately, modern IDEs will write MOST of this code for you and search and replace will finish it (except for the special cases).  I won't reproduce every line here, but I'll explain the technique.

First, understand that I'm dealing with client calls to a server, and these are built on HttpsURLConnection.  For those of you who've been programming in Java, you may already understand that this is not an interface, but rather an abstract class, and the finicky details are found underneath it in sun.net.www.protocol.http.HttpsURLConnectionImpl (BTW: Good luck finding the source for that).

When you have your URL Connection, you will need to wrap the SSL Socket Factory it is using with a new socket factory that intercepts calls to the existing one.

    HttpsURLConnection conx = (HttpsURLConnection)url.openConnection();
    if (debug) {
      conx.setSSLSocketFactory(new MySSLSocketFactory(conx.getSSLSocketFactory()));
    }

Next you are going to create this new SSLSocketFactory:

public class MySSLSocketFactory {
  private final SSLSocketFactory base;
  MySSLSocketFactory(SSLSocketFactory base) {
    this.base = base;
  }
   ...
}

Inside this class you will override every method implemented in the class (Eclipse's Source | Override Implement Methods menu makes this easy).

Each override follows one of two patterns:

  @Override
  public void methodX(Type0 arg0, Type1 arg1) {
    base.methodX(arg0, arg1);
  }

Or for methods returning a value:

  @Override
  public TypeR methodX(Type0 arg0, Type1 arg1) {
    return base.methodX(arg0, arg1);
  }

For the createSocket methods, you will vary this slightly:

  @Override
  public Socket createSocket(Type0 arg0, Type1 arg1) {
    return new MySocketWrapper(base.methodX(arg0, arg1));
  }

Next, you will create MySocketWrapper following similar instructions.  This time there are 60-70 methods you must override (I did say this was tedious, did I not).

public class MySSLSocketWrapper extends SSLSocket {
  private final SSLSocket base;
  public MySSLSocketWrapper(SSLSocket base) {
    this.base = base;
  }

  @Override
  public InputStream getInputStream() throws IOException {
    return new MyInterceptingInputStream(base.getInputStream());
  }

  @Override
  public OutputStream getOutputStream() throws IOException {
    return new MyInterceptingOutputStream(base.getOutputStream());
  }

  // ... Add other Overrides here just calling the base method of the same name
}

Finally, create the MyInterceptingInputStream and MyInterceptingOutputStream classes just as before, overriding the read or write methods to copy the input or output to another place of your choosing.  I just write what was read or written to System.err, but in the case of the InputStream, I also write a couple of escape sequences before and after to change the color of the output in my console so I can distinguish which stream I'm seeing.  Here's an example of what I mean.

  private static final byte[] BLUE = { '\033', '[', '3', '4', 'm' };
  private static final byte[] NORMAL = { '\033', '[', '0', 'm' };
  @Override
  public int read(byte[] b, int off, int len) throws IOException {
    int val = in.read(b, off, len);
    if (val > 0) {
      try {
        out.write(BLUE);
        out.write(b, off, val);
        out.write(NORMAL);
      } catch (IOException ex) {
        // Swallow it.
      }
    }
    return val;
}

Now, when I set debug to true, I'll get the HTTP communications appearing in my console.

Later this week I'll show you another hack I implemented to make HttpURLConnection support PATCH in JDK-11.

Wednesday, December 7, 2022

New CMS Proposed Rule Released on PatientAccess and a Feature Request for the @FedRegister Web Site

 CMS Announced the updates to the Patient Access Rule yesterday.  So another tweet tweet through and summary are coming by EOW (my time zone).  You can find the preview here.  My comments on the prior rule are here, and you might read that first before starting on this one.

I'm not going to get through this one right away because I have other high priority tasks in front of that (releasing is a very important feature).

I've been a Federal Register user for quite some time.  I really appreciate all the work that has gone into it, especially for reviewing regulation.  My biggest use of it is for providing feedback on regulations, and that leads me to a feature request or three that I'd love to see.

  1. Provide users with the capability to make notes on individual paragraphs and sentences in a publication requesting feedback (e.g., a rule or proposed rule).
  2. Enable users to coordinate with other users so that multiple users can make notes in the same note repository.
  3. Enable users to access and download that feedback in a machine readable, preferably standardized format.
  4. Enable users to upload/merge feedback from other exports into a note repository.
  5. Enable users to share a link to that feedback with others for read or write access.
  6. Enable users to automatically submit a repository with additional attachments as feedback on a proposed rule, RFI or other publication.
  7. Annotations should take the format: Link to original text (a span of text in the rule), proposed wording, comments, and author.  See the last paragraph below for why this is the format.
What this would do is enable users to comment on regulations, provide a standardized format that would enable federal agencies to automate much of the work of coordinating comments from different users, and enable feedback to be tied directly back to required sections.  This could vastly improve response times for feedback.

I try to provide feedback on regulations the same way as I do for standards: Here's the original text, here's how it should read, and here's why.  When writing the "how it should read", I try to use the same voice as the original proposed rule so that the text can just be copy-pasted into the final rule. It makes everyone's day easier, and that's how I've gotten verbatim text I and my colleagues have written to appear in at least three different rules (yes, you too can write text that appears in a final rule).

     Keith


Tuesday, November 29, 2022

42CFR2_NPRM: Summary of a Tweet Through

The awaited 42 CFR Part 2 update NPRM has been published in preview form in the Federal Register, and is expected to be published later this week.  I finished my tweet through last night, and you can find all the text below.

A thread on the NPRM revising rules on Confidentiality of Substance Use Disorder (SUD) Patient Records #42cfr2_nprm

#42cfr2_nprm This rule is required to implement requirements in section 3221 of the CARES act (see https://congress.gov/116/plaws/publ136/PLAW-116publ136.pdf#page=95)


That law changed the consent requirements, simplifying them, but rule changes were necessary to conform.  Thus we now have the long-awaited #42cfr2_nprm

There's a 60 day comment period starting soon (official publication in FR), then a final rule, effective 60 days after its publication, and requiring compliance 22 months later.  So, all of this would be REQUIRED of entities within about 2.5 years. #42cfr2_nprm

#42cfr2_nprm Is two years enough for compliance (plus the ~ 6 months additional warning this NPRM gives you)?  @HHSGov specifically asks this question on page 8.

#42cfr2_nprm Major proposals include: aligning more with HIPAA in various places, including noting that this rules does not prevent anything required by HIPAA, referencing HIPAA content, or revising existing HIPAA content for use in this rule.

#42cfr2_nprm Major proposals (cont.): Apply breach notification requirements for records covered by part 2, 

align w/ HIPAA accounting of disclosures, patient right to request restrictions, HIPAA authorizations with 42CFR2 Consents, ...

#42cfr2_nprm next one is huge: replace ... requiring consent for uses & disclosures for payment & certain health care operations with permission to use & disclose records for TPO with a single consent ... until ... patient revokes ... in writing

HIPAA NPP and Part 2 SUD Notice to patients are being aligned under #42cfr2_nprm

And NOTE, this rule also mods some regs under HIPAA too in minor ways to attain better uniformity across both.

I'm guessing that post-implementation, this page https://hhs.gov/hipaa/filing-a-complaint/index.html will undergo revisions, so that there's one place to complain the secretary regardless of whether it's a HIPAA or Part2 violation.

hhs.gov

45 CFR 164.520 (HIPAA Privacy stuff) will undergo some changes to enable alignment with #42cfr2_nprm for NPP, Accounting of Disclosures, but will wait on some HITECH stuff to complete before finalizing privacy rule provisions to make implementation easier on affected entities.

"The existing Part 2 regulations do not permit the disclosure of Part 2 records for public health purposes", but #42cfr2_nprm would "permit Part 2 programs to disclose de-identified health information to public health authorities." NOTE: De-identified = HIPAA 45 CFR 164.514(b)

There's a big chunk of stuff in the #42cfr2_nprm about court orders for disclosure for various purposes.  This is not my bailiwick, both literally and figuratively.

And now we have completed the bulk of our reading, and get to @HHSGov's request for specific feedback at page 115 for the #42cfr2_nprm 

This is followed at page 126 by a summary of what I just summarized (mine is shorter).

I'm going to skip the cost benefit analysis in #42cfr2_prm; b/c that takes a while for me to process.  It isn't just reading and gut feel and an understanding of history.  I make models when these are important to me, and this one is.

But to provide a short summary of the #42cfr2_nprm analysis: The ROI is about 6 years.

The proposed regulatory text for #42cfr2_nprm appears starting at page 202.  We aren't going over that today (although I may later).

This is expected to be published in the FR on 12/2

I like #42cfr2_nprm.  It will probably get some minor revisions, and possibly some delayed activation dates, but frankly, I think many providers and much of the #HealthIT industry would support its content. From a patient perspective, I find it good, but requiring a deeper reads.

And yes, deeper reads is plural. I read a rule three times.  This was just my first cursory read-through/tweet through.



Friday, November 4, 2022

Porch 2.0

This started off as a tweet stream, but is also a great blog post.  It's about how every project is like an onion.  You think you understand it, but as you peel it, you find that there are layers that need to be trimmed out.  Most onions are completely salvageable, you just need to plan for the fact that some parts will need to be thrown out.

This spring I took the screen frames off my screened in porch to replace the screens. The frames turned out to be rotted. I'll build new ones eventually.  In the meantime, it still looks better this way.  

After pulling out the frames, I noted that one 4x4 had been badly weathered and needed replacement. I bought $100 of lumber to fix it and the posts mounted on it. Well, after removing it, I realized the rot extended to the deck beneath it.

I pulled off the facia and the side frame also needed replacement. Both it and the end frame were also badly joined to 2ft extenders.

I searched for and got estimates from deck/porch contractors to demolish the old porch, expand and add a deck and handicap access ramp (combining another project into this one).  That started a few weeks ago.

Two days ago, while digging the footings, they drilled through my well line.

Today, the well company came out to fix the well line.  While trenching to reroute the line they found the power to my barn and severed it with their backhoe.

I now have to hire an electrician to run a new (installed to code) electrical line out to the barn now.

In case you were wondering, this is not a disaster.  It's just another day building upon the experiences I routinely have in my day job as a software developer.

The title of this story should be something about how Porch Maintenance Release 1.2.0.1 subsumed and became Porch 2.0, with Water 1.5.1 Patch, with a subsequent Barn Electrical Patch 1.3.2, which will probably ship with the MVP of Barn/Office 2.0.

For what it's worth, my farmhouse is a collection of 1895 and 1970 construction with few extra (uninspected) homeowner modifications built in, and an add-on side deck I had professionally installed when I moved in (complete now with hot tub).

-------------
Postscript:

Because of all the on/off hammer with the well water supply, I now have a leak in the cold water to the upstairs bathroom, and a toilet valve that's constantly running downstairs, so two more tiny patches. Also, I have a small driveway patch to make because they had to extend the hole for the water feed into the macadam across the front step. I'm sure there will be more to come.



Wednesday, August 17, 2022

The Ages of Legacy Software

You've maybe heard about levels of maturity.  You may also be aware of orders of ignorance.  Well, now you know about the Ages of Legacy.
  1. The person who wrote that no longer works here. Their protégé has taken over.
  2. The person who wrote that is retired. Their protégé still works here and oversees maintenance by a junior staffer.
  3. The person who wrote that is dead. Their protégé recently departed the company.  The junior staffer has been promoted to project lead.
  4. The person who wrote that is dead. Their protégé is now retired.  The project lead has moved on to another project.  There's an intern who can still fix some of the bugs.
  5. The intern quit.  The old project lead threatened to if we gave him any more work related to the software.
The ages of legacy for software are very much related to finer detail in the last two of the the Nine Ages of Man, and also the Seven Stage's of Man (inspired by Shakespeare's "All the World's a Stage" in Act II Scene VII of As you Like It).

A picture of an old man sleeping in a chair by Robert Smirke
"Old Age" by Robert Smirke



Thursday, June 16, 2022

My Comments on the SANER Rule

Thank you for the opportunity to comment on the CMS 2023 Prospective Payment Rule.  I won't spend a lot of time on introductions.  I'm a highly trained Health IT subject matter expert, and have been employed in the Health IT field for multiple decades.  If you want to learn more, simply go back to the source for these comments and learn more about me. Please note, these are my personal comments on the IPPS rule, not those of my employer or any other organization you might presume I represent.

I am also publicly sharing these comments for anyone else who may have forgotten that these are due tomorrow.

My comments are focused on section M. Condition of Participation (CoP) Requirements for Hospitals and CAHs To Report Data Elements To Address Any Future Pandemics and Epidemics as Determined by the Secretary.

  1. In summary, CMS proposes "to require hospitals and CAHs to report specific data elements to the CDC's National Health Safety Network (NHSN), or other CDC-supported surveillance systems, as determined by the Secretary.” 

    I strongly support having the NHSN continue this work.  NHSN has been at the forefront of surveillance and reporting efforts for decades, and that expertise should not be lost in addressing the needs of this sort of reporting or the already established infrastructure supporting tens of thousands of existing connections to reporting facilities and the staff and processes necessary to support and maintain those connections. I’d hate to see NHSN expertise lost in this effort. If it were to go elsewhere within CDC, I would strongly recommend a restructuring based on the existing core NHSN expertise, however, given NHSNs leadership in looking for and adopting new ways to communicate this information (see link below to NHSNLink), that seems unnecessary.  It was already very disruptive to transition this reporting away from NHSN in the first COVID-19 summer under the previous administration.

  2. Section 3. Summary of Costs and Benefits addresses the costs for manual reporting efforts the collected data.  Many facilities will want to automate this process if they have the technical capacity to do so, which has an alternative cost structure. The rationale is that not only is nursing staff time a cost to the facility, but that it also represents anywhere between two weeks (for weekly reporting) and a half a year of nursing time devoted to non-patient care activities, and thus lost revenue.  We already know that during a pandemic emergency, qualified staff are in short supply, so it is not just a matter of making up for the lost staff time.  This represents an opportunity cost that is hard to quantify, but should be a consideration.  Facilities recognize this, and thus many opt to automate these reporting solutions.

    Consider that many hospitals operate at very thin margins.  Published statistics show the average cost of a hospital bed day to be around $2400.  Considering nurse staffing norms between 3 and 5 beds to a nurse, that's between 3 (at weekly reporting) and 42 (for daily reporting) days of lost nursing time, in dollars ~$10,000 for weekly or ~$400,000 for daily reporting of revenue lost due to the nurse not able to care for a patient.

    The data being collection for automating this reporting would not generally come from a single system. To automate requires data collected from between 3 and 5 different hospital systems. Clinical data might come from the EHR, bed capacity from a bed management system, PPE from inventory systems, and medication and vaccination inventory from pharmacy information.  Some facilities might use a combination of manual and automated solutions because they may not have (or need) all of these different systems. 

    Automated solutions are essentially interfaces (a term of art in Health IT) between different health information systems, and NHSN or other CDC entity, but since all reporting is consolidated their must also be a central system that consolidates the data into a single report.  The interfaces themselves require either IT staff effort (or may be purchased from IT vendors), and also require deployment and maintenance to either existing or new hardware.  There are several published estimates for the INITIAL costs for the development of various interfaces, ranging from $3000 to $25,000 depending on complexity and features, as well as the maintenance costs, and some portion of the interface cost may need to go into additional software licenses and infrastructure (e.g., computers) to run those interfaces, as well as IT staff to manage and support them.  There are from 4 to 6 possible interfaces that may be necessary to automate this reporting (thus returning nursing time to the care of patients).  The cost of development for the interface (including first year of operations), could be as much as $250K depending on the approaches used by the facility and again, features and complexity.  Maintenance costs for deployed software can generally be estimated as being somewhere between 10 and 25% of the initial software cost (and some vendors actually compute their annual maintenance prices based on the cost of the initial interface. 

    Assuming a 20% rate for maintenance (a popular number) with minimal associated facility staff time which might be absorbed into routine interface maintenance efforts, this brings the total cost of the interface to around $300K for a two year period, or $500K for a five year period, an amortized cost of around $100K per year over five years.  This effort by the way, also is opportunity loss for the facility, with respect to investing in other interoperability initiatives, such as promoting interoperability.  Just as for any other hospital based professional, there's only so many competent interface people to go around to work on these efforts.   Some of these costs may be offset by the ability of the IT staff to repurpose existing automated solutions, which might reduce these costs to $50K per year (a ballpark back of the napkin estimate) when amortized over a five year period, which would bring the two year cost down around $150K (slightly lower than the cost projected by CMS for manual reporting, but note this response argues that CMS has underrepresented the actual financial impact of the manual cost on hospitals).  This may only be feasible in larger hospitals with more advanced IT staff and capabilities, but does provide a range for the estimation.

    These arguments serve to show that the projected costs of reporting are likely underestimated, either based on the lost revenue due to inability to staff beds due to nursing resources being used for non-direct care activities, or due to somewhat higher to automate such a solution.

  3. The rule states: "For purposes of burden estimates, we do not differentiate among hospitals and CAHs as they all would complete the same data collection."

    Many CAHs have a much lower capacity to support IT innovation, as they provide essential and low margin hospital services in needed areas, and are not able to fund extensive IT departments.  Some CAHs have "a guy who comes in once a week" to work on the IT systems.  Their ability to automate is marginal, and furthermore, it's not just an RN, but probably the most senior nurse at the facility who is doing the reporting, because they are likely one of the few people with access to all of the information.  The reporting in these facilities is a team effort, 2 or 3 people gather data, the reporting nurse consolidates, validates and reports, which also increases the time it can take for reporting. CMS should strongly consider that the burden of this reporting on CAH facilities is going to be much higher just based on the nature of the ways that these facilities operate.

  4. The preamble further says: "Furthermore, we note that this estimate likely overestimates the costs associated with reporting because it assumes that all hospitals and CAHs will report manually."

    Respectfully, I disagree.  As previously noted above, a nurse is a revenue generating employee in a hospital, and the CMS estimates did not account for revenue lost due to engagement in a non-direct care activity.  Just replacing the nurse with another paid at scale does not account for the financial burden of having that person perform non-revenue generating activities.

  5. CMS notes immediately thereafter that "Efforts are underway to automate hospital & CAH reporting that have the potential to significantly decrease reporting burden and improve reliability".  References to such efforts would be very helpful to understand the potential impacts.  Some suggested references follow:

    * NHSNLink developed for NSHS and described at https://www.cdc.gov/csels/phio/exchanging-data-efficiently.html
    * Helios, an HL7 FHIR Accelerator supported by CDC and ONC at https://blog.hl7.org/hl7-launches-helios-fhir-accelerator-for-public-health
    * The HL7 FHIR Situational Awareness for Novel Epidemic Response (SANER) Implementation Guide at https://hl7.org/fhir/uv/saner/.

  6. Also note the two recommendations from the HITAC on SANER (used in all of the above listed references) found here and quoted (and with my emphasis) below:

    a. We recommend that ONC list Situational Awareness interoperability priorities in the ISA and should catalog SANER as well as related standards and IGs; ONC should via work with stakeholders on pilots and early implementation, evaluate and mature standards towards broader adoption.
    b. We recommend that ONC work with stakeholders at HHS to create aligned policy and funding mechanisms to harmonize adoption of a combined situational awareness standard that maximizes readiness and minimizes state-by-state divergence.

    I see the conditions of participation in this rule as being one piece of the aligned policy and would recommend that CMS be prepared to coordinate with other Federal agencies on other pieces (e.g. the Helios effort listed above, USCDI and USCDI+, CDC Grants in aid to the states)

  7. I applaud the efforts that CMS has made to generalize the reporting requirements and learning the lessons from COVID-19 in ways that appropriate to the variety of causes of a pandemic Public Health emergency.  It's good, but honestly more work will be needed to develop the necessary standardized templates that can be used to quickly create measures specific to each PHE, and CMS should collaborate with other existing Federal efforts (e.g., the Helios FHIR Accelerator project, and specifically the Aggregate Data project within Helios) and with ONC/USCDI and USCDI+ to develop these templates, measures and value sets as national standards.  Also, please do not forget that a Pandemic need not be related to a respiratory condition.  Consider AIDS/HIV, or MonkeyPox as examples.

  8. With "that are captured with interoperable data standards and elements", it's clear that CMS understands the need to adopt such standards and data elements in national standards such as those referenced by USCDI.

    The list following this paragraph identifies kinds of things can be captured in a terminology Value Set, maintained readily in VSAC.  Such value sets must be developed and used in measures, and should be adopted from standard vocabularies, but I would recommend that the efforts by the secretary to standardize these value shoulds should focus more on the vocabularies from which they are selected and the standard formats in which they are delivered.  The development of these value sets is more correctly delegated to professionals with relevant background and training, with appropriate governance to enable others outside of the maintaining group to submit new terms for inclusion (much as how vocabularies themselves are developed).  I would encourage CMS to ensure that their are appropriate funding mechanisms to develop and curate such value sets, and investments in VSAC to support the rapid update and easy distribution of them through interoperable solutions.

    * Disease
    * Treatment Devices
    * Vaccine
    * Theraputics (meds or biologics)
    * Co-morbidities

  9. It's unclear whether this text: "The proposed requirements of this section would apply to local, state, and national PHEs as declared by the Secretary." applies to regions under tribal jurisdiction or not.  Given the complexity of jurisdictional governance, I would have appreciated some clarity on this point.

  10. "to include medical record identifier".  Get to work on National Patient ID, please.  In the meantime, investigate existing CDC efforts in application of privacy preserving record links.  It's about time we do away with the dream of longitudinal records through patient matching and move on to the reality of having a unique identifier.  Many of the challenges reported earlier with COVID reporting in public health stem from the inability to walk longitudinally across state, jurisdiction or organizational boundaries.  If you want interoperable data that can provide a national picture, you need a way nationally to identify patients.

  11. On Burden:
    "For purposes of this burden collection, we acknowledge the unknown and the ongoing burdens that may exist even if CMS is not collecting information outside of a declared PHE. We recognize that considerations such as building and maintaining the infrastructure to support readiness are necessary to ensure compliance with this requirement. Therefore, we are soliciting comment on the burden associated with these proposed requirements given the intended flexibility provided in reducing or limiting the scope and frequency of reporting based on the state of the PHE and ongoing circumstances. We are specifically asking for comment on the potential burden associated with the proposed reporting requirements as they might relate to any differences in the public health response to one specific pathogen or infectious disease versus another that would be directly related to the declared PHE. We are also interested in public comments addressing burden estimates (and the potential differences in those estimates) for variations in the required reporting response for a local PHE versus a regional PHE versus a national PHE that might be declared by the Secretary based on the specific circumstances at the time of the declaration."

    Building and maintaining the infrastructure has burdens on Health IT Vendors, and upon their customers (Hospitals and CAHs), as well as on the supporting organizations.The IT Vendor burden is in reality a shifting of focus from vendor determined priorities to national interoperability priorities established by public policy, as their financial burden otherwise flows through and is borne by their customers as a cost of goods and services.  The financial burden on hospitals and CAHs is one which must be borne, and better borne before the next PHE rather than during.  We already well understand the challenge of building the plane while flying it given recent experiences under COVID-19, and the cost of performing such efforts during a PHE surely outweigh those of performing outside one.

    Some of this burden can be reduced by relying on natural aggregators of health information at the local, state, territorial and tribal levels.  CMS should consider enabling health information networks (as defined on ONC rules) including Health Information Exchanges, regional public health entities and supporting organizations (e.g., hospital associations and others) the opportunity to provide services to hospitals and CAHs to support reporting of the requested data to NSHN on behalf of those facilities who want to use them.  This will help by aggregating some of the common infrastructure functions under a single entity, e.g., maintaining compute, storage network and interoperability infrastructure necessary to automate reporting, enable reuse of secured connections to those HINs, and reduce the effort needed to support national reporting.

    I also note that CMS considers only pandemic public health emergencies, but would also remind CMS that other emergencies may also benefit from such a reporting infrastructure.  Forest fires, rolling blackouts, hurricanes and tornados, freezing weather in parts of the country that see it only once a decade or century, all of these emergencies can create a strain on our health infrastructure that appropriately designed system for reporting on situational awareness can address.

    As we've learned, focusing on just beds isn't enough, and reporting multiple separate measures to local, state and national authorities just trebles the burden.  We need to find, dare I say it, a SANER way to accomplish this.

Tuesday, June 7, 2022

Digital Transformation is not computerizing paper forms

This is very related to what we are trying to accomplish with CREDS, and so is sort of a followup to my previous post on CREDS, but is more broadly scoped.

It starts here with this tweet, but not really.  It actually starts with all of the work that people have had to do to mediate between the data in the EHR, and measurement of what that data actually means.

It boils down simply to how one asks questions in order to perform a measurement.

In the early days of quality measurement and/or registry reporting, it was not uncommon to see questions like this:

  • Does this patient qualify for XYZ treatment?
  • Has the patient been prescribed/given XYZ treatment?
  • Is XYZ treatment contraindicated and/or refused?
And, the reporting formats be structured in Yes/No form in some sort of XML or other format.

It's gotten to the point that some of these questions and their possible answers have been encoded in LOINC.  Now, when used for a survey or assessment instrument, that use is fine.  

But for most registry reporting or quality measurement activities, this should really be handled in a different fashion.  This is a start, and can be written in Clinical Quality Language format, or even more simply in a FHIRPath Expression.

  • Does this patient have any of the [XYZ Indications ValueSet]?
  • Has this patient been prescribed/given [XYZ Treatment ValueSet]?
  • Does this patient have [XYZ Treatment Contraindications ValueSet]?

The theme in this restructuring is: Ask the provider what they know and did, and define the logic to compute it.  But even better is to ask the provider what they know and did (and recorded), and have the quality measure reviewer actually do the compute on the quality measure.

Apply normal workflows to keep track of what is learned and done; these shouldn't be interrupted.  I can recall a case where normal workflow added a checkbox to an EHR screen just to get a clinician to acknowledge that they had reviewed and/or reconciled the medication list.

Building these value sets and the logic to evaluate them is hard.  Doing it so that it is interoperable across systems is also hard.  But honestly, the cost per provider to do this is so much less to do it once and do it well, than it is to have hundreds or thousands of systems all need to do this is much more costly, and likely to introduce differences in the compute, and variability in the reported values.

Stop asking for the answers, start asking for the existing evidence to get the answers you need consistently.  And if you cannot get the existing evidence, ask yourself why before asking that it be added to the normal workflow.

   Keith