MyHR PDF requirements should not conflict with HL7AUSD-STD-OO-ADRM-2018.1

[jdavison-mo]

In
"DR-1.0.0-2020JUN-full-ig/site/StructureDefinition-diagnosticreport-path-mhr-1.html",
"DR-1.0.0-2020JUN-full-ig/site/StructureDefinition-diagnosticreport-imag-mhr-1.html" and
"DR-1.0.0-2020JUN-full-ig/site/StructureDefinition-diagnosticreport-otherdiag-mhr-1.html"

it says:

"the attached PDF is viewable by any individual that is a My Health Record participant; it does not have any of these features: encryption, password protection, printing or copying restrictions, embedded fonts (as not all PDF viewers support them)"

The above statement is at odds with (HL7au:000008.2.4) | PDF Display segment from HL7AUSD-STD-OO-ADRM-2018.1, and would make it impossible to put a PDF generated for use in HL7v2 messaging into MyHR. A lab would then have to choose which format to produce or produce both.

• Documents must be valid according to the PDF/A-1b profile.
• Must embed fonts

Further the argument that producers shouldn't embed fonts because some PDF viewers may not display the fonts is a weak argument against the pros of producing a PDF/A for archivability.

There is no guarantee at all that font substitution will be adequate or that a font used by a producer will be available on a receiver. Consider users of Mac/Windows/Android/Linux. All have different fonts installed.

If a viewer is not PDF/A compliant and unable to show information correctly, then that problem should be localised to them rather than applied to all users.

In HL7AU OO There are conformance points for receivers:

 - HL7au:000008.2.4.2.1 | Receivers | Results, Referrals | Receiver software must display the received PDF with a PDF viewer component. |  

 - HL7au:000008.2.4.2.2 | Receivers | Results, Referrals | Receiver software must be capable of rendering PDF/A-1b content.

Consistent application of these would be appropriate.

[davidmckillop]

Feedback from an Agency Business Analyst who is aware of the history of NEHTA's approximately 2011 documentation which was pre Agency and pre-development of the HL7AUSD-STD-OO-ADRM-2018.1 document, says:
"There is no rationale I know of – other than that in the requirement: there is a belief that some PDF readers don’t’ support embedded fonts. Remembering the CCP was first released in 2011 – that was thought to be the safest approach. It is certainly open to review."