Skip to end of metadata
Go to start of metadata

Monday September 21, 2020

Q2:

Chair: JD Nolen

Scribe: Riki Merrick and???

  • From Chat:
  • DiagnosticReport versus Observation for retrieve queries (eCQMs and CDS)
    • USCore diagnosticReport has not been reviewed by OO
    • Discussion around use of diagnosticReport vs Observation
    • DiagnosticReport is the more structured than observation – it provides the structure around all the observations
    • Everything should be coming back as diagnosticReport, it contains all the observations that should be sent
    • What is in diagnosticReport tha tis not in observation
      • Had discussion around making structured report
      • Could include a composition to create the structure needed or make a profile of composition to create the diagnosticReport
    • The labs wanted to send everything they send out to have the same format, since they needed
    • If you are searching for specific observations in EHR-S that can be done, but the lab would
    • You go to observation for discrete data, go to diagnosticReport to get what the lab sent
    • You can get the structure of CBC in observation, but should really use the diagnosticReport for that
    • diagnosticReport is what you look for as response to the serviceRequest
      • it is more about the metadata around all the observations and how it was obtained
      • observations themselves have the discrete outcome and can be used to search for in EHR-S
    • need to document why using diagnosticReport is the correct way to get
    • observation applies to other domains like imaging,
      • looking just for direct results and physiological time = observation
      • get more information around the order = diagnosticReport
      • daignosticReport has represented form, so you can send the pdf of the report, that has the discrete data form the observations as well
      • need more structure may need to include a composition
    • Composition could include the diagnosticReport in order to get the structure needed like sections, which we currently don’t have in diagnosticReport
    • There is real world pressure that folks just want to look for observations, while we should really use diagnosticReport for exchanging between organizations
    • Implementers use the diagnosticReport as packaging for the observations
    • So for CDS – if we are looking for workflow / reports will look for diagnosticReport, otherwise search for observations
    • Next STEPS:
      • Have decision about when to use diagnosticReport and observation
      • How to deal with structured elements still open
      • Need to find a time for a call = OO Co-Chairs to do: Schedule during OO on FHIR call on Tuesdays 2 – 3 PM EDT
        • Need CDS, CIMI, CG, CQI, US Core
  • FHIR trackers
    • 26636
      • In real life have been using serviceRequest and observation of use rather than 
      • When do we use which of the listed resouces
      • Where do you find the data about use vs sharing information between informations
        • Patient is using a wheelchair (but a patient would not document that in a deviceUseStatemetn, but the doc would document that the patient reported
        • Bring this up on the device quarter later this week

Riki drops off at 1:02 PM EDT

Q3:

Chair: JD Nolen

Scribe: Lorraine Constable

Administration Quarter

  • Reviewed and updated Project Insight
    • Project 682: Specimen CMET Second Release. This has been On Hold for a while and we do not intend to work on this.
      • Motion to Archive Lorraine Constable / Frieda Hall Against: 0 Abstain: 0 In Favour: 6
    • Project 1568: At home blood pressure monitoring. This was a draft pss that was never approved by OO and the sponsors withdrew. Will get Dave to remove from Project Insight 
    • Project 1370: Transplant, Transfusion and Grafts on FHIR. - Need to check with Bob Milius to determine status
    • Project 1496: FHIR DME Orders - Confirm when reconciliation is scheduled <post meeting note - when did this end up to be?>
    • Project 1539: Laboratory Model/ Profiles - ask CIMI the status of this in our joint later in the week
    • Project 1095: EHR-S Func Reqs Doc for Laboratory Interoperability Transactions - EHR-S Func Reqs IG for LRI - follow up with Riki on this one
    • Project 1541: Vital Signs. The ownership has been fixed in the Project Database, but we don't have rights to edit in Project Insight. Check with Dave. Ballot reconciliation planned for later this week
  • v3 Nutrition Order and v3 Nutrition Preferences. (Projects 902 / 1009)
    • These based Informative ballot and the material has been provided to Lynn for Publishing. Initial publication request drafted but needs some cleanup
      • Motion to approved submission of Informative publication requests for these two specifications. Lorraine Constable / Ralf Herzog Against: 0 Abstain: In Favour: 0
  • Discussed review of product grid and project metrics
    • Project 1335: LIVD - Unpublished ballot will be replaced and metric cleared when subsequent ballot commences. Checked with Lynn post meeting; No action required
    • Nutrition DAM should be moved from Stable to Active as it is being updated under Project 1614
    • v2 IGs need review as some currently published should be superceded, etc. Hans to do a review. Post meeting note - deadline for this is Oct 31

Q4:

Chair: Did not meet

Scribe:

Q5:

Chair: JD Nolen

Scribe: Riki Merrick

  • FHIR resource to handle movement https://confluence.hl7.org/display/FHIR/TransportEvent+Resource+Proposal
    • Specimen in the lab
      • Between 2 labs
      • Inside the lab
      • Specimen collection
      • biobanking
    • Patients
      • Administrative
        • Status changes and class changes
        • Arrival and departure at encounter
      • Physical movement
        • Movement inside encounter
          • Imaging
          • Bed location
          • Labs
        • Transport between facilities
      • Supply movement
    • PA OOS:
      • Device dispensed for home use
    • PA has list of questions
    • PA has evaluated what part of encounter would need to be in this new resource
      • Will need to have to be able to correct an incorrectly entered location
        • Encounter supports multiple location instances, so the new resource can help with tracking that rather than relying on resource history
    • Questions
      • Relationship between resources:
        • TransportEvent reports the actual movement
        • ServiceRequest is before the TransportEvent
          • May need to add a few elements to accommodate
        • Task to track the workflow around the movement
      • How would the planned movement be referenced in the serviceRequest resource?
        • Depends which systems are involved
          • Just see the encounter event updated in the provider’s EHR-S
          • So just the systems that care about the more detailed information use this new resource
      • Possible overlap between SupplyRequest and SupplyDelivery would need to be evaluated
      • Including both physical movement and administrative changes (ER to inpatient – not the specific location associated with that change)
        • Class change can occur even without the physical movement – this was looked at from ADT encounter perspective
        • Maybe not track in this resource?
        • The encounter class would be changed, so encounter history would tell you about this
        • Encounter has different history for:
          • status (not physical, but matters for billing)
          • class (not physical, but matters for billing)
          • location
      • Need to exclude device tracking?
        • Not in scope of PA working group
      • Transport of things that contain another thing
      • Tracking of a thing over time / displacement
      • Dealing with planning and tracking plan vs actual event
      • What is the purpose of the resource?
        • Documentation of the event vs fulfillment of requests
        • Could this be done using a multi-component observation?
          • We did look at this, but wanted to be sure to know how to look this up other than just what the observation.code is.
          • Pretty much anything could be done using observation, but that “waters it down” some
      • How to deal with rejection of transport
        • Something is sent to the incorrect place
      • Would need to add multiple occurrences for location in device, if we didn’t track that as part of the transportEvent resource?
        • Would need to an element of history there
        • We may need to track something has been transported / or is planned to be transported
        • Some devices move a lot, which would increase the resource size
      • Subject of the movement
        • Patient
        • Device
        • Specimen
        • biologicDerivedProduct
        • substance
        • Medication
        • encounter is not the subject – but could be related to the movement
          • Could an encounter be moved?
      • difference between subject vs focus
        • should the specimen be the subject vs the focus (patient)
        • Example patient movement:
          • Subject = patient
          • Focus = encounter
      • Reason for creating a different resource also was to be able to track additional observations during the movementEvent
        • Temperature during transport
          • Use associated observation and reference observation
            • Observation subject does not have specimen as a choice, would have to use focus
          • Waypoints?
        • If something happens during the movement
          • like procedures on the patient in an ambulance?
            • Could that be a separate encounter?
            • They have dedicated EMRs and do a lot of documentation about the procedures, because you are doing a hand off of care, so should be able to push a CCD
            • Separate encounter because a different organization from the hospital makes sense, if the same could be same encounter
          • What about delivery of a product and something breaks on the way?
      • SupplyRequest (ordering provider) could trigger a movementRequest (fulfillment system tracks this part) that then results in a completion of the SuppyDelivery
      • Current location is on the resource itself
      • It’s ok to have a history on the resource would be tracking the “final” location = destination.
      • Would this work for contact tracing?
        • Could track movement of patient
        • If you make location more flexible – would this track the people they were with?
          • That should be more the participation?
          • Put this into the boundaries / open questions / parking lot
          • If location is not a distinct physical location or an assigned number
      • Planning a movement
        • Always have a ServiceRequest at the start, or could there be a Transport / MovementEvent in planned status?
        • Would we need a separate resource for movementRequest?
          • Any data we need to add to SeviceRequest to cover movementRequest?
            • Add “to” and “from” location
              • Maybe not need the from location?
              • SourceLocation is in the resource that is the subject
            • When CPO system is separate from patient transport and need ot order a patient transport
              • ServiceRequest is created by the physician
                • Need to explore the location element in serviceRequest, to see if it can handle that (not assume current location as the from location = may need an extension for that)
              • ADT planner finds the right bed
                • Pending transfer = planned movement, scheduling can happen
                • When the transfer happens
                • If you want to ask: pick up this COVID positive patient from his home (wherever that is) and bring to the nearest hospital
      • What to name this resource?
          • Would transportEvent still cover the status/class change?
          • Or should it be movementEvent?
    • Link to PA notes: https://confluence.hl7.org/display/PA/Encounter+History+and+Movements#space-menu-link-content
    • Next Steps:
      • PA to define the OOS elements
      • OO will re-discuss tomorrow afternoon Q3: 2 -4 PM EDT
      • PA will discuss related FHIR tracker tomorrow Q3 also


Tuesday September 22, 2020

Q0

Chair: Hans Buitendijk

Scribe: Riki Merrick

Topics

  • Often the order system is updated after the fact, so then the report code will be updated based on the code the filler sends back- so in the end of the documentation the codes will matchV2 issues related to COVID, LOI

    • COVID-19 reporting to PH:
      • HHS guidance came out June 4thhttps://www.hhs.gov/sites/default/files/covid-19-laboratory-data-reporting-guidance.pdf
      • HL7 guidance confluence page: Proposed HHS ELR Submission Guidance using HL7 v2 Messages
      • HHS published implementation guide: https://www.hhs.gov/sites/default/files/hhs-guidance-implementation.pdf
      • Pooled specimen
        • What data needs to be included?
        • Collected materials so far: Pooled Specimen Data Requirements
        • Summary:
          • Several approaches for pooling
          • Different parties are interested, may not be a high priority, since there is so much other things going on
            • FDA
            • PHAs
          • Matrix set up for testing pooled samples allows for reporting of both negative and positive elevates the interested
        • LRI ballot reconciliation – do we need to include guidance around pooled samples there?
        • How is it implemented?
          • Quest
            • Only using it in low prevalence areas
            • Only for back to work testing
            • Small pool number of 4
            • Same test, so hard to identify when to use SCT for not detected or the SCT for not detected in pooled specimen
          • LabCorp
            • Different test
            • Using matrix approach
            • Could assign the SCT codes specific to pooled samples
        • Have reached out to several professional organizations and should hear back by next week at the earliest
        • Do we need a separate LOINCs for this?
          • The test is the same, the specimen is different
          • If you have it set up as a different test, then a separate LOINC is possible, else not possible
          • If we are doing back to work testing, and we know it’s pooled testing, but someone enters the wrong LOINC, but then they change over to individually tested approach – that could cause confusion
  • LRI ballot reconciliation
    • Motion to approve all A-T comments for editor to fix, but bring back any that don’t seem to be just typos – Riki Merrick, Freida Hall, no further discussion, against: 0, abstain: 0, in favor:15
    • Brian Pech’s comment – overall vote: affirmative
      • Single comment – Hans will merge text into row #1
    • Add in Chris Schutz Negative seems to be related to V2 to FHIR? – Will move over there
    • Craig Newman’s comments – overall vote: affirmative
      • Rows #2 – #24
    • Erin Holt’s comments – overall vote negative
      • Rows #25 – #34
      • #32 – related to page #176 is blank – Motion to recover this page content Riki Merrick, Craig Newman, no further discussion, against: 0, abstain: 0, in favor:17
    • Freida Hall’s comment – overall vote negative
      • Rows #35 – #43
      • #39 – Demographic Data table: Patient Race
        • Since race does not influence the test, drop last part of the sentence, since this is COVID-19 specific scope – the driver to add this guidance, but we would like to have this more generic here- we will have the AOE document to adjust for any new pandemic specific AOEs
        • The AOE document already has the guidance that if race affects the result interpretation, then it needs to be sent as AOE in addition to the PID elements
        • Choices:
          • Drop the last part of the sentence
          • Adjust the scope of the use case and the audience
          • Add sentence that this does not applies to COVID-19
        • Motion to adjust the use case and audience section to make clear that COIVD-19 was the instigator for this section, but make this more generic Riki Merrick, Swapna Abhyankar, further discussion: what about when these elements then become part of non-pandemic reporting, but should still report – add to the last sentence in the AOE “if applicable to the lab test” – persuasive with mod - against: 0, abstain: 0, in favor:14
      • #40 - Demographic Data table: Patient Sex = use same resolution as #39
      • #41 – Ordering provider zip code
        • Idea here was that when 2 ordering provider practices in more than one offices they pick the one where the service is provided
        • What happens when it’s a tele visit?
        • Reason to have this is to use as backup for deciding where to report, when patient address is not known
        • Leave this up to the provider, because it is not different for other reporting rules
        • Motion to adjust sentence: This field contains the zip code for the address of the provider requesting the order – Freida Hall, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor:15 – persuasive with mod
      • #42 – TABLE 4-5; Usage notes for the AOEs
        • Motion to remove the usage columns add a note: Usage (e.g. Required, Requested, Optional) is dependent on the reportable condition and the jurisdiction it needs to be reported to Riki Merrick, Freida Hall – no further discussion, against: 0, abstain: 0, in favor:14 – persuasive with mod
      • #43 – “Last usage note Although not a requirements for HHS, if you need to convey (race, sex, ethnicity” – should be similar to AOE document – or just add “as applicable”
        • Motion to ass “if applicable and clarify that it depends on the test or the reportable condition Frieda Hall, David Burgess no further discussion, against: 0, abstain: 0, in favor:14 – persuasive with mod
    • Genny Luensmans comments- overall vote: affirmative
      • Rows #44 – #68
    • Karin Frank’s comments – overall vote: affirmative
      • Rows #69 - #70
    • Kathy Walsh’s comments – using the later version – overall vote: negative
      • Some in-person comments, she will not be at WGM, so discuss later
      • Rows: #71 – 87
      • Sheet at end of session / fully prepped: 
  • LOI DSTU Comments
    • Not discussed

Q1:

Chair: JD Nolen

Scribe: Riki Merrick / Lorraine Constable

From Agenda - Joint with CG

  • Diagnostic report 
    • What to use for DiagnosticReport.code (removing fixed LOINC panel code, guidance on which LOINC codes are appropriate)
    • Should be a ‘starter’ list, should be extensible
  • Further discussion/plans on the use of "notes" or something else for extra information on genetic findings that we talked about a few months ago. 
  • Discuss the ability/guidance around delivering biomarker observations
  • Merging DocRef/Media - updates on the current status
  • Alignment of Observation.category and DiagnosticReport.category valueSets?
  • FYI update on OO/PA work on a new "task"-like resource to handle the movement of specimens and other procedural things

Discussion:

  • DiagnosticReport = https://jira.hl7.org/browse/FHIR-27864
    • .code value set definitions to use
    • Looking for collection of LOINCs that would represent the report
    • Should the ServiceRequest.code match the DiagnosticReport.code?
      • Not necessarily
      • LOINC has a class indicating if a LOINC is order only, observation only or both
      • Linkage between the two should be based on the .identifier element
      • Currently we have a fixed value for the genomic report code, but wondering, if we should allow more
    • Often the order system is updated after the fact, so then the report code will be updated based on the code the filler sends back- so in the end of the documentation and the codes will match
    • Looking for a kind of reports, then we would need to have the same code in all the reports that are the same
    • Make the starter test be extensible / preferred
    • Send this back to Clin Genomics
  • Usages of Notes to capture extra information on genetics findings
    • Bits of information about the results (“canned comments”)
      • One implementer created extension on observation / DiagnosticReport
        • Observation summary - For this particular variant this is canned text that should be sent – this is result specific
        • Disclaimers for all results for a specific test
      • Container for this type of text
    • EXAMPLE: Look at Page 3, under the "Somatic Variant Details - Potentially Actionable" section https://drive.google.com/file/d/1wqoVUMP0dDsM4msSrgolv4At7sVDkoN_/view?usp=sharing
    • Why not use observation.note?
      • Want to have labels for the text
    • Expand the annotation datatype to include a type?
    • This should be folded into the discussion around the dealing with a structured report:
      • Use the observation to create groupers (observation.hasMember) in diagnosticReport.result
      • Use composition in diagnosticReport.result to create the report structure
      • Add a section into diagnosticReport
      • ACTION ITEM: OO Co-Chairs will need to schedule a call Tues 2-3 PM EDT in the near future
  • Delivering Biomarker observations
    • They are results, but they don’t change over time and remain relevant for the rest of the patient’s life – it becomes more of a patient characteristic = condition
    • And they will need to get pulled into other diagnosticReports – for example for cancer resulting several years later
      • Lab would issue a new report when a biomarker has changed significant
      • EHR-S would need to know it is now important by using the observation as trigger to create a condition and recorded as condition.evidence
      • Maybe genomic biomarker profile on condition to harmonize approach on how these are documented
    • mCode handling biomarkers, but this is limited to cancer and is not a universal IG
    • They handled with an observation and put a code to indicate which kind of biomarker the observation is about - used LOINC and NCI codes
    • question which workgroup this profile should be maintained
      • multiple work groups ?
      • Clem - genomics should address and collaborate with others
    • Condition ties the biomarker to cancer in the IG
    • Others tying to a report and the episode of care
    • mCode struggles with trying to align with other similar models. Having an umbrella / coordinating work group to handle the cross domain 
    • Can the US specific material in mCode be generalized to be more universal - we need material that will work across jurisdictional boundaries
    • Tumour marker profile within mCode is one of the less US specific
      • Patrick; this is general enough that it should be usable. The concern in Europe is more political than technical
      • Lorraine mentioned the Realm Transferable Standards work should work with the mCode Team
  • DocRef/ Media
    • Have merged
    • Renaming considered 
    • What has changed
    • Renaming is more about clarity since this is not just documents
    • media has been fully merged into Document Ref
    • In observation, the only place DocRef currently goes is in derivedFrom
    • Need to work through how to add attachments along with value. Does using attachment for the VCF work?
      • there will be 20 or 30 variants in observations related to one VCF report
    • In this case, should there be an attachment at the the DiagnosticReport level
      • the media element provides a link. We need to reconsider the backbone element name and elaborate how you would handle these kinds of use cases
        • May need to update limitation to DiagnosticReport.media to be broader than images (would we need to
        • Could you also reference a specific VCF file, if more than one are included?
      • question - do others have issues with connecting these items to DiagnosticReport rather than specifically the observation
        • sees benefit from also attaching to derivedFrom. Patrick does not see the downside to both
        • Clem - having two approaches increases complexity. We should walk before we run
    • Will roll this item into the DiagnosticReport discussion
  • Observation.category and DiagnosticReport.category
    • category valueset is preferred with a smaller list than the example value set for DiagnosticReport.category
    • category is just a Preferred Binding and CG can constrain
    • Clem wants to merge DiagnosticReport.category and Observation.category
      • need better categories to make the queries work
      • we have had several sessions trying to build consensus on the value set for Observation.category
      • run into the lumpers and splitters
  • Proposed Transport Resource
  • Will we keep this quarter for next cycle? Yes

Q2:

Chair: JD Nolen

Scribe: Riki Merrick

From Agenda: 

Discussion:

  • Agenda Review
  • PPE – no takers – can go back, when folks join for this
  • eDOS AOEs:
    • https://confluence.hl7.org/download/attachments/76152954/2020-08-25%20eDOS%20questions%20for%20OO.docx?api=v2
    • STU#2019 (Craig)
      • Have added a comment about use of units in OBX-6
      • These examples don’t need units, so drop this sentence
      • Motion to find persuasive - Freida Hall, Craig Newman, no further discussion, against: 0, abstain: 0, in favor: 9
    • STU#2020 (Craig)
      • New AOEs with LOINC that needed datatypes
      • Assigned CWE for the first 2
      • Test method seems to not be standardized yet, which is why we held off on making this CWE, but the LOINC would suggest use of CWE
      • Also suspected organism LOINC should be coded (we have organism SCT codes)
      • Motion to assign CWE datatype for all 4 AOES, - Freida Hall, Craig Newman, no further discussion, against: 0, abstain: 0, in favor: 10
      • Example lists here:
        • In LOINC these concepts have LA codes assigned to them, but we don’t want to have these here, and in the organism list it is a mix of concepts with and without SCT codes
      • Motion to remove any of the listed organisms that don’t have a SCT listed for them Craig Newman, Riki Merrick, further discussion: Does this require a change to the title of LOINC Example Answer list to reflect that this is just a selection? – Abridged LOINC Example Answer List - agreed to the friendly amendment, against: 0, abstain: 0, in favor: 10
    • STU#2025 (Freida)
      • Using Clinically relevant and Clinical significant interchangeably in the AOE tables, use clinically relevant in LRI– so should align – Motion to change clinically significant to clinically relevant Frieda Hall, Craig Newman (enthusiastically!!!!), no further discussion, against: 0, abstain: 0, in favor: 10
    • Peer Review Comment from Craig:
      • Adding a legend to the guide what each column is for
      • Also added definition for LOINC level of answer lists Example, Preferred or Normative
        • Do normative answer lists ever change?
          • Usually normative lists are for sruvey instruments / questionnaires - not sure if an updated version would be a different method, so different code - Question for Swapna Abhyankar
        • Are you a refugee AOE had odd mix of answers:
          • Yes, no, refused to answer – we did assign a LOINC to this, the LOINC answerlist includes mapping to SNOMED CT for yes and no
          • Do we always want to include the LOINC answer list
            • Sounds like it would be good to be consistent
            • Use abridged version for long lists
          • LOINC uses SCT codes for Yes and No – but we would prefer use of HL70136 for v2 mapping – change the title from "HL7 mapping guidance" to "HL7 V2 Example Answer list"
          • Refused to answer – how to map?
            • ASKU = Asked but unknown
            • UNK = Unknown
          • Motion to accept with modification:
            • Change usage note to relabel header to HL7 V2 Example answer list
            • No change in the terms under it
            • Leave LOINC Example answer list as is
            • In addition FOR each line item in the Guide add LOINC Answer lists, where available and they may be abridged Freida Hall, Dan Rutz, further discussion: do we want to use the extended Yes/No Indicator table for all? It is not preferred, because most folks are using HL70136 and also have gotten used to using NULLFL, which also is listed in HL70396 as correct code for the V3 Nullflavor code ssytem, against: 0, abstain: 0, in favor: 10
          • Next Steps
            • Freida will edit and present the updated document to OO
            • Then will publish
    • LRI reconciliation
      • Riki Merrick’s comments – overall vote = Neg
        • Rows in Riki’s tab - to be adjusted when moving into the merged file:
        • #25 OBX-17
          • In the FDA table they change Manufacturer to Entity so update the text here and also on the confluence page (and update the screenshots)
          • Would be good to have the guidance on how to use abbreviation, when there is a length restriction – include the description
          • If you cannot support OBX-17 or OBX-18, then there are 2 LOINCs that can describe the Test kit and the instrument – should we explain that here?
          • All the options for OBX-17:
            • Use the longer description in OBX-17.2 and not use NTE? – Riki will post this question to basecamp, so we will need to get back to this
        • #26 Update the profile figure to include the new component
          • Motion to find persuasive Riki Merrick, Freida Hall, no further discussion, against: 0, abstain: 0, in favor:10
        • #18 Testing Lab Specimen ID – is SM-2.2
          • Motion to find persuasive Riki, Craig, no further discussion, against: 0, abstain: 1, in favor: 9
        • Add in the now LOINC identified AOEs in HHS guidance, dropping the HHS usage column – applies to #19, #20, #21 – motion to do this Riki Merrick, Craig Newman, no further discussion, Against: 0, abstain: 1, in favor: 9
          • Keep #20 open for follow up based on notes to balloters input on handling repeating OBX values for AOEs
        • These rows were migrated into the consolidated sheet and updated version is here: https://confluence.hl7.org/rest/hotovo/amazon-s3/1.0/buckets/29/content/download?path=LabV2IGs/V251_IG_LRI_R1_D5_2020SEP_consolidated.xls&targetId=86974073

Adjourned at 1:15 PM EDT

Q3:

Chair: JD Nolen

Scribe: Riki Merrick

From Agenda:

  • Review work on transport/movementEvent resource = TransportEvent Resource Proposal
  • New discussion:
    • If a thing is moved 3 times would have 3 transport/movementEvent resource instances
    • The final location is on the subject resource of the transport/movementEvent
      • But specimen does not have location – but we said specimen would be covered by container, which has a location
      • Not sure about the other
    • What is the distinct role of having the 2 resources – task vs transportEvent
      • In this case the task to monitor is the movement – so what is the use case to use task in this situation?
        • Task is being used as the actionable flag – it is instigated by a ServiceRequest
        • Can we just use a status on the transport/movementEvent
        • Maybe only use the task, for inter-organizational movement
    • When we are moving a specimen 4 times, with different temperatures – where would these be tracked?
    • Think we ended up with the container to track the temperature history
      • Observations on the container for the temp measure
      • If you want to know about the movement time frames, search for that specific timeframe
      • Could also be good to just track that on the transport/movementEvent resource – similar to clinically relevant observations
    • ServiceRequest
      • Review if it has enough attributes, or if we need to have a new resource
        • Missing “from location”
    • Dealing with not accepting the moved item
        • Need to have a status of “not accepted/rejected”
          • Planned, in process, complete – add failed / rejected
          • Maybe that’s where task is used
    • For specimen movement we usually have a ServiceRequest for some procedure that prompted the move, except for storage related moves
    • Should we take 1 use case and walk it through the example resource
      • ACTION ITEM: Ask Hans Buitendijk  to get some Cerner outreach solution (Courier system) to work with on this
      • Specimen collection centers and shipping the specimen to the lab
      • Take the SET IG examples, too
      • What is the status of the ID Specification? Nothing new at the moment
      • Take the PA diagram and move forward with what we need for specimen and then flesh out the resource proposal have OO review it and send it to PA afterwards
    • Next Steps:
      • Finish this off in the specimen calls for the specific use cases
        • IHE use cases, and data from Hans
        • The crosswalk with LDA can be done later, but is a good idea
    • Open Issues
      • Dealing with ServiceRequest and task relationship to this resource
      • Resource ownership
  • Other planning:
    • Cancel Wed Q0 – JD to figure out how to do that in WHOVA

Adjourned at 2:53 PM EDT


Wednesday, September 23, 2020

Q1:

Chair: Hans Buitendijk

Scribe:

Agenda:

  • OO Topics
  • II Topics
    • map out what the radiology order-to-acquisition workflow looks like in FHIR. This has come up before in joint meetings but I think we now have some bandwidth to work on it
      • Current IG proposal
      • Discussion before Patient, ServiceRequest (imaging service, requested procedure), Encounter (visit), Task (scheduled procedure step)
      • Do we need appointment?
      • Task is likely already needed with ServiceRequest
      • 2-To-FHIR Project can provide mappings that indicate what FHIR resources to use where v2-DICOM/IHE mappings/relationships are known.
    • work going on in the IHE around AI results, which involves looking at how imaging measurements map to FHIR observations. On the DICOM side we are getting a steer to look at the precedent to look at the DICOM SR to CDA mapping defined in DICOM part 20. I think it makes sense to look at the more granular level first but I am open to suggestions.

      • Need to complete the DiagnosticReport - Composition discussion.  have not landed on DiagnosticReport.presentedForm pointing to Composition for structure, although it seemed 
      • SR-CDA-FHIR should be in sync so one can go through either translation and get the same outcome/meaning.
      • Is tracking identifier sufficiently similar to order group number to just be another type of Observation.identifier rather than a separate attribute/extension. 
    • Dose Summary

Q2:

Chair:

Scribe:

Topics

  • FHIR Planning
    • R4B
      • Focusing on not much change then MedicationDefintion and Evidence
      • Anything urgent for OO?
      • BR&R desire to enhance relationships in resources, e.g., Observations
      • Ballot in January then Q2
      • Prefer not that PackagedProductDefinition is impacting existing resources.  Note that these are involving low FMM resources, so still should have ample opportunity to learn.
    • R5
      • Changing Observation.device to CodeableReference is a breaking change.  That would not be R4B, but could be brought up for R5 for consideration.  Alternatives then need to be considered, e.g., additional attribute with invariant, or deprecation/new,  Deprecation is more for something that is wrong, rather than something new/better.
      • While the tooling allows for pre-adopting new constructs from a build, but risky.  I.e., only support that when you are really sure that it will be adopted in publication.  Documented in the published core spec.
      • What for Normative?  Potentials are:
        • Need to be at right level (FMM5) in April and solid.
        • DiagnosticReport and Device are high priority, but hard to get there AND be ready to go normative.
          • DiagnosticReport main issues are how to deal with sections, e.g., categories/grouping inside DiagnosticReport or using DiagnosticReport.presentedForm pointing to Composition, and media dealing with images.
          • This includes whether we need one, the other, or both when done with that conversation.
        • Device - the introduction of DeviceUseStatement and ...Dispense may introduce structural changes that need to done quick.  Properties/characteristics/specialization needs to be settled too.
        • Specimen - primarily examples, updates, and use but also specimen collection and procedure vs. specimen.  Movement is more outside the specimen.
        • Task - focusing on progress, not Normative
        • Aim for November-ish
        • However, FMM4/5 are dependent more on adoption.
      • For all else, target FMM levels.
      • End of October for all target levels.
    • Dose (radiation therapy, x-ray, chemotherapy, ordering, documentation, registry)
      • Discussions starting in various
      • Similar discussion on bio markers that reflects latest/always the same
      • Need to work with ServiceRequest, MedicationRequest, Medication, Procedure, Observation (OO, PtCare, Rx, II).  So 1-2 conference calls with workgroups to set a direction.
    • ObservationDefinition
      • FMM1
      • Gravity, CIMI, and LIVD are looking at this or using it.
      • Gravity is exploring what it needs.
      • LIVD is good with what is there.
      • CIMI is looking at it to make about the right way concepts are to be represented.  Interest in structure and process.  ActivityDefinition may be in play for the process guidance.  CIMI is using the term "dictionary of observation structures"
    • Substance
    • Resource Proposals
      • Current FMM 0-s
      • Transport ownership / Movement
        • Different projects/groups have need for moving something.  Specimens need to be moved, as well as patients, supplies, etc.  
        • Had a meeting with PA to start to sync.
        • Need to look at relationship with SupplyRequest
        • Still to be determined where to draw the line, e.g., moving encounter to the correct patient, or state change.  the latter is not quite a movement.
        • Link to PA discussion: Encounter History and Movements#menu-link-content
      • DeviceDispense
        • Association of e.g., device to a patient, akin to medication dispense.
        • Should not be part of a use statement
        • No immediate need to create, but want to avoid it being part of another resource.
      • SupplyDelivery is able to point to Patient, while SupplyRequest is not.  Need to resolve in context of movement as well.
      • Inventory
    • IG plans
      • Current:
        • DME (Thursday to as Bob)
        • Vital Signs IG (next quarter)
        • LIVD (January maybe May as well)
        • "v2-to-FHIR" (different animal)
      • Futures (next year)
        • Nutrition Process
        • UDI IG 
        • Lab Profiles (next quarter with CIMI)

Q3:

Chair: Hans Buitendijk

Scribe: Hans Buitendijk/Riki Merrick

Topics:

  • Lab Profiles IG plans
    • Patterns/Templates on how to represent lab results
    • Profile on observation for lab (Argonaut already has one of these)
      • Profile on lab observation for quantitative
        • Profile for titers
          • Specific templates for each analyte
        • For ranges etc
      • Profile on lab observation for qualitative
        • coded observations
          • Specific for analyte
    • If we could get a good review at level, that is the goal.
    • For detailed leaf-node level profiles, then into spreadsheets for specific analytes as the structure is not changing, rather LOINC codes, etc. - folks are not usually looking at that level of detail until they are actually implementing
    • So ballot at the pattern level, while how to review/ballot the spreadsheets is TBD.
    • Earliest May 2021 Ballot, maybe September 2021 Ballot.
    • Is this focusing on what is coming from the analyzer/instrument? Or from LIS to EHR?  LIS to EHR.
    • Similar patterns applies for ordering medication
      • Oral
      • IV
      • IM
      • IV piggyback etc
    • Need to update the PSS 1539 to reflect focus.
    • CIMI call is typically Thu 2-4pm ET.  Would 12-1pm ET work?  OO is 1-2pm ET.  2-3pm it is.  Hans/Susan to sort administrivia.
  • ObservationDefinition needs/plans
    • Suggestion for the spreadsheet/dictionary to use ObservationDefinition.
    • Look at R5 Build for latest
    • Get an idea of missing data/structure 
    • Will sync with LIVD calls and Catalog calls (1-2pm and 12-1pm respectively.
    • Need to get ObservationDefinition to FMM1+ by end of year.
    • How is observationDefiniton to be used?
      • Instance for each lab test type, can it be used to validate on the wire package?
      • LabTest definition is based on activity definition with related observationDefinition and specimenDefinitions
      • What is the relationship between profiles on observations vs observationDefinition
        • Similar to how activityDefinition is used to create goal and carePlan
    • How to create a validation profile from ObservationDefinition to be applied to the actual Observation on the wire?
  • Vital Signs Ballot
    • URL for ballot version: http://hl7.org/fhir/us/vitals/2020Sep/
    • We started the review of ballot items.  The reconciliation in progress is here.
      • Notes from the reconciliation:
        • Motion to let editor address al AT comments – bring back, if not typo Lorraine, Susan Matney, no further discussion, against: 0, abstain: 0, in favor:17
        • Seth Blumenthal’s in person comments:
          • #135: Structure of the IG
            • Relationship between the individual data elements and grouping is not clear
            • Motion to improve this linkage in the future version of the guide persuasive with mod – Seth Blumenthal, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor:18
          • #136: why is diastolic not required?
            • A newborn baby does not have a blood pressure – add this as an example and maybe other examples
            • find not persuasive with mod – Seth Blumenthal, Nathan Davis, no further discussion, against: 0, abstain: 0, in favor:18
          • #137: Orthostatic body position = standing?
            • Not sure what orthostatic bodyposition is – it is a value in the valueset for bodyposition – we may need to update what the definition – per SNOMED synonym standing is correct. Motion to find Question answered Riki Merrick, Seth Blumenthal, further discussion – do we want to use synonym here? No, because we only use the FSN and n the near future they won’t even be expanded, but only provide the valueset definition and folks retrieve on their own, against: 0, abstain: 0, in favor:18
          • #138: TOC formatting
            • Motion to find persuasive – Riki Merrick / Susan Matney, further discussion: will have to look for cs templates that will help with the formatting in the tool, against: 0, abstain: 0, in favor:18
          • #141: importance of elements in the blood pressure panel
            • This seems to be very subjective, as it is context dependent
            • Motion to find question answered – Lorraine Constable, Nathan Davis, no further discussion, against: 0, abstain: 0, in favor:19
          • #142: same resolution as #141
          • #143: clinician feedback on specificity
            • Use of cm, m, inches, feet – lots of discussion around units of measure at the connectathon – solution was that folks should convert their observations to the normalized units of cm, folks can display it in other units in their system
            • Valueset around the body site is preferred, so it can be expanded, if desired
            • Method is optional, not required, which enables the use of more or less detail as clinically relevant
            • Motion to find question answered – Seth Blumenthal, Nathan Davis, no further discussion, against: 0, abstain: 1, in favor:15
    • The project team will prepare block votes that will be sent out and the voted on in the OO conference calls.
      • Proposed dispositions for ballot items that are marked as in-person requested and are persuasive following the proposers suggestions can be included.  They can still pull it from the block vote.  But if the proposed disposition varies from that, the ballot item should be scheduled with the submitter in attendance.
    • All other items, or items pulled from a block vote, will be discussed in the CIMI meetings (Thursday 2-4pm ET) and upon completion of the review OO will finalize.
    • Meeting minutes will be labeled so they will be available here.

For Thursday 4 PM Quarter – are we joining FHIR-I or do we have also an OO quarter?

  • Will do FHIR trackers 2 – 3:30 PM EDT
  • Join FHIR-I 4 – 5:30 PM EDT

Q4 = Plenary Session

Thursday, September 24, 2020

Q1:

Chair: Hans Buitendijk

Scribe: Hans Buitendijk/ Riki Merrick

Topics:

  • Device/DeviceDefinition/DeviceMetric
    • DeviceMetric is an "extension" effectively of the Device resource.
    • DeviceMetric is not the same as an ObservationDefinition.
    • The Observation is the actual observation/result of a Device /  DeviceMetric, where a DeviceMetric addresses a particular measurement capability of a Device that generates an Observation, such as the state of that capability, calibration, etc.
    • The DeviceMetric in essence provides further information on certain capabilities that are documented on a Device or DeviceDefinition.
    • Needs to be clarified in the Boundaries and Relationships of DeviceMetric.  Dev WG will progress that.
    • That also needs to be done in reverse on ObservationDefinition, Device, and DeviceDefinition by OO WG.
  • Specialization/Capability/Property
    • Concerns with overlaps.
    • Proposal:
      • Merge DeviceDefinition.specialization and .capabilities to cover both and call it .capabilities that capture what the the device could do.
      • Update DeviceDefinition.property to reflect all possible properties.
      • Remove Device.specialization and include Device.capability that mirrors DeviceDefinition for what it is actually capable to perform in use.
    • With Device.type now being 0..* the Device.specialization purpose can be put into Device.type.  It seems that 
    • Further Proposal
      • Collapse into Property.
  • Substance, PackagedProduct update
  • Use substance resource and make indicator to show instance or kind
    • Link substance to substanceDefinition
    • Allow using code or reference to a definitional resource
    • Reason to allow this linkage to figure out if we want need 2 definitional resources
    • We need to describe all the conditions and when to use which way to use either one of these
      • Will discuss that Q1 tomorrow
    • How would you identify the package/container to identify instances of substances?
      • Substance itself has an ID, if the flag is set to instance
      • Should update in boundaries when to use package and when to use substance instance
        • Medication definition Module has some of this described for – when to use kinds and when to use instances
  • UDI Ballot Recon
  • v3 Cardiac Implants withdrawal?
    • Was reaffirmed and has April 2020 date
    • We have time – need to update the standards product page

Q2:

Chair: Hans Buitendijk

Scribe: Hans Buitendijk/ Riki Merrick

Topic: 

  • DME Order Ballot Reconciliation Update
    • Get summary sheet from Robert Dieterle
    • Has amalgamated worksheet – is being cleaned up, will need to be updated for uploading to jira
      • We need to update the instructions on how to upload spreadsheets to jira
      • Bob can share his notes with Lorraine
      • Need to have issues making changes to content in the votes
        • changing A-S to A-T
        • auto-applying the A-Ts as technical corrections – set disposition comment to auto-approve
        • adding summary text
        • adding the artifact
      • have to go find the exact text that the ballot is called in jira, which is not easily discoverable
      • we need to bring this up to TSC
    • Motion to let the editor address A-Ts, as well A-n that actually are typos, and bring those that require further review back to the team.  Bob Dieterle, Lorraine Constable
      • Against: 0; Abstain: 2; In Favor: 17 
    • Planning to change from DME and POAb
    • Will continue Monday DME calls for ballot reconciliation and prepare block votes, bring big items back (may be 5)
    • Hans’ submission was for HRex – Bob will be notifying Lloyd about this mismatch, ccing Hans
  • Device/Definition Update
    • FHIR-26424 - Getting issue details... STATUS
    • Difference between capability and property, type and specialization
      • Type should be 0..* on both resources, this allows to then drop specialization (some have already implemented – need to figure out
      • Clean up the definitions of capabilities and properties, boundaries are not well described currently
        • Drop capability
        • Move description from capability to property
        • merge the definitions
        • add more examples to show the breadth
        • add value Boolean to the datatype choices
    • Will be on Monday’s Healthcare product calls 3 – 4 PM EDT
    • DeviceRequest can point to either device or DeviceDefinition has been approved for R5 (Bob D has an extension currently)
  • Order Catalog
    • ADD LINK TO Francois' slides
    • Start expanding on creating a catalog for devices using deviceDefinition
      • Sept ballot has a shell for it – no content yet – need input
    • Reach out to II and update them on the progress and ask them to provide order sets
    • Discussion around publication:
      • Publish now, which “ties us on R4” or stay in current build only and wait for next official release of FHIR to publish?
        • Makes sense to go with R4B, which will ballot in Jan 2021 and released in second quarter of 2021, since this will support medicationKnowledge
        • DaVinci created a profile of list for medicationFormulary – Check with Bob D and Viet – need to get alignment
          • This is from insurance point of view – what drugs are covered and the price points that are covered by insurance
    • LIVD
    • IICC format updated to support result coding
    • Added that to the FHIR resources
    • Also updating based on ballot reconciliation from first ballot
    • decided not to publish now and add the new capabilities and ballot in Jan 2021 and use that for first publication
    • working on converting content from spreadsheets to FHIR shorthand format (FISH)
  • Task
    • May update task with more elements based on event pattern – that was discussed in FHIR-I – <Vassil to forward the tracker ID>
    • DME ballot exchange patterns are using task to support workflow with intermediaries – but there are some assumptions that when intermediaries are involved should be dealt with using FHIR messaging
      • But in DME IG task is used to deal with exchanging the state of the DME order, where the intermediary is the holder of the task – the performer is subscribed to task, so they get notified when
        • ServiceRequest lives on the Ordering side – performer asks the intermediary to get the ServiceRequest for them for the ordering Provider
        • This can be done using the configuration set up
          • Any GET for a specific endpoint s=results in GET from a defined endpoint and do a PUT to the performer – the intermediary also has the option to store the ServiceRequest, but with the RESTful technology you get the most receipt version for the ServiceRequest
        • When ServiceRequest is being picked up – how are the references dealt with to other resources?
          • ServiceRequest has link to the ordering provider (URL)
          • Intermediary MUST (acting as full proxy) replace the initial link to the local link inside the intermediary with the version referenced
        • You can also mix this approach with messaging approach, depending on what either partner supports
        • Can have an intermediary using messaging in both directions as well
        • Vassil has comment on expanding more verbiage around these diagrams and adding examples
        • Tricky part will be around messageHeader.ID, messageHeader
        • Difficult part will be how to link the acknowledgments back and how to manage the messageHeader reference elements
      • HRex ballot also had a lot of generic advice on how to do data exchange – how can we keep this guidance in a central place rather than in IGs as it is right now
        • Vassil made a negative comment on HRex to move this content into FHIR core
      • V2-to-FHIR ballot also has Vassil’s comment around task mapping

Q3:

Chair: JD Nolen

Scribe: Riki Merrik (for the first 30 minutes)

FHIR tracker review

  • FHIR-28097 - Getting issue details... STATUS - Make device in DeviceDefinition from 0..1 to 0..*
    • Does this mean * is “AND” or “OR”
    • If you need multiple devices to perform then it would be and (applies to PCRs, where you use Thermocycler and Electrophoreseis afterwards for detection), or is it an or to indicate this is allowed to be done on these kind of
    • Check for other trackers to see, if Francois has solved this in catalog
    • Persuasive with mod
    • More modeling on how to indicate the AND vs OR issue discussed above
  • FHIR-28096 - Getting issue details... STATUS  – Change specimen in observationDefinition from 0..1 to 1..*
    • Cannot be 1..* - because not all observations have specimen
    • This case * is only OR – we should describe this in the comments on the element
      • For LOINCs like Ser/Plas/Blood will need to have more than one
    • For LIVD profile we can make it 1..*, since for lab tests we always expect a specimen
      • How would we deal with a composite test like calculation of a creatinine clearance?
        • Have observation on serum creatinine
        • Have observation on urine creatinine
        • What would the specimen be for the calculation?
          • Have 2 or none, if none, then we don’t want this to be 1..*
        • In specimenDefinition for lab catalog we allow more than one specimen reference
          • This was for dealing with preferred vs allowed

Riki dropped off after 30 min (sad)

Q4:

Chair:

Scribe:

Friday, September 25, 2020

Q0:

Chair: Hans Buitendijk

Scribe: Hans Buitendijk/Riki Merrick

V2 to FHIR mapping

  • Take HL7 V2 message and create a FHIR message bundle – though it does not necessarily have to end up in a bundle, but could also just map to the individual resources for using RESTful or storage
  • See project page 2-To-FHIR Project
  • Balloted version: Hans Buitendijk <ADD LINK>
    • Used conceptMap to create the IG mappings
    • Is available in JSON and XML in IG, is in GitHub for FHIR Shorthand (FSH) https://github.com/HL7/v2-to-fhir 
    • This was the first round to get a good idea what the scope of work needs to be
      • Will not publish after this ballot, will for sure go to another round
      • Will include all complete mappings, but may have some placeholder even in final publication to start getting the common mappings out
    • Reconciliation:
      • Consolidated spreadsheet is not fully complete – need to get the comments from Keith, which he put into Jira underFHIRpath – looks like he didn’t vote
      • Motion to let the editors address the A-Ts and come back to the team for questions.  Craig Newman, Riki Merrick
        • Against: 0; Abstain: 0; In Favor: 11
      • Looking at all Negatives:
        • #15: How to handle mappings to segments in messages, that are not yet/completely mapped or they are decided to only focus on the normally used elements from these segments?
          • Include what we have
            • Freida and Riki like this approach – as long as this is properly labeled- maybe use FMM levels?
            • Craig agrees for work cycle, but does not like it in publication, because it is not normally done in other venues being published – maybe we need to narrow our scope for publication
              • We don’t do it in IGs, but we do this in the core FHIR spec using FMM levels
            • Remove those completely
              • If we do that, we need to figure out how to exclude that content in GitHub
                • Add a column as an indicator?
                • Add a column for each draft element in the mapping
                • Use a specific character for any element to exclude from the mapping
              • Completely remove them from the work – we don’t like that approach, we need to retain the content in the source
            • Include in the message map and nowhere else?
            • Need to hear from the tool smiths on what approach works best for them
              • There is an agile approach taken to development, so marking what is published vs work in progress is important
            • Include a hyperlink to open issues / additional mappings that are NOT yet published to help people find it
            • Need to define what is done enough to include as Draft
            • Next step: Get input from project team and bring back to OO for vote later
          • #17: CWE/CE/CNE mapping is still underway – must be resolved BEFORE final publication
            • Motion to find persuasive Riki Merrick, Freida Hall, no further discussion, against:0, abstain: 0, in favor: 14
          • #22: Add Camila Altman into list of contributors, if she agrees - Motion to find persuasive Freida Hall, Ralf Herzog, no further discussion, against:0, abstain: 0, in favor: 14
          • #23: Dealing with identifying HL7 V2 tables as user defined vs HL7Defined – do not like to have “USER” instead of “HL7” in the name of the HL7 table; agree it’s important to distinguish
            • Needs to work for the tool smiths
            • Riki likes it closer to the name (on the V2 side)
            • Should we harmonize with how V2+ is dealing with it?
            • Figure out the name and harmonize with the representation in V2+
            • Motion to do what Hans has written into the spreadsheet Riki Merrick, Ralf Herzog, persuasive with mod, no further discussion, against:0, abstain: 0, in favor: 11
          • #24: Need to include the conceptMap profile used, so folks understand what they are looking at
          • #25: Need to include the bundle profile used, so folks understand what they are looking at
            • Motion to find #24 and #25 persuasive Riki Merrick, Ralf Herzog, no further discussion, against:0, abstain: 0, in favor: 11
          • #27: Make sure example messages are fully vetted and any vendor reference should be dropped from these examples –
            • Let project team decide on this one
          • #28: Skip
          • #42: Confusion between event and message structure needs to be clarified
            • Agree that the message structure notation and the name don’t map
            • Intent was to be only based on message structure, but the trigger event may change the context, which may affect the mappings
            • Next step should be to review the message structures that are used across different events
              • ADT
              • SET
            • Motion to find persuasive with mod: Use message structure with the correct names, differentiate by event trigger ONLY in situations when the message structure is used differently (showing the FLL mapping) Riki Merrick, Rob Hausam, no further discussion, against: 0, abstain: 0, in favor: 10
          • #52: Broken links in the table under HL7 FHIR column
            • Motion to find persuasive Riki Merrick, Freida Hall, no further discussion, against:0, abstain: 0, in favor: 10
          • #58: Vassil’s comments are all in person need project team discussion
          • #59: Vassil’s comments are all in person need project team discussion
          • #60: Vassil’s comments are all in person need project team discussion

Q1:

Chair: Hans Buitendijk

Scribe: Hans Buitendijk/Riki Merrick

Topics:

Joint with BRR

  • Agenda Review:
    • PackagedProduct
    • Substance, SubstanceDefinition, Sample
    • Specimen
    • Common Product Model plan / SPL plans
    • Use of observation in context of manufacturing of any product (batch or otherwise) for QC reasons


  • PackagedProductDefinition
  • Scope clarification
    • can be broader than just medicinalProduct
    • Represents a package and what it contains with information on both the package as well as each item as it applies to the item in the context of the package.
    • How does IDMP fit in here?
      • You have unpackaged product (medication)
      • The packaged version of the product (number of pills in a bottle)
    • Clarify the boundary in context of dealing with packaged devices
  • Is "information on the package" considered "the label", the sticker with warning?
    • It is not about what is printed on the package.
    • It is what is the package physically (dimensions, material, etc.) and what is in it.
    • Concerned that this is part of the labeling information.  
    • Labeling information is currently across various resources (medication / device / packagedProduct).  There is no singular "label" resource. 
      • add a comment around this in the boundary section
  • It is more around manufacturing what the package would entail, not the actual package.
  • For finished product or drum of raw material.
  • Packaging is not regulatory labeling.
  • One has:
    • Unpackaged product information
    • Packaged product information
  • Challenge is that sometimes when referencing "a device" one means one or the other, depending on context.
  • May talk about the overall package only (not the items that are to go into it), or the entire package configuration.
  • Sellable product vs. package.  What is the difference?
    • For device = that is on deviceDefinition (we don’t have the packaging around that)
    • Is this at the same level here?
    • I can sell insulin pens in a single package or 10, it will still be the same device, but a different sellable item
    • Packaging for purpose of transport (can be covered here)
    • Packaging for the purpose of selling (can be covered here also)
    • We approve bulk packaging that then will be re-packaged to smaller prescribed amounts – to pharmacy give 1000 pills, re-packaged to smaller Rx amounts like 30 or 90
  • Three levels :
    1. Product - Unpackaged - the medication, the device, gloves, etc.  MedicinalProductDefinition, DeviceDefinition? (see also: https://build.fhir.org/medication-definition-module.html)
    2. "Middle" - packed type
    3. Box - The configuration of boxes and items.  - the box that contains boxes (and boxes) that contains the 100 glove box.
      1. We can then profile this resource to use with devices, where the middle level is constrained out
  • PackagedProductDefinition covers 2 and 3.


  • Substance, SubstanceDefinition, Sample, ManufacturedItemDefintion
    • Substance resource use:
      • Instance and some level of definitional attributes
      • Main use is kind of (for medication)
      • Instances are represented as backbone element
    • SubstanceDefintion is always definitional, has many more attributes than the substance resource, when used to describe the kind of substance, but it is not needed for ALL substance descriptions
    • Should the substance resource be able to point to substanceDefintion?
      • Not needed – these are both referenced from other resources – depending on the level of detail used they would chose – these don’t usually overlap in practice
    • code – change to codableReference
      • To allow the reference to the instance
        • If it has a lot number, wouldn’t it be a product?
        • We don’t have just a “product” resource
    • Continue the discussion on OO’s Monday calls:
      • Specimen call is 2 – 3 PM EDT
      • HealthcareProduct is 3 -4 PM EDT
      • Have Co=Chairs work out if both call times are needed, since specimen overlaps with workflow call time
      • Aim for October 12, 3-4pm ET on Healthcare Product call.
  • Specimen
    • October 12, 2-3pm ET if needed with Specimen on Sample.
  • Common Product Model Plans - RPS plans (10 min at the end)
    • RPS is moving forward, so CPM cannot go away.  Cannot be retired.
    • ICSR is still around as well using CPM.
    • SPL is moving to FHIR.
    • At least 5-10 years.
  • Observation - Manufacturing of any item (batch, otherwise) for quality processes
    • October 6 - BR&R - 4-5 ET   Tuesday