hl7 / ieee 11073 meeting in phoenix, arizona, may 2008
TRANSCRIPT
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
ISO/IEEE 11073, IHE-PCD, PHD and NIST
Medical Device CommunicationMedical Device CommunicationTest EffortTest Effort
HL7/IEEE WG Meetings (Phoenix, Arizona)6 May 2008
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Medical Device Test EffortMedical Device Test EffortNIST Team Members
• John Garguilo ([email protected], 301-975-5248)
• Sandra Martinez ([email protected], 301-975-3579)
• Maria Cherkaoui ([email protected] Guest Researcher)
• Richard Theimer ([email protected] Group, Inc., Contractor)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Meeting Topics/Discussion
• Testing focus areas of IHE-PCD– Device to Device (via ISO/IEEE 11073 protocols)– Device to Enterprise (via HL7 protocols)
• NIST Test Tool Inventory (IHE-PCD)• NIST P11073-10202 DIM XSchema (PAR)
– PAR Project Plan– X73-10202 Documentation– Feedback to standards
• IHE-PCD Testing - Next Steps and Future Direction…– Objectives– Technical Framework Profiles Carrier Test Tools– Continue baseline Year 2 and Begin Year 3 Profile development
(roadmap)– Develop Use Cases for new profiles as detail added (roadmap) – Establish example data (useful/necessary for described use cases)
• http://www.nist.gov/medicaldevices
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Test Focus Areas
• NIST Test Tools Inventory– Device Communication
• X73– ICSGenerator – ValidatePDU– XML Schema (IEEE P11073-10202TMD01a)
– Enterprise Communication• IHE-PCD
– Data Mapping from device to “enterprise” (via IHE-PCD Vol II/III Framework Doc)
• HL7 (general across all IHE domains)– MWB (VA), MessageMaker (NIST)– MESA / Kudu (IHE, Steve Moore)– Web Services (mainly Validation) (NIST)– Gazelle (next generation building on Kudu [and other tools])– Cypress Effort – just kicked off
• Cypress wiki: http://collaborate.nist.gov/twiki-cypress/bin/view/Cypress/WebHome
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
IHE-PCD Year 3+ Profile ProposalPCD-Real Time Plug-n-Play
PCD
PCD Client
Device ObservationReporter
Device Observation Consumer
PCD
PCD
PCD-01 &PCD-02
PCD-RT PnP
Device Observation Consumer
Gateway / ManagerX73
APDU
• Validate APDUs against Standard• Determine if APDUs meets device profile (defined using
ICSGenerator)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
What are we doing? Test Tools
Test Tools ICSGenerator ValidatePDU
What is it? Implementation Conformance Statement Generator, Profile builder
X73 Message validation: profile and standard
Why? •Easy to use interface •Based on standard
Promote Interoperability
Who’s using it?
Most major medial device manufactures –IHE-PCD participants (pre-connectathon, connectathon, HIMSS)–PHD participants (smaller devices - Continua effort)
A few small manufactures have expressed interestCountries participating: US, Europe, Japan, Korea, Canada
How is it being used?
As a requirement to standard (ICSs)Early stage interoperability
IHE-PCD profile validationMessage validation
Who are we working
with?
•IHE-Patient Care Domain•Personal Health Device WG•IEEE 11073 WG
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
CEN 13734 and 13735
DIM MOCICS
Reports
DIMXSchema
Compare Devices
HL7/OBXMapping
(XML)
Service Support ICS
ReportService Support
ICS XML
Transport ICS Report
TransportICS XML
General ICS
Report
General ICS XML
Device Specialization
(DIM MOC XML)
Device UML Diagram
ISO/IEEE 11073
DIMPart 10201
NomenclaturePart 10101
ICSGenerator
ICSGenerator Tool and XSchema
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
ICSGenerator Capabilities
• Generates Implementation Conformance Statements (ICSs) – Required in conformance section (10) of DIM x73 document– Ensures common format for ICS generation
• Builds Device Profile (XML) – Generates an electronic (XML) version of device data model based
strictly on the IEEE x73 DIM– Includes private or manufacturer-specific extensions
• Provides validation against DIM Schema– A device data model generated using this tool can be validated against an
updated version of the DIM XSchema
• Provides high level semantic interoperability– Ensures correct containment relationship and terminology at the object
class and related attribute, notification, and behavior level– Compare Device ICSs
• Device ICSs comparison capability aids in identifying potential interoperability issues
• Generates HL7 OBX Segments• Generates Device UML Diagram
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
ValidatePDU Tool
• ValidatePDU: Performs APDU syntax/structure and semantic validation using a MDER Coder.
APDU(XER)
ValidatePDU
(APDU Syntax and Semantic Validation)
Device Profile(xml)
ValidationReport
ROSEapdu(MDER) (MDER + XER Coder)
ValidatePDU
(APDU Syntax and Semantic Validation)
Device Profile(xml)
ValidationReport
ROSEapdu(MDER) (MDER + XER Coder)
ValidatePDU
(APDU Syntax and Semantic Validation)
Device Profile(xml)
ValidationReport
ROSEapdu(MDER) (MDER + XER Coder
Encode/Decode)
(From ICSGenerator)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
ValidatePDU Capabilities
• Validates APDU syntax against X73 DIM specifications and the X73 Application Profiles – Base Standard
• ASN.1 data types syntax.• Object hierarchy, cardinality, acceptable behaviors, notifications and
attributes in compliance with X73 Standards.• Relationship between ROSE and CMIP data types.
• Validate APDU semantic/content against device profile (object, attribute, behavior, notification and services implementation)
– Tool determines if:• a MOC, attribute, behavior and notifications identified in a message is
implemented by the device profile.• attributes identified in a message are implemented as part of a MOC in
the device profile. • the message contains the attribute as required by the device profile
(missing or unrecognized attributes).• the message contains valid MOC information, such as handle and
context-id according to the device profile.• the message contains valid attribute information, such as fixed values
and value ranges according to the device profile.• a behavior identified in a message is supported by the device profile.• MOC objects hierarchy complies with device profile specifications.• the message contains the MOCs as required by the device profile
(missing MOC or unrecognized MOCs)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
ValidatePDU Capabilities
• Decodes MDER PDUs and builds ASN.1 object instances.• Provides an interface to display a parsed message in the
following formats:– XER (in compliance with the standard XER where applicable).
– MDER binary– Enhanced view (JTree representation)
• Generates Validation Reports.• Highlight incorrect fields in enhanced view. • Associates report messages with Test Assertions.
Note: ValidatePDU functionalities are captured in a ValidatePDU Software Requirements Specification document. (Reviewed by members of the WG)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
DIM XSchema Status/Update
• Quick XSchema Component Review • PAR Approval DIM XSchema
– Approval Date: 05-December-2007– IEEE P11073-10202TMD01a Draft Standard for
Health Informatics – Medical Device Communication – Domain Information Model – XML Schema Format
• Project Plan• Next Steps• Future Directions?• Issues (next: May ‘08 IEEE/HL7 WG mtgs)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Next Steps for X73-10202…Call for help w/ P10202 document content, issues, and review• Need (Industry involvement with) V & V
– Verification of translation: DIM XML Schema• Is it a faithful translation?
– Validation of tools by modeling devices• E.g., Monitor, Ventilator, Infusor (PHD devices?)• Do users find the XSchema correct? Usable?• How do we support it?
• 10202 Document and Standardization Process– Usability issues and content
• E.g., mapping of XML to/from paper DIM, nomenclature, etc.– Who is the audience?
• Could be the main users of the doc/project are conformance folks?– Is the draft a reasonable starting place?
• Still need 1 or more iterations to get things organized?– Tracking
• Issues: e.g., Informative vs. Normative, how do we handle copyright and IP issues, etc…
– Establish review process for DIM XSchema• Establish core review group
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
IHE-PCD Year 3+ Profile ProposalPCD-Real Time Plug-n-Play
PCD
PCD Client
Device ObservationReporter
Device Observation Consumer
PCD
PCD
PCD-01 &PCD-02
PCD-RT PnP
Device Observation Consumer
Gateway / ManagerX73
APDU
• Validate APDUs against Standard• Determine if APDUs meets device profile (defined using
ICSGenerator)
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
IHE-PCD Testing
• IHE PCD Testing – Key Objectives– Increase test comprehensiveness & quality – Support both conformance & interoperability testing– Coordinate with IHE Gazelle Project– Establish single framework for PCD covering increasing complexity
and technologies over next 5 years– Support for pre- & virtual connectathons, actual connectathon &
enable year round testing– Generate work products that companies can use in their regulatory
submissions– Remain in alignment with IHE-PCD profile development road map
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
IHE-PCD Testing
• IHE PCD Testing – See Visio Diagrams– PCD Technical Framwork Documents (Transactions and Content)– IHE-PCD Profiles
• ACM Alarm Comm. Management• DDT Device Document Template• DEC Device Enterprise Comm.• DS- Device Specializations• PIV Point-of-care Infusion Verification• MEM Medical Equipment Mgmt.• PIB Patient ID Binding• PNP Plug-and-Play• RTM Rosetta Term Mapping• SPD Subscribe to Patient Data• RM Remote Monitoring
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Gazelle moving forward (from Steve Moore’s slide set)
• Healthcare Enterprise Testing discussed– Monitored Single and Collaborative
• Connection Testing– Monitored Single and Collaborative
• Pre-Connectathon– Self-graded, singular– Integration testing via Internet
• Virtual Connectathon– Supplement w/ monitor– Monitored single– Collaborative via Internet
• Company Internal– Unmonitored, Single– Self-graded Single– Unmonitored Collaborative– Internet Collaborative
• Certification Testing– Not an IHE category– Extension of monitored testing with appropriate rigor
• Building a Gazelle• Openness, transparency, free distribution
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Gazelle Process… (from Steve Moore’s slide set)
• Control System– One of Several
• Connection Testing• Private Vendor Testing• Internet Testing
• Test Engine– Base Test Engine
• Test Engine by Profile• Test Engine by Kind of Testing
– Connectathon, Singular
• Data Store/Data Base• Simulators – Actors• Validation Services
– Pick Validation Service(s) based on region
• Test Scenarios• Demographic Services
– IHE Japan may need particular encoding for Japanese Language– Based on region– Seed tests with different data
• Proxy – to/from- System Under Test
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Gazelle Process (cont.)…(from Steve Moore’s slide set)
• Run Gazelle…– Users register systems/actors/profiles
• Handoff from Controller to Test Engine• Determining Points of Intersection- collaboration areas?• Data Structures/Files in Gazelle• Gazelle Common Interfaces
– Controller/test engine– Test Engine/Simulator, etc…
• Simulators• Other Gazelle Needs
– Authoring Tools
Soft
ware
Dia
gn
osti
cs a
nd
Con
form
an
ce T
esti
ng
D
ivis
ion
Potential Future Direction…
• Gazelle Detailed DEC Test Scenario– Test Scenario
• Actors / Evaluation Items• Notes and Questions• Message Profile and Data
– Transactions [1..x] e.g., communicate data, query data… » Segment Spec and Data (e.g., MSH, OBX, etc.)
• *Validation Criteria– Transactions [1..x] e.g., communicate data, query data…
» Message Profile» Table Definitions» Test Case Specific Validation Criteria
• *Validation CriteriaSpecified for the purpose of determining whether or not
the implementations successfully completed the tests