TEP PID practitioner comment resolutions

Timothy Grapes - Evolution Technologies, Perspection Inc.

Description

EDXL-Tracking of Emergency Patients (TEP) - Stakeholder Comments and Issues TrackingLast updated: May 05, 2010TEP Requirements Statement and draft Messaging Specification Version 2.2TEP Project Initiation Document Version 4.4Doc Raised By Status Document Section Title Line Comment Description ResolutionNumNote 1: For overall context for these responses, please first refer to the TEPMemoOfRecordJuly2009.doc found at: http://www.evotecinc.com/TEP/Note 2: Given the commitment to expand the effort scope and pursue a 2-phase approach, a name for the overall effort has not yet been addressed. Perhaps utilize the term "victim" as all-inclusiveNote 3: To provide further context, comments from Christy Music written in red, with additional PID paragraph context in black text.The TEP effort will define requirements for the elements required to support the Patient Tracking process. TEP will coordinate to the furthest extent possible to ensure consistency of the common elements. Our objective is to adopt or re-use where appropriate. The Standards Barbara NENA and APCO work will define the elements of “Responder Dispatch Information”. They Development Organization (OASIS) in partnership with the OGC (Open Geospatial Consortium) Thorburg(Brian Open PID will probably also define the elements of any agency and units responding. This work must re- will ultimately determine appropriate technical solutions / structures to support those Rosen) use that work. ...

Informations

• Publié par: Musong
• Nombre de lectures: 34
• Langue: English

Extrait

EDXL-Tracking of Emergency Patients (TEP) - Stakeholder Comments and Issues Tracking Last updated: May 05, 2010 TEP Requirements Statement and draft Messaging Specification Version 2.2 TEP Project Initiation Document Version 4.4

Doc Raised By  Status Document Section Title  Line Comment Description Resolution Num Note 1: For overall context for these responses, please first refer to the TEPMemoOfRecordJuly2009.doc found at: http://www.evotecinc.com/TEP/ Note 2: Given the commitment to expand the effort scope and pursue a 2-phase approach, a name for the overall effort has not yet been addressed. Perhaps utilize the term "victim" as all-inclusive Note 3: To provide further context, comments from Christy Music written   in red , with additional PID paragraph context in black text.

Barbara Thorburg(Brian Open PID Rosen)

Barbara Thorburg(Brian Open PID Rosen)

Barbara Thorburg(Brian Open PID Rosen)

TEP Steering Committee

In- S process pec

TEP Message

The TEP effort will define requirements for the elements required to support the Patient Tracking process. TEP will coordinate to the furthest extent possible to ensure consistency of the common elements. Our objective is to adopt or re-use where appropriate. The Standards NENA d ACO   d th ts  “ sd Dsth It”  hy Development Organization (OASIS) in partnership with the OGC (Open Geospatial Consortium) will probably also define the elements of any agency and units responding. This work must re-will ultimately determine appropriate technical solutions / structures to support those use that work. requirements consistent with EDXL and future direction. However, we have received no responses to requests for information beginning June 19, 2008 for data structures defined through the NG911 effort. Have these structures been defined? If not, what is the definition and vetting process, and what is the current schedule?

NENA NG9-1-1 documents should be referenced. There are a couple of IETF documents which The TEP effort is happy to review appropriate documents for reference when received, per will need to be referenced requests for information beginning June 19, 2008. The TEP effort is happy to review appropriate documents / structures for consideration when A th y  t st , th ddt ts – Y  t t s th NG received, per requests for information beginning June 19, 2008. The TEP effort will define t stt, hh s dtd  th IEF – IDFLO hs d  “ Idt requirements for location information within the context and purpose of this messaging Lt” , d y th   t s ( t O a p n e d n a   r G d e .   o T s h pa e t   i S a t l a  C n o d n a s rd o s r   ti D u e m v ) e   l w o i p ll  m d e e n t t e   r O m r i g n a e n   i a z p at p i r o o n p  ( ri O at A e S   I t S e )  c i h n  n p ic a a r l t   n so e l r u s t h i i o p n   s w   i / t   h s   t t r h u e c   t O ur G e C s    to  support those location requirements consistent with EDXL and future direction.

The steering committee decided that gender, age, and age units elements will remain “ EIED”  th  ss - Some minimal patient identifying information must be collected in order for true patient tracking to work and work effectively. - This information should be very quick to obtain and enter under any circumstance. An There is ongoing debate whether TEP Data Element "gender", "age", "ageUnits" should be a estimated age is acceptable - the objective is to distinguish between a child, middle aged required data element. female or elderly male to interpret vitals, guide treatment and possibly destination. Per Capt. Christy Music DOD-"With different systems becoming interoperable, they are bound to share same numbers. In fact, there is no guarantee that like numbers won't be used by different IT systems. We see this routinely within DoD and VA systems, and therefore, add additional data as input. The National Advisory Board (Nat'l Initiative-AHRQ-DoD) recommended more than just the unique ID, as well. "

EDXL-Tracking of Emergency Patients (TEP) - Stakeholder Comments and Issues Tracking Last updated: May 05, 2010 TEP Requirements Statement and draft Messaging Specification Version 2.2 TEP Project Initiation Document Version 4.4

Doc Raised By  Status Document Section Title  Line Comment Description Num

Resolution

In- Jolene Whitney process Spec I R n e fo q r ui m re at m io e n n   ts R #  q 1 m 4 t  Should the "revised trauma score" element be included in the patient care data requirements? T c h o e n   t s a t i e n e s  r t in h g e    c c o o r m e  m el i e tt m ee e   n d t e s  c r i e d q e u d that t o h  c e a  " lc R u e l v a i t s e e  T d  R T S r   a if u  d m e a s   i S re co d. r   e" is being used less, and TEP  ired t null value In- Should null lues be valid values for the "gender" data requirement? t A h ll  o s w t i  n  g     a  tt w  o  u   l D d  e  s d se  n d t t ia  l   l  y d m d “ ak  e N " K g N en O d W er N " ”     o  p s t   i  o  n  a  l  , d w  h  i  c  h      i t s  n  o  t  r  e  c  o t m  m  ended by process Dictionary va situations where gender cannot be determined. Jolene Whitney Client(Patient) In- Since there is no formal national/international Agency Naming Convention, it is decided that S e Dd  d th  –   th th Ay  d/  y ID both Agency name and id should be collected to support agency identification, which can John Donahue process p c  Data Dictionary  likely be defaulted by sending systems. Though it is strongly desired that patient tracking utilize a single unique ID throughout the Nee c d a   r t e o     p h r a o ve i   d a e   r w s  a a y n  t d o     a t r r e a   c g k i   v s e o n u   r a c  d e i   f ( f c e li r e e n n t t )     u u n n i i q q u u e e    i i d d     n as u   m we b l e l  r a  i s n     p c r a o s v e i s d   e w  t h h e e r   e a   b p il a i t t i y e  t n o t   s t   r c a h c a k n   ge  t p r  a a   t c h i k e  i n  n t d g    e l  i v f d e e   - n  c  i y f     c a  l  e n ,  o   i t  t  h  is e I   r r   D j e   u c  r o i  s t g d h n i   i c  z t   e i  o d  n  t  h h  a a  t s    d  p i   f r  f e  e v   r t i e o h n  u t t s   l j I y u D ri   s  d  i a c t  t e  i d  o  n a   s n       m I  D   a .  y  T c  h r  e e  r a  e t   f e t o  t r  h e t e ,   i   r m E o  u  l w ti  n p    l I  e D  I s f  D o   '   r “ s     a N w  ill      cre v  multiple[le clientUniqueId 's from multiple systems Os d d”, “tt  Myd”,  “NDM      – My Hst Mhs”  Requirements will state need for association of these multiple ID's. ttdtCttts –st t  Ot As, CHANGE  stty Boolean to an defaulted enumerated list but allow other values: True, False, Unknown.  The steering committee decided this element will remain as Required, but add "Unknown" to B / d F    ’  t    y     d    s  t  h ’t           s         ,          d   d y   s   ’ t t      t     t  s t       h           s t t h    s    t s    d s  t     s   y  y                 F    ss st  t w h h e i   c e h n  c u o m ul e d r   a o t t e h d e  l r is w t i   s o e f    " e T n r d u a e n " g a e n r d     o   t " h Fa e l r s s e .  "    . This element is viewed as a key saftey feature  JPATS does not collect care provider information.  TEP currently h   a c s a   r m e  a p n r d o a v t id or e y r    i c n a f r o e r  p m r a o t v i i o d n e   r  p T r h o e v   i s d te er e   r i i n n f g o   r c m o a m ti m o i n tt .  e   e H   o re w c e o v g e n r i , z   e m s o  t v h in at g     s f o or m w e a   r e d x   i s st o in m g e     p p r r o o c v e i s d s e e r s  i   n a f n o d r  s m y a s t t i e o m n  s  m d u o s   t n  r o e t  m tr a a i c n k     information. In order for JPATS to send/receive TEP messages,  required and be tracked. Decided to keep "Care Provider" information mandatory in a TEP must be optional  message, but change personnel elements to optional. Agency elements remain Required.

In- process NDMS-TEP Pilot In- process NDMS-TEP Pilot In- process NDMS-TEP Pilot

In- process Dr. Stephen Cantrill

In- process Dr. Stephen Cantrill

Data Dictionary Data Dictionary

In an effort to minimize human error, look at implementing a "check-digit" so digits/characters This recommendation will be submitted to the OASIS Emergency Management Technical in the clientUniqueId do not get transposed. Committee for consideration.

Certain records may need to be merged. Reference HL7 v2 or v3 for record merge We researched HL7 ADT:A40. TEP information elements and structure supports the procedures. requirement for merging Patient messages within specific implementations.

Raised By

Dr. Jack Potter

Jim Kragh Jim Kragh Jim Kragh Knox Andress Randy Fike Maria Emerson Maria Emerson

EDXL-Tracking of Emergency Patients (TEP) - Stakeholder Comments and Issues Tracking Last updated: May 05, 2010 TEP Requirements Statement and draft Messaging Specification Version 2.2 TEP Project Initiation Document Version 4.4

Doc Status Document Section Title  Line Comment Description Num

In- process

In- process

In- process In- process In- process In- process In- process In- process

Data Dictionary

Spec/Recommend ed Changes Data Dictionary Data Dictionary

Resolution

Make sure HIMSS representatives are included on this project. Current HIMSS project representatives include: Robert Kaye, David Collins, Mary Griskewicz

 HIA, dsst stts  s d  y sss H, EM’ s st Might need to carry an ’    .  Client declares what  i d s i   s to a   s a t l e w r  a si y t s u  a at d i h o e n r s e     m to a   y p  i ri n v h a i c bi y t     i t n h f i o s r  a m d a h ti e o re n  n g c u e i   d a e t  li ti n m es e   s t , o     t t h h e e     g e o x a t l e  i n s  t t  p o  o a s l s w ib a l y e s .     f   o W ll h o il w e i   n s g o   m pa e t   ient  t s t t, t “ ”  s confidentiality guidelines, making this element unneccessary. In addition, registration processes and systems must be in place and available to faciliate use of such an element.

in the demographic section in much of t  be added to the Patient Information section. individuals pri h m e a   r H y I   T sp SP o   k m en a   t l e a r n ia g l u  i a t  g a e s   ks the question what is an  A primarySpokenLanguage data element will  The steering committee felt that, while this may be useful, an existing element "Special if there is an untimely event and the individual is non responsive do they have a written  Medical Needs" may be used to share this information. The definition will be revised to directive such as a DNR (Do Not Resuscitate)  include this as an example. Capabilities to provide for client associatio ill n     i a m n p d  o s r o ta rt n i t n .  g using 2 (or multiple) system identifiers  Incorporated.  See issue #208 and #212.   w I feel the minimum data entry for the patient should only include the ClientUniqueidNumber. Requiring additional information in order to create an initial message may result in messages that are either delayed or sent with inaccurate information, requiring correction once the See issue #173 for recommended approach and reasoning. client is conscious or a family member is located. I feel the revisions are definitely on the right track and I hope these thoughts help In developing a patient tracking system, I have had a few requests for The specification incorporates a contact structure with multiple contact elements utilizing multiple pieces of contact information both for patients and care either CIQ or vCard. Updated specification also handles multiple instances of Closet Relative- providers. Does (or can) TEP allow for this? Guardian/Contact information. However, no requirements exist to carry contact information for care providers; in fact the objective is to minimize the care provider information carried.

What about multiple pieces of contact information for the patient, or multiple pieces of contact information for each relative/guardian? I had requests to be able to list multiple See issue 222. phone numbers and addresses for example.

Raised By

Maria Emerson Maria Emerson TEP Project Team Glenn Pearson Glenn Pearson Glenn Pearson

EDXL-Tracking of Emergency Patients (TEP) - Stakeholder Comments and Issues Tracking Last updated: May 05, 2010 TEP Requirements Statement and draft Messaging Specification Version 2.2 TEP Project Initiation Document Version 4.4

Doc Status Document Section Title  Line Comment Description Num

In- process

In- process In- process In- process In- process In- process

Data Dictionary Data Dictionary Data Dictionary

Resolution

The following are related to data contained in the HITSP CCD Component that I don't see the ability to include in a TEP message. Based on the current inclusion of medications and procedures in the message, I think  Though basic information is captured on medications, procedures etc., "details" are not some of these should be considered.  carried to keep the message usable in the field. Pre-existing patient information (e.g. - Details on a medication -     a Al d le m r i g n y i   s i t n e f r o e r d m  ( a e t . i g o .: n  dose, frequency, route) electronic care records) are not specifically in scope, except that TEP and / or its routing  mechanism must be capable of carrying / attaching other related XML and non-XML content - Deta - i   ls P   r o e n g   n a  a p n r c o y c  i e n d f u o r r e m  p at e i r o f n ormed related to the TEP message patient such as NEMSIS, HITSP, or HL7 Constructs. I.e. if your  - Insurance information  implementation requires detailed patient history or patient insurance information, the EDXL - Advance directives  Distribution Element supports the inclusion of this content. - Comments  Also, can you clarify whether multiple values are allowed for the following fields within a single patient care record? Or is a separate patient care record required for each different medication (for example)? Good comments on medicationsAdministered and proceduresPerformed -changed to allow - medicationsAdministered Multiples. - proceduresPerformed CareProviderPrimaryImpression is a simple string. - careProviderPrimaryImpression If age becomes an optional element, then age units should become conditional. If age is IF age is changed to optional, then age units will become conditional in the data dictionary provided, then age units required (only used if age is present) H  d y td LstN’ s t  hs  sd s t E h  e  s  e     in  s t t  a  n  c  e t s – .     t T h h  e     O y A  SI  S       S Y D  O      p  r  o t c  e  s  s y     w  i  ll     ul h t t i   m  a  te s l t y  v  e  t      t  e   c h h  n  i   c  al      d  e  c t i  s  io d n  s d .      t R  e s q  u  i  r  e y m   ents ValueListURN:xsd:AnyURL rather than ValueListURI:xsd:AnyURI. Is this in order to disallow  wherever applicable will incorporate a defaulted enumerated list, but provide the ability to htt ” s F Ns, d y td t  y std ss  hh s th n st ys  n  o s d  e  s t ) h , “ o  r  u  n ” r , e  g  is  t , e “ re  d  n  a  m d … es ” p   a  c  e , s     s a  s y, H el L l?   CDC sts  OID  “ e  xt  e  d L v  i s a t    y  ou N r   r  e sd m  a A r  k y s: I w  sd t   ” Recommended and specify URIs for all values of type ValueListURN:xsd:AnyURI. One of the st s  s th t  t  AH’ s L’ s st  ValueListURN:xsd:AnyURI is that few examples URIs were given in the specification documents, and it was often impossible to locate pre-existing, public sources to which to link See Issue #227 or reference, for the purposes of determining choices for enumerations. Presumably y d ths tht t’ s s s’ s  t d ths D’ t  th s mistake. As an alternative, allow explicit, self-documenting enumeration of a ValueList type. In LPF, for every such XML element (and by convention following it), another element with the same  t  “ E” s s d hs s st h th   hs s reasonably small, e.g.: Will take into consideration during the OASIS Emergency Technical Committee process. <Gender>Male</Gender> <GenderEnum>Male,Female,Complex,Unknown</GenderEnum>

“