hl7 nlm ehr project n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
HL7 NLM EHR Project PowerPoint Presentation
Download Presentation
HL7 NLM EHR Project

play fullscreen
1 / 23

HL7 NLM EHR Project

104 Views Download Presentation
Download Presentation

HL7 NLM EHR Project

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. HL7 NLM EHR Project alschuler.spinosa CommerceNet Webify Liora Alschuler liora@the-word-electric.com

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

  3. Contract: how quick & how dirty is quick & dirty? • 5 weeks • “120” hours • Lightweight • Find and retrieve baseline, human-readable information

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

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

  6. 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 Attachements (ASIG stylesheet)

  7. Interim report • Infrastructure • Messages • Data

  8. Interim report: infrastructure • PHIN-MS • Requires 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 abit of time • Now developed and working, will be deliverable back to CDC

  9. Interim report: infrastructure • Input into standards process: • Should review with security and accountability SIG

  10. Interim report: Messaging • Candidate areas of V3: • V3 messages to be considered: (from RFP) • 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)

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

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

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

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

  15. Interim 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) • … this just in… sample available from HIMSS demo 2004 courtesy Epic systems

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

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

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

  19. Application overview • Requesting a document

  20. Showing what’s available

  21. Transforming the document

  22. … and delivery

  23. Thank you! Questions?