This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

ArB Priorities

From HL7Wiki
Jump to navigation Jump to search

Proposals for things to do:

A submission from Mead Walker (To summarize, I think the most important thing to do is to make things easier for existing implementers and for those who are making implementation decisions now.):

  1. Have a clear expression of where one goes to get the items needed for implementation; in particular, for concept domains, HL7 value sets and OIDs. Have these data stores updated more speedily with new material.
    1. The new Document Core Properties of V3 models should do this - please check it at [[1]]
  2. Get the Normative Edition out in a more timely fashion.
    1. Need to clearly define what is in the normative edition.
      • All material which has passed ANSI membership ballot, and any as-of-yet non-normative materials referenced by the normative material.
    2. what prevents it from coming out every week?
  3. Work out, and clearly express the boundaries around what, within the collection of artifacts and doctrines needed to enable interoperability, is defined at the Universal Realm by HL7, is defined at the realm level by a national affiliate (and so we need a US affiliate), and what is defined at the interface level by the implementing parties. Do this work in the spirit of realism rather than that of maximum interoperability.

Some thoughts of what we should address (Yongjian Bao) :

  1. Help HL7 develop and deliver products with shared goal, processes, and rules, so that they can work collaboratively and consistently to address real-world problems. This also helps customer easily decide what they need and how they use HL7 products. For example:
    1. The products of the Clinical Decision Support TC are developed with overlapped goals, but very little in the way of compatibility between them: Arden Synax, GELLO, Order Sets and vMR.
    2. The HL7 Services and Messages. They logically should share the same business payload content. In some cases they may be used in the same system.

ArB can work with CDS to see how it envisions the clinical support landscape to work in 3 to 5 years, and see if it can then help them build a rational framework for reworking these pieces into a cogent whole.

  1. Recommend / define design patterns for V3 message model development to improve the consistence. Same business concept should be modeled in the same structure, no matter where it is used. PA used different patterns (one message type in many interactions or many message types dedicated to respective interaction), they felt ArB can give guidanceTony Julian