iEHR.eu IHIC 2012 Presentation
Upcoming SlideShare
Loading in...5
×
 

iEHR.eu IHIC 2012 Presentation

on

  • 136 views

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 ...

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

Statistics

Views

Total Views
136
Views on SlideShare
103
Embed Views
33

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 33

http://iehr.eu 33

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

iEHR.eu IHIC 2012 Presentation iEHR.eu IHIC 2012 Presentation Presentation Transcript

  • 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.
  • Results
  • 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 implementation • The prototype has been developed using open source components only, and does not require any commercial software to run, except Microsoft Windows operating system. • It is implemented as a single HTML file containing: – JavaScript code – Files embedded as a base64-encoded strings: • Report Template (CDA XML), • XSL stylesheet for tranformations for presentation, • CDA XSD schema for structural validation. • There are some operational parameters that must be stored in a browser persistance mechanism: – Next available document Instance Identifier extension – List of setId.exension and versionNumber.value pairs from all modified documents – to prevent older versions of a document to be corrected once again.
  • 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.