Difference between revisions of "Consensus"
From IHE-UK
(→Items for debate) |
(→Items for debate) |
||
Line 32: | Line 32: | ||
**** Under both specialties | **** Under both specialties | ||
*** More generally, is there a need for multiple specialties per document? | *** More generally, is there a need for multiple specialties per document? | ||
− | * Possibly "content" - medications, allergies etc. | + | ** Possibly "content" - medications, allergies etc. |
Latest revision as of 13:59, 3 July 2014
This page is an attempt to document the emerging consensus on metadata requirements for clinical documents which may be emerging from the group discussions - as of 30th June it is not agreed - merely a draft, for discussion at the forthcoming t'con:
- The primary purpose of generating clinical document metadata is to facilitate tailored searching for clinical documents by "users"
- Requirements should be driven by clinically important "use-cases"
- The initial focus of this group is on generic metadata requirements, but if/when those are agreed, then representation within the XDS framework should be examined and if possible agreed:
- There is some disagreement on this
- Perhaps we should look generically, but always keep an eye on how to structure in XDS?
- Or work in parallel with 2 work streams?
- Or do generic first then look at encoding?
- There are multiple possible types of users, but for the purposes of metadata discussions, they are limited to those with an interest in the care of an individual patient (i.e. excluding data mining of populations). Examples include:
- Primary care clinical staff (medical, nursing, etc.)
- Secondary care clinical staff (medical, nursing, etc.)
- Social care staff
- Patients and their agreed representatives (friends, relatives etc.)
- Searching, can be a multi-stage process, including one or more of the following steps:
- Server based filtering of searchable metadata (find me only documents from the last 2 months)
- Automated Client based filtering of metadata (after full retrieving metadata) - this may enable filtering based on fields not treated as queryable by the server
- Visual scanning of metadata to identify items of interest (possibly in "free text" fields, which are not suitable for automated filtering)
- Final filtering based on document content itself (only useful where the document is suitably structured - e.g. CDA, and contains useful filter fields not otherwise represented in the metadata)
Items for debate
- All use cases seen so far, both nationally and globally, are based on the following search fields
- Date/Time (of clinical data - not document generation)
- Type of document (however classified, and to however many levels)
- Specialty/Specialties to which the document relates (however classified, and to however many levels)
- There is not yet agreement about the following aspects of specialty:
- Is the specialty of the author of a document a valid proxy for the specialty describing the type of care to which the document relates?
- How should requests/reports to/from service specialties be recorded:
- Related to the requesting specialty
- Related to the service specialty
- Each by its source (and so separated from each other)
- Under both specialties
- More generally, is there a need for multiple specialties per document?
- Possibly "content" - medications, allergies etc.