First of all, when it installed, I'd have it ask a few questions about who I was, my name, e-mail, et cetera. Then I'd have it ask some questions about the organizations I was affiliated with, possibly selecting some of them (e.g. HL7, IHE, etc) from a pick list, or adding others.
When the application starts, I'm going to want to do one of three things: Start where I left off from my last project, or from where I left off on a recent project, or start a new project. When first loaded, I'm going to have to create a project.
That project is going to be one of five things: Creating an IG, a value set, a profile, an operation or an extension. That project is going to be created on behalf of one of my organizational affiliations, which will have some preset rules for how the project structure works (or maybe I want to apply my own personal rules -- because I might be setting them for the organization). Those rules affect where in the project certain files are stored, and in what sort of repository they are stored (e.g., CVS, SVN, a file system, a website or FHIR Server, et cetera). Having some useful presets would be good. For example, for GAO, I set up a particular file system structure for the contents of the IG, and the files were checked into SVN. Files are named in a certain way based on the kind of resource, its id and a few other bits of trivia perhaps. You could come up with a couple of different schemes.
An IG would start off with one of a few sample IG starter page sets, adhering to a particular content design. I could swap them out for the most part without fear that my customized content would be messed up. Similarly for a profile, value set, operation or extension would also allow for some preset designs and customized content files.
When creating an IG, a wizard would guide me through certain selections, "style", kinds of content to include (profiles, value sets, extensions, operations), et cetera. It would take me through the process of identifying actors (an IHE term mostly closely associated with Application Role in HL7 Version 3), to which a conformance statement might apply. It would have me define the conformance statement for each actor, including some optional features that might implemented (right now, FHIR conformance resources don't really have support for options though).
When creating a profile in an IG, I'd specify the resource and possibly a role being played. The tool would create the profile name based on the IG name/code, and the resource name and role. Thus, a profile for a patient resource in the Guideline Accountable Ordering IG (GAO) would be named gao-patient, and one for a ordering provider might be gao-ordering-practitioner (the form defaulting to igcode[-role-name]-resourcename).
After having named a profile, I'd basically be asked to check of those properties that I wanted to profile, and then quickly modify their values (cardinality, must support, etc). Where an existing value set was present, I'd be asked if I wanted to restrict or extend it where permitted. On creating a new value set, I'd be given simple ways to select codes from existing value sets that I'd used previously or which already exist). On creating an operation, I'd be asked to name the parameters, and further specify their details. As things went on, I'd discover the need to create a new profile, and could add that profile to a resource elsewhere, and the tool would remember that I referenced an as yet unknown profile, and would put it on my to-do list to create.
Building the IG would be a two stage process. The first stage would take the information I supplied in separate component files, and put it together into FHIR resources sufficient to be the guide. The second stage would be to compile those FHIR resources into the content we see on the FHIR IG site today, essentially running the FHIR IG build part of the process over those resources. The tool would also verify that I followed a number of best practices... that I had validating examples for each profiled resource, that I had examples of input and output parameters, and that I had conformance statements that linked to those profiles, and that no profile or valueset or operation was not linked back to something in the IG (ever create a set of constraints that weren't ever referenced any where? It's been done before. I'll bet you can't find the CCD template that was never referenced by any other CCD template, and so hardly ever used).
Anyway, that's my wish list. Get crackin' on it guys, would you.
Keith
When the application starts, I'm going to want to do one of three things: Start where I left off from my last project, or from where I left off on a recent project, or start a new project. When first loaded, I'm going to have to create a project.
That project is going to be one of five things: Creating an IG, a value set, a profile, an operation or an extension. That project is going to be created on behalf of one of my organizational affiliations, which will have some preset rules for how the project structure works (or maybe I want to apply my own personal rules -- because I might be setting them for the organization). Those rules affect where in the project certain files are stored, and in what sort of repository they are stored (e.g., CVS, SVN, a file system, a website or FHIR Server, et cetera). Having some useful presets would be good. For example, for GAO, I set up a particular file system structure for the contents of the IG, and the files were checked into SVN. Files are named in a certain way based on the kind of resource, its id and a few other bits of trivia perhaps. You could come up with a couple of different schemes.
An IG would start off with one of a few sample IG starter page sets, adhering to a particular content design. I could swap them out for the most part without fear that my customized content would be messed up. Similarly for a profile, value set, operation or extension would also allow for some preset designs and customized content files.
When creating an IG, a wizard would guide me through certain selections, "style", kinds of content to include (profiles, value sets, extensions, operations), et cetera. It would take me through the process of identifying actors (an IHE term mostly closely associated with Application Role in HL7 Version 3), to which a conformance statement might apply. It would have me define the conformance statement for each actor, including some optional features that might implemented (right now, FHIR conformance resources don't really have support for options though).
When creating a profile in an IG, I'd specify the resource and possibly a role being played. The tool would create the profile name based on the IG name/code, and the resource name and role. Thus, a profile for a patient resource in the Guideline Accountable Ordering IG (GAO) would be named gao-patient, and one for a ordering provider might be gao-ordering-practitioner (the form defaulting to igcode[-role-name]-resourcename).
After having named a profile, I'd basically be asked to check of those properties that I wanted to profile, and then quickly modify their values (cardinality, must support, etc). Where an existing value set was present, I'd be asked if I wanted to restrict or extend it where permitted. On creating a new value set, I'd be given simple ways to select codes from existing value sets that I'd used previously or which already exist). On creating an operation, I'd be asked to name the parameters, and further specify their details. As things went on, I'd discover the need to create a new profile, and could add that profile to a resource elsewhere, and the tool would remember that I referenced an as yet unknown profile, and would put it on my to-do list to create.
Building the IG would be a two stage process. The first stage would take the information I supplied in separate component files, and put it together into FHIR resources sufficient to be the guide. The second stage would be to compile those FHIR resources into the content we see on the FHIR IG site today, essentially running the FHIR IG build part of the process over those resources. The tool would also verify that I followed a number of best practices... that I had validating examples for each profiled resource, that I had examples of input and output parameters, and that I had conformance statements that linked to those profiles, and that no profile or valueset or operation was not linked back to something in the IG (ever create a set of constraints that weren't ever referenced any where? It's been done before. I'll bet you can't find the CCD template that was never referenced by any other CCD template, and so hardly ever used).
Anyway, that's my wish list. Get crackin' on it guys, would you.
Keith
In FHIR, "application role" or "actor" is handled using the Conformance resource.
ReplyDeleteThere's an extension you can use throughout the Conformance resource to differentiate "SHALL" vs. "SHOULD" vs. "MAY" - quite a few of the implementation guides have made use of it.
For naming scheme, I'd go with gao-practitioner-ordering rather than gao-ordering-practitioner. I understand that the latter is slightly more natural, but the former ensures that all of your provider-related profiles sort together and makes things slightly easier to find. You'll always remember the resource name, but might not always remember the adjective :>
Do I hear someone calling out our name? That's a nice comprehensive picture of profiling and I fully agree on it. Given the current version of the profile authoring tool we have (Forge, see http://fhir.furore.com/forge), and our discussions last week at the FHIR DevDays, I'd say it also mostly aligns with our roadmap for the tool. I'll admit there are some nice additional points (e.g. about setting up company policies) that we hadn't thought of before.
ReplyDeleteSo, we're cracking and working on this for you, right now and daily ;-)