At least in the case of subscriptions I looked at:
1) It's a continually updated file, so if you didn't subscribe you wouldn't get new data weekly/monthly. Likely the subscription aligns with the data refreshes for most products.
2) It's a one-time fee with a hefty cost attached (I saw some healthcare data sets that were $100K+). You are paying for that in its entirely and just have data rights to it.
It's rough. We thought about switching to Microsoft Teams and we realized that so many decisions about our relatively young company were tucked in DMs and private channels in Slack that we couldn't leave.
Email is non-sticky (just take your emails/save them on client and leave)
Files storage is non-sticky (just move your files from OneDrive to GDrive)
Chat/Collaboration is sticky as mud.
This sounds more like a problem with your young companies processes, not a problem with slack or email.
Maybe you should think about a formal method of documenting important decisions for your company instead of relying on a chat log.
"Hey, I just purchased 20k of widgets"
"What? Why?! We can't afford that! We decided to discontinue those widgets month ago! Didn't you scroll through the chat logs before making that purchase order??!"
I agree that some folks often exaggerate the danger in HIPAA, especially for someone like OP with a relatively small operation. But, for companies with larger operations and reach it's definitely a non-trivial problem. Our relatively small organization has two people dedicated to compliance (and plenty of ancillary support) and goes through hundreds of audits a year. Not having a locked down well thought out solution, both technical and operational, can really put growth at risk in healthcare. Of course, that's not "HIPAA compliance", but it is "what it takes to reach scale in healthcare".
> But, for companies with larger operations and reach it's definitely a non-trivial problem.
The more hands you have touching any given system the work required to ensure compliance in any regulated industry increases, that's certainly a given.
Technical compliance is the easy part in all honesty, all of the human elements (policy, procedure) requires constant attention and is the majority of what our compliance and QA teams deal with. This is the hardest thing to deal with, and it's not even just "don't expose PHI" but making sure you have everything just the way a certain insurance company likes things, that a chart has supporting documentation for a specific procedure, etc. Makes me glad I only have to deal with our applications and the systems they run on, props to the compliance team for all the headache they have to deal with.
Our company had early access to this product and I was impressed by it. Our company had built our own FHIR datastore and I can attest to the fact that it's a more complex endeavor than it seems externally.
The killer feature of the product is its simple connectivity to other Google Cloud products for ML/Analytics purposes. Being able to receive a large quantity of radiology images (DICOM) or clinical data (using tools like Epic Kit/Caboodle) and immediately _do something with it_ is pretty impressive and hopefully lowers the burden for innovators in the space.
Of course, there are other options if you are looking for them, namely:
2) HAPI FHIR: http://hapifhir.io/doc_intro.html Open-source library from the makers of the most popular HL7v2 parser library. We run a bit of this today and it works smoothly. There's unofficial commercial support (same creators, different effort) from https://smilecdr.com/.
3) Vonk: Made by a company that has focused alot on FHIR based tooling. https://fire.ly/vonk/
It's not necessarily liability, but it is shared responsibility. Someone validating that they will take responsibility for parts of your stack can be very important, especially at scale.
HL7v2 was invented in 1989. It was invented to meet the needs of then intra-operability between existing HIS systems. HL7 itself is a open organization comprised of a variety of members from vendors to health systems to life sciences/pharma.
HL7v2's problem is that it is 30 years old and probably should have been replaced by something earlier. Then again, so should most X12, mainframes, COBOL, etc. etc. FHIR is good, but the challenge is that the incentives for interoperability are much lower than those for intra-operability.
People love to bitch about HL7, but it gets far too much vitriol compared to X12. You want to talk about an antiquated format that should be taken out back and shot, here is your target.
The annoying part is the QACH CORE Connectivity Rule has finally made interacting with health care partners for X12 transactions suck less by providing standard REST and SOAP interfaces for transaction exchange, but we couldn’t be bothered to implement a less shitty transaction format.
That's a gross exaggeration. Every OneNote client (except for the browser one) downloads everything from OneDrive to the local machine and does all the changes to that local copy, which then gets synced to OneDrive. You could take weeks' worth of notes and peruse mountains of reference without any Internet access and the app wouldn't bat an eye.
It's true the app's positioned as an online service rather than a file reader for offline files the way it started, but calling a native app that operates on local data a "thin client" is just disingenuous.
The textbook answer is typically that there is exponentially more data in unstructured data, but I agree with you. I thought about the unmodified use cases for this tooling for awhile and the major use case that I could come up with was finding unknown interactions or side-effects for medication and treatment combination regimens. That's all tracked very poorly in discrete fields today, especially with the nightmare that is cross-organization problem list management. Most drugs are approved by the FDA with the understanding that there will be post-marketing research (read this: https://undark.org/article/fda-drugs-post-marketing-research...), which this could hypothetically streamline.
If you want to play with this and you're looking for a decent sample exam note, I grabbed some pieces of standard looking notes (Physical, ROS, Hand exam) and tossed them into a gist here: https://gist.github.com/molsches/32fcec2499e95b5b23bc268800e...
Mostly impressive in how it parses the data and can find conditions and tests in the unstructured data. Handles a few things strangely, but I imagine that gets better over time as it continues to be trained.
I think for it to truly be useful it needs some layer of semantic data mapping to something to standards like IMO/SNOMED/LOINC/RxNorm etc but I could see that being where other companies build their "products" on top of AWS vs. AWS competing with other Healthcare ML vendors in the space.
Did you grab several pieces from several notes? This looks like a garbled mess to me, but if I understood how you had transformed it to get it into this state, it might make more sense.
The posted text is actually a series of "dot phrases" or "smart texts" (aka templates in EHR speak), _not_ actual notes. Mostly these are inserted into clinical notes to achieve a certain level of documentation; typically they are saved in a "all negative" format, and the relevant parts are edited to reflect the patient history and physical. These seem to have been derived from the Univ of Washington Emergency Medicine residency.
These might make OK material for some initial testing but they don't reflect a real clinical note. A good source of those might be the MIMIC database [1]
Of course. I mostly wanted to get something out quickly. Those are all a bunch of small snippets of ROS and Physical Exams which demonstrate many of the things which the article discussed, notably finding Dx, Medications and whether or not they were negative or not.
I didn't know that there was a database of notes like MIMIC! I'll have to check it out.
1) It's a continually updated file, so if you didn't subscribe you wouldn't get new data weekly/monthly. Likely the subscription aligns with the data refreshes for most products.
2) It's a one-time fee with a hefty cost attached (I saw some healthcare data sets that were $100K+). You are paying for that in its entirely and just have data rights to it.