While the public hospitals are trying to adopt FHIR as soon as possible this seems to not be the case for private entities. I heard that private entities are less likely to adopt FHIR due to the cost of transition and the fear of losing clients. I understand the cost reason, but the other one doesn't seems right. I chose a clinic based on the doctor I want to go to and the medical insurance I have. I don't know about HIPAA but in Europe the GDPR gives you the right to ask any entity to provide you the medical history in an interoperable format. This doesn't necessary means FHIR, but rather xml or json.
What do you think about this? What are the other problems and how do you tackle it?
Adoption patterns of FHIR vary from country to country and discipline to discipline. They're influenced by a bunch of factors:
are there regulations or government initiatives requiring the use of FHIR? requiring the use of a different standard? requiring interoperability at all?
are there business drivers that encourage interoperability (e.g. "My patients want to have their data on their phone" or "I can't keep up with the customization demands, I need people to be able to write plug-ins for my system"
are there already interoperability solutions in place and, if so, do they work?
These don't typically break down into public/private but in some countries they might.
Certainly there can be pushback against interoperability because of concern it may make it easier for patients to move elsewhere. That's one of the reasons for regulations such as GDPR or the data blocking rules in the U.S. Such regulations help, but if the desire isn't there to make sharing easy, then the tendency will be to meet the barest letter of the laws and to avoid as much as possible supporting their spirit.
One of FHIR's advantages is that it reduces the technical cost of interoperability. It's also spawned lots of examples of successful interoperability which proponents can point to. Both factors help to lessen the excuse for inaction of "it's too hard/expensive". However, for those who want excuses, there are always others to be found...
Related
I am using the SIU^S12 segment and I need to indicate the financial entity (IN1). But IN1 is not allowed in segment SIU^S12. Has anyone ever experienced this?
You're right that financial information is not included in the SIU^S12 message, nor is it in the entire HL7v2 scheduling domain. I can't really attest to the "why" behind this, but only share my experience in the US domain.
From a very high level, in the United States, scheduling HL7v2 interfaces are used almost exclusively before the patient arrives, and ADT (HL7v2 Chapter 3) is used almost exclusively once the patient arrives. This is not ideal, and sometimes bears extra licensing costs in terms of getting two HL7v2 interfaces.
From a design perspective, I it makes sense to have a separation of concerns - SIU^S12 is chiefly concerned with scheduling resources - even treating patients as resources. SIU^S12 can have multiple patients in its schema, whereas ADT^A01 must have exactly one. While it would be possible to attach GT1, IN1/2/3 to each potential patient in SIU, it's easier to wrap your head around when only one patient is in play.
From a workflow perspective, insurance/payment information is typically verified with the patient in person once they arrive, so the majority of use cases won't need or more importantly trust insurance information were it to be sent by a scheduling system.
In International Patient Summary (IPS), how is it expected to uniquely identify a cross-border Patient?
To elaborate, IATA has a way to track all passengers across the globe. How can the healthcare systems do that?
I'm unable to figure this from hl7 documentation and implementation guides. Any help is appreciated.
That's a good question. There certainly isn't anything like a "global MPI" that's available, of course, and I think your question fairly points out that we haven't explicitly provided a solution for this in the IPS and our other HL7 specifications. For "international" use in the patient summary and specifically for supporting cross (national) border patient care, I don't think that we can give an absolutely definitive answer, but I think that there are some reasonable ways that we should be able to deal with this issue. I'm thinking of two in particular at the moment. The first is that in cases where there is dedicated organization and infrastructure (I'm thinking of something like the European cross-border services) then it may well be possible to provide some type of MPI service(s) that can establish and verify identity across the jurisdictional boundaries (and I'm not saying that for sure this actually exists in Europe or anywhere else, but just that it may be possible to do). The second, which I expect will turn out to be the more common and useful case overall, is that the patient is the ultimate owner of his or her data, so if the patient transports and provides the data directly to the receiving clinician (e.g., via their mobile device) then that should be more than sufficient to establish the identity. In that case the provenance and reliability of the data may still need to be considered, but that is a different question. Hopefully that may help a little! It is something that I agree we probably will need to address further in future versions of the IPS.
Rob
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
There are any number of situations in the standard day where priority conflicts exist for projects. Management wants maximum productivity from employees. Marketing wants maximum salability and fast turnaround. Ownership wants maximum profit. Customers want usability and low cost. Regardless of the origin of the demands, time and money are always the limiting factor in business.
Sometimes project elements have intrinsic or goodwill benefits for which there is not a hard, fast way to measure with monetary means (e.g. arguments for an attractive UI appeal vs. functional but plain). Other elements of software may have a method of providing “mental breaks” or motivating “cool factor” for developers that can get them back on track on other bigger, complex issues. While they may sidetrack the project short term they may have greater results long term through improved job satisfaction, etc. Continued training is a must, but working it in can setup back progress.
What are your suggestions for setting priorities? How do you evaluate requests/demands on your projects?
What are your suggestions for communicating and passing those on to your team in a way that they stay focused?
In brief, this is exactly why a PM cannot be replaced by a piece of software or methodology. Finding trade-offs between different constraints and matching them to opportunities or team abilities constitutes design and projects are designed in a way similar to software that comes on the other end. The scope and quality requirements will differ depending on the PM personality, knowledge, experience, influence, ability to negotiate and convey his or her vision especially in the software development world where few regulations or hard and fast rules exist. Moreover, project scoping is as much political as rational exercise.
That’s why project plan is an intellectual artefact reflecting individual perspective and project conceptual integrity always hangs on the shoulders of a few key individuals.
Usual inputs and tools used in the scoping process apart from specific requirements are:
Cost and benefits analysis and various financial measures indicating how profitable or prudent specific requirements are.
Organisational strategy what exists exactly for the purpose of showing direction and giving focus to the efforts.
Various regulations. Their role in software is a somewhat less prominent than in lets say construction. However, financial, entertainment, safety critical software are all subject to regulations.
Industry guidelines
Company Principles (Don’t be evil, Treating Customers Fairly etc)
Human factors
Environmental factors.
Even department with the same name within different companies would usually have different amount of power to influence project requirements. This depends on organisational structure and PM needs to be aware of and understand such power configuration really well. For instance, some companies would have a very influential marketing and sales, in others finance would be mostly in charge of the direction. Political requirements can be dissected using a three-dimensional scale of
Legitimacy — indicating whether the claim is valid and claimant actually has a lawful interest in asking for something to get done.
Power — whether claimant has the authority and muscle to have the things done their way.
Urgency — indicating if the claimant actually has the need or attributes importance to their claim.
If would be very difficult to ignore requirements that have all three: legitimacy, power and urgency. However when looking at the repercussions of this division, most interesting are scenarios where one or two of the elements are missing:
Combination of urgency and power without the legitimacy results in some really bad heavily political requirements.
Urgency and legitimacy that lacks power will be looking at making a union or bringing a powerful player on their side to make sure the requirements are heard and acted upon. It might be better to make a deal before hand, since it’s likely to be on much more favourable terms.
Power and legitimacy are unlikely to pursue specific requirements until there is urgency. A PM has to be clever about deciding whether these requirements can be safely ignored or assigned a lower priority.
One mechanism (which has similarities to a mechanism described by Joel as being used at Fog Creek) is essentially an auction.
Start by getting everyone who should have a say together. This is likely to be one or two representatives from each of sales, development, support, marketing and so on.
Each of these representatives or teams is given a "budget" according to their say. The way the budget is divided up is unlikely to be even - Sales should probably have a far larger say as they represent the users, or the prospect of more money - but that's up to you. The only thing I'd suggest is that no-one team should have 50% or more of the budget.
Get all the possible changes in the next release on the table and describe them, their benefits and how long they'll take to develop so that everyone understands them. They should be broken down into similar size chunks as far as possible and no one chunk should take up 50% or more of the time available in the next release.
Now people get to spend their budget. Each team / individual divides their money up between the things they want to do. You can spend all of it on one thing or divide it between many.
Once that's done you work out what fits into the release, starting with the thing with the total most money against it, going down until you run out of time in the release.
You might then want to allow them to adjust their "bids" and repeat but generally you want no more than three rounds.
Why does this work?
Most importantly for me it taps into the knowledge people have about what's important and allows them to make choices based on that.
If the developers and / or support know that, say, refactoring the database is key to them, they can spend their whole budget on that (note: this is why no-one should have 50% or more of the budget and no single change should be more than 50% of the release - if you breach those then individual team's ability to say "this is really critical" falls away because they don't have the clout to make them happen even if they sacrifice everything else).
What you're not doing is forcing them to quantify the benefit in ways that don't really make sense to them, they just get to say "we know this is important and we back this up by saying to us it's more important than anything else and we'll sacrifice everything else (or a bunch of other things) to do it".
Similarly if sales absolutely must have that holographic interface they can do so but they will have to make sacrifices (in the form of having less money to bid for other things they believe will drive sales) to get it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As we are a small company, I work as both a project manager and developer. The specifications I create for clients contain a number of elements used to describe and define the project, including user stories alongside any other elements I feel need to be included to define the project (e.g. wireframes, userflows, sitemaps etc.) to the client.
If a functional specification “describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features.“. Then does anyone see any problem with using User Stories to define a functional specification for a website? Does anyone actually do functional specifications in this way?
Really I am trying to up my game a little, and wondering if this would approach would work for larger clients who perhaps have more stringent ideas on what a functional specification should contain, whereby a formal approach may be required. Definitely at the moment our clients respond well to our method of producing documentation.
I am interested in hearing what people who do project management professionally think about this.
I'm at odds with what a couple of other people have said.
First up the bit I agree with - stories are a great way of stating functional requirements. For my money they're one of the best ways of actually communicating requirements in a way end users will really take in. I've seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements - covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they're better covered in a way that crosses all stories.
In terms of whether it's suitable for large companies this is where I disagree. In my experience (and I've done projects for Shell, American Express, a couple of multi-national banks and others) they're often no more formal than smaller companies so they'll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it's the size of the project, not the size of the company that matters when you're determining how you document requirements.
For me the best requirements documentation is documentation that's suited to it's audience, and for me user stories hit the nail on the head most of the time - they're short enough and clear enough that when they sign them off they mean something because they've read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven't really read it), but good enough for the developers to work from too.
Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.
Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.
I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.
What you're describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.
An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.
We also work in small teams (sometimes one or two developers) and believe the above is all that's required in this instance.
Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I am a reasonably experienced C# developer (about 5 year experience) that has recently been put in charge of my first development team as technical lead (varying between 3-5 other developers). Over the last 4 months in this role, one dilemma that keeps arising is trying to find the right degree of sharing awareness of the communication that goes on between the project manager, account manager, clients, designers, CEO and myself (especially via emails).
On the one hand, I know the more awareness each developer has of the overall direction of the project, the better they can understand the scope that their particular functionality has in the big picture.
However on the other hand, a lot of my time seems to be lost in the sea of emails between all the different stakeholders and managers, so I like to think that isolating the developers to just "what they need to do their current bit of work" will keep them free from interruptions.
I have considered just BCCing all the developers so they can filter these emails and essentially "opt in" to all the emails, but I'm concerned that some of the developers will just see this as extra noise to deal with. It may open the door to "too many cooks" if all the developers want to contribute to too many discussions. Yet on the other hand, other opinions can help me reach better decisions (i.e. House MD style).
Phew... so much to consider. Anyone have some wise guidance in this area?
Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
EDIT:
On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
Important info comes in (depending on urgency this can wait up to a week)
Developers are in the office, preferably for other reasons (developer-to-developer meetings)
Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
Customer reported bug via e-mail
There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.