TEP PID practitioner comment resolutions
13 pages
English

TEP PID practitioner comment resolutions

-

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
13 pages
English
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

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

Sujets

Informations

Publié par
Nombre de lectures 34
Langue English

Exrait

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(tOapnedna rGde.  oTshpaet iSatla Cnodnasrdosr tiDuemv)e lwoipll mdeentte rOmrignaen iazpatpiroonp (riOatAeS ItSe) cihn npicaarlt nsoelrusthiiopn sw i/t hs ttrhuec tOurGeCs  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 SpecIRnefoqruimreatmioenn tsR# q1m4t Should the "revised trauma score" element be included in the patient care data requirements?Tchoen tsatienes rtinhge  ccoorme meliettmeee ndtes criedqeud that toh cea "lcRuelvaitsee Td RTSr aifu dmeas iSrecod.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 Neecda rteo  phraovei dae rws aayn tdo  atrrea cgki vseonu rac dei f(fcelireenntt)  uunniiqquuee  iidd  nasu mweblel ra isn  pcraosveisd ew thheer ea bpilaittiye tnot st rcahcakn ge tpr aa  tc h ike in nt d g  el ivf d ee  -n c iyf  ca l en, o  it t h ise I  rr D je  uc roi s t gd h ni  ic zt  ei od n t hh aa ts d pi  fr fe ev  r t ieo h n ut t s  lj I yu D ri  s d iact te id o na  sn   mI  D  a. y Tc hr ee ra et  fe t o tr he t e,  i  rm E o u lwti np lI eD I s f Do  '  r s  a N w ill   cre v multiple[le clientUniqueId 's from multiple systems Os d d, tt  Myd,  NDM   My Hst Mhs 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 /dF t y ds tht  s ,  d dy stt tt st  h  stths ts ds t sy y   F ss st twhhei cehn cuomuledr aottehde lriswti soef  "eTnrduaen"gaenrd  o t"hFaelrsse. "  . This element is viewed as a key saftey feature JPATS does not collect care provider information.  TEP currently h acsa rme apnrdoavtidoreyr  icnafroer pmraotviiodne r pTrhoev isdteere riinnfgo rcmoamtimointt. e eH orewceovgenri,z emso tvhinatg  sfoormwea redx isstoinmge  pprroocveisdseers i nafnodr smyasttieomn s mduos tn roet mtraaicnk  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 idsi stoa satlewr asiytsu aatdihoenrse  mtoa yp irinvhaicbiyt  itnhfiosr amdahtieoren ngcuei daet litinmese st,o  tthhee  geoxatle ins tt po oaslswibalyes.  f oWllhoilwei nsgo mpaet 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 prihmea rHyI TspSPo kmena tlearniaglu iat gaes 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 associatioilln  iamnpd osrotartnitn. 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-  aAldlemrignyi sitnefroerdm (aet.igo.: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 lsP roeng na apnrcoyc iendfuorrem pateirofnormedrelated 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>
  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents