In principle XSLT can be used to convert between HL7 V2 Messaging, CDA, and FHIR formats. I have actually done this to an extent. But it's a huge mess and difficult to maintain or even understand. Most implementers have now moved on to other technologies for healthcare data mapping and transformation. And format conversions are only one minor piece of the interoperability puzzle.

The standards bodies in the clinical interoperability space aren't accountable to the FDA (although the FDA is a registered organizational member of HL7 and contributes to standards development as a peer to other members). Services like Metriport aren't FDA regulated medical devices. The standards bodies don't inspect implementers.

There are open source libraries for dealing with the data formats used for interactions between providers and health plans (insurers), primarily ASC X12N and NCPDP. The standards documents themselves are somewhat expensive. But Metriport doesn't appear to be playing in that space so it's a moot issue.

Interesting, up north the ISO 13485 certification etc. is required to even deploy an App, as your phone would be considered a medical device under the rules if used for diagnostics and or reporting.

Don't get me wrong, I am sure people have no issue paying the $84k each release cycle to be cleared as compliant. Notably, our health authority legally can't buy software without these certifications, and for the past 6 years only Microsoft offers a framework through their partner for the e-records exchange systems.

There is zero "open" anything in this ecosystem, as commercial insurance won't cover mystery commits.

Best of luck, =)

Can you elaborate, aren’t there cheaper cloud based hosting solutions e.g. aws?

AWS is usually not compliant, and thus likely prohibited as well. Microsoft partnered with a large local telecom company to provide the NOC.

It is 100% a monopoly, and thus why we left a competing firm a long time ago. =)

I'm not sure what you mean by "mystery commits". Health plans are legally required to accept transactions that conform to CMS adopted standards. They don't know or care what software is used to generate those transactions.

https://www.cms.gov/priorities/key-initiatives/burden-reduct...

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... =)

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.

It is ok to disagree kid (I often make mistakes), but asserting your locale's rules are somehow international is a nonsense argument for your own ego.

I would recommend considering programs compatible with your obvious temperament:

https://www.youtube.com/watch?v=XUAsU_zQVMo

Feel free to append any additional off-topic nonsense below if it makes you feel better. I still like you. =3

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. =)