For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US.
The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone.
If the data is not being used in _any_ way for patients diagnostics/e-record roles, than your team might get away with just clearing HIPAA rules in the US (not sure how each state would handle that exception.)
You have been warned about the historical rules, but if something changed since I was last in that Circus... than I hope the project does well.
It is always wise to talk with a local legal specialist to clear up current rules. I'd wager people had a billion reason$ to keep things as they were... =)
OpenEMR is an OSS practice management system and is certified for medical use by ONC in the USA. It has been deployed in the medical context in many jurisdictions in the USA. There are some government agencies / larger organizations that require 'sole-sourcing' which I think is what you are referring to, it varies by jurisdiction, but I've never heard of anything at the federal level and widespread state level that 'requires' this. If this was the case I doubt we'd have made it through the many times we've been certified.
I will mention that the certification process is expensive. It ranges in the 100K-250K range each time we go through it in fundraising and to go through the certification process.
In general, up here the 3 relevant ISO certifications (around $45k to $80k each) that apply to e-record and diagnostic systems are required, or software cannot be legally purchased by the health authority. For many reasons, the e-record system software was written in partnership between a large telecom and Microsoft.
slicer.org has their detailed story why "3D Slicer is NOT FDA approved", and its unfortunate given the transient nature of volumetric imaging data formats.
My point was this area is a mine-field of regulation. Generally, the above rules trip the instant a doctor uses something to diagnose or communicate patient data. Notably, the same software is deployed across provinces and states... but will obviously have different certification requirements in each locale.
Some people seem to get really rude over the most mundane details. =3
It's kind of hilarious how some people with no real industry experience aren't able to do a simple search on the CHPL. Obviously, there's nothing illegal about using OpenEMR regardless of who wrote the code. And certification isn't even necessarily required. Providers who don't participate in certain federal or state programs are free to use non-certified software as long as they're able to comply with applicable interoperability and privacy/security regulations; regulatory compliance and enforcement for that stuff is at the provider organization level, not at the product level.
"there's nothing illegal about using OpenEMR regardless of who wrote the code"
Indeed, in your area this may be true. However, the health authority can't legally purchase or use these projects without the ISO certs, and thus it is a moot point.
I think we will have to agree to disagree, as there are two truths here. And people seem to be getting emotional about their egos. =)
Wrong. Merely storing clinical data or providing it to clinicians who use it for diagnostics isn't sufficient for software to be considered an FDA regulated medical device. I have actually built such software and was careful to avoid adding any features that would make it a medical device. Open source software has being used legally by provider organizations for decades.
Instead of remaining ignorant and spreading secondhand misinformation you can literally just go read the federal regulations and supplementary guidance. Or just ask the FDA for a formal opinion letter if you're in a gray area. This is basic stuff, not hard to find or understand.
I too have written software for both Canada and the US markets.
Don't YOLO this one kid.
(the fact you didn't mention the 2 other common ISO standards I omitted on purpose, means you have not done your work properly for "years" as you put it.)
It's always disappointing to see such ignorance in HN comments like this. While there are some relevant technical standards cross listed with ISO, adherence to ISO standards isn't legally required for products like Metriport. Seriously buddy, you can just go read the FDA regulations instead of making a fool of yourself. But if you'd like to keep looking silly then feel free to have the last word.
The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone.
If the data is not being used in _any_ way for patients diagnostics/e-record roles, than your team might get away with just clearing HIPAA rules in the US (not sure how each state would handle that exception.)
You have been warned about the historical rules, but if something changed since I was last in that Circus... than I hope the project does well.
It is always wise to talk with a local legal specialist to clear up current rules. I'd wager people had a billion reason$ to keep things as they were... =)