Published on March 6, 2014
The Prototype of Standalone Diagnostic Report Editor as a Proof-of-Concept for an Interoperable Implementation of Health Level Seven Clinical Document Architecture Standard (HL7 CDA) not Integrated with Electronic Health Record (EHR) System Sebastian Bojanowski, Roman Radomski iEHR.eu, Warsaw, Poland September 28, 2012
Background • Low number of EHR systems implemented in some countries or regions is one of the causes of limited widespread use of the HL7 CDA standard. • EHR systems are perceived as too expensive for small service providers. • Lack of EHR system implemented results in paper-based cooperation in service ordering and reporting.
Example of paper-based document exchange process Referral document (paper form) Delivered by patient Study report document (paper form) Main service provider Shared EHR Usually delivered by patient Service performance report (unspecified form) Delivered in agreed process, not supported by any computer system Subcontractor of specialized medical service
Objectives • Investigation of feasibility of fully interoperable implementation of HL7 CDA standard: – at small medical service provider, – with no EHR system implemented, – for electronic medical documents exchange with bigger partner having implemented EHR system. • Design of HL7 CDA documents structure for document exchange scenario. • Development of proof-of-concept prototype of standalone HL7 CDA document editor.
The concept criteria • • • • • Minimum cost of software purchase and external services. No database system. No online connection during patient visit and document issue. No need of integration with any other systems. Full compliance with the CDA standard and best practice of CDA implementation. • Interoperability based on CDA only, with no extensions, no templates or profiles agreed with the referring health care provider (intended recipient of the report). • Maximum use of data from available sources to minimalize the amount of data being entered by the user.
Methods • Diagnostic ultrasound has been chosen as an example of document exchange scenario: – ordered by health care provider using the EHR system, – performed by subcontractor with no EHR system of its own. • HL7 CDA Release 2 have been chosen as a standard of exchanged medical documents (referrals and reports). • Functional requirements and architecture for the prototype have been defined. • Assumptions have been verified during development of the prototype.
HL7 CDA Implementation • Any level of Referral document conformance to HL7 CDA is supported. • The Report document will be conformant to the HL7 CDA on level 2. • There is no concept-related limitations to the potential use of clinical statement based content (HL7 CDA on level 3) – it is only the matter of Report Text Editor complexity. • The Report document content is constrained: – mainly by the Report Template, – by the Referral document (for PatientRole and Order elements). • All documents opened or generated in the prototype (referrals and reports) are structurally validated against embedded CDA XSD schema.
The need for initial online registration • Due to the requirement for the identifiers to be globally unique the document editor cannot be standalone product. • Some configuration data must be registered by the third party and serialized to the working instance of the Report Editor. • Configuration required at the initial point: – Report template generation for specific document exchange scenario. – OID namespace assignment per generated report template for document identifiers. – OID node assignment for user’s organization. – OID identifier assignment for: • author, • legal authenticator (in most cases the same as author), • service performer (in most cases the same as author).
Report document data sources • Report Template • Referral document: – patient role, – order with procedure code. • Data entered by the user in the Report Text Editor: – – – – document title, document issue time, procedure code, report study details. • Data generated by the prototype’s script: – extensions for document id and set id, – document version number, – date for authoring, legal authentication and service event. ClinicalDocument Id.root code confidentialityCode languageCode setId.root Author Custodian LegalAuthenticator DocumentationOf ServiceEvent Performer StructuredBody Section title: ST Section
Data flow between referral and report documents Referral document title: ST RecordTarget RecordTarget Author Author InformationRecipient LegalAuthenticator Custodian Custodian DocumentationOf LegalAuthenticator InFulfillmentOf ServiceEvent StructuredBody Order Section text: ED Report document code: CE id: II effectiveTime: IVL<TS> code: CE Performer Entry StructuredBody Procedure classCode: PROC moodCode: RQO Section Section title: ST text: ED text: ED
The prototype in real world • The reason for development and implementation of simple applications similar to our prototype is limited to specialized medical providers, which do not need the EHR system. – The typical EHR system functionalities, like complex searching, sharing, analysis and processing of data extracted from medical documentation are not needed. • According to the current Polish regulations, there are two possible cases for such implementation: – When the potential system owner uses electronic form of documents for their exchange with its partner, but documents are printed for the purpose of archiving. – The partner takes over the responsibility for the whole document management process.
Conclusions • It is possible to use basic, open source tools to implement an interoperable solution based on HL7 CDA standard in the environment with no EHR system at minimal cost of software purchase and maintenance. • The requirement of no integration with other systems, except an interoperable exchange of CDA-conformant document, has been proven as possible and reasonable to implement. • All header data for the report document may be copied from the Referral document and from the Report Template. • The Report Template has to be generated by the external party to allow proper use of global identifiers. • Using the build-in standard transformation for presentation results in different appearance of the document for its authenticator and for the recipient. • Using only embedded XSD schema lacks any kind of semantic validation, but it is possible to implement schematron for the prototype.
Two Polish presentations at IHIC 2016. Thursday March 24th, ... © 2012-2016 iEHR.eu • HL7 and CDA are the registered trademarks of Health Level Seven ...
We help to implement healthcare interoperability standards HL7 CDA ... Two Polish presentations at IHIC 2016; ... MCRO and iEHR.eu cooperate in Rheumatoid ...
presentations. In order to facilitate evaluation ... IHIC 2012 - Call for Papers Author: Seifter Peter;Stefan.Sabutsch@elga.gv.at;email@example.com
Imam Husain Islamic Centre, ... Upcoming Events at Imam Husain Islamic Centre. visit: www.ihic.org.au for more information. ... 2012. Highlights All ...
Presentations; IHIC Highlights ... award for 2012 and the American Collage of ... endorsing partner of this Convention, please email firstname.lastname@example.org ...
... (IHIC) is an annual ... Austria (2012) ... Since 2011, presentations at IHIC conferences can be awarded with the Joachim W. Dudeck Award.
CONNECTING THE HOSPITAL TO THE PATIENT: PATIENT PORTALS AND MOBILE. Dr. Osama Alswailem. Director, ... 2012. 546. Postpone Appointment Request . 2012. 247.
HIMSS Middle East 2013 Unlocking technology’s potential to ... Copyright © 2012 Accenture. All rights reserved.Copyright © 2013 Accenture.