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

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

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

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

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

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

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

7. Results

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

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

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

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

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

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

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