PlanDefinition for Care Planning: Difference between revisions

Revision as of 12:26, 5 March 2018

Profile Development Work

Meeting is every other Wednesday 2-3pm EST
Webex
- Call-in toll-free number (US/Canada): 1-866-469-3239
- Call-in toll number (US/Canada): 1-650-429-3300
- Access code:926 359 852

December 6, 2017 Call Notes

Agenda
- Confirm template to use
- Discuss if we should write a new profile or add an update to DCP
- Raffaele use case

Notes
- Open Issue - Add recommendation for opt-in for updates as default for when treatment recalls occur - Make a SHALL
- Raffaele reviewed his pregnancy workflow use case
- Decision made to work on updating DCP with new profile work
- Discussed how updates of the carePlan resource occurs in DCP

December 20, 2017 Call Notes

Agenda
- Review process flow
- Confirm Actors and start transactions
- Review Actor Diagram

Notes
- Reviewed Actor Transactions diagram
- Reviewed New Actors and transactions
- Updated profile template used

January 03, 2018 Call Notes

Agenda
- Review Actors, transactions, options, actor grouping
- Plan use case update

Notes
- Profile artifacts on FTP site
- Raffaela will send me his use case
- Emma will post updated profile on the FTP site.
- Question about a care plan specific implementation google group - John will start the google group.

January 17, 2018 Call Notes

February 28, 2018 Call Notes

Discussion

walk thru forge to define the constaints and use the output of Forge to define the constraints and drop the definition in volume 2
Have been working with ClinFHIR as well. ClinFHIR can create the same think and have a better graphical representation.
Volume 1 - server must support subscription and subscription on plan definition
- when the user get a list of plan def
ClinFHIR - can generate the profile and export into Forge
Transaction - no specific constraints on the transactions can leave as is

Use an apply operation to generate the care plan Suggestions:

(John) ITI document sharing pattern uses the broader document description that anything can be shared with the specific mimeType - FHIR resouce can be defined as a mimeType. MHD document sharing - change back to mime. Will need to create a format code
Another suggestion for the interaction between content creator and content consumer is to get rid of content creator and use operations as transactions between Care Plan Contributer and Content Consumer. Don't use RESTFUL transactions.
- Using $Apply
  - Agreement that the requests $Apply should be an operation - not the usual RESTFUL transaction. See Apply
  - Updates made to Figure X.1-1: DCP Actor Diagram.

To Do

@@ Line 104: / Line 104: @@
 *Transaction - no specific constraints on the transactions can leave as is
 Use an apply operation to generate the care plan
-*ITI document sharing pattern uses the broader document description that anything can be shared with the specific mimeType - FHIR resouce can be defined as a mimeType. MHD document sharing - change back to mime
+Suggestions:
-Will need to create a format code
+*(John) ITI document sharing pattern uses the broader document description that anything can be shared with the specific mimeType - FHIR resouce can be defined as a mimeType. MHD document sharing - change back to mime. Will need to create a format code
-*the requests $Apply should be an operation - not the usual RESTFUL transaction. See [http://hl7.org/fhir/2018Jan/operation-activitydefinition-apply.html Apply]
+*Another suggestion for the interaction between content creator and content consumer is to get rid of content creator and use operations as transactions between Care Plan Contributer and Content Consumer. Don't use RESTFUL transactions.
+**Using $Apply
+*** Agreement that the requests $Apply should be an operation - not the usual RESTFUL transaction. See [http://hl7.org/fhir/2018Jan/operation-activitydefinition-apply.html Apply]
+***Updates made to Figure X.1-1: DCP Actor Diagram.
+'''To Do'''
+*Emma will post this version on the FTP site for folks to review.