Mr. Peter Given

wrendeceitInternet and Web Development

Oct 21, 2013 (4 years and 17 days ago)

81 views

Mr. Peter
Given

Computing and Mathematics Department

Institute of Technology, Tralee


Introduction


This paper shows how


Service Oriented Architectures can be combined with


the HL7 Clinical Document Architecture to facilitate


the sharing of Summary Care Records between health
care information systems

Goals


The solution demonstrates that


A federated architecture based on SOA and coding
standards is a viable alternative


to a centralized record architecture for the sharing of
summary care records

System Architecture


The design describes a system that facilitates the
sharing of documents from the electronic medical
record between GPs and other healthcare providers
(Out of hours, emergency etc)


The architecture facilitates storing healthcare data
locally and querying the data via an indexing
mechanism.


Data Layer


The Data layer involves the capture and storage of
patient information in a GP Information System


An Open source GP Information System was chosen to
represent legacy open source GP Systems (openEMR)

OpenEMR


A free open source medical practice management and
electronic medical records application
(www.openemr.org)


Licensed under GNU GPL


Operates in Linux, FreeBSD,
MacOS

X and Windows


A client/server architecture written in PHP with a
mySQL

database


downloadable as a WAMP
application




OpenEMR


The system is being used successfully at a number of
sites [86,87,89].


A number of commercial companies are also
supporting the software [88,89,90].


Not based on any EHR Standards but has some
support for coding standards

Functionality of OpenEMR


The application stores


patient demographic data


patient encounter information


vital signs


laboratory results


prescriptions and allergy information.


The system also allows the management of
appointments and the generation of reports.


OpenEMR

Interfacing to OpenEMR


The project entailed building an Interface Engine was
developed in order to extract:


A Summary Care Record (SCR).


This will hold patient demographic data along with known
allergies and any medications prescribed in the last 6 months.


A Prescription Record (PR).


This will contain demographic details and prescription
information that can be forwarded to a pharmacy system.


A Patient Index for the SCR

Interfacing to
OpenEMR

Index

SCR

Interfacing to OpenEMR



The HL7 Clinical Document Architecture was chosen
as the document architecture standard.


The Interface Engine retrieves data from openEMRs
databases and construct CDA conformant documents
using the CDA schema



HL7 CDA



The HL7 Clinical Document Architecture (CDA) is a
document
markup

standard that specifies the structure and
semantics of "clinical documents" for the purpose of
exchange
” (HL7 website)


A CDA document can include


Text


Images


Sounds


other multimedia content.


Document
-
level, section
-
level and entry
-
level templates
available


The content of CDAs defined in the HL7 Reference
Information Model and HL7 Data Types

CDA Structure


<
ClinicalDocument
>


... CDA Header ...


<
StructuredBody
>


<section>


<text>...</text>


<Observation>...</Observation>


<Observation>


<reference>


<
ExternalObservation
>...


</
ExternalObservation
>


</reference>


</Observation> <


/section>


<section>


<section>...</section>


</section>


</
StructuredBody
>


</
ClinicalDocument
>

Summary Care Record as a CDA
document


The Summary Care Record


Header


Title, Time, Confidentiality Code, Version Number, Record
Target (
PatientRole
, Patient Name, Gender, Birth Date),
Provider Organization, Author, Custodian, Legal
Authenticator, Encounter Information


Section


Allergies and Adverse Reactions


Section


Medications


Prescription Record as a CDA
document


The Prescription Record



Header


Title, Time, Confidentiality Code, Version Number, Record
Target, Prescription Provider Organization, Author, Custodian,
Legal Authenticator, Encounter,


Section


Prescription Information


drug name, quantity, dosage, refills and notes


Interfacing to OpenEMR

Index

SCR

Implementing the interface


The Interface Engine was coded using PHP/DOM and
using a CDA document/section template schema


The mapping from the
openEMR

database to the CDA
schemas was incomplete as the database did not hold
all the data specified in the CDA document schema.


For example
openEMR

currently does not store clinical
codes with separate parts of the medical record so the
code fields in the CDA documents were left empty

Mapping inconsistencies


Also the openEMR system stores dosing intervals as


qid
,
bid
,
q3h


while the CDA document needs these intervals to be
represented as time periods and unit (e.g. 3 hours).

Designing the Communication
Layer



The Communication layer was designed in two parts.


MPI Subsystem
:The first part is the design of a
distributed Master Patient Index


Record Retrieval Subsystem
: The second part of the
design allows the user to retrieve the Summary Care
Record or prescription record using a Service Oriented
Architecture.


Master Patient Index Subsystem


The Master Patient Index was designed on top of a
peer
-
to
-
peer network called the
GP Peer Group
.


A GP with the correct credentials can join and leave
the peer network.


The GP can then publish patient indices to the
network.


The index advertises the existence of a Summary Care
Record for a patient and the endpoint address for that
record

Patient Index


The patient index is designed to hold the following
information:


document type etc


The patients’ surname and first name


The patient’s date of birth


The patient’s PPS number


The organisations’ id

and name


The endpoint where the full Summary Care Record can be
found.


The information to build the index was extracted from
the
openEMR

system by the Interface Engine.

Generating Master Patient Index

Index

SCR

Generating a patient index from
OpenEMR


The index information is initially retrieved from the
openEMR

Clinical Information System using the data
layer interface as described above


The index information is wrapped in an XML message.
A typical message is shown below:


Example Mater Patient Index


<?xml version="1.0" ?>


<
SCR_Advert
>


<
Document_CDA_Type
>11488
-
4</
Document_CDA_Type
>


<
Document_Name
>Summary Care Record</
Document_Name
>


<
Document_Description
>Clinical
Document</
Document_Description
>


<
Patient_Surname
>
Bloggs
</
Patient_Surname
>


<
Patient_Firstname
>Joe</
Patient_Firstname
>


<
Patient_DOB
>19670425</
Patient_DOB
>


<
Patient_PPS
>1</
Patient_PPS
>


<
Organisation_ID
>6</
Organisation_ID
>


<
Organisation_Name
>givens
sugery
</
Organisation_Name
>


<Endpoint>http://localhost:8080/ccx/mySCRInterface</Endpoin
t>


</
SCR_Advert
>


Peer Advertisement


The peer
-
to
-
peer software uses this information to generate
a
peer advertisement
which appends the following
header



<?xml version="1.0" ?>


<!DOCTYPE
SCRAdvertisement
>


<
SCRAdvertisement

xmlns:jxta
=
http://jxta.org
>


<
Advert_ID
>urn:jxta:uuid
-
59616261646162614E50472050325033272C475C1C344417800
08001</
Avert_ID
>


MPI
Infromation


</
SCRAdvertisement
>


Peer to peer network


A node can both publish to and search this network for
indices.


To search for a particular patients SCR a discovery
message is propagated to all peers in the network.

Searching for a Patient Index


The metadata contained within the index will improve
the search results from the discovery process.


Once a peer has retrieved the index for a patient the
endpoint information is retrieved from the index.


The second part of the communication layer will now
use this endpoint to retrieve the actual Summary Care
Record from the system in which it is stored.

Implementing MPI Application


The MPI application itself consists of Java Swing
components that implement a Graphical User
Interface, along with calls to the JXTA API to join the
GP Peer Group network and to publish/discover
advertisements
on the network.



Searching for a patient summary
care records


Once the user provides values the peer sends a discovery
message to the other peers on the sub
-
network.


Any Rendezvous peers on the local sub
-
network will
further propagate the discovery message to other sub
-
networks they know about.


Any advertisements that match the surname/PPS number
are returned to the requesting peer.


Clicking on a particular patient from this list will show the
endpoint where the full Summary Care Record can be
found.


This endpoint information is now presented to the Web
Service client to retrieve the patient’s full Summary Care
Record

Security in the Peer Network



The JXTA configuration requires a username and
password. A certificate may also be required.


Once the peer starts up it can issue discovery messages
to locate other peer groups it may wish to join.


The peer groups enforce a second level of security. The
user must supply a login name and password to join
the GP Peer Group.


Record Retrieval Subsystem



SOA is used to deliver the Summary Care Record


A client program that knows the endpoint address can
send a message to a Web Service on the GP site to
retrieve the Summary Care Record as a CDA document

SOA Solution


A Web Services Server called Cape Clear was used to
build the SOA


The Web Service was defined in WSDL using Cape
Clear Studio.


The Web Service was implemented in Java and uses
the SOAP protocol at the messaging layer.


A Web Services client was built in Java


It generates SOAP requests which are sent to the sever
and the response contains either a Summary Care
Record or a Prescription Record

Retrieving the Summary Care
Record


The Web Service had two services;
getSumaryCareRecord

and
getPrescriptionRecord
.


Both services require the patient’s PPS number (a
java.String
) and the patient’s surname (
java.String
).


The service returns a CDA documents (also as a
java.String
) if one exists

Integrating the CDA record


A reverse process to that taken to generate the data at
the data layer could be followed in order to integrate
the data with a local system.


For this project it was enough to be able to view the
record

Viewing the Record


Once the record is saved the user can finally view the
file.


A standard XSL transform is attached to the file.


The transform creates an HTML document that can be
viewed by any browser.


The document can also be printed out.


Application areas


Out of Hours Services


telephone triage etc


Emergency Services


Community Nursing


Conclusions: Advantages


GP buy in



can maintain their systems of choice (open source or
commercial)


GPs can maintain their records locally (pull model)


Healthcare Standardization


CDA for clinical document exchange


Other summaries can be implemented easily


Technology Standardizations


SOA and Web Services


Distributed MPI with location information

Conclusions: Challenges


Technical barriers


Each GP system requires an interface Engine to generate
CDA documents


GP database may not hold required information


GP Communications System is a hybrid SOA/P2P
solution


Security


Cost


Distributed MPI with location information

Questions?