Difference between revisions of "Straw Man2"
From IHE-UK
(Created page with "This schema will be based on minimal standard metadata, with additional name value pairs in the Reference ID fields to hold some or all of the following: *Specialties (hiera...") |
|||
| (8 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | This schema | + | This schema is based on minimal standard metadata, with additional name value pairs in the Reference ID fields to hold some or all of the following: |
*Specialties (hierarchical and potentially multiple) | *Specialties (hierarchical and potentially multiple) | ||
*References to "content" - such as PRSB sub-headings | *References to "content" - such as PRSB sub-headings | ||
| Line 5: | Line 5: | ||
*Episode, spell IDs etc. (as used in mental health/community) | *Episode, spell IDs etc. (as used in mental health/community) | ||
| − | + | ||
| + | {| class="wikitable" | ||
| + | |+ Metadata summary # = searchable | ||
| + | ! Generic Requirement | ||
| + | !Suggested XDS implementation | ||
| + | ! Open Issues | ||
| + | |- | ||
| + | | Patient demographics (global# and local IDs) | ||
| + | | Standard XDS usage - Patient ID and source Patient info | ||
| + | | Should local ID be searchable | ||
| + | |- | ||
| + | | Overall Coded Document Classification | ||
| + | | Class Code (source TBD) & Type Code (from SNOMED "correspondence document type" subset) | ||
| + | |- | ||
| + | | Author(s)& Authenticator | ||
| + | | Standard XDS representation, including person (name), role, specialty and institution & Legal Authenticator | ||
| + | |- | ||
| + | | Context * Environment | ||
| + | | Healthcare Facility Type Code & Practice Setting Code | ||
| + | | What is Healthcare Facility Type Code? IP/OP ?? | ||
| + | |- | ||
| + | | Human readable summary for visual scanning | ||
| + | | Title & Comments | ||
| + | |- | ||
| + | | Low level technical representation, location, Date time etc. | ||
| + | | | ||
| + | * Format Code, | ||
| + | * Mime Type | ||
| + | * Availability Status | ||
| + | * Creation Time | ||
| + | * Entry UUID | ||
| + | * Hash | ||
| + | * Size | ||
| + | * Home Community ID | ||
| + | * Repository Unique ID | ||
| + | * UniqueID | ||
| + | * URI | ||
| + | * Language Code | ||
| + | * Service Start Time | ||
| + | * Service Stop Time | ||
| + | |- | ||
| + | | Confidentiality requirements | ||
| + | | Confidentiality Code | ||
| + | |- | ||
| + | | Specialty-specific codes (e.g. modality/procedure/body part for radiology, or operation code for surgery) | ||
| + | | EventCodeList | ||
| + | |- | ||
| + | | Speciality/"treatment function code"/"folder" - see note 1. | ||
| + | | ReferenceIdList with multiple key-value pairs (in reality, coded values) - e.g. | ||
| + | * "Specialty=Surgery" | ||
| + | * "Specialty=Orthopaedic Surgery" | ||
| + | * "Specialty=Hip Surgery" | ||
| + | | Single vs. Multi-level? | ||
| + | Source? | ||
| + | |- | ||
| + | | Administrative "links" - e.g. | ||
| + | *accession number (lab and radiology) | ||
| + | *Pathway ID | ||
| + | * Visit and Episode IDs (mental health) | ||
| + | | ReferenceIdList with key-value pairs (in reality, coded values)- e.g. | ||
| + | * Accession Number = 12345 | ||
| + | * Episode Number = ABC-1243-99 | ||
| + | |- | ||
| + | | Contents included - see note 2. | ||
| + | | ReferenceIdList with multiple key-value pairs (in reality, coded values)- e.g. | ||
| + | * SubSectionType = History | ||
| + | * SubSectionType = Problem List | ||
| + | * SubSectionType = Drugs on Discharge | ||
| + | |- | ||
| + | | Keywords | ||
| + | | ReferenceIdList with multiple keywords | ||
| + | | How would these be structured and coded? | ||
| + | |} | ||
| + | |||
| + | Notes: | ||
| + | |||
| + | ;1 - Specialty | ||
| + | : This is emerging as one of the most important search fields, and as shown in DocMan may need to have a different level of granularity for different users. | ||
| + | |||
| + | ;2 - Content | ||
| + | : This would share codes with the PRSB headings/sub-headings to allow a user to locate a document which '''contains''' a particular type of data, irrespective of the document's nominal type. | ||
Latest revision as of 14:20, 7 August 2014
This schema is based on minimal standard metadata, with additional name value pairs in the Reference ID fields to hold some or all of the following:
- Specialties (hierarchical and potentially multiple)
- References to "content" - such as PRSB sub-headings
- Pathway ID
- Episode, spell IDs etc. (as used in mental health/community)
| Generic Requirement | Suggested XDS implementation | Open Issues |
|---|---|---|
| Patient demographics (global# and local IDs) | Standard XDS usage - Patient ID and source Patient info | Should local ID be searchable |
| Overall Coded Document Classification | Class Code (source TBD) & Type Code (from SNOMED "correspondence document type" subset) | |
| Author(s)& Authenticator | Standard XDS representation, including person (name), role, specialty and institution & Legal Authenticator | |
| Context * Environment | Healthcare Facility Type Code & Practice Setting Code | What is Healthcare Facility Type Code? IP/OP ?? |
| Human readable summary for visual scanning | Title & Comments | |
| Low level technical representation, location, Date time etc. |
| |
| Confidentiality requirements | Confidentiality Code | |
| Specialty-specific codes (e.g. modality/procedure/body part for radiology, or operation code for surgery) | EventCodeList | |
| Speciality/"treatment function code"/"folder" - see note 1. | ReferenceIdList with multiple key-value pairs (in reality, coded values) - e.g.
|
Single vs. Multi-level?
Source? |
Administrative "links" - e.g.
|
ReferenceIdList with key-value pairs (in reality, coded values)- e.g.
| |
| Contents included - see note 2. | ReferenceIdList with multiple key-value pairs (in reality, coded values)- e.g.
| |
| Keywords | ReferenceIdList with multiple keywords | How would these be structured and coded? |
Notes:
- 1 - Specialty
- This is emerging as one of the most important search fields, and as shown in DocMan may need to have a different level of granularity for different users.
- 2 - Content
- This would share codes with the PRSB headings/sub-headings to allow a user to locate a document which contains a particular type of data, irrespective of the document's nominal type.
