Conformance
The matrix below shows how the public HealthOS Onco site and product frame relate to standards and sources. It is not a full conformance claim, clinical validation claim, or medical device registration dossier.
Statuses are literal:
- implemented — the claim is already reflected in the site text and call-to-action boundaries;
- product design — the claim is part of the product logic for the personal cabinet, storage, audit, or integrations;
- architectural reference — the standard is used as a design direction, but the site itself does not exchange data;
- limited automation — automation may support drafts and extraction, but not medical decisions;
- out of scope — the scenario is deliberately outside the product promise.
| Area | Status | Verifiable claim | Limit |
|---|---|---|---|
| Positioning | implemented | Public pages describe HealthOS Onco as patient support for preparing an oncology consultation, second opinion, or cost conversation. | The site is not a medical consultation, registry dossier, or clinical validation report. |
| Medical-purpose boundaries | implemented | The home page states that the service does not diagnose, issue medical orders, select therapy, sell medicines, or guarantee care cost. | Final oncology decisions remain with the doctor. |
| Independent review of basis | implemented | The site promises sources, dates, versions, gap reasons, and report limits instead of opaque advice. | Review depth is stated in the report generated by the product, not by the brochure site. |
| Not a black box | implemented | The site explains that important outputs should connect to a source document, questionnaire answer, date, and understandable reason. | This is a product principle, not a certified algorithm claim. |
| Personal cabinet | implemented | All personal-cabinet calls to action use an external configurable URL. | Registration, documents, reports, payment, and user data live in the product cabinet, not on the static site. |
| Source and data version | product design | The public site promises source links, report versions, dates, a price snapshot, and explicit limits. | Production storage and audit are verified in the product itself. |
| HL7 FHIR | architectural reference | FHIR is used as a compatibility model for future oncology data structures and integrations. | The public site itself does not perform FHIR exchange. |
| Oncology terminology | architectural reference | MONDO, NCIT, and OncoTree are referenced as future terminology anchors for disease and tumor subtype normalization. | The brochure site does not claim a complete terminology implementation. |
| OCR/NLP | limited automation | Document parsing may create draft facts, but drafts are not treated as confirmed oncology facts without review. | The site does not accept documents; processing happens in the personal cabinet. |
| AI and automation bias | product design | AI may support drafts and candidate detection, but not diagnosis, therapy selection, or medical ordering. | OCR/NLP quality is verified in the product itself. |
| Cost | implemented | Cost is described only as indicative context; risk and data completeness are shown before cost. | The site does not guarantee medicine or medical-care cost and does not sell a medical pathway. |
| First module | implemented | Public pages state that the first product module focuses on breast cancer. | Other oncology modules are not presented as ready comparison boards. |
| Public site and personal data | implemented | Public pages explain that documents and reports live in the personal cabinet, not on this brochure site. | Technical data-protection controls are verified in the product itself. |
| Emergency support | out of scope | The product is framed as preparation before consultation or second opinion, not acute care. | Urgent symptoms and complications require direct medical care. |