go to post Jenny Ames · Dec 5, 2016 Take a look at the Learn FHIR for Software Developers resource guide for resources on how to use FHIR in HealthShare Health Connect.
go to post Jenny Ames · Nov 29, 2016 Since Ens.DataType.ConfigName only allows you to select one component, you could also simply this by omitting the loop:set tSC = ..SendRequestAsync( ..TargetConfigNames, pRequest)If you do this, you should include a note for the setting to only specify one component as you can still specify multiple by hand.
go to post Jenny Ames · Oct 11, 2016 We have a few online learning resources that may also be of interest to you:OAuth2.0 Resource Guide - This includes a video about what OAuth2.0 is at a high level as well as current OAuth2.0 documentation. (Of note, OAuth2.0 documentation is now available here).FHIR content exists in a few places on the online learning site as well. For example:Getting Started with FHIR online courseIntroduction to FHIR from our Global Summit conference (only available to HealthShare customers)FHIR in HealthShare from our Global Summit conference (only available to HealthShare customers)A new FHIR resource guide is coming soon...Health Connect documentation which includes FHIR documentation (only available to HealthShare customers)
go to post Jenny Ames · Sep 22, 2016 Great example! Thanks for sharing! I love how simple and elegant your solution looks.
go to post Jenny Ames · Sep 21, 2016 Here's one: One best practice we often recommend is to build backwards.. Build business operations first, then business processes, then business services. That way you can test your business operation using the test utility and then when you go to test your business process, you know any new issues must be in the business process. And finally when you create your business service, you can pass a message in like normal and know that the interface works as a whole.
go to post Jenny Ames · Sep 21, 2016 Very interesting Mike! Thanks for sharing. There are always multiple ways to solve a problem but I think you're on to something here...So thinking through a bit more about when this approach might make more sense than using a built in loop (like a foreach): Because the stream was one item, it sounds like a foreach would probably have been more difficult in that situation? Were there other ways you considered doing this? And if so, what went into the decision to use the code action here? I'm assuming this was called from a business process built using the Business Process Designer?That's a cool idea of setting variables in debug/testing mode!
go to post Jenny Ames · Sep 19, 2016 Great post Ben. Thanks for the best practices. For those who start on a newer build that uses the new JSON syntax, is there any benefit to using these macros? Or is this only for those who will upgrade from an older version?
go to post Jenny Ames · Sep 9, 2016 Hi Jeff, thanks again for your suggestion! We actually included this in one of our newer online courses Advanced Data Transformations. Thanks!Jenny
go to post Jenny Ames · Jun 21, 2016 I can imagine moving NTEs would be a common use case as v2 does provide a bit of optionality in implementation but if its the only place that's needed, using a Code Action makes sense to me! Thanks Liz!
go to post Jenny Ames · Jun 8, 2016 To get the conversation started: One interesting way I've seen people use code actions is to comment out several actions while debugging. Since its not immediately apparent what is in a code block, you need to be careful to clean up your work when you are finished (potentially removing actions you no longer want as well as removing your code block) so others (and let's face it, you!) don't get confused later.
