Here I step through the draft standard making comments.\u00a0 Where a comment is answered later in the standard, I go back to my original comment and make notes.\u00a0 An uncommented comment is potentially worthy of becoming an official comment on the standard.<\/p>\n
I decided to review this draft standard as I currently work with IT security software and have an idea of the needs for secure electronic documentation.<\/p>\n
Preface<\/strong><\/p>\n The standard appears to specifically apply to the digitization of health records, not to the creation of \u201craw data\u201d aka Electronic Heath Records (EHR).\u00a0 Here the standard is called AS 2828.2 Health records, Part 2: Digitized (scanned) health records.\u00a0 <\/em>Whatever the name, it needs to be stated consistently.<\/p>\n This is a \u201cnew\u201d AS based on AS 2828.2 (int) 2012. Int informs the reader of the interim nature of the standard. An interim standard is used for a period of time before review and submission for consideration for issuing as a formal Australian Standard.<\/p>\n Scope<\/strong><\/p>\n Specifies the requirements for digitization, storage, security, conformance and reproducibility of scanned record(s).\u00a0 Specifies the requirements when scanned records accessed from within context of EHR.<\/p>\n Section 1 Scope and General<\/strong><\/p>\n 1.3 Terms and definitions<\/em><\/strong><\/p>\n 1.3.2 born digital<\/em><\/strong><\/p>\n This is also known as raw (or original) data (at least in laboratory circles).<\/p>\n 1.3.11 electronic health record (EHR)<\/em><\/strong><\/p>\n Note that this is a record that computer calculations can be performed on.\u00a0 Photos of paper records will not be able to manipulated without text conversion or complex image analysing software.<\/p>\n 1.3.21 individual healthcare identifier (IHI)<\/em><\/strong><\/p>\n Is this Medicare number?\u00a0 Perhaps clarify this.\u00a0 It could be a number assigned by a clinic, a hospital or someone else.<\/p>\n 1.3.28 personal health record (PHR)<\/em><\/strong><\/p>\n States this is controlled by the person.\u00a0 This should ultimately be the same as an EHR and all access to such records should only be allowed when authorised by the person.\u00a0 Ideally there would be a central repository for such data (eg the MyHealth record).\u00a0 In other words, the person, not the doctor or organisation should own their data, regardless of who captured it, controls it or where it is stored.\u00a0 I acknowledge that could get tricky unless the storage and security is overseen by the Government.<\/p>\n Perhaps provision should be given to a person being able to request their full EHR from any organisation and perhaps they should be able to request the record\u2019s deletion from locals storage once transferred to the person.<\/p>\n Section 2 Digitization of health records<\/strong><\/p>\n No comments.<\/p>\n Section 3 Processes for digitization of health records<\/strong><\/p>\n No comments.<\/p>\n 3.1.2 Metadata and value domains<\/em><\/strong><\/p>\n About the only transactional \u00a0meta data that could be captured here is scan date and scannee (or when using a camera, camera settings and time stamp).\u00a0 I am not sure as to the value of such data.\u00a0 This is covered in 3.3 Design of paper health records, documents and forms<\/em> which details OCR readable identifiers so patient details and test specifics can be automatically added to the file upon scanning.<\/p>\n 3.2 Clinical relevance<\/em><\/strong><\/p>\n \u201c[b] Documents captured in a digitized health record shall \u2013 (iii) be subjected to quality control checkes\u2026to reduce likelihood of errors or omissions arising from digitisation\u2026\u201d<\/p>\n Here the scanned document should be visually compared to the original and signed off (once meta data is confirmed as correct) indicating a full and complete transfer.\u00a0 The scanned document, including meta data should be then be hashed.\u00a0 This will reveal any change to the document following initial conversion and approval.\u00a0 Any changes should be captured by an audit trail (and for scanned images, unless there is an error in the meta data, I do not see why changes would be required).\u00a0 3.4 Support for legal obligations<\/em> (c) states the captured record cannot be altered, though does not details how that can be determined. 3.5 Quality Processes (e) NOTE <\/em>addresses visual inspection and more.\u00a0 4.4.2.1 Required metadata functionality<\/em> describes capturing device meta data<\/p>\n \u201c[d] [iv] minimise the need for clinical personal to re-enter data that already exists in other clinical and administrative systems.\u201d<\/p>\n How would clinical personnel know what has and has not be scanned into an existing system?\u00a0 Shouldn\u2019t 3.1.1 General<\/em> and 3.1.3 Planning for implementation<\/em> cover this?<\/p>\n 3.3 Design of paper health records, documents and forms<\/em><\/strong><\/p>\n Very good.<\/p>\n 3.4 Support for legal obligations<\/em><\/strong><\/p>\n (c) States the record cannot be altered<\/p>\n (d) States alterations need to be authorised and captured with an audit trail.\u00a0 Which is it?\u00a0 (c) or (d)?<\/p>\n (f) Which states the original data should be maintained until QA checks on the scanned document are complete. This should be a standard QA practice regardless of legal obligations.<\/p>\n (h) Audit trails for records access \u2013 very good.<\/p>\n (i) Privacy consents from patient to be recorded.\u00a0 Here perhaps have an expiry period for consent.<\/p>\n (j) Mentions up to date privacy consents, so perhaps this includes an expiry period.<\/p>\n 3.5 Quality Processes<\/em><\/strong><\/p>\n I agree with everything here with the exception of 3.5.4 Key performance indicators<\/em> as such stats should have been captured during operational and performance qualification of the capturing system.\u00a0 KPIs are only of use to determine how much money is spent\/lost reprocessing failed scans.\u00a0 Periodic system revalidation would\/should capture performance metrics and such data should be compared to initial system qualification.<\/p>\n 3.6 Cybersecurity and access control<\/em><\/strong><\/p>\n Suggested: Add \u201c(c) safeguard of data from malicious actors and unauthorised access.\u201d\u00a0 Add malicious actor<\/span> definition to relevant section of standard.<\/p>\n 3.6.2 Unique access credentials<\/em><\/strong><\/p>\n Only single factor authentication is required.\u00a0 Given the sensitive nature of the DHR, at a minimum, 2 factor authorisation should be mandated.\u00a0 Ideally, multi factor authentication would be mandated.<\/p>\n 3.7 Retention and Disposal<\/em><\/strong><\/p>\n Suggested: \u201c(d) Digital records should be backed up across at least two physically distinct locations and employ some form of error checking to ensure the data remains consistent across the sites.\u00a0 Backups should be incremental and for a sufficient time period so data recovery in the event of a disaster can be accomplished.\u201d<\/p>\n The above statement would be just at home in 3.8 Maintenance and operation of a digitizing health record system<\/em>.<\/p>\n 3.8 Maintenance and operation of a digitizing health record system<\/em><\/strong><\/p>\n Suggested: \u201cIf for any reason, it is envisioned decommissioned (scanning) equipment might be needed during the DHR\u2019s legal retention period, said equipment should be retained\u201d.<\/p>\n Section 4 Digitizing health record system (DHRS)<\/strong><\/p>\n 4.1 Key characteristics<\/em><\/strong><\/p>\n (a) states to capture at highest resolution of capturing device.\u00a0 (b) states a loss of resolution is allowed (if permitted or required).\u00a0 Which is it?<\/p>\n (e) (ii) states DHR cannot contain embedded objects.\u00a0 This precludes the use of PDF files or other documents containing text and images or clickable hyperlinks.<\/p>\n 4.3 Image processing<\/em><\/strong><\/p>\n 4.3.1 Required image processing functions<\/em><\/strong><\/p>\n (f) (ii) and (h) States there should be an ability to crop and scale images.\u00a0 Cropping and scaling images effectively reduces the resolution and thus is lossy.\u00a0 This is NOT recommended.<\/p>\n 4.3.2 Desirable image processing functions<\/strong><\/p>\n States that poor contrast, high contrast etc images can be post processed to improve the look.\u00a0 This technically means the original data has been altered.<\/p>\n Suggestion: \u201cAll image manipulations including post processing during conversion an original document into a DHR mist be logged as part of the document\u2019s audit trail.<\/p>\n 4.4.2.1 Required metadata functionality<\/em> (c) mentions the capture, acceptance and processing of image-level metadata so that might be sufficient.<\/p>\n 4..7 Storage of digitized health records<\/p>\n 4.7.1 General<\/strong><\/p>\n \u201cDigitized \u2026records\u2026shall be\u201d (a) Maintained on media which is stored securely in formats that are readily readable and periodically refreshed to ensure that they remain current.\u201d<\/p>\n What is classed as secure?\u00a0 Encrypted?\u00a0 Physically inaccessible (I assume password protected for LAN or WAN access).\u00a0 What does refresh mean?\u00a0 Hardware replacement?\u00a0 Format update?<\/p>\n (b) implies secure facilities.<\/p>\n (d) Reference to backup and disaster recovery plans = very good.<\/p>\n Also a note that backups needs to be tested to ensure they work as intended.\u00a0 Very good.\u00a0 Expanded in 4.7.3 (d)(iii).<\/p>\n 4.7.2 Requirements for storage of digitized health records<\/strong><\/p>\n (b) Keep the primary copy and any secondary or backup copies\u2026on devices physically located within Australia.<\/p>\n Ideally the company providing backup services should also be Australian owned and operated.\u00a0 Why?\u00a0 No conflict of interest related to foreign powers (not that that is really an issue, but I cannot say what foreign intelligence agencies or powers will be able to do with such data with or without the aid of advancements in medical technology).\u00a0 It will also generate Australian jobs.<\/p>\n 4.7.3 Desirable measures for storage of digitized health records<\/strong><\/p>\n Question?\u00a0 Lossless encryption?\u00a0 Lossless applies to compression, not encryption.<\/p>\n Suggestion: remove section (a).<\/p>\n \u201c(d)(vi) Apply timely updates to operating systems, application software, and network operating systems, devices and firmware.\u201d.<\/p>\n Suggestion: Add the following, \u201cAny update should first be tested before being applied to a live system.\u201d\u00a0 This reduces the risk of a loss of data integrity or the introduction of undocumented security holes.<\/p>\n 4.8 Reproduction of digitized health records<\/strong><\/p>\n Comment: How is the dissemination of reproduced records to be managed?\u00a0 Should a password be required to access digitally reproduced records?\u00a0 What steps should be in place to ensure physical copies of reproduced digital records remain private or unseen by unauthorised persons?\u00a0 Will the viewing of reproductions (digital or physical) \u00a0be logged, and if so, how will this be added to the EHR\u2019s audit log?. \u00a0\u00a0Section (c) requires the logging of printing or other reproduction.\u00a0 Should a metadata point be included in the EHR to log the destruction of the duplicated digital record?<\/p>\n Did you find this informative or useful? Please consider a small donation so I can expand and improve on what I deliver.<\/strong><\/p>\n One way I keep myself up to date with developments within laboratories and related areas is by reviewing draft standards.\u00a0 This keeps me appraised of the current state of affairs, keeps my documentation audit skills fresh and potentially allows me to contribute to the content of standards.\u00a0 For this draft standard, I have some knowledge […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,5,17,2],"tags":[29,42,35],"class_list":["post-816","post","type-post","status-publish","format-standard","hentry","category-commentary","category-documentation","category-how-i-benefit-you","category-the-regs","tag-documentation","tag-regulations","tag-standards"],"_links":{"self":[{"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/posts\/816","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/comments?post=816"}],"version-history":[{"count":5,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/posts\/816\/revisions"}],"predecessor-version":[{"id":1201,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/posts\/816\/revisions\/1201"}],"wp:attachment":[{"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/media?parent=816"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/categories?post=816"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/paulyeatman.net.au\/index.php\/wp-json\/wp\/v2\/tags?post=816"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.paypal.com\/en_AU\/i\/scr\/pixel.gif\"){kind=tracking}
<\/p>\n","protected":false},"excerpt":{"rendered":"