|5 min||Welcome, agenda review, meeting minute approval||Danny|
- Motion- Craig moves to approve last week’s minutes
- Second- Joginder
- Vote- 11,0,0
| 10 min|| |
- Expired STU Withdrawal Approval
|Hetty Khan|| |
- PI ID 1208 – HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, DSTU 2 (US Realm)
- replaced by 1477 – Vital Records Death Reporting V2.6
- Project 1208 Expired recently
- Is now replaced by project 1477, has been updated to include additional roles medical examiners and funeral directors.
- Will list on website as retired, but will withdraw
- Motion- Hetty moves to approve withdraw request with updating the justification to reflect that 1477 has completed ballot recon.
- Second- John
- Question- AMS- STU 2 is replacing STU 1
- Vote- 14,0,0
| 15 min|| Review of gForge ticket for immunization route || Craig|| |
- The value set for administration route includes a code for NASINHLC (Inhalation, nasal cannula/ Inhalation, nasal, prongs)
- Presumably the nasal route if intended to account for intranasal live attenuated flu vaccine but this vaccine is not administered via cannula
- This value set is only an example and draws from codes in http://hl7.org/implement/standards/fhir/v3/RouteOfAdministration/cs.html
- There is a code in this code system for "inhalation, nasal" but the US LAIV product administration instructions uses the term "intranasal" and we're not sure if inhalation and intranasal are really equivalent
- Because it's only an example value set, we think it's better to just remove the code from the value set rather than try and replace it
- Any IG using the Immunization resource would likely need to develop their own value set anyway, so having an incomplete value set probably is not a major issue
- Leaves the value set incomplete, but it’s just an example value set and any user of the IG will need to go through and define the value set anyway.
- We could punt to vocab, though they will likely punt back to SMEs
- The value set right not draws from the V3 value set. We could create a value set using a different code system, like a V2 table. No one really knows why the V3 code system was used initially anyway. Were reluctant to change the underlying code system for something that isn’t really critical at this point.
- The initial FHIR resources were modeled after the V3 counter parts
- This is just an example value set in a base resource, not for an IG
- Motion- Craig moves to approve the removal of the NASINHLC code from the example value set.
- Second- John
| 10 min||Review of gForge ticket for ImmDS patient reference and broken links|| Craig|| |
- A couple of ballot recon comments for the Immunization Decision Support FHIR IG (2018 ballot) were missed
- Both are persuasive and have already been fixed in the most recent ballot version
- ImmDS Patient reference- persuasive-
- in the imm profile we did not update the reference to the profile of the patient as defined in the IG. This change was made in the second ballot. The profile should be referenced in the Imm, ImmEval, and the ImmReco resources. Will build off of US Core and change only those things that are needed for this use case.
- Will be bringing back on a subsequent call.
- Broken link- persuasive-
- will make sure all links are working before publishing anything.
- Motion- Craig moves to approve as persuasive and will ensure that all links are functioning before publishing and updated IG.
- Second- John
|15 min||Review of gForge ticket for address classification || Craig|| |
- Crystal Snare asked for clarification so she could do some research on her side. She is not on the call. Will revisit.
- For epi use cases, it might be useful to classify a patients address beyond what is in the AddressUse, which has a defined set of codes that must be used.
- There is a classification element that could be added that would allow for classifying an address, like for assisted living facility, dorm, correctional facility…
- Would this be useful for public health purposes? YES
- For CCDA there is a characteristic of home in the social history template
- This is more about the location, not so much the address, but for every instance of address, there is not necessarily a location. Could create a template that you add.
- How is this handled in ODH?
- Isn’t quite modeled like this currently. May have an interest in an element like this, intrigued about the opportunity of something like this.
- Could you have a location on the patient resource that you could qualify?
- This definitely is important in supporting epidemiologic, contact, outbreak investigations
- Could help identify potential places and likelihood of exposure, as well as imply infection control measures or transmission mitigation measures
- Address includes points in time which would be helpful, there it is unclear as to what those dates represent.
- Sarah will research what is documented in eCR and submit to workgroup
- AMS will research and provide info from vital records domain and submit to workgroup
- We noted that the patient resource doesn’t have a location element for either home or work or other types of activities. Workgroup members will submit the ways of documenting location types today including value sets so that we can get a picture of places that this sort of data is exchanged today. There may be a need to update the address data type possibly by extension as this could be useful for Public Health purposes. Or it may make more sense to add the ability to document patient related locations.
- Will bring this back to this group in a couple of weeks to allow for research. Will tentatively put on the agenda for the 21st.
- May bring to the attention of other work groups like PA.
|5 min|| Reminders|| Craig|| |
- Reminder for EDHI coming up on 11/14 and CCHD on 11/21