Federal law regarding access to digital health records

[MillCreek]

https://www.statnews.com/2022/10/06/health-data-information-blocking-records/?utm_source=facebook&utm_campaign=facebook_sponsored_lp_rt_pw&utm_medium=social&fbclid=IwAR2hUYAwSeKZkMOT5HqO0Q6K0n19CcwFVIb7sKtyPGN-h5GoEafDSce1mEs

Washington has had such a law for years, but now it is on the Federal level.  You can get an electronic copy of your healthcare records upon demand.

However, do not give us a CD of your records and expect us to do much of anything with it.  We cannot import it into our own electronic medical records system.  As the patient in the article points out, even different versions of Epic (one of the most commonly used EMR systems) cannot talk to each other easily, much less export and import data.

[230RN]

<not a rant, but almost>

A couple of  years ago I requested a provider-insuror to forward my data to a new provider-insuror and it was like the proverbial tooth-pulling and at some ridiculous cost.  One desk jockey asked "All of it?" and indicated that the high cost was due to the fact that it was 50 or more pages --don't remember exactly, but it was a lot.

Kind of strange, since I'm generally pretty healthy and (knock wood, throw salt over my shoulder) rarely need doctoring.

I finally prevailed  and when I got it for free, I discovered that most of it was blank pages.

I finally, using a text search, found what I wanted among the 50+pages, most of which were blank.

I hate to say this again, but too much of the medical profession is folderol and guesswork.  One irksomeness is when they take your weight with clothes on, which can trigger you into a higher BMI category than when you actually are stark nekkid and with your hair dry and teeth flossed.

Good thing you have to disarm when going into a health facility, otherwise you'd show up with an extra kilo or so.

And I think I'm begining to see that they are shrinking the "normal" categories of basic health tests.... also tending to "trigger" concern about other anomolies.

Which is good for business.

</not a rant, but almost>

Terry, 230RN

[Hawkmoon]

The VA has all our records stored electronically. If you sign up for a program they call My Healthevet, as a patient yoi cen get access to your own records. (They are not in a form that's compatible with EPIC, or any other known system, AFAIK.) I have tried print out what they call a "Blue Button Report" of selected portions of my records. The reports spit out multiple pages of garbage filler for every two- or three-line entry of actual, useful information.

I think just to use that system to prove that I received the first two COVID-19 vaccinations would require printing about six pages.

[230RN]

Huh l  i've got a little card with blank spaces to fill out  type, place, and date of each shot.

I rember bitching as to how they wee not smart enoughto make the card small enough to fit in your wallet slots.  I had to scissor mine down ~1/8 inch to fit.  Dumbasses.

No, Millcreek, I don't hate the medical industry.  I'm just New Yorkish enough to sense when bu$ine$$ takes precedence.

Some wag once suggested a system where you pay the doctor while you're well and stop paying when you get sick until you're well again.

In the present system, you pay while you're well pay more when you get sick, and keep paying when you get well again.

[AZRedhawk44]

I remember this stuff from back in the mid-2000's when I was a medical records database admin, and having to do bulk "imports" of records from disparate systems.  My target import system was NextGen EMR.

My import mechanism?  Turn 'em all into multipage TIFs (basically a PDF-esque picture file) and attach them to the patient record as image references.  None of the meaningful data is put into charting, it still takes a human eye to consume it and find meaning from it, and it cannot be used for analytical graphing or trending in the EMR user interface like other data.

Same thing for exporting.  Turn data into TIFs or PDFs, export to directories named after each patient, name each document for the date of the patient encounter.  Send it to someone else to "import" as a leaf attachment.

Real ETL interfaces between these systems would require an enormous collaboration between software vendors and standardization of data models. 

[MillCreek]

Real ETL interfaces between these systems would require an enormous collaboration between software vendors and standardization of data models.

And the various EHR vendors resist this since it would make it too easy to switch from one rival system to another, if they had standardized data import/export functionality into the EHR, as opposed to image files. 

We get this all the time: someone sends us a CD (and most of our computers no longer have CD drives for security) with 500 pages of images as their medical chart.  I can assure you that your doctor is not going to spend umpteen hours unpaid time carefully looking at the images and inputting the salient data into the EHR.  At most, if there is a handy problem list, medication list and the last year of chart notes readily available and we can look at that in 15 minutes. we might put a summary of all that into the current EHR.

[Nick1911]

Eh, slap something on top of FHIR or IHE  API's and call it good.   

[AZRedhawk44]

Eh, slap something on top of FHIR or IHE  API's and call it good.   

HL7 interfaces work fine for sending prescription information, mainstream lab requests and results, and other fairly standardized information... but an entire medical record set of a patient is not standardized.  "A medical record" is an ever-evolving document that has extended schema every month/day/year as new patient complaints arise, new test mechanisms are implemented, new laboratory processes are designed, new standards for cross referencing vitals panels, and new diagnoses are discovered.

A lot of places have custom data input templates for their EHR users, with streamlined and specialty specific data fields that pertain only to their practice specialty.  Cardiologists and Oncologists will collect different subsets of information and reference them differently.  It's still essentially on a per patient-encounter basis, but the itemized test result subset is wildly different.  If every practice specialty had their data points merged horizontally into one massive patient-encounter table/entity to include every possible logged item it would be too large (wide) for most relational systems to handle.

And if some well meaning data despot stepped in to force-unify this information, it would end up slowing down the evolution of the science of medical record keeping and collaboration.  If you can't invent a new means of cross referencing information without getting approval from some national (international?) committee and synchronization with the installation base across the country (world?) in order to keep schema flowing with no unhandled exceptions, then everything would devolve to hand written notes and PDF scans in order to comply with mandatory digitalization of records.

Ultimately I think the best that can be hoped for with regards to medical information portability is document generation and on-demand portability.  Cross integration of raw data into disparate schemas will always lag, and be constrained to work that mostly only pertains to the general practitioner threshold of medicine.  Anything beyond that will be specialty bespoke formatting that will require synthesis by a human mind (and thus require that mind to read a digital document and derive meaning from it that pertains to the particular patient in front of the doctor).  Which makes sense... specialty medicine is not something that can be programmed or automated.

[MillCreek]

Years ago, I was in London talking to the Lloyd's underwriters about my medmal risk retention group.  While I was there, I heard a lecture from the NHS in which they had a plan to create a medical records 'spine' to which different EHR programs could connect and use it to import and export seamlessly from one EHR to another.   I have not checked for quite some time, but I think the project was shelved due to technical and/or cost reasons.

[230RN]

Thank you, ladies and gentlemen; I did not realize the difficulty in harmonizing all these things.

It leaves me wih the wish / hope that firearms records were this awkward to implement and data-mine.

Thanks !

Terry, 230RN

[AZRedhawk44]

Years ago, I was in London talking to the Lloyd's underwriters about my medmal risk retention group.  While I was there, I heard a lecture from the NHS in which they had a plan to create a medical records 'spine' to which different EHR programs could connect and use it to import and export seamlessly from one EHR to another.   I have not checked for quite some time, but I think the project was shelved due to technical and/or cost reasons.

I can about guess how something like that would go.

The dominant EHR vendor would salt the talent pool working on the project so that the resultant "spine schema" had greatest compatibility with their product schema.  The net result would be increased market share of their product, constraints on other products to expressly prohibit them from adopting the "spine schema" directly into their product schema, and an ever-increasing market share for the dominant company as a result of such a coup.  The only defense the secondary product vendors could lean upon would be anticompetitive/monopolistic laws that are supposed to prohibit such public/private collusion.

[Nick1911]

AZRedhawk44, I was referring to the patient portal side, not interop.  Although yea, that's what those API's are suppose to do.  But half the time, pdf's just get shoved in as a blob object.  Okay for retrieval, not good for DB purposes.

[MillCreek]

https://www.medpagetoday.com/opinion/second-opinions/101354?xid=nl_secondopinion_2022-10-25&eun=g149952d0r

We have to use the EHRs, but we by no means love them.