4 ms·

While any XSLT/XML based interface can act as middle-ware for such a messy ecosystem. There are several problems with touching medical data: 1. Some government

While any XSLT/XML based interface can act as middle-ware for such a messy ecosystem. There are several problems with touching medical data: 1. Some governments require ISO certifications for security 2. Some standards bodies require commercial accountability (FDA), data site redundancy, and company inspection by a standards body. 3. The ecosystem for the insurance documentation is never open source. It is not only prohibitively expensive, but comes with legal strings in the EULA. Good luck, but please read the slicer.org story before committing too much time to the project. =)

nradov 2y ago
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.
- Joel_Mckay 2y ago
  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, =)
  - moneywoes 2y ago
    Can you elaborate, aren’t there cheaper cloud based hosting solutions e.g. aws?
    - Joel_Mckay 2y ago
      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. =)
  - nradov 2y 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-reduction/administrative-simplification/hipaa/adopted-standards-operating-rules https://www.cms.gov/priorities/key-initiatives/burden-reduct...
    - Joel_Mckay 2y ago
      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... =)
      - nradov 2y ago
        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.

nradov 2y ago

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.

Joel_Mckay 2y ago
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, =)
- moneywoes 2y ago
  Can you elaborate, aren’t there cheaper cloud based hosting solutions e.g. aws?
  - Joel_Mckay 2y ago
    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. =)
- nradov 2y 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-reduction/administrative-simplification/hipaa/adopted-standards-operating-rules https://www.cms.gov/priorities/key-initiatives/burden-reduct...
  - Joel_Mckay 2y ago
    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... =)
    - nradov 2y ago
      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.