This wiki has undergone a migration to Confluence found Here
2016-03-23 FMG concall
Jump to navigation
Jump to search
| HL7 TSC FMG Meeting Minutes Location: |
Date: 2016-03-23 Time: 4:00 PM U.S. Eastern | |
| Chair: | Note taker(s): Anne W. | |
| Quorum = chair + 4 | yes/no | |||||
| Co chairs | David Hay | x | Lloyd McKenzie | |||
| ex-officio | Woody Beeler, Dave Shaver FGB Co-chairs |
x | Wayne Kubick, CTO | |||
| Members | Members | Members | Observers/Guests | ||||
| x | Hans Buitendijk | x | Brian Postlethwaite | x | Paul Knapp | x | Anne W., scribe |
| Josh Mandel | x | John Moehrke | x | Brian Pech | x | Grahame Grieve | |
| . | |||||||
Agenda
- Roll Call
- Agenda Check
- Minutes from 2016-03-09_FMG_concall
- Administrative
- Action items
- Lloyd to follow up on MnM PSS
- Lloyd to update on AdverseEvent changes/whether or not WG will complete the proposal
- Brian Post to check on SOA PSS
- Brian to finish up ServicesDirectorandScheduling
- David to ping the track leads again re: track reports
- Brian Post to tidy up/combine tracks
- David and Lloyd will work offline on how to edit the ReferralsWorkflow proposal appropriately
- David to ping Eric to see how it's going with updating DAF to reflect lab results
- Paul/David to follow up with Devices to make sure proposals are complete with approval dates noted
- Grahame and Lloyd to meet with Wayne to discuss alternative to gforge and associated integration points
- Approval Items:
- Review Pending Resource Proposals
- Discussion topics
- WGs contributing to FHIR in terms of WG health balloting metric
- Further discussion on custom resources?
- Zulip for FMG/FGB
- Reports
- Connectathon management (David/Brian)
- FGB –
- MnM –
- FMG Liaisons –
- Process management
- Ballot Planning
- Ballot content review and QA process FHIR QA Guidelines
- AOB (Any Other Business)
Minutes
- Agenda review
- Add freeze
- MOTION to approve by Grahame; second by Brian Post
- VOTE: all in favor
- Minutes from 2016-03-09
- MOTION to approve by Paul; second by Brian Post
- VOTE: all in favor
- Action items
- Lloyd to follow up on MnM PSS - MnM is aware; add to next week
- Lloyd to update on AdverseEvent changes/whether or not WG will complete the proposal - add to next week
- Brian Post to check on SOA PSS - add to next week
- Brian to finish up ServicesDirectorandScheduling - add to next week
- David to ping the track leads again re: track reports - complete
- Brian Post to tidy up/combine tracks - add to next week
- David and Lloyd will work offline on how to edit the ReferralsWorkflow proposal appropriately - add to next week. Add Brian Post to discussion.
- David to ping Eric to see how it's going with updating DAF to reflect lab results - add to next week
- Paul/David to follow up with Devices to make sure proposals are complete with approval dates noted - add to next week
- Grahame and Lloyd to meet with Wayne to discuss alternative to gforge and associated integration points - complete.
- Content freeze:
- Date is midnight Eastern on Sunday 2016-03-27. Decision to push it to end of day on Monday, 2016-03-28. Lloyd to post to implementers. Continuous build won't be frozen.
- Resource proposals:
- DecisionSupportRule: should be RIM mapping. Missing scope and explanation of why it's meeting appropriate boundaries of a resource. Missing implementations.
- Lloyd to reach out to Bryn to ask him to complete.
- DecisionSupportService: same issues
- Lloyd to reach out to Bryn to ask him to complete.
- GuidanceResponse: Should beef up definition. Couldn't they use an existing resource? Need examples of what this is to understand what makes it unique. Grahame: we should hold off approving decision support resources until after Montreal connectathon. Lloyd reached out to Bryn to ask why other resources aren't a good fit. Grahame would like to see more than one Connectathon around this space.
- SupplyDelivery: Lloyd - this one has two open issues against it. One is the relationship between this resource and DeviceUseRequest. Both are dealing with same space. The other is whether we should be using the same resource for patient-specific supply requests and events as we use for bulk supply requests and events. Has OO dealt with those? Hans: No. It would be helpful to get input from this group on whether we should be more generic or specific. Lloyd: We could send a request from the FMG to get together to do this. What's typical in the business space? If it's typical to track them and display them together, then having a single resource makes sense. If it's typical to manage them separately, then it would make more sense to have distinct resources. May evolve towards helping out with DeviceUse piece. Hans: The question is other than having the ability to associate with the patient, what other data on the resource would be different? Lloyd: It would be instructions. Grahame: Bulk supplies may also have instructions. Lloyd: Also possible overlap with VisionPrescription on the request side. Need to further discuss DeviceUse issue. SupplyRequest is an authorization.
- Hans to reach out to relevant WGs to help nail down the issues around SupplyDelivery
- DecisionSupportRule: should be RIM mapping. Missing scope and explanation of why it's meeting appropriate boundaries of a resource. Missing implementations.
- WG Health Balloting: No clean way of differentiating level of contribution. Should count if they're listed as Developing and have a PSS.
- Custom Resources
- Issue continues to bubble. In the current build we have the technical support infrastructure. It's a governance question. Grahame suggests that if you do a custom resource, you have to get name approval. Lloyd: we would have to have a policy defining our rules for approving or not. Grahame: simple names would be best but we have to manage the issuance. Paul: what if we prefix custom resources. Grahame: they should be prefixed in a way that indicates the provenance of the resource. Hans: Trying to understand why we need HL7 approval. We do allow for extensions. Do we really want to put a limiter on that? Grahame: I'm proposing an approval process for the name registration, not the resource. Lloyd: We would ensure name uniqueness. We could also include the submitted names in the schema such that they would pass schema validation. As part of the name registration process, would there be differentiation between the two categories that we anticipate? 1) Those who want to define a resource that is not included in FHIR but it is interoperable; and 2)Those who use the FHIR platform to build things that are not interoperable. Discussion over whether or not that is supportable or appropriate. If not interoperable with FHIR, Paul suggests it's not appropriate to call it FHIR. Lloyd states it's at least a good idea to identify through naming which category the resource falls into (FHIR compliant or something simply using FHIR tooling). Lloyd: how close are we to actually needing a policy in place for submission and management of naming requests? Grahame: It would make a difference as soon as it came available. Lloyd: From a technical perspective we could use gforge for submissions. One question is do we have an expectation that names would be in English? Our ability to evaluate non-English names would be constrained. So let's say that Open EHR can use our stuff. We can keep them from using the trademark symbol and go after them if they use the word FHIR in the name of their product; but if they say FHIR-based or FHIR-aligned or similar, it's going to be hard. We are best off defining a term, and a specific set of criteria around using that term. If we look at resources that don't overlap with existing content: are we comfortable issuing names for those? Grahame returns to idea of prefixes. Lloyd: My leaning is we do go the route of prefixes. All prefixes aside from one is outside of the conformance space. Paul: registering is a useful thing. Discussion over whether or not interoperable custom resources will be tested; decision that they just declare they are and we revisit if disputes arise.
- ACTION: Grahame will write up proposed process over Easter for review by FMG
- Issue continues to bubble. In the current build we have the technical support infrastructure. It's a governance question. Grahame suggests that if you do a custom resource, you have to get name approval. Lloyd: we would have to have a policy defining our rules for approving or not. Grahame: simple names would be best but we have to manage the issuance. Paul: what if we prefix custom resources. Grahame: they should be prefixed in a way that indicates the provenance of the resource. Hans: Trying to understand why we need HL7 approval. We do allow for extensions. Do we really want to put a limiter on that? Grahame: I'm proposing an approval process for the name registration, not the resource. Lloyd: We would ensure name uniqueness. We could also include the submitted names in the schema such that they would pass schema validation. As part of the name registration process, would there be differentiation between the two categories that we anticipate? 1) Those who want to define a resource that is not included in FHIR but it is interoperable; and 2)Those who use the FHIR platform to build things that are not interoperable. Discussion over whether or not that is supportable or appropriate. If not interoperable with FHIR, Paul suggests it's not appropriate to call it FHIR. Lloyd states it's at least a good idea to identify through naming which category the resource falls into (FHIR compliant or something simply using FHIR tooling). Lloyd: how close are we to actually needing a policy in place for submission and management of naming requests? Grahame: It would make a difference as soon as it came available. Lloyd: From a technical perspective we could use gforge for submissions. One question is do we have an expectation that names would be in English? Our ability to evaluate non-English names would be constrained. So let's say that Open EHR can use our stuff. We can keep them from using the trademark symbol and go after them if they use the word FHIR in the name of their product; but if they say FHIR-based or FHIR-aligned or similar, it's going to be hard. We are best off defining a term, and a specific set of criteria around using that term. If we look at resources that don't overlap with existing content: are we comfortable issuing names for those? Grahame returns to idea of prefixes. Lloyd: My leaning is we do go the route of prefixes. All prefixes aside from one is outside of the conformance space. Paul: registering is a useful thing. Discussion over whether or not interoperable custom resources will be tested; decision that they just declare they are and we revisit if disputes arise.
- Zulip:
- Zulip cannot be public without allowing open posting. Other option is having a closed group with a bot, or staying on Skype (although Skype is hinting they will disable their API). Grahame thinks it's fine to move it to Zulip and tell everyone it's open but FMG members only aside from invitation. Lloyd: How do we tell people? New people will be coming continuously. How do we communicate community expectations?
- ACTION: Grahame will see if he can get a place for code of conduct/community expectations and then we can revisit. Lloyd suggests having a prefix for threads to identify.
- Zulip cannot be public without allowing open posting. Other option is having a closed group with a bot, or staying on Skype (although Skype is hinting they will disable their API). Grahame thinks it's fine to move it to Zulip and tell everyone it's open but FMG members only aside from invitation. Lloyd: How do we tell people? New people will be coming continuously. How do we communicate community expectations?
- Adjourned at 5:28 pm Eastern
Next Steps
| Actions (Include Owner, Action Item, and due date) | |||
| Next Meeting/Preliminary Agenda Items |
Back to FHIR_Management_Group
© 2015 Health Level Seven® International
