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 ID: 1038936
Download Presentation The PPT/PDF document "A Summary Care Record Architecture based..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. A Summary Care Record Architecture based on HL7 CDA and SOAMr. Peter GivenComputing and Mathematics DepartmentInstitute of Technology, Tralee
2. IntroductionThis paper shows how Service Oriented Architectures can be combined withthe HL7 Clinical Document Architecture to facilitate the sharing of Summary Care Records between health care information systems
3. GoalsThe 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
4. System ArchitectureThe 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.
5.
6. Data LayerThe Data layer involves the capture and storage of patient information in a GP Information SystemAn Open source GP Information System was chosen to represent legacy open source GP Systems (openEMR)
7. OpenEMRA free open source medical practice management and electronic medical records application (www.openemr.org)Licensed under GNU GPLOperates in Linux, FreeBSD, MacOS X and WindowsA client/server architecture written in PHP with a mySQL database – downloadable as a WAMP application
8. OpenEMRThe 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
9. Functionality of OpenEMRThe application storespatient demographic datapatient encounter informationvital signslaboratory resultsprescriptions and allergy information.The system also allows the management of appointments and the generation of reports.
10. OpenEMR
11.
12.
13.
14. Interfacing to OpenEMRThe 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
15. Interfacing to OpenEMRIndexSCR
16. Interfacing to OpenEMRThe 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
17. 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 TextImagesSoundsother multimedia content.Document-level, section-level and entry-level templates availableThe content of CDAs defined in the HL7 Reference Information Model and HL7 Data Types
18. CDA Structure<ClinicalDocument> ... CDA Header ... <StructuredBody> <section> <text>...</text> <Observation>...</Observation> <Observation> <reference> <ExternalObservation>...</ExternalObservation> </reference> </Observation> </section> <section> <section>...</section> </section> </StructuredBody> </ClinicalDocument>
19. Summary Care Record as a CDA documentThe Summary Care RecordHeaderTitle, Time, Confidentiality Code, Version Number, Record Target (PatientRole, Patient Name, Gender, Birth Date), Provider Organization, Author, Custodian, Legal Authenticator, Encounter InformationSection Allergies and Adverse ReactionsSection Medications
20. Prescription Record as a CDA documentThe Prescription Record HeaderTitle, Time, Confidentiality Code, Version Number, Record Target, Prescription Provider Organization, Author, Custodian, Legal Authenticator, Encounter,Section Prescription Informationdrug name, quantity, dosage, refills and notes
21. Interfacing to OpenEMRIndexSCR
22. Implementing the interfaceThe Interface Engine was coded using PHP/DOM and using a CDA document/section template schemaThe 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
23. Mapping inconsistenciesAlso the openEMR system stores dosing intervals asqid, bid, q3hwhile the CDA document needs these intervals to be represented as time periods and unit (e.g. 3 hours).
24.
25. Designing the Communication LayerThe Communication layer was designed in two parts.MPI Subsystem :The first part is the design of a distributed Master Patient IndexRecord 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.
26. Master Patient Index SubsystemThe 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
27.
28. Patient IndexThe patient index is designed to hold the following information: document type etcThe patients’ surname and first nameThe patient’s date of birthThe patient’s PPS numberThe organisations’ id and nameThe 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.
29. Generating Master Patient IndexIndexSCR
30. Generating a patient index from OpenEMRThe index information is initially retrieved from the openEMR Clinical Information System using the data layer interface as described aboveThe index information is wrapped in an XML message. A typical message is shown below:
31. 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</Endpoint></SCR_Advert>
32. Peer AdvertisementThe 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-59616261646162614E50472050325033272C475C1C34441780008001</Avert_ID>MPI Infromation</SCRAdvertisement>
33. Peer to peer networkA 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.
34. Searching for a Patient IndexThe 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.
35. Implementing MPI ApplicationThe 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.
36.
37. Searching for a patient summary care recordsOnce 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
38. Security in the Peer NetworkThe 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.
39. Record Retrieval SubsystemSOA is used to deliver the Summary Care RecordA 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
40.
41. SOA SolutionA Web Services Server called Cape Clear was used to build the SOAThe 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 JavaIt generates SOAP requests which are sent to the sever and the response contains either a Summary Care Record or a Prescription Record
42. Retrieving the Summary Care RecordThe 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
43.
44. Integrating the CDA recordA 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
45. Viewing the RecordOnce 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.
46.
47.
48. Application areasOut of Hours Services – telephone triage etcEmergency ServicesCommunity Nursing
49. Conclusions: AdvantagesGP 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 exchangeOther summaries can be implemented easilyTechnology StandardizationsSOA and Web ServicesDistributed MPI with location information
50. Conclusions: ChallengesTechnical barriersEach GP system requires an interface Engine to generate CDA documentsGP database may not hold required informationGP Communications System is a hybrid SOA/P2P solutionSecurityCostDistributed MPI with location information
51. Thank You! Questions?