Mark as DSTU 2.1 BodySite Resource Reason to create this was that have more information than just a code is now choice where – body site might be needed Is used in specimen should be available in observation also – Bodysite is using reference to patient Why not have reference to order? We have that from the patient Do we want to re-create ALL the information Should this be linked to procedure? DSTU comment what about a separate resource vs datatype – Bodysite MUST be related to procedure, and the patient Editor is Eric what more information we need to decide if data type or resource – What is the need for the resource? Tracking the specific location on a patient’s specific location Example: Description is left arm just below the tattoo the tattoo is not represented in the coded representation here yet could take a picture of the site and attach the foundational model for coding this more information than what can be transmitted – Specimen resource also needs work have to set up some predetermined time on FHIR project requested this resource can have a text description on the element Consider removing this resource create a tracker item that we will monitor the use of this; MUST have a use case also should have been reviewed by the FMG at the proposal state We agree that the information needs to be captured, but how that should be represented in FHIR Key question: can body site on its own”? “stand Reach out to requestor (Grahame) and ask FHIR infrastructure may be try it at connectahon to get it past status Looking at specimen: Why parent is 0..* - to accommodate pooling of identified specimen (example HIV testing) might be – good to add explanation Reviewing related tracker items: #5858: add patient as specimen collector choice currently supports ONLY practitioner, excludes patient or parent by definition how best to add this do we need to track the role of the collector (related person and role) do you need to know that? It is not normally collected we decided that we don’t want to add at the moment, need more concrete use cases (implementers actually needing it)
Mark as DSTU 2.1 BodySite Resource Reason to create this was that have more information than just a code – is now choice where body site might be needed Is used in specimen – should be available in observation also Bodysite is using reference to patient Why not have reference to order? We have that from the patient Do we want to re-create ALL the information Should this be linked to procedure? DSTU comment – what about a separate resource vs datatype Bodysite MUST be related to procedure, and the patient Editor is Eric – what more information we need to decide if data type or resource What is the need for the resource? Tracking the specific location on a patient’s specific location Example: Description is left arm just below the tattoo the tattoo is not represented in the coded representation here yet could take a picture of the site and attach the foundational model for coding this – more information than what can be transmitted Specimen resource also needs work have to set up some predetermined time on FHIR project requested this resource can have a text description on the element Consider removing this resource create a tracker item that we will monitor the use of this; MUST have a use case also should have been reviewed by the FMG at the proposal state We agree that the information needs to be captured, but how that should be represented in FHIR Key question: can body site “stand on its own”? Reach out to requestor (Grahame) and ask FHIR infrastructure may be try it at connectahon to get it past status Looking at specimen: Why parent is 0..* - to accommodate pooling of identified specimen (example HIV testing) – might be good to add explanation Reviewing related tracker items: #5858: add patient as specimen collector choice currently supports ONLY practitioner, excludes patient or parent by definition how best to add this do we need to track the role of the collector (related person and role) do you need to know that? It is not normally collected we decided that we don’t want to add at the moment, need more concrete use cases (implementers actually needing it)
Minutes%2020151004-09%20WGM.docx