230 likes | 328 Views
HL7 NLM EHR Contract Phase I. alschuler.spinosa CommerceNet Webify Liora Alschuler liora@the-word-electric.com. RFQ: Develop Phase I EHR Query-Response Message Set. The system components will be assembled from existing open source implementations, the initial components of which are:
E N D
HL7 NLM EHR Contract Phase I alschuler.spinosa CommerceNet Webify Liora Alschuler liora@the-word-electric.com
RFQ: Develop Phase I EHR Query-Response Message Set • The system components will be assembled from existing open source implementations, the initial components of which are: • Transport/encryption/data integrity - candidate CDC PHIN-MS • Phase I EHR Query-Response Message Set- developed within NLM project by modifying existing messages
Contract: how quick & how dirty is quick & dirty? • 5 weeks • “120” hours • Lightweight • Find and retrieve baseline, human-readable information
Objectives • How easy can we make it to request and receive human-readable information? • What HL7 components are available? • Identify • Implement • Major deliverables: • Operational prototype, proof-of-concept software and implementation guide • Report on what works as-is, what requires modification, constraint or extension, where gaps lie and recommendations on best direction moving forward • Input into the standards development and refinement process
Scenario: • Client: requestor, low-end, small office, low-cost, simple, web-enabled • Server: data source, high-end, large facility, more sophisticated technically • Client can request, receive documents; Server can respond to query, supply documents • Server backend database has mix of data sources including non-CDA reports, CDA, V2 and V3 lab results
Primary components • CDC’s Version 2 PHINMS messaging system • MS SQL Server database development license used locally by CommerceNet, other participants, including HL7, to supply own license • Version 3 query/response messages: Shared Messages, Medical Records • Utility to transform unstructured documents into CDA R1 (non-XML body): Webify • Client application for query definition and viewing of retrieved documents: Webify • Style sheet for displaying CDA R1 documents: adapted from one developed for CDA Claims Attachments (ASIG stylesheet)
Final report • Infrastructure • Messages • Data
Final report: Infrastructure • PHIN-MS • Required addition of asp message handler • CDC had not implemented message handler talking to asp page; this was in the functional spec, but undocumented, so it took a bit of time • Now developed and working, will be deliverable back to CDC • Input into standards process: • Should review with security and accountability SIG
Final report: Messaging • Candidate areas of V3: • V3 messages to be considered: (from RFQ) • Transport Specifications: • ebXML, Release 1 DSTU - Pending Board Approval • Webservices SOAP/WSDL Profile, Release 1 DSTU - Pending Board Approval • MLLP, Release 1 ( Membership #1 ) • Common Domains: Shared Messages: • Act Status Topic • Act Reference Topic QUMT (document query and query response) • Infrastructure Management: Transmission Infrastructure: • Generic Message Transmission • Polling Message Transmission • Infrastructure Management: Query Infrastructure: • Query Control Act Topic • Infrastructure Management: Master File/Registry Infrastructure: • Master File Registry Topic • Health and Clinical Management: • Clinical Document Architecture • Laboratory: Result Topic • Medical Records: Document Topic RCMR (document request & retrieve) • Public Health Reporting: ICSR Topic • other, as desired (eg, Pharmacy, Blood Bank and so on)
Final report: Messaging • Input into standards process: • Query messages: QUMT (document query and response) -- CQ/OO/MRM: • Review query parameters • Review document parameters in query response • Retrieve messages: RCMR (document request and retrieve) – MRM/SDTC • Accelerate creation of MRM query-by-parameter message • Future consideration: query-by-example (new MRM/SDTC project), constrained for implementation • Promote use of MRM retrieve messages, possibly open issue with OO as well
Final report: Clinical content • 4 types of native data format: • CDA • Henry Levin 7th (Release 1 Membership ballot sample) • MS Word • CCR sample by Dr. Tom Sullivan • Transform to CDA • V2 lab result • Result sample provided by Mike Henderson • Transform to CDA • V3 lab result • Result in development (HIMSS 2004 as basis)
Final report: Clinical content • Input into standards process: • CDA R1 sample: no issues • Word to CDA: no issues • V2 lab to CDA: rich source of issues to bring forward within SDTC, in conjunction with O&O
Lab2CDA Transformation Issues • document ID: for every transform or every source document? • timestamp: time of source report creation? transmission? time of transform? • document type code: no LOINC scale=doc • provider: CDA assumes role in encounter; relationship to lab unclear • referring physician: anticipates an encounter • lab tech: no such role • order status: no such status • authentication: who is the authenticator?
Final report: clinical content • Input into standards process: • CDA R1 sample: no issues • Word to CDA (show): no issues • V2 lab to CDA: rich source of issues to bring forward within SDTC & O&O, many resolved in R2 • V3 lab to CDA: in progress… input to O&O: • Sample generation non-trivial because in active development • Cross-enterprise interaction modeling an incremental challenge beyond V2 • Schema generation complex (multiple CMETs) • Sample available from HIMSS demo 2004 courtesy Epic systems
Functional description • Client: Invoke Send Query GUI, enter query parameters (patient ID; optional: document type, provider, date range) • Completed query, packaged in PHINMS and sent to Server. • Server unpacks query, searches for corresponding artifacts, formats response per guidelines, and sends response to Client listing matching data. • Client (requesting system) receives response, unpacks message, and renders response as HTML list in browser. • User selects one or more records to retrieve, sends request to Server. • Server unpacks request, identifies records to be retrieved; if needed, transforms them to CDA R1, packages in message and sends back to Client. • One or more documents received, can be displayed by Client using CDA R1 style sheet on Client java-enabled web browser.
Client Server Client Sends HL7 Query Server gets data from db and creates a HL7 V3 response Server sends HL7 Response with a list of document metadata Client parses HL7 V3 response and displays it on screen Client Sends HL7 Query with specific document ID Server transforms/gets CDA document from db and creates a HL7 V3 response Server sends HL7 Response with a CDA document Client parses CDA document response and displays it on screen
Do you have a referral for Zsazsa from June ’03? Okay, here it is Yes, several I’ll take that one Thanks! patientID=x123 docType=LOINCxxx date=YYYYmmDD
Application overview • Requesting a document
For More Information • Contact for technical Info Gary Griffin Technical Consultant Rainbow Builders Intl RainbowBuilder@comcast.net • Downloads Phase I Deliverable (2c) - Implementation Guide http://hl7.org/nlmcontract/ehrfiles.cfm
Thank you! Questions?