word2007打不开doc Agenda PCD TC F2F June 2007.doc

Minutes

PCD Technical Committee

Face To Face June 20-21, 2007

DRAFT

Andover, 8 am - 5 pm

June 20, 2007

Marion Blount, Todd Cooper, Al Engelbert, Manny Furst, Ken Fuchs, John Garguilo, Jack Harrington, John Hotchkiss, Andrew Kim, Slav Lerner (second day), Bridget Moorman (first day), I. K. Mun, Steve Weisner, Jan Wittenber, Ray Zambuto

Dr. Marion Blount, guest, is a Research Staff Member, IBM TJ Watson Research Center.

Standards Coordination - HL7 and TC251 have made a proposal to TC215 for coordination. Jan Wittenber

There is a proposal for a joint working group between CEN, ISO and HL7 to facilitate collaboration. Jan submitted several objections/concerns, including the exclusion (at least initially) of other SDOs such as IEEE and DICOM and the additional burden this presents. Jan also feels that existing mechanisms for coordination and extensions as needed can overcome the concerns that led to this proposal. Jack voiced a concern that the SDOs are legally independent and considered as such by ANSi; thus coordination may be seen as unbalancing and legally an issue. On the other hand, Todd supported the concept as meeting the national efforts requirements for meeting deadlines while multiple countries are working on the same issues.

Schedule for 2007-8. Ray.

The public comments period for the Supplements is followed by release by Aug. 15 of the Call for Participation (for opening of the Connectathon and Showcase applications). The TC Tcon meeting on the 27th is intended to finalize the Supplements.

Change proposal deadline moved to July 15.

Preparing the Supplements for Public Comment: the primary focus of the F2F meeting. Discussions led by Paul Schluter, Ray Zambuto and Todd Cooper.

Patient ID Binding (PIB)

Two use cases:

1. Associate device with patient

Define patient info from ADT

Query patient registry for ID/demographics

2 Suspend Associations

3 Resume Association

4 Disconnect then associate with another patient Part of the complexity is to reduce burden by not requiring set up of each device

individually. Potential for “high level” patient “control” point. The PnP may be used to assure consistency; e.g., for several devices connected through a gateway.

Bridget raised several concerns: System must reduce clinician effort; adding steps is unacceptable. Jack suggested that a standard semantic for patient demographics would make data entry simpler and independent of technology (bar code, rfid). This could be accomplished by HL7 or other entity. Standardization would be of significant help. Jan described several processes for associating the patient at the device level as opposed to the gateway level. This may complicate the Suspend or other transactions.

This led into discussion of issues Ray had identified as well as related issues:

Discussion of simplicity for the caregiver and the need to associate with the device, with the DOR and with the DOC in order to provide flexibility. Jan suggested introducing new actors: Patient ID Reporter, Patient ID Consumer (an API) and possibly a Patient ID Manager. Benefits include: minimizing user effort, ability to communicate the

information among the other devices within a context at a given time and place, ability to accommodate legacy devices. The device ID can be the key to associating that device on that patient with another DOR, e.g., ambulatory patient. Initial associations of the patient will require caregiver acceptance. Note: these are actors, not physical elements, so that (for example) a gateway sending patienr ID information to a device takes on a different actor role.

Question 2.2.4: What happens if a device is placed in use but the patient has not been bound? The enterprise would then not receive data (or alarms) but local data is acquired and alarms are available for patient care and safety. Data is not sent to enterprise until there is a patient association; but there may be a John Doe policy. Note: the DOR is responsible for placing the patient ID in the message. DOCs will not accept data without patient ID.

Ray translated the additional actors, inserting them in the PID diagram.

The Use Cases were then examined in detail to determine if the actors are functionally sufficient. Among these are ways to generate the pient id under various conditions: the ADT feed is continuous and the DOR builds a database of possible patients (PAM), a query (PDQ), manually, or when the patient demographics are unknown, automatically (time and device MAC address) as appropriate. This last approach can also be used as an audit trail as a complement to the other binding mechanisms.

Suspend is an operational issue at the DOR. It does not deal with the Patient ID and thus is out of scope for this Profile. The difficult case here is when the patient device was in a suspended mode and placed on a different patient without having been unbound from the patient.

Real Time Point of Care (PoC) Plug and Play (PnP) Easy

Plug and play

Real time

Networked

Integration to EMR

Closed loop control

Peer to peer device recognition, establishing device community

Unique device identification

Device type nomenclature

Support AI and clinical decision support systems systems; data representation is consisten with that required by decision support and AI systems

Open source

Open standards

License free/hassle free technology

Interface should be application agnostic (generic purpose devices) Consistent time/SNTP Harmonization (2.1.1)

 ref. 3.1.4.1 from ITI TF vol. 1 says we should be able to reach microsecond resolution, b ut in Table 3.1.4-1 “high accuracy” says this is prohibited. Thus, a CP must request this change along with a footnote that describes the requirements that must be met to achievc high accuracy. NTP would get to millisecond, perhaps 100 microsecond.

 Manager will need to be NTP for resolution, with phase lock loop stability. NTP or Sntp would be allowed for the device. Point to point CT would be used rather than broadcast for enhanced accuracy.

 Is this to be included in this Profile or a version of CT; this might be a subset or separate. Todd prefers this be related to CT rather than PnP profile. This could apply to other domains in the future.

Scope of Profile

 Basic PnP/ -to-Manager/DCC to BCC:

 Not … Configurable Scanners / Link QoS Management

RCOP Extension (2.1.2) remote control

Profile Extension (2.1.3) for the future

 Basic PnP => PCD-04

 Symmetric Communications (agent provides information, but may also want to receive info (DCC and BCC remain the same, but manger and agent exchange role).

 Remote control

Actors (2.1.4)

 PCD MD Agent & PCD MD Manager

 Integrate DCC/BCC component

Simplifying constrains for Y2 Profile – to ensure it is manageable for Year 1 (2.1.5)  Limiting transport protocols

 ACSE as defined vs personal health defices (PHD) optimizations

 Application Profiles: Baseline Async (must) + Polling Mode (optional)  All scanner objects pre-configured … thus message ssequence is defined.  Objects supported are defined

Content supplément (2.1.6)

 Semantic Content movedto TF volume 3.

 Additional semantic content: mor comprehensive set for physiological monitors, pumps, vents

 Develop as a white paper and have IHE Wiki point to it

Patient ID Coordination (2.1.7)

 How to support the PCD PID Binding profile

 Actors from PID Binding will be referenced

Legacy Device Requirements (2.1.8)

Profile sections (2.1.9)

 New Directions area at the HIMSS Showcase in 2008 and Development of a White Paper on Remote Control of Medical Devices. Todd will lead the

discussion.

 Review the ITI white paper on configuration management, which has a section reserved for medical devices.

 Roadmap Update. Ray.

 HIMSS Showcase Scenario: Initial discussion, with attention to implications for the Connectathon. Todd and Ray.

 Year 1 Technical Framework: finalizing the document. As time permits. Jack Harrington.

 CP for completing parameter table to have a more comprehensive set. This could lead to a very complete Scenario at the Connectathon. This could also be an outcome of Year 2 work.

 NIST Test Tooling for Year two

Thursday, June 28

John and Todd reviewed the NIST Tool Support for X73 slides. These tools along with user guides will be available in time for developers to use in preparing for the Connectathon. Information will be available in a few weeks.

PCD-02

Paul Schluter and Robert Flanders led the discussion over a phone line.

Paul led with questions:

Table 5, QPD Input Paramater Field Description and Commentary, line 516, interval: Paul suggests this be a fuzzy request, expressing an acceptable interval and a preferred interval within that range. Interpolation will not be permitted.

The filter predicates need to have a minimum set (patient ID, interval).

Are multiple queries for a group of patients acceptable (alter parameters for one or more of the patients)? Message trigger and instances are issues. I.e., single or multithread? Is there a unique identifier for each query (e.g., to be able to delete a previous query). Jack believes a new query will replace the old.

EndDateTime – need to correct the description

Should the data include the min., max. (and perhaps the time of the event) as well as the average? Is there a way to do this in HL7? E.g., the request is for once an hour from a system that sends data once a minute.

Table 3, line 509 and Table 4, line 514: changing the data request will require deleting the initial request and then requesting a new one.

Al asked how to end the subscription – suggestion is to send a replacement with the EndDateTime to match the moment.

Discussion of how to request a group of related parameter (e.g., ECG) values led to two possibilities: use the in vmd portion of the device to obtain vmd.channel.* would request all metrics for that specific vmd and channel in vmd.channel.metric; alternatively, a table would be available at both ends. By the same concept, *.channel.metric would request everything with that parameter (.e.g., heart rate).

Query would not be disrupted by powering down and then up. Query tag may solve the problem.

Jack recommended building some sample applications to explore several issues Paul raised.

Robert asked about a one time “snapshot”: can the connection be left in place for later use. The DOC will remove the connection when the components are no longer needed. E.g., periop would only permit one active connection at a time. This question remains open.

The outbound server must be able to support multiple DOCs with different requirements for the same patients.

Query parameter definition needs to be edited.

New Directions area at the HIMSS Showcase in 2008 and Development of a White Paper on Remote Control of Medical Devices. Todd will lead the discussion. Todd explained that demonstrating remote control of service capability would be an important contribution. This does not require a published TF or a Connectathon. Instead, a white paper with much the same information would serve to qualify for the New Directions area (Todd will prepare the document). The deadline for publication is the same, permitting companies to sign up for participation (end of August). There will be fees for the Showcase and there will be an informal meeting in advance of the Showcase to prove the systems will work. Potential demonstrations: remote silencing of alarms, remote clearing of PID to initialize for new patient, remote establishment of a patient ID. Review the ITI white paper on configuration management, which has a section reserved for medical devices.

Configuration management across systems. There is a section reserved within the document for devices. Ron Horn (Agfa) is leading the effort.

HIMSS Showcase Scenario: Initial discussion, with attention to implications for the Connectathon. Todd and Ray.

Build upon PCD-01, highlight filter, show analogy to EMR with CIS with filter if no EHR vendor participates. Patient ID. Need to avoid getting into a specific hospital with multiple domains (RHIO). Need hospital admission scenario. Potential for database

patient size at the HIMSS Showcase could be 10K or __? (Manny will inquire) PnP with consistent time at high resolution time sync.

CP, Supplement or White Paper for completing parameter table to have a more comprehensive set. This would be a White Paper that would become a part of Volume 3 next year. The date would be the end of August.

PDC consumer has two different transactions – query/response or identify feed Options

Need just add

Need to constrain

Need to make one optional, the other required

PAM/PIX and PDQ - testing – just turn on identity feed

Summaries of the Work

PIB Patient Identity Binding – Ray will provide an update after making changes resulting from the meeting.

Next year, when devices are addressed, then there may be new transactions introduced if the PIB is handled outside of the DOR as well.

PnP – Todd will provide an update after making changes resulting from the meeting.

爱华网本文地址 » http://www.aihuau.com/a/300951/636233948506.html